The email looked like a routine procurement follow-up. Professional tone, a corporate signature block from a HACCP Coordinator at a food processing company, a polite request to review attached documents. No urgency. No credential requests in the body. SPF passed. DKIM passed. DMARC passed. Every authentication check returned green.
The weapon was the attachment: a 454 KB HTML file named "Inbox - [Sender] - Outlook.html."
That filename mimics the format of an exported Outlook mailbox. At 453,996 bytes, the file was roughly nine times the size of a typical HTML email. A file that large, with that naming pattern, is almost certainly a self-contained phishing page designed to render a fake Outlook inbox or login screen when opened locally in a browser. Scanner verdicts came back clean on both attachments because the HTML was inspected as a static file, never rendered in a browser context where the credential harvesting logic would execute.
Themis, the IRONSCALES Adaptive AI, flagged the behavioral anomaly. The message was quarantined across multiple mailboxes before any recipient opened the attachment.
The message arrived from [Sender]@[food-company][.]com, a first-time external sender with no prior communication history with the target organization. The sender profile indicated medium risk. The corporate signature block listed a HACCP Coordinator title.
Two attachments accompanied the message:
The PDF reinforced the procurement narrative. The HTML file was the payload.
A typical HTML email runs 10 to 50 KB. A 454 KB HTML file is an anomaly that demands explanation.
At that file size, the HTML attachment is large enough to contain everything needed for a standalone credential harvesting page: inline CSS for pixel-perfect styling that mimics a Microsoft Outlook login screen, base64-encoded images for logos and UI elements embedded directly in the file, JavaScript for form validation and credential capture, and form action handlers to exfiltrate captured data. All of this can function without a single network request when the victim opens the file.
The naming convention, "Inbox - [Name] - Outlook.html," adds a layer of social engineering. This format mirrors what Outlook produces when a user exports their mailbox. The recipient sees a file that looks like someone accidentally attached their own inbox export, which is exactly the kind of file a curious recipient would open.
Full content analysis of this specific file was not possible because the sandbox environment could not render the HTML in a browser context. But the combination of file size, naming pattern, content type, and delivery mechanism points strongly toward a self-contained credential harvesting page. This technique is well-documented. The SANS Internet Storm Center has cataloged multiple campaigns using oversized HTML attachments as standalone phishing kits that render locally without requiring any attacker-hosted infrastructure.
This maps to MITRE ATT&CK T1566.001 (Phishing: Spearphishing Attachment) for the delivery mechanism and T1204.002 (User Execution: Malicious File) for the required victim interaction of opening the HTML file in a browser.
See Your Risk: Calculate how many threats your SEG is missing
The authentication results tell a story that should trouble any security team relying on email authentication as a primary defense:
The message relayed through Microsoft and Outlook protection infrastructure. Every protocol confirmed the email originated from infrastructure authorized by the sender's domain. That is because it almost certainly did. The sending account was likely compromised, giving the attacker access to a legitimate corporate email account with established domain reputation, valid DKIM signing keys, and SPF-authorized sending infrastructure.
A compromised account is the hardest phishing vector to detect at the gateway level. No newly registered domains. No IP reputation mismatches. No authentication failures. The only signals available are behavioral: a first-time sender, an anomalous attachment profile, and a filename pattern inconsistent with normal procurement workflows.
Two separate scanner evaluations returned clean verdicts on the HTML attachment. Both were wrong.
Static file analysis checks for known malware signatures, embedded executable code, and flagged URL patterns. An HTML file with obfuscated or base64-encoded content does not match known signatures. The credential harvesting logic is inert until rendered in a browser, which static analysis does not do.
The scanner evaluated the file as a document. The attacker designed it to function as an application. Without browser-context rendering, the scanner cannot distinguish between the two. The clean PDF attachment further reduced suspicion by making the overall message structure look like a plausible procurement exchange.
IRONSCALES flagged the message on converging behavioral signals:
No single indicator was conclusive. The convergence of all four triggered quarantine before any recipient could open the attachment.
| Type | Indicator | Context |
|---|---|---|
| Sender | [Sender]@[food-company][.]com | Likely compromised corporate account, first-time sender |
| Authentication | SPF=pass, DKIM=pass, DMARC=pass | Full auth pass via legitimate infrastructure |
| Attachment | Inbox - [Sender] - Outlook.html | Self-contained HTML phishing page (453,996 bytes) |
| Attachment | PDF document | Standard business PDF (237,232 bytes), clean |
| Sender Role | HACCP Coordinator | Corporate signature block, food processing industry |
| Relay | Microsoft/Outlook protection infrastructure | Message routed through legitimate email protection |
Flag oversized HTML attachments. Any HTML file over 100 KB arriving as an email attachment warrants scrutiny. Legitimate business workflows rarely produce HTML attachments, and files in the hundreds of kilobytes almost certainly contain embedded resources designed to render a standalone page.
Do not trust clean scanner verdicts on HTML files. Static analysis evaluates HTML as a document. Attackers design HTML phishing attachments to function as applications. Deploy sandbox solutions that render HTML attachments in isolated browser contexts.
Treat full authentication pass from first-time senders as a signal, not an all-clear. Compromised accounts produce perfect authentication results. When SPF, DKIM, and DMARC all pass but the sender has zero communication history with your organization, behavioral analysis is the only reliable detection layer.
Audit attachment policies for HTML content types. Many organizations block executable attachments (.exe, .bat, .ps1) but allow HTML files through without inspection. HTML files with embedded JavaScript are functionally equivalent to executable code when opened in a browser.
| Attack | What happened |
|---|---|
| The SOC Alert That Came From a Compromised FinTech: An Authenticated BlueVine Sender Delivering a Typosquat Link Buried in Operational Context | A fully authenticated email from bluevine.com impersonated an internal SOC quarantine notification. |
| A School Email That Passed Authentication Twice, Then Changed: Post-Signing Content Injection via Compromised .sch.uk Domain | A message from a legitimate UK school domain passed DKIM and SPF at the first hop. |
| The Fax Notification That Was Just a Pregnancy Test for Your Curiosity | A Gmail account sent a fax notification with a 24KB HTML attachment. |
| The Tax PDF That Every Scanner Declared Clean (It Wasn't) | A tax-season PDF arrived from Gmail with no JavaScript, no links, no forms, and a clean verdict from every scanner. |
| The Voicemail That Wasn't: How Calendar File Attacks Bypass Email Security | An attacker sent an empty email with a voicemail-themed .ics calendar attachment from a Japanese domain while impersonating a US financial services... |