The email said: "Please find the attached Organization-Wide User History Report." The body was professional. The tone was neutral. There was no urgency, no credential request, no link to click. Just an attachment to open.
The attachment was the weapon. And most scanners never saw it.
The attached spreadsheet arrived with a filename that contained embedded CR/LF control characters: GS-US-695-6509\r\n Organization-Wide User History Report_2026-04-27-16-00-44.xlsx. Those invisible characters, a carriage return and line feed injected into the filename string, caused the file extraction pipeline to produce a zero-byte artifact. The automated scanner examined that empty file, computed its hash (d41d8cd98f00b204e9800998ecf8427e, the MD5 of nothing), and returned a verdict of "clean."
The actual payload was 557,952 bytes. It existed as a companion .b64 file in the same analysis directory, base64-encoded and waiting for a decoding step that the standard scanning pipeline never performed. The reported hash from the original incident metadata (8bd593c18c151bc6abcfddbdd6aef249) did not match the zero-byte artifact the scanner inspected. Two different files, two different hashes, one verdict that applied to the wrong one.
The message originated from bo4@mdsol[.]com via SocketLabs (s1-ba68.socketlabs.email-od[.]com). At that first hop, SPF passed, DKIM passed, and DMARC passed for mdsol[.]com. The ARC seal at i=1 recorded all three as valid.
Then the message hit a Cisco IronPort gateway (esa1.hc3244-53.iphmx[.]com). The gateway rewrote the envelope, and the Return-Path shifted to a bounce address at gileadconnect.onmicrosoft[.]com. By the time the message reached the recipient's tenant, SPF failed, DKIM failed, DMARC failed, and ARC validation at i=2 recorded the breakdown. Every authentication signal that passed at the origin was gone by delivery.
The sender address bo4@mdsol[.]com returned no results in public directories. The clinical data management context in the body suggested a pharmaceutical or research organization, but the combination of an unverifiable sender, an envelope rewritten through a third-party gateway, and a broken authentication chain left no trustworthy identity signal for the recipient's mail system to evaluate.
Themis, the IRONSCALES Adaptive AI engine, flagged the message on structural anomalies: the authentication chain failure across relay hops, the unverifiable sender identity, and the attachment metadata inconsistencies. The mailbox was quarantined before the attachment was opened.
See Your Risk: Calculate how many threats your SEG is missing
| Type | Indicator | Context |
|---|---|---|
| Sender Address | bo4@mdsol[.]com | Unverifiable in public directories |
| Return-Path (rewritten) | bounces+SRS=...@gileadconnect.onmicrosoft[.]com | Envelope rewritten by forwarding gateway |
| Sending Relay | s1-ba68.socketlabs.email-od[.]com | SocketLabs ESP, initial auth passed |
| Gateway | esa1.hc3244-53.iphmx[.]com | Cisco IronPort, caused SPF/DKIM/DMARC failure |
| Attachment | .xlsx with CR/LF in filename | 557,952 bytes (reported), zero bytes (scanned) |
| Companion File | .b64 base64-encoded payload | Real workbook content, not inspected by pipeline |
| Hash (reported) | 8bd593c18c151bc6abcfddbdd6aef249 | Did not match the artifact the scanner examined |
| Technique | ID | Relevance |
|---|---|---|
| Phishing: Spearphishing Attachment | T1566.001 | Malicious spreadsheet as primary delivery vector |
| Obfuscated Files or Information | T1027 | CR/LF filename obfuscation and base64 encoding |
| Masquerading | T1036 | Clinical data report pretext from unverifiable sender |