A Fake Microsoft Quarantine Notice Rode a Hijacked Business Thread Through Amazon SES

Five messages are being held for you. Review them within 24 hours by going to the Quarantine page in the Security Center below.

That was the pitch. A pixel-perfect Microsoft logo, a green "Release Messages" button, and a ticking clock. The whole thing sat on top of a real, ongoing, multi-party business email thread written in Hebrew, complete with signatures, phone numbers, and reply chains referencing a Kemper insurance matter. If you were scanning your inbox on a Monday afternoon, you might have clicked it. A supply chain operations manager at a metals manufacturing firm nearly did.

The attack, observed on April 6, 2026, represents a growing class of threats that combine thread hijacking, brand impersonation, and authenticated delivery infrastructure to bypass every traditional email security check. SPF passed. DKIM passed. DMARC passed. The email was not spoofed in any conventional sense. It was sent through legitimate infrastructure with malicious intent.

The Anatomy of a Hijacked Thread

The attacker did not start from scratch. The email body contained a genuine multi-party business conversation between insurance professionals discussing EPDM roofing claims, contractor coordination, and Kemper policy details. The thread included real names, direct phone numbers, company signatures (referencing a building products distributor in West Seneca, NY), and a natural conversational cadence spanning multiple replies.

This thread was almost certainly harvested from a compromised mailbox. The attacker then injected a fake Microsoft quarantine notification as an HTML overlay at the top of the message. The juxtaposition was deliberate: the legitimate thread body provided social proof and context, while the injected banner provided the call to action.

The "Release Messages" button pointed to secure[.]bakrubber[.]com, a domain whose actual content (a gaming blog called "THE GAMER'S GUILD") had zero connection to Microsoft, quarantine services, or email security. A second link variant wrapped through INKY and Cisco Secure Web proxies used a heavily tokenized URL path, suggesting the attacker anticipated enterprise URL rewriting and planned for multiple redirect layers.

Authenticated Delivery, Malicious Content

The sending infrastructure tells its own story. The email originated from Amazon SES endpoints in the eu-west-3 region (Paris), egressing through e246-79[.]smtp-out[.]eu-west-3[.]amazonses[.]com at IP 23[.]251[.]246[.]79. The sender address, a 64-character randomized token at almko[.]com, authenticated cleanly against the domain's SPF, DKIM, and DMARC records.

This is not a case of header spoofing or failed authentication. The attacker either compromised an existing Amazon SES configuration tied to almko[.]com or provisioned one using a domain they controlled. Either way, the email passed every authentication gate that most secure email gateways rely on as primary trust signals.

The X-Forefront-Antispam-Report header tagged the message language as Hebrew (LANG:he) and assigned a spam confidence level of just 1 (on a scale where 5+ indicates spam). Microsoft's native filters categorized it as CAT:NONE, meaning no threat category was assigned. The message landed in the inbox.

The PDF: Small, Encrypted, and Malicious

Attached to the email was SMK78345.pdf, a 1,993-byte file. That file size alone is a red flag. Legitimate PDFs with meaningful content rarely weigh under 2 KB. The file was password-protected and contained an AuthEvent on DocOpen, a trigger mechanism that executes actions the moment a user opens the document.

Password protection serves dual purposes for the attacker. It prevents automated sandbox analysis from extracting the payload, and it creates a social engineering hook ("use the password in the email to unlock the document"). The encrypted content could not be extracted through static analysis, but the DocOpen trigger and upstream verdict confirmed malicious behavior.

This maps to MITRE ATT&CK T1566.001 (Spearphishing Attachment) and T1566.002 (Spearphishing Link), with the thread hijacking component aligning to T1598.003 (Spearphishing for Information via Service).

See Your Risk: Calculate how many threats your SEG is missing

Why Authentication Was Not Enough

The 2024 Verizon Data Breach Investigations Report found that phishing remains the top initial access vector in confirmed breaches, and the FBI IC3 2024 report documented $2.77 billion in BEC losses alone. Attacks like this one explain why: they do not fail authentication. They weaponize it.

DMARC, SPF, and DKIM verify that a message came from authorized infrastructure for a given domain. They say nothing about whether the content is malicious. When attackers abuse cloud sending services (Amazon SES, SendGrid, Mailgun), they inherit the domain's full authentication posture. The Microsoft Digital Defense Report 2024 acknowledged this gap, noting that threat actors increasingly leverage legitimate cloud infrastructure to deliver phishing payloads that pass technical validation.

This is precisely where adaptive AI email security changes the equation. Rather than relying solely on sender reputation and authentication signals, behavioral analysis examines the relationship between message components. A Microsoft quarantine banner does not belong inside a Hebrew-language insurance thread. A 2 KB encrypted PDF with a DocOpen trigger does not match the context of a roofing claim discussion. A first-time sender using a 64-character randomized mailbox name does not align with legitimate notification services. Each signal individually might pass a threshold check. Together, they form a pattern that only content-aware, context-sensitive detection can catch.

In this case, community intelligence from thousands of organizations reporting similar Microsoft quarantine impersonation patterns provided additional confidence. The email was automatically quarantined within seconds of delivery, before the recipient could interact with either the link or the attachment.

Defending Against Authenticated Thread Hijacking

For security teams facing this class of attack, the defensive priorities are clear:

1. Treat authentication as necessary, not sufficient. SPF/DKIM/DMARC passing does not mean an email is safe. Layer behavioral analysis on top of authentication checks.
2. Flag first-time external senders aggressively. Randomized, high-entropy sender addresses from unfamiliar domains warrant elevated scrutiny, regardless of authentication status.
3. Block password-protected attachments from external senders by default. Encryption is an evasion technique more often than a privacy measure when it arrives unsolicited from unknown senders.
4. Monitor for thread hijacking indicators. Language mismatches between the message body and injected overlays, HTML injection patterns, and CID-referenced images that do not match the sender domain are strong signals.
5. Submit attachment hashes to threat intelligence feeds. The MD5 hash 04166dd9a0ccee4b4355c7697feb92e9 should be blocked at the gateway and shared with your security vendor ecosystem.

The attacker behind this campaign understood that trust is the real vulnerability. They borrowed a legitimate conversation, dressed it in Microsoft branding, delivered it through authenticated infrastructure, and attached a weaponized PDF for good measure. Every traditional control said "this is fine." The content said otherwise.