How a Fake HR Email Laundered Itself Through Microsoft 365

The email looked like it came from inside the building. The display persona read as the company's own HR Workforce Team, the subject spoke to a new employee handbook, and a personalized attachment was already waiting with the recipient's name on it. The recipient, a project manager at a mid-size material-handling and logistics systems integrator, had every reason to open it.

The From address told a different story. It resolved to dekkenya[.]org, an unrelated .org domain with no connection to the employer, its HR team, or anything resembling a benefits portal. And the message had not originated from any corporate mail system. It was injected from a rented virtual private server in a hosting provider's rack, failed authentication at its true origin, and reached the inbox anyway. The trick was not that it defeated authentication. It was that it borrowed someone else's pass.

The Message That Failed SPF and Passed Anyway

Trace the path backward and the sleight of hand becomes clear. The message was first injected by a HostSailor VPS at 185[.]106[.]120[.]95 (hostname vps1173582[.]hostsailor[.]com), a host that dekkenya[.]org never authorized to send on its behalf. SPF evaluated against that true origin and failed, exactly as it should.

Then the message was relayed onward through a Microsoft 365 outbound protection node (protection.outlook.com) at 40.107.159.86. At that later hop, SPF was re-evaluated, this time against Microsoft's own outbound IP, and it passed. Same message, same forged sender, but a clean checkmark at the second checkpoint. DKIM was absent entirely, and DMARC returned bestguesspass, Microsoft's non-authoritative heuristic for domains that publish no policy of their own. A weak guess is not the same as alignment, but downstream filters and human readers rarely make that distinction.

This is authentication laundering. An unauthenticated message picks up a legitimate pass by being routed through a trusted platform's infrastructure, and the pass that matters to a casual reviewer is the last one, not the first. Sender Policy Framework only ever validates the server in front of it at each hop, never the human identity in the From field. When the final hop belongs to Microsoft, the result reads as trustworthy even though the origin was a spoofed injection from a commodity VPS. Outlook did surface a first-time-sender and external banner, the one honest signal in the exchange, and exactly the kind of cue a busy employee learns to click past.

The Payload Was an Email Inside an Email

The delivery vehicle was as evasive as the routing. Rather than a link or a macro-laden document, the attacker attached a nested message file, an .eml container carrying what was labeled as an employee handbook and personalized with the recipient's own name. Opening an .eml re-renders it as a fresh email inside the client, complete with its own body, links, and any further attachments. It is a Russian-doll technique: hide the real payload one layer deeper than most scanners bother to look.

That blind spot is not theoretical. The SOC's own recursive attachment parser could not fully unpack the nested file, returning an "Attachment not found" error on the inner pull. A container that a purpose-built parser cannot open is a container a production mail filter is unlikely to open either, which is precisely the point. The handbook framing gave a mundane reason to click into the nested message, where the second stage, a credential prompt or a malicious link, would live beyond the reach of the outer scan. Payload containers like this are why attachment inspection has to be recursive, and why a single clean verdict on the outer envelope means very little. This is the category IRONSCALES treats as advanced malware and URL attack protection: the threat is not the file you can see, it is the one nested inside it.

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

Mapping to MITRE ATT&CK

• T1566.001 Spearphishing Attachment covers the core delivery, a targeted message whose payload is the nested .eml handbook file.
• T1036.005 Masquerading: Match Legitimate Name or Location covers the internal HR persona, a Workforce Team identity chosen to match the recipient's own employer.
• T1585 Establish Accounts covers the disposable VPS infrastructure stood up to inject the message outside any legitimate mail platform.

Indicators of Compromise

Detection and What to Watch For

Static defenses were poorly positioned for this one. The infrastructure that mattered, Microsoft 365, is trusted by definition, and the sole attacker-owned asset was a throwaway VPS with no reputation to burn. The signals worth catching are relational and behavioral: a sender domain that has nothing to do with the HR team it claims to speak for, an SPF pass that appears only after a relay hop while the true origin failed, a bestguesspass DMARC result standing in for a real policy, and a nested .eml attachment that resists unpacking.

This is where Themis, the Adaptive AI analyst on the IRONSCALES platform, changes the outcome. It weighs the claimed identity against the actual sending domain and the full relay chain the way a seasoned analyst would, so a Workforce Team message arriving from an unrelated .org through a laundered SPF pass reads as anomalous no matter how clean the final hop looks. The 2024 Verizon Data Breach Investigations Report puts the human element in 68 percent of breaches and names pretexting, largely business email compromise, as the top social-engineering incident type. The Microsoft Digital Defense Report 2024 documents the same pivot toward abusing trusted services rather than breaking them, and the FBI's 2023 Internet Crime Report ranks business-identity impersonation among the costliest fraud categories. Across the 35,000+ security professionals and 17,000+ organizations we work with, the pattern is consistent: the attacks that land are the ones that borrow trust rather than defeat it.

The Takeaway

Authentication was built to answer a narrow question: is this server allowed to send for this domain right now. It was never designed to answer the question that actually matters to a targeted employee, which is whether the human identity in the From field is real. A spoofed HR handbook can fail SPF at its origin, carry no DKIM, earn nothing better than a best-guess DMARC result, and still land, because it borrowed a Microsoft pass on the way in and buried its payload one email deep. Treat a green authentication checkmark as one input, not a verdict. Confirm that the sending domain actually belongs to the identity it claims, inspect attachments recursively rather than trusting the outer envelope, and lean on behavioral detection to catch the impersonation that server-level checks were never meant to see.

CISA's guidance on recognizing and stopping phishing early (https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one) and NIST's working definition of phishing (https://csrc.nist.gov/glossary/term/phishing) are solid references for building that habit across a team.