When Authentication Passes and Malware Still Walks In: A PE Hidden Inside an Inline PNG

A message landed in an insurance claims examiner's inbox with a subject line that read like routine software onboarding: a new-user account had been created on the company's claims-management platform. It read like standard setup: an account had been provisioned, credentials would follow in a separate transfer, and the recipient should add a mobile number for multi-factor authentication. The email rendered cleanly, complete with portal screenshots and training video links.

It also passed every authentication check email security teams are taught to trust. SPF returned pass. DKIM verified. DMARC, under a reject policy, passed. The composite authentication score was 100. By every header-level signal, this message originated from an authorized mail path and arrived unaltered.

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

Authentication Confirms the Route, Not the Cargo

It is worth being precise about what email authentication proves, because this case sits exactly where practitioners tend to over-read the results.

SPF (Sender Policy Framework) checks whether the sending IP is permitted to send for the envelope domain. DKIM (DomainKeys Identified Mail) verifies a cryptographic signature confirming specific headers and the body were not modified after signing. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties those results to the visible From domain. Together they answer one question well: did this message travel an authorized path for the domain it claims, without tampering?

That is a question about provenance, not safety. A valid signature says the body was not altered in transit. It says nothing about whether that body, or its inline images, contain something malicious. The Verizon 2026 Data Breach Investigations Report still puts phishing among the leading initial-access vectors, attributing roughly 16 percent of breaches to phishing-driven access, and authentication adoption has not changed that, because attackers increasingly send from infrastructure that authenticates correctly. The DMARC result is a routing fact. Treating it as a verdict on content is where defenders get hurt.

The Mechanics: An Image That Was Also a Binary

The message carried three inline PNG images. Two were genuine interface screenshots and a signature graphic. The third, image007.png, was the problem.

On the surface it was a valid PNG. It parsed, it rendered, and a header check confirmed a legitimate image format. But PNG does not store pixels as raw bytes. It stores them as zlib-compressed data inside one or more IDAT chunks. Decompress those chunks and you get the actual bitmap, and in this file the decompressed IDAT stream ran to roughly 6.5 MB. At offset 696,056 inside that decompressed data sat the bytes "MZ," the signature that begins every Windows portable executable (PE), the file format used by .exe and .dll binaries.

In other words, a complete executable payload had been placed inside the compressed image stream itself. This is not a binary appended after the image's end marker, the crude trick most scanners already catch. The executable bytes were woven into the data the image format legitimately carries, so the file remained a structurally valid, renderable PNG.

That distinction is what makes the technique effective. It maps to MITRE ATT&CK T1566.001, spearphishing attachment, combined with T1027, obfuscated or embedded payloads. The image is both a believable visual element and a container, and the obfuscation is the container.

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

Why the Inline Image Slipped Through

Most secure email gateways (SEGs), the legacy filtering appliances that sit in front of the mailbox, treat attachments and inline images differently. An attachment that arrives as a file is a candidate for sandboxing and deep parsing. An inline image referenced in the message body is usually treated as a display asset, something to render, not something to detonate. The IRONSCALES dataset shows SEGs miss an average of 67.5 phishing emails per 100 mailboxes every month, and content that hides inside trusted-looking display assets is precisely the kind of thing that contributes to that gap.

Catching this specific case requires a scanner to do something most do not do by default: decompress the IDAT stream and scan the resulting bytes for embedded file signatures such as MZ and the PE marker. A header check sees a PNG. A visual render sees a screenshot. Only inspection of the decompressed content sees the executable. The Microsoft 2024 Digital Defense Report and CISA advisories have both pushed defenders toward content and behavioral inspection over signature and reputation alone, and image-borne payloads are a clean example of why.

This case also differs from a prior pattern worth contrasting. We have written before about a PE hidden in a PNG that was itself embedded in a DOCX, where SPF, DKIM, and DMARC all failed. That message looked suspicious from the headers down. This one inverts the posture entirely: authentication fully passed, and the payload rode inside an inline image rather than a document. The lesson is sharper here precisely because nothing at the routing layer was wrong. The FBI IC3 2024 report continues to rank email-borne fraud and malware delivery among the costliest reported categories, and image-embedded payloads are an evolution of that same delivery problem.

Indicators to Hunt

The publishable indicators here are narrow by design. The sending path authenticated legitimately and the branded names belong to real organizations, so the durable, attacker-controlled artifacts are the file and its hashes. Defanged for safe handling:

There are deliberately no domains, URLs, or sender addresses in this table. The message authenticated through an authorized mail path for a real domain, so blocking that domain would be wrong. The signal to act on is the embedded executable, not the route it traveled.

The Mixed-Brand Signal

The message body carried inconsistencies that, read together, suggest templating or content injection. A financial-services brand appeared in the header graphics, a different vendor name appeared in the contact block, and the sign-off named yet another entity. Legitimate onboarding mail occasionally mixes co-branded partners, so any one alone is weak. Stacked, they are the kind of provenance smell that should lower trust even when authentication is clean.

Defensive Takeaway

Authentication is necessary and worth enforcing. It is not a content verdict, and this case is a clean demonstration of the difference. The defensive posture that catches an embedded executable in an inline image is layered and content-aware.

Inspect the content, not just the envelope. Decompress and scan image streams for embedded file signatures rather than trusting the file header or the rendered preview. Advanced malware and URL protection that parses payloads inside images is the control that closes this gap.

Weight the full message. Mixed branding, first-time senders, and signature inconsistencies are behavioral signals that matter even when SPF, DKIM, and DMARC pass. Adaptive AI that evaluates sender context and message anomalies alongside authentication results is built to catch what a binary pass-or-fail check cannot.

The takeaway is small and durable: a green authentication result tells you the message took an authorized road. It never told you what was riding in the trunk.