The Email With Nothing to Scan: A 1 MB HTML Attachment That Renders Its Own Phishing Page

The Email Carried Nothing a Gateway Could Look Up

The message that landed in the inbox had almost nothing to inspect. The visible body was a single line, "Full report," wrapped in the two safety banners the mail client adds for external first-contact senders. The subject was short and ambiguous, naming the recipient by first name plus a reference code. There was no link to follow, no payment demand, no urgent credential-reset language.

The only meaningful object in the message was an attachment: a self-contained HTML file just over one megabyte, named like a finished report with a date stamp. An HTML attachment is a complete web page delivered as a file. When the recipient double-clicks it, the page renders inside their own browser, off the network, from content that already traveled inside the email.

That is the entire problem. A Secure Email Gateway, the legacy filtering layer that sits in front of the mailbox, earns its keep by extracting URLs from a message and checking them against threat intelligence. This message had no malicious URL to extract. The phishing page was inside the file, and the file rendered locally, so no destination ever surfaced for a reputation lookup. The gateway had nothing to look up.

How the Delivery Was Built to Pass

The sender was an external, first-time Gmail address with no prior correspondence with the organization, flagged high-risk by the detection system. Despite that flag, the message authenticated cleanly. SPF, DKIM, DMARC, and ARC all passed. The mail left a Google outbound server, was handed to Microsoft 365 inbound protection, and arrived with every authentication assertion intact.

That combination is the point worth sitting with. SPF, DKIM, and DMARC are the protocols that confirm a message was genuinely sent and signed by the domain it claims, and was not forged in transit. Here they all passed because the message really was sent through Gmail and signed by a gmail.com key. Authentication tells you the envelope is real. It tells you nothing about intent. A compromised personal account, which the sender profile here is consistent with, sends fully authenticated mail all day. The high-risk first-time-sender flag and the lack of any prior relationship were the only transport-layer signals pointing the right way, and authentication did nothing to reinforce them.

The mechanics map cleanly onto known adversary behavior. Delivering the payload as an attachment rather than a link is MITRE ATT&CK T1566.001, spearphishing attachment. Packaging the page content inside a large file so that scanners cannot readily parse it aligns with T1027, obfuscated files or information. The body existed only to do one job: get the recipient to open the file.

The Uninspectable Attachment Is the Technique

Here is where this case is honest about its own limits, and where the technique is most instructive.

The static scan returned a verdict of clean. That is expected. Static scanning matches a file against known-bad signatures and pulls out URLs for checking. A purpose-built HTML page with no recognized signature and no external link in the message passes that bar.

The deeper analysis is what is revealing. When the detection system attempted a content-level inspection of the HTML, looking for embedded forms, scripts, redirects, and remote resource calls, that analysis failed to complete. The file exceeded the analyzer's processing limit. The system could not extract dynamic behavior from it.

That failure is not a footnote. It is the attack working as designed. The file was large enough that even the engine built to look inside it could not finish. HTML attachments of this size routinely carry the machinery of credential harvesting: a login form that posts to an attacker endpoint, script that assembles a page from encoded blocks, or a redirect that fires only after rendering. This case does not let us name which mechanism is present, because the evidence does not show it. What the evidence shows, cleanly, is the gap: an authenticated message, a clean static verdict, and an attachment too large to deep-inspect. An attacker does not need a clever payload if the file itself is large enough to fall through every layer that would have read it. For background on how this class of attack monetizes once a victim does interact, see how credential harvesting works.

Indicators of Compromise

What Actually Catches This

The lesson is not that scanning is useless. It is that reputation-based scanning has a structural blind spot, and the data backs that up. The 2026 Verizon Data Breach Investigations Report attributes 16% of breaches to phishing as the initial-access vector and 39% to stolen credentials, the exact prize a credential-harvesting page is built to capture. The Microsoft Digital Defense Report 2024 documents the steady shift toward identity-based and evasive delivery. The FBI IC3 2024 report ranks phishing the most-reported crime type by complaint volume. And the IBM Cost of a Data Breach 2024 puts the price of a single breach high enough that one missed attachment is not an acceptable rounding error.

IRONSCALES telemetry across 1,921 organizations shows SEGs miss an average of 67.5 of every 100 mailboxes per month. A message like this one, with no URL and an uninspectable file, is precisely the kind that lands in that miss rate.

Detection has to move off reputation and onto behavior. The signals that mattered here were available before anyone opened the file: a first-time external sender, no prior correspondence, a high-risk flag, and a one-line body whose only function was to push a large attachment. Those add up to a profile, not a signature. An Adaptive AI engine that scores sender relationship and message anatomy catches that profile even when the URL check and the static scan both come back empty.

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

The second layer is time. Because the malicious behavior may only be confirmable after delivery, in a sandbox or once a user reports the message, the defense has to include the ability to pull a message back across every mailbox after the fact. Layering dedicated credential-harvesting protection on top of authentication closes the part of the gap that SPF and DMARC were never built to cover. Treat the clean verdict as provisional, not final. A 1 MB HTML attachment from a first-time sender deserves suspicion regardless of what the scanner said, and the architecture should assume that some of what passed will need to be retracted later. That is the difference between a gateway that decides once at the door and a system that keeps watching after the message is inside.