Don't send customer-generated content

"The bad actor created a throwaway domain, eilingrecepientvi.review, and set up an email account there at an often abused german hosting provider. Then he signed up for a - free, presumably - Zoom account using that email address. He told Zoom that his name was ", Thank you for purchasing Zoom Workspace for $969.85 via PayPal. If you didn't made this order, Call PayPal [phone], "."

"Because it was sent via Microsoft, with an onmicrosoft.com return-path, SPF passes. Because the content of the body of the email is unchanged from when Zoom originally sent it, the DKIM signature Zoom applied to it still passes. So it's fully authenticated when the victim receives it. The only recipient visible sign that it's not legitimate is that their email address isn't in the To: field."

"SPF is valid. It passes DKIM for zoom.us. It has enforcing (p=reject) DMARC for zoom.us, which passes. My mail setup doesn't display BIMI, but there's a valid BIMI record for zoom.us and a mailbox provider might display the nice Zoom logo and checkmark next to it. (They also might not, given the number of technical red flags under the covers, but I wouldn't blame them if they did.) Zoom are vouching for the legitimacy of this email, in every way that matters."

SPF, DKIM, and DMARC for zoom.us validate the messages and a BIMI record exists that may show Zoom branding. An attacker created a throwaway domain (eilingrecepientvi.review) and a mailbox at an abused German hosting provider, then registered a Zoom account with that address. The attacker placed the phishing text into the Zoom account fields, triggering Zoom to send a DKIM-signed message. The attacker used a Microsoft onmicrosoft.com account to forward that signed message unchanged to victims. Because the DKIM signature and SPF alignment remained intact, recipient systems authenticated the mail despite it being a phishing campaign. The only visible inconsistency was the absence of the victims' addresses in the To: field.

Read at Wordtothewise