The Shipping Notice That Hid a Windows Executable Inside a PNG

The email looked like every other arrival notice the operations team had seen that week. A shipment reference, a house bill of lading number, an ETA, a container number, and a note that the cargo was off rail and pending customs entry. The sender domain had been registered since 2001. The signature block included a street address in Manhattan, a direct extension, and a wire-transfer verification warning. SPF passed. DKIM passed. DMARC passed. ARC passed.

Buried inside one of the inline images was a Windows executable.

The file, image003.png, was 30,248 bytes. It rendered as a valid PNG. An initial scan flagged it as clean. But deeper binary inspection revealed a PE header signature (MZ) at byte offset 21763, embedded inside the PNG IDAT data stream. Not appended after the IEND marker. Inside the image structure itself.

A Binary Hiding in Plain Sight

The technique is steganographic embedding: concealing executable code within the data chunks of an otherwise valid image file. The PNG specification allows for compressed image data in IDAT chunks, and the file entropy for this image measured approximately 7.99 bits per byte. For a 30 KB image of what appeared to be a corporate logo, that entropy level is anomalously high, consistent with compressed or encrypted embedded data rather than simple pixel information.

The tEXt metadata chunk reported Software = Microsoft Office, indicating the image had been saved or processed through an Office application. Zero bytes were appended after the IEND chunk, which rules out the simpler (and more commonly detected) technique of concatenating an executable onto the end of an image file. This was not a polyglot file in the traditional sense. The PE was woven into the PNG data itself.

The SHA256 hash of the PNG was 7173a2c0c37f5f224ff3aa46ab57d08dcaac4ef20d74843518a33b3b3c26e32c. The MD5 was 5fbf4707645d2a9e96c54c9d63c4bc6a. The PE payload beginning at offset 21763 would need to be carved out and analyzed separately to determine its function, whether a dropper, a loader, or a standalone implant.

What made this delivery vector particularly effective was the context. The email body contained no social engineering urgency, no credential harvesting links, no payment diversion request. Every URL in the message resolved to the sender's legitimate corporate website or to a known third-party logistics provider (chrobinson[.]com). The body read like a real operational message because, aside from the embedded payload, it may have been one. The most likely scenario is account compromise: a legitimate user's mailbox was used to send operationally plausible messages with a weaponized inline image.

The thread also contained messages referencing oneview[.]descartesservices[.]com, a domain belonging to a legitimate logistics software provider, and the signature block's mailto: target pointed to a different employee at the same company rather than the visible sender. These thread-level inconsistencies are subtle but point toward either a compromised forwarding chain or manipulated message threading.

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

Why Authentication Passed and Scanners Missed It

This is a case where every protocol-level check returned the answer defenders want to see, and every one of those answers was irrelevant to the actual threat.

SPF confirmed that the sending IP was authorized by the domain. DKIM confirmed the message was cryptographically signed and unmodified in transit. DMARC confirmed alignment between the envelope and header domains. ARC preserved authentication across relay hops. All of these validate sender identity and message integrity. None of them inspect attachment content.

The attachment scanner's clean verdict was equally misleading. The file was a valid PNG. It rendered as an image. It had no macro, no OLE object, no JavaScript. The PE header at offset 21763 is invisible to scanners that check file type and known signatures without performing deep binary entropy analysis or structured chunk inspection.

According to the 2024 Verizon DBIR, the use of pretexting in social engineering attacks, where the attacker establishes a plausible operational context before delivering a payload, has increased substantially in recent years. Embedding malware within operationally normal communications from compromised legitimate accounts is a natural extension of that trend.

Themis, the Adaptive AI engine, flagged this incident based on behavioral signals that protocol checks do not evaluate: the entropy profile of the attachment, the thread-level domain inconsistencies, and the mismatch between the signature block identity and the visible sender. Community intelligence across the IRONSCALES network contributed confidence scoring from similar steganographic delivery patterns observed at other organizations. Across the IRONSCALES customer base, 67.5 phishing emails per 100 mailboxes per month bypass traditional secure email gateways, and steganographic payloads are among the hardest for legacy tools to catch.

This attack maps to MITRE ATT&CK T1027.003 (Steganography) for the embedded payload technique, T1566.001 (Spearphishing Attachment) for the delivery vector, and T1036.008 (Masquerade File Type) for presenting an executable as an image.

What Defenders Should Take Away

Steganographic embedding in email attachments is not theoretical. This was a real message, delivered to a real mailbox, from a real domain, with real authentication, and a real PE binary hidden inside a 30 KB PNG.

Detection requires moving beyond file-type classification and signature matching. Entropy analysis of image attachments, structured chunk inspection for unexpected headers, and behavioral analysis of the surrounding message context (thread consistency, sender-signature mismatches, first-time attachment patterns) are the signals that surface this class of threat.

For incident response, any organization that received this message should carve the PE from the PNG byte range starting at offset 21763, compute its hashes, submit it to sandbox and AV engines, and search mail logs for other occurrences of the same attachment hash. The sending account should be treated as compromised until confirmed otherwise.

The wire-transfer verification warning in the signature block is an ironic footnote: the sender's own company had a security notice urging recipients to verify bank details by phone before wiring money. The compromised account used that same trust to deliver something far worse than a fraudulent wire request.

Indicators of Compromise