Microsoft 365 AiTM Phishing: Why Passing DMARC Doesn't Mean You're Safe

A green auth check – and still phishing

SPF: Pass. DKIM: Pass. DMARC: Pass. For many IT admins, that combination means one thing: the email is legitimate. A recently observed attack chain targeting Microsoft 365 environments shows exactly why that assumption is dangerous.

The attackers use real, compromised GMX accounts as senders. Because those accounts are genuinely registered at GMX, all three authentication checks pass without issue. The receiving mail server sees a cleanly signed message from a legitimate domain – and lets it through.

How the attack chain works

The attack is technically deliberate and broken into several stages:

• Compromised sender account: Attackers take over real GMX mailboxes. The sending infrastructure is authentic – no spoofing, no look-alike domain tricks.
• Randomised display name per target: The visible sender name is customised individually for each victim. This makes rule-based detection significantly harder because there is no fixed pattern string to match.
• PDF invoice as lure: The attachment is a PDF invoice containing a link to an AiTM (Adversary-in-the-Middle) phishing page. That page harvests not just credentials but also session cookies – which allows multi-factor authentication to be bypassed entirely.
• Microsoft 365 as the target: The fake login pages mimic the Microsoft 365 portal. Once the session cookie is stolen, attackers take over the session directly without ever needing the password.

The result: account takeover despite MFA, despite DMARC pass, despite modern email security infrastructure.

The critical gap: what DMARC does – and what it doesn’t

DMARC was designed to prevent domain spoofing. It ensures that an email claiming to come from example.com was actually sent from example.com’s infrastructure. That is valuable – but it is a narrowly defined guarantee.

What DMARC does not check:

• Whether the sender account itself has been compromised
• Whether the display name matches the actual sender address
• Whether the email content is malicious
• Whether a link in the email points to a phishing page

In the attack described here, the sending domain is gmx.de or gmx.net – and the email genuinely originates from there. DMARC worked exactly as designed. The problem sits one layer deeper: in the compromised account itself.

Behavioural signals: the second line of defence

When technical authentication alone is not enough, you need additional detection layers. Behavioural signals are particularly relevant here:

Detect display-name anomalies: When the visible sender name does not match the actual sending address, or changes with every message, that is a strong warning signal. Modern email security gateways and SIEM systems can be configured to flag these patterns.

Unusual sender domain for the context: If an employee expects an invoice from a German supplier but the email arrives from a GMX account, that context mismatch should be evaluated independently of the auth result.

PDF attachments containing only a link: PDFs with no substantive content other than a URL are a classic phishing lure pattern. Sandbox analysis and URL rewriting help here.

Anomalies in DMARC aggregate reports: Even when an attack like this generates no DMARC failure, aggregate reports can help you spot unusual sending volumes from third-party domains – especially if your own domain is being abused in Reply-To fields.

What this means for your DMARC strategy

Setting DMARC to p=reject is correct and important. It prevents attackers from spoofing your own domain in outbound attacks. But it does not protect you from someone else’s domain being used to attack you.

The practical takeaways:

• DMARC pass is a necessary but not sufficient condition for trusting an email.
• User training needs to go beyond “look for the padlock.” Display names are trivially manipulable.
• Technical controls such as anti-phishing policies in Microsoft 365 Defender, specifically targeting impersonation attacks, are a sensible next step.
• MFA alone is not enough when AiTM attacks harvest session cookies. Phishing-resistant MFA methods like FIDO2/passkeys are significantly more robust here.

DMARC monitoring as an early-warning system

Even though this specific attack generates no DMARC failure, continuous DMARC monitoring remains essential. Here is why.

First, attackers iterate. A campaign that works with compromised accounts today may switch to subdomain spoofing or look-alike domains tomorrow – and that is when DMARC fires.

Second, aggregate reports show you which services are sending email on your behalf. Unknown sources in those reports are always worth investigating.

Third, a properly configured DMARC setup with p=reject and regular report review is the foundation on which every additional security layer depends.

Check right now whether your domain is correctly configured and whether you have full visibility over all your sending sources: Free domain check at DMARCPulse