A Bonus Notice Wrapped Inside Another Email

The subject line named the recipient's own employer. Not a vendor, not a bank, not a shipping carrier. The company the reader worked for, in lowercase at the front of a string of underscored fragments about renewed fiscal year benefit compensation. The sender had no relationship with that company at all. And the entire payload was not a document or a link. It was another email.

The message landed in mailboxes at a global engineering and construction consulting firm. The body was one line, an invitation to review the attached file. Outlook rendered its own first contact banner above it, noting that the recipient does not often get email from this sender.

A Subject Line That Named the Recipient's Own Employer

The subject read like a payroll system export rather than a human sentence, roughly in the shape of [employer name] Renewed Fiscal_Year Q4 Benefit_Compensation_[date]_ref:_[per-recipient token]. Underscores in place of spaces, a fiscal quarter, a date stamp, a long random reference string on the end. Automated notices from HR and payroll platforms genuinely look like this, so the format borrows credibility from every legitimate benefits email the reader has ever archived.

The usual pattern in brand impersonation is a well known vendor spoofed in the display name. This inverted it. The brand being borrowed was the target's own employer, pasted into the subject to make outside mail feel like an internal announcement about money the reader might be owed. The strongest available signal is therefore a mismatch: an internal sounding benefits notice from a completely unrelated external domain.

The Attachment Was a Message Inside a Message

The lone attachment was a .eml file, roughly 155 KB, whose filename paired the words for a bonus payout with a leading token lifted straight from the recipient's own mailbox name. Whoever built this had the target address in hand. A .eml file is a complete email message stored as a file, so attaching one nests a second message inside the first, and this one arrived declared as application/octet-stream, raw binary, rather than as a message type. A scanner walking the MIME tree got no structural hint that a whole new message waited underneath.

The results split exactly where the attacker needed them to. The antivirus and attachment scan returned a verdict of clean. The deeper content analyzer, the layer meant to reach inside a container and evaluate what is in there, tried to extract the nested message and failed outright, reporting that it could not find the attachment to inspect.

Those are not the same answer. A clean verdict on a container a deeper layer could never open describes the wrapper, not the contents, and the contents here were never established. An unknown is not a negative. The recipient mail client, meanwhile, would have opened that nested message natively on a double click, with none of the parsing difficulty that stopped the analyzer. That asymmetry is the whole technique. There was no malicious URL in the outer message at all, only Microsoft's own sender identification help links.

Authentication Passed on a Domain That Published Almost Nothing

The sending account was a compromised or reputation-thin third-party business email account on a domain registered back in 2002 and sitting behind a registrar privacy proxy. Age was the asset. There was no freshly registered lookalike to flag. What that domain published was thin to the point of permissive. Its Sender Policy Framework record ended in a soft fail default, and it published no DomainKeys Identified Mail signature, so nothing in the message was cryptographically bound to the sender.

It published no Domain-based Message Authentication, Reporting and Conformance policy either, which means the alignment layer described in RFC 7489 had nothing to align. The evaluated results still came back green. SPF passed, because the message relayed through 64[.]78[.]48[.]42, a commercial email and hosting gateway the domain does authorize, before handing off to Microsoft front end filtering. DKIM was absent. DMARC resolved to a best guess pass with no action to take. Composite authentication passed on an implicit reason code, and the spam confidence level came back at 1. A Microsoft 365 tenant relying on the built in verdict had every reason to deliver this.

Two Origin Addresses That Did Not Agree

One header contradicted the rest. The originating IP recorded on the message pointed to 212[.]8[.]251[.]143, an address in the Netherlands with no reverse DNS record, while the authorized relay that delivered it sat in a US commercial hosting range. Alone, that gap proves nothing. Alongside a first contact sender, a borrowed employer name, and a container nobody could open, it stops looking like noise.

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

What Actually Caught It

Nothing in the payload was going to produce the verdict. No failing signature, no attacker domain, no credential page, and a clean antivirus result on the only file present. The evidence was entirely relational, which is where Themis, the Adaptive AI analyst on the IRONSCALES platform, operates. A first contact sender, a subject quoting the recipient's employer from an unrelated domain, a filename templated from the recipient's own mailbox name, and a container whose deep inspection failed rather than passed: individually weak, collectively decisive.

Automated threat detection flagged the message and resolved the incident as phishing with no manual analyst step. The same template reappeared the same day against additional mailboxes at the same organization, each carrying its own reference token, and each was mitigated automatically. That is the shape of attachment based attacks with no reachable payload: waves rather than single shots, varied per recipient to defeat exact matching, all of them depending on a clean scan being read as an all clear.

Mapping to MITRE ATT&CK

The delivery is T1566.001 Phishing: Spearphishing Attachment, the file being the entire lure. Wrapping content in a nested message declared as raw binary, unreachable by inspection but trivial for a mail client, is evasion by container under T1027 Obfuscated Files or Information. Quoting the recipient's employer to pass as an internal notice maps to T1656 Impersonation.

Indicators of Compromise

The Takeaway

Attachments are still the front door. The 2024 Verizon Data Breach Investigations Report puts phishing in 15 percent of breaches and the human element in 68 percent of them, and clocks the median time to click a phishing link at 21 seconds. A benefits notice naming your own employer, arriving with a file to review, is engineered for exactly that reflex. The IBM Cost of a Data Breach Report 2024 puts the global average breach cost at 4.88 million dollars.

Three practices close most of this gap. Treat an inspection failure as a failure, not as a pass, and route containers your stack cannot open into review rather than the inbox. Flag any subject line that references your own organization from an external sending domain. And verify compensation notices through the internal channel that owns them, following CISA phishing guidance and the baseline NIST maintains for phishing.

See You Next Time

A clean scan on a file nothing could open is not good news. It is the absence of news, and attackers build for that gap.