Postmortem: The BEC Attack DMARC Couldn't Stop

The alert landed in the tier-1 queue like a hundred others that day. A user reported a potential phishing email. The junior analyst did a first pass and almost closed it: SPF passed, DKIM passed, DMARC passed with flying colors. The sender was a known vendor. Looked like a false positive.

But it wasn't. Two hours later, the finance department confirmed they had processed a six-figure wire transfer to a new bank account based on that very email. The authentication checks were perfect, but the money was gone. Our post-incident forensics revealed that the entire attack hinged on a single piece of data everyone had, but nobody was looking at: the IP address in the `Received` header.

This is the story of a sophisticated Business Email Compromise (BEC) that succeeded not by breaking email authentication, but by neatly fitting within its rules. It’s a critical lesson for any security team that thinks a DMARC `pass` verdict means an email is safe.

A Flawless Phish: How an Invoice Scam Passed Every Check

The attack vector was brutally simple. An attacker gained access to the email account of an accounts payable clerk at a long-term partner company. Credentials could have been phished, bought, or lifted from a previous breach—it hardly matters. The point is, the attacker wasn't spoofing the sender; they *were* the sender, at least from the mail server's perspective.

From inside this compromised account, the attacker found an existing email thread about an outstanding invoice. They replied to the thread, claiming their company was updating its banking relationships and provided new wire instructions for the payment. The language was correct, the invoice number was real, and the sender's email address was legitimate. For the target in our finance department, it was a routine request.

Why the Authentication Stack Didn't Flinch

When our mail gateway received the email, it ran the standard playbook. First, SPF, defined in RFC 7208. It checked the connecting IP address against the vendor's SPF record. Since the email was sent from the vendor's actual Microsoft 365 tenant, the IP was in Microsoft's published ranges. `SPF=pass`.

Next, DKIM, per RFC 6376. The vendor's outbound mail server cryptographically signed the message, and our server validated that signature. The message body hadn't been tampered with in transit. `DKIM=pass`.

Finally, DMARC, as outlined in RFC 7489. This protocol’s entire job is to ensure that the domain in the visible `From:` header aligns with the domain validated by either SPF or DKIM. Since both passed and the domains were the same, the result was an unequivocal `DMARC=pass`. According to the Big Three of email authentication, this email was perfectly legitimate. The system worked as designed, and that was precisely the problem.

Unraveling the `Received` Header Trail

In any incident investigation, the `Authentication-Results` header gives you verdicts, but the `Received` headers give you the travel history. Each Mail Transfer Agent (MTA) that handles the message prepends a new `Received` block, creating a chronological audit log you read from bottom to top. It's the digital equivalent of postmarks on a letter.

Most analysts stop reading once they see the handoff from the sender's external MTA to their own. But the real story is often in the first few hops—the ones that show how the message got *to* the sender's mail server in the first place. This is where we found the smoking gun.

Received: from CH0P221CA0033.NAMP221.PROD.OUTLOOK.COM (2603:10b6:806:11a::20) by SN4P221MB0565.NAMP221.PROD.OUTLOOK.COM (2603:10b6:805:175::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7394.31; Tue, 19 Mar 2024 15:02:12 +0000
Received: from [41.66.198.110] (41.66.198.110) by CH0P221CA0033.NAMP221.PROD.OUTLOOK.COM (2603:10b6:806:11a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7394.31 via Frontend Transport; Tue, 19 Mar 2024 15:02:11 +0000 — Excerpt from sanitized message headers

See it? That second `Received` header shows the Microsoft 365 infrastructure (`CH0P221CA0033...`) receiving the message from an external client IP: `41.66.198.110`. That isn't another server. That's the IP of the authenticated user's device. This is the origin point of the attack.

DMARC's Blind Spot: Authentication vs. Authorization

It's easy to blame DMARC here, but that misses the point. DMARC is an authentication protocol, not an authorization engine. It does one job very well: it confirms that the sender is permitted to use the domain they are claiming. It protects against domain spoofing, where an attacker fakes the `From:` address.

In an Account Takeover (ATO) scenario like this, there is no spoofing. The attacker is using the legitimate account, the legitimate mail servers, and the legitimate authentication mechanisms. DMARC sees a message sent by Microsoft's servers, signed with a valid DKIM signature for the vendor's domain, and correctly concludes that the message is authentic. It has no visibility into the *intent* behind the message or the *context* of the user sending it.

Alignment Is Not Intent

DMARC's concept of 'alignment' is purely technical. Does the `d=` field in the DKIM signature match the `From:` header? Does the `MAIL FROM` envelope domain used for the SPF check match the `From:` header? If yes, you get alignment. DMARC cannot tell you if the person who authenticated to the server to send that message should have been doing so.

Think of it like a building's security badge. The guard at the front door scans your badge. The system confirms it's a valid badge and that it belongs to an employee. The door unlocks. The system did its job. It couldn't know that your badge was stolen and you're here to steal laptops. The check was for authentication (is this a valid badge?), not authorization (is this person, at this time, from this location, supposed to be doing this?).

Geolocation, Geopolitics, and a Nigerian IP

That connecting IP, `41.66.198.110`, was the key. A simple IP geolocation lookup placed it in Lagos, Nigeria. The vendor company is headquartered in Columbus, Ohio. The employee whose account was compromised had never left the state, according to HR records and their own login history.

This isn't about blocking an entire country. That's a crude, ineffective strategy. This is about anomaly detection. An accounts payable clerk from Ohio has sent your company emails every week for five years from IPs belonging to a corporate office or a US-based residential ISP. Suddenly, an email arrives from a residential ISP in Nigeria. That is a massive deviation from the established baseline. It's a signal strong enough to warrant holding the message and raising an alert.

Going Deeper with ASN Data

Beyond the country, the Autonomous System Number (ASN) provided more context. The IP belongs to AS37129, registered to Spectranet, a Nigerian ISP primarily serving residential and small business customers. It does not belong to a corporate VPN provider, a known data center, or a cloud provider's IP range.

So, the evidence mounts. We have a financial request coming from a known business partner, but the authenticated session originated from a consumer-grade ISP on another continent. This combination of legitimate authentication and anomalous origin is a hallmark of modern, sophisticated BEC. The attacker is counting on your security stack to only check the former and ignore the latter.

Hardening Your Defenses: Layering In Situational Awareness

Relying on SPF, DKIM, and DMARC alone is building a wall and leaving the gate wide open for anyone with a stolen key. To catch these attacks, your email security analysis must evolve to incorporate situational awareness. The `Received` header is the place to start.

Building a Dynamic IP/ASN Profile

You cannot do this manually for every email. It must be automated. Your mail security platform should be profiling your key partners and vendors. What IPs, subnets, and ASNs do their emails normally originate from? This isn't about using the SPF record as a static allow list; it's about observing which parts of that record are actually used.

When a new email arrives, especially one containing high-risk keywords like 'invoice', 'wire transfer', or 'updated banking', its originating client IP should be checked against this historical baseline. A severe deviation—a new country, a new ASN type (e.g., from corporate to residential), or an IP on a known threat feed—should dramatically increase the message's risk score, even if DMARC passes.

Automating the Anomaly Check

This is where modern email security platforms show their value. They can parse the headers, perform the IP geolocation and ASN lookups, compare them against historical data for that specific sender, and factor it into the filtering decision in milliseconds. An email from `vendor.com` with a DMARC pass might have a base score of 0. Add in the fact it came from an anomalous ASN in a new country, and that score might jump to 85, triggering quarantine and an immediate SOC alert.

Combine this with other signals. Is this the first time this sender has emailed about a payment change? Does the message create a sense of urgency? These behavioral cues, when layered with technical data like IP geolocation, create a much more resilient defense against email fraud that bypasses legacy checks.

The takeaway

Authentication protocols like DMARC are foundational. You absolutely must have them. But they are not, and were never intended to be, a complete defense against threats from compromised accounts. They verify the 'what' (the domain) but are blind to the 'where' (the geolocation) and 'who' (the specific user context).

This incident was preventable. The data was right there in the email headers. The failure was one of analysis, not of authentication standards. To stop this class of attack, you have to look beyond the pass/fail verdicts and start analyzing the context around the message. Authentication tells you if the keys fit the lock; anomaly detection tells you if the person holding the keys belongs there. Platforms like MailSleuth.AI help bridge that gap by automatically correlating header data, sender history, and IP risk signals to spot the attacks your DMARC policy will miss.