Best of the Worst: Five Attacks That Cleared Authentication and Landed Anyway

Quick context for new readers. Every week, I pull a handful of real phishing attacks we caught, sit with them for a while, and look for the thread connecting them. The thread this week is authentication.

Specifically, what happens when the standard email auth stack (SPF, DKIM, DMARC, ARC, compauth) says everything looks fine and the message is still hostile.

The five attacks below all cleared at least one of those checks. Most cleared all of them. One was sent from a purpose-built Microsoft 365 tenant with full DMARC alignment. One came through Amazon SES with a valid DKIM signature from amazon.de. One was a real Gmail account. One was a compromised UK school email whose DKIM-signed body got rewritten in transit. One was a Teams notification spoof from a domain with valid SPF and DKIM at the sending hop.

All five passed authentication. All five were hostile.

This is the part of the threat picture that the SPF-DKIM-DMARC story does not cover. Auth pass is now the price of entry for any attacker who can spend twenty dollars on a domain and an afternoon on a Microsoft 365 tenant. The bar to clear the auth stack is the same bar a small business owner clears when she sets up her first marketing mailbox.

Four Attacks. One Clean Auth Stack.

Authentication confirms the wire was clean. It says nothing about display names, Reply-To headers, body modifications between hops, or the kind of payload sitting in the message. Each of the four attacks below cleared the auth stack and landed on a different one of those blind spots.

In The Teams Invite That Came From the Wrong Domain: Display-Name Impersonation With All-Legitimate Links, the attacker provisioned a Microsoft 365 tenant at usafederal[.]us and built a pixel-accurate Microsoft Teams "you have been added to a team" notification. SPF and DKIM passed at the M365 sending hop, because M365 was actually sending. Every URL pointed at a real Microsoft domain (aka.ms, teams.microsoft.com). The trick was in the display name. It matched an internal employee at the recipient's organization exactly. Display name is not authenticated. The whole point was to establish trust on a domain the recipient had never heard from before, so the next message in the sequence would land on a warmer rail.

In A School Email That Passed Authentication Twice, Then Changed: Post-Signing Content Injection via Compromised .sch.uk Domain, the attacker compromised a UK secondary school's mailbox and let the school's real DKIM key sign the original NHS-themed note. Then a finance-themed "Go to file" credential-harvest banner pointing at manage.kmail-lists[.]com got injected into the body somewhere downstream of signing. The body hash on arrival no longer matched the signature. The SEG saw the upstream DKIM pass, trusted the chain, and never re-verified. Two incompatible content blocks landed in one message.

In Amazon Said You Owe $879. The Phone Number Was the Payload., Amazon itself carried the message. A real Amazon SES account, with valid DKIM signatures for both amazon.de and amazonses.com, with DMARC aligned, and every link pointing at Amazon's own gp/r.html redirect endpoints. The body claimed a pending charge of $879 (USD) from the German Amazon marketplace, with no order ID, no items, and a U.S. phone number (865-292-7594) as the only call to action. The currency mismatch was the visible tell. The phone number was the payload, and a phone number is not something a URL scanner can evaluate.

In The Reply-To Was One Letter Off: How a Typosquat Domain Turned a Gmail BEC Into a Payment Diversion, the attacker sent from a real Gmail account impersonating a credit manager at a major steel distributor, with Google's SPF, DKIM, and DMARC all aligned. The signature in the body linked to the real vendor website. Reply-To pointed at mill-steels[.]com (extra "s") instead of the real millsteel[.]com. Reply-To is not covered by any authentication protocol. Authentication did everything it was built to do. The reply diverted to a typosquat the gateway never evaluated, because the gateway only checks From and Return-Path.

What the four share is that nothing in the auth stack failed. Every alignment check returned what it was built to return. The signal that something was wrong came from outside the envelope. From the display name, from the Reply-To, from the body hash on a re-verification the SEG did not run, from the relationship between the currency and the marketplace.

Featured Attack: The Tenant Built for One Click

A consultancy that did not exist sent an authenticated email to a cybersecurity firm. The "consultancy" was Nordic AI Growth, contactable at nordicaigrowth[.]pro. The fictitious sender was Oliver Henriksen. The domain was registered specifically for this attack. The attacker stood up a full Microsoft 365 tenant on the domain, provisioned a mail server, configured a DKIM key, published an SPF record, and set DMARC to enforce. They then sent a four-sentence email referencing a fabricated previous conversation, with an In-Reply-To header forged to make it look like a continuation of an existing thread, carrying a single Google Docs link.

Read the full incident breakdown here.

SPF passed. DKIM passed. DMARC passed. ARC vouched for the path. Microsoft's compauth scored the message at 100 with reason=100 (full alignment). The Google Docs URL scanned clean, because the malicious content lives one click past the scanner inside the document. The Themis Adaptive AI flagged the message anyway on a different signal entirely. The geographic routing in the headers did not line up. The X-ClientProxiedBy field showed a U.S. proxy. The mailbox server was MA0P287MB2895.INDP287, an India-region tenant. The combination of a first-time .pro sender, a brand-new tenant in a region inconsistent with the proxy path, and a fabricated thread header on a single-link payload added up to a behavior signature that authentication alone could not produce.

The headers on this one are doing a lot of work. The attacker stood up a Microsoft tenant. Provisioned a mail server. Configured DKIM. Registered SPF. Set DMARC. Forged an In-Reply-To. Every architectural piece of "looking like a real sender" was assembled before the first message went out. The payload was four sentences and a Google Docs link. The cost of mounting an attack with full authentication coverage is now low enough that an attacker will spend an afternoon on a single credential phish. That is the floor.

The single click would have taken a recipient to a Google Docs document hosted on Google infrastructure with a valid Google session, which is the kind of trust transfer that any URL scanner is structurally incapable of evaluating. The whole architecture is built around making the click look ordinary. The headers say a legitimate consultancy is sending you a follow-up. The body says a legitimate consultancy is sending you a follow-up. The link says Google Docs. The first signal that something is wrong is the one that comes from a behavioral model looking at the relationship between the sender, the domain, the routing, and the intent. Our Adaptive AI caught this one. Three commercial gateways did not.

See Your Risk: Find out how many threats like this your current security stack is missing

What Defenders Should Take From This Week

A few concrete takeaways:

1. Auth pass is the floor, not the verdict. SPF, DKIM, and DMARC alignment confirms the wire was clean. None of those checks evaluate sender intent. Build detection that treats auth pass as one signal among many, alongside sender novelty, tenant age, geographic routing consistency, and behavioral baselines for the relationship between sender and recipient.
2. Re-verify body hashes downstream of relays. The school-domain case landed because the SEG trusted upstream DKIM and never independently checked the body hash. If your stack inherits an upstream auth verdict without re-evaluating the body, post-signing content injection in transit is invisible to you. Verify at every meaningful hop.
3. Reply-To belongs in detection logic. Authentication protocols cover From and Return-Path. They do not cover Reply-To. An attacker who sends from a clean Gmail and sets Reply-To to a typosquat will pass every header check and still divert the conversation. Pair sender domain comparison with Reply-To domain comparison. Flag mismatches as a separate signal.
4. Display-name impersonation is asymmetric. Free-mail and external M365 tenants can spoof internal employee names without any DKIM penalty, because display name is not authenticated. If your detection is keyed only on header alignment, it cannot see the impersonation. Pin display-name detection to known-good sender domain pairs.
5. "No malicious URLs or attachments" is not a verdict. Phone numbers, fabricated thread headers, empty bodies pointing at clean attachments, and single SaaS-hosted documents are all functional payloads now. Detection has to evaluate what the message is asking the recipient to do, not only what artifacts the message contains.

See you next time

Attack of the Day publishes daily in the Threat Intelligence section. Next roundup: another pattern from the next seven posts. If the pattern is "authentication coverage got cheaper again," I will say so.