This Message Was Sent by Microsoft - Turning First Party Services into our Phishing Platform

The talk starts from last year's research, when custom CSS on the Microsoft sign-in page let a phishing login look genuine. Microsoft has since blocked those CSS techniques. This year the speaker asked whether an attacker could move earlier in the chain and have Microsoft's own mail systems deliver the phishing message.

The speaker tested several built-in notification features. Azure DevOps work items let an attacker control the subject and much of the body, though default links and boilerplate had to be hidden with injected CSS. Power BI report subscriptions and the SharePoint share-by-email API gave fuller control over content. Weak recipient validation allowed external addresses, and removing licenses let the sender display name match addresses such as billing or HR on Microsoft domains. The most effective case was Entra ID adaptive cards, which render interactive forms inside the mail client. Registering an originator and getting a global provider approved let the speaker collect passwords in the message itself and then relay an MFA prompt to the victim.

Microsoft's responses were mixed. The Azure DevOps report was ruled out of bounty scope but still fixed, and the speaker reports that the global provider was approved within two days. The main takeaway is that a message with valid SPF, DKIM and DMARC from a Microsoft address does not prove it came from Microsoft's customer or from the sender it claims. Defenders should treat SaaS notification abuse as a real phishing vector and review how external recipients and interactive cards are handled in their tenants.