The Spreadsheet That Arrived Twice: CR/LF Filename Obfuscation and a Base64 Shadow Payload

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 File That Wasn't There

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.

Authentication That Dissolved in Transit

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 Nobody Could Verify

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

Indicators of Compromise

MITRE ATT&CK Mapping