Table of Contents
When a Government Ministry's Mailbox Sends a Benefit Scam
A project director at a large US engineering and infrastructure consulting firm received an email that, on paper, had nothing wrong with it. SPF passed. DMARC passed with the header From aligned. Microsoft's composite authentication returned a clean reason 100. The message had genuinely traveled through a real, WHOIS-verified government mail relay. By every signal a gateway typically leans on, this was legitimate mail from a legitimate sender.
It was an invitation to apply for a "Texas State Benefit program," complete with a single button that promised to "Process your application."
The problem was the return address. The email came from a mailbox belonging to a Mexican federal government ministry. A foreign land-and-urban-development ministry has no plausible reason to contact a US engineering firm about a US state benefit program, and it certainly has no reason to route that firm's employees to a third-party application form. The authentication was flawless. The premise was absurd. That gap is the entire story.
A real mailbox, not a spoofed one
This was not a spoof. The attacker did not forge the ministry's domain from unrelated infrastructure. They took over an actual, active mailbox inside the ministry and sent from it. That distinction matters enormously, because it is the reason every authentication check passed.
When a domain is spoofed, SPF and DMARC are designed to catch the mismatch between the claimed sender and the infrastructure delivering the mail. When the real account is compromised, there is no mismatch to catch. The mail leaves the ministry's own authorized servers, carries its own DKIM keys, and aligns perfectly under its own DMARC policy. Authentication is not lying. It is faithfully confirming that the message came from where it says it came from. The account holder is an innocent victim here, their mailbox weaponized without their knowledge.
The 2024 Verizon Data Breach Investigations Report puts stolen credentials at the top of the list of initial actions, present in 38 percent of breaches, and notes the human element factors into 68 percent overall. Once an attacker holds working credentials to a reputable mailbox, they inherit that mailbox's entire authentication and reputation posture for free.
The one cryptographic tell
There was a single technical anomaly buried in the headers, and it was subtle. The message carried two DKIM signatures rather than one. One of them verified cleanly. The second failed body-hash verification.
A DKIM body hash is a cryptographic fingerprint of the message content taken at signing time. If the body that arrives no longer produces the same hash, the content changed after that signature was applied. The most likely explanation here is benign in origin: the message transited a legacy mail-security relay that modified the body slightly, for example by appending a footer or rewriting a link, after the first signature was in place. That is ordinary gateway behavior, not proof of malice by itself.
But it is a reminder that a partial DKIM failure is a signal worth reading, not discarding. In an environment tuned to treat any DKIM pass as sufficient, a split result like this vanishes into the noise. The message still cleared DMARC, so most pipelines never surfaced the discrepancy at all.
No malware, just a form
There was no attachment. There was no credential-harvest page dressed up as a Microsoft login. The entire payload was one link to a rented form-builder page, the kind of legitimate no-code service anyone can spin up in minutes. The lure asked the recipient to enter application and benefit details, which is a clean, quiet way to harvest personal information without ever tripping a malware sandbox or a URL reputation engine.
This is the modern shape of a lot of phishing. MITRE ATT&CK catalogs it as Spearphishing Link, delivered here on the back of a compromised account. There is no attacker-owned domain to block, no signature to write, no attachment to detonate. The infrastructure is a hijacked government mailbox plus a form on a service used by millions of legitimate businesses. Blocklists and gateway reputation have almost nothing to grab onto.
Why authentication was never going to catch this
It is worth being precise about what email authentication promises. SPF, DKIM, and DMARC answer one question: did this message really come from the domain it claims? They do not answer whether it is safe, whether the sender should be trusted for this conversation, or whether the content makes sense in context. A perfect authentication pass on a hijacked mailbox is not a bypass of the system. It is the system working exactly as designed, on an input it was never meant to judge.
That is precisely why gateways that equate an auth pass with a trust verdict keep letting these through. If you have never measured how many authenticated-but-malicious messages your current stack waves past, our email security gap calculator is a fast way to size the exposure. The uncomfortable answer for most organizations is that clean authentication is table stakes, not a filter.
What flagged it
Every cryptographic and reputation signal on this message was green. What was left was context, and context was enough.
Our Adaptive AI, Themis, does not read a clean authentication result as an end to the analysis. It weighs the relationship. This sender had never corresponded with the recipient's organization before, a first-time, rarely-seen sender arriving unannounced. It weighs the premise. A federal ministry from one country soliciting a benefit application in another country, aimed at an engineering firm with no connection to either program, is a content-context mismatch that no legitimate correspondence would produce. It weighs the ask. An unsolicited push toward an external data-collection form carries risk regardless of how the mail authenticated.
None of those signals live in a DKIM header. They live in the behavioral fingerprint of the conversation, and that is the layer a compromised, fully authenticated account cannot fake. The message was surfaced and contained before the project director filled out anyone's form.
Account takeover of a trusted third party is one of the hardest problems in email security precisely because it turns authentication into the attacker's ally. Stopping it means grading messages on behavior and relationship, not just on whether the envelope was signed. For teams working to close that gap, our business email compromise protection is built around exactly this class of authenticated-but-hostile mail.
Indicators of Compromise
| Indicator | Value (defanged) | Notes |
|---|---|---|
| Sending relay | mail1.bemta40.messagelabs[.]com | Legitimate hosted mail-security relay |
| Sender IP | 67.219.247[.]2 | SPF-authorized for the sending domain |
| Auth result | SPF pass, DMARC pass, compauth reason 100 | Fully authenticated from a real mailbox |
| DKIM anomaly | Two signatures: one pass, one body-hash fail | Content altered after signing, in transit |
| SCL | 5 | Suspicious content level, not blocked |
| Payload link | hxxps://admin.rebolt[.]app/form/[REDACTED-ID] | Rented form-builder page, "Process your application" |
| Lure theme | Fake cross-border "Texas State Benefit program" | External-form PII collection, no attachment |
MITRE ATT&CK mapping
| Technique | ID | Use in this attack |
|---|---|---|
| Phishing: Spearphishing Link | T1566.002 | Single external-form CTA as the payload |
| Compromise Accounts | T1586 | Genuine ministry mailbox hijacked to send |
For more on how the attack cycle begins and how to break it, see CISA's phishing guidance and the 2024 Verizon Data Breach Investigations Report.
See you next time
Authentication tells you where a message came from. It will never tell you whether the sender belongs in the conversation. When the mailbox is real, the signatures are valid, and the request still makes no sense, context is the last line that holds.
Related attacks
| Attack | What happened |
|---|---|
| The Webinar Invite That Came With an Apple Wallet Pass and a Three-Hop Redirect Chain | A Google Calendar invite for a fake AI webinar passed full authentication and carried an .ics file, an Apple Wallet .pkpass. |
| The Bank Statement You Had to Unlock With Your Birthday: PII-Gated PDF Evasion From Authenticated Infrastructure | A fully authenticated email from banking infrastructure delivered a password-protected PDF that required the recipient's mobile number and date of birth... |
| Every Authentication Check Passed. The Display Name Was the Weapon. | An attacker impersonated a known contact's display name from an authenticated business domain, embedding a Google Form as the data-collection vehicle. |
| The Fax Notification That Was Just a Pregnancy Test for Your Curiosity | A Gmail account sent a fax notification with a 24KB HTML attachment. |
| 136 Bytes Was All It Took: The SVG That Redirected to a Credential Harvest | A 136-byte SVG attachment used a JavaScript onload event to redirect the browser to a credential-harvesting page. |
Explore More Articles
Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.