The file was called HLLK_CloudFlare_ io - Yahoo D2S.2024.12.25.docx.pdf. Every automated scanner that touched it returned the same verdict: clean.
Not because the file was safe. Because the file was broken on purpose.
This is how a single malformed attachment, sent from a free Gmail account with a plausible vendor pretext, sailed past automated defenses at a digital media firm and landed in an accounts payable inbox. The payload was not a macro, not a link, not an embedded script. It was the structural damage itself, engineered to make every parser fail silently.
The email arrived on a Tuesday morning, addressed by first name to a staff member at the recipient organization. The sender identified himself as "Paul Strickland" writing from pubcodirector@gmail.com, a free Gmail account. The subject line mimicked an internal file naming convention: HLLK_PERI_Agreement_2026.03.24.
The body was short and business-appropriate:
> In 2024/2025 my company entered into an agreement with Perion/Codefuel. See attached. For the purposes our audit and accounting, I require some historical documents. Specifically, on 4/17/2025, Codefuel/Perion sent my company $20,872.49. Our auditors have asked for support around this payment. Can you please put me in touch with the accounts payable department?
The dollar amount is specific. The company names are real. The request (connecting a vendor to AP for an audit) is entirely normal. There is no urgent wire transfer demand, no password reset link, no obvious red flag in the message text.
That specificity is the point. According to the FBI IC3 2024 Internet Crime Report, business email compromise caused over $2.9 billion in losses in 2024, with accounts payable and vendor fraud among the most common pretexts. Accounts payable teams field exactly this kind of inquiry. The email body does not need to do much heavy lifting because the attachment is supposed to close the deal.
The file name contains two extensions: .docx.pdf. That pattern is T1036.007 in the MITRE ATT&CK framework, double file extension masquerading. It exploits two separate failure modes simultaneously.
For human recipients, the .docx label in the middle of the filename signals a familiar Microsoft Word document. Someone scanning quickly may read that and feel safe before they even register the .pdf at the end. For automated scanners, the .pdf extension at the tail end triggers PDF-specific analysis routines. And that is exactly where this file was designed to break things.
Verizon's 2024 Data Breach Investigations Report found that phishing via malicious attachments remains one of the most reliable initial access vectors, appearing in a significant share of social engineering incidents. The attachment weaponizes that reliability: the pretext is low-friction, the file looks real, and the evasion is baked into the structure.
When scanners attempted to parse the attachment, they hit a wall of structural errors:
A well-formed PDF has a header starting with %PDF-, an object tree, a cross-reference table, and a trailer dictionary. This file had none of the structural markers that PDF parsers depend on. The document stream returned empty. The scanner logged errors and moved on, recording a verdict of "clean" because it could not find anything malicious inside a file it could not open.
That is the trap. The malformed structure is not a bug in the attacker's work. It is the feature.
A file that crashes your parser produces the same output as a file that passes your scanner: no detection. From the scanner's perspective, both look identical. The attacker does not need to hide malicious content inside the file. They only need to make the file unreadable, and the tooling does the rest.
The attachment itself weighed 1.24 MB, large enough to look like a real document, small enough not to trigger size-based heuristics. The MIME type was declared as application/pdf, consistent with what the email client would display to the recipient.
See Your Risk: Calculate how many threats your SEG is missing
No single indicator here would have been enough in isolation. IBM's 2024 Cost of a Data Breach report put the average cost of a phishing-initiated breach at $4.88 million, a figure that reflects how often these attacks succeed precisely because they exploit trusted infrastructure and legitimate-looking signals. The sender passed SPF, DKIM, and DMARC. That is expected when you send through Google's infrastructure using a legitimate Gmail account. Authentication passes prove transport, not identity. A clean auth result from a first-time external free-account sender tells you the message moved through Google correctly. It tells you nothing about whether "Paul Strickland" is who he says he is.
IRONSCALES evaluated the full signal stack together: first-time sender, external free-account origin, high sender risk score, a subject line with an internal-looking file reference, and an attachment that failed every parsing attempt. No single flag is decisive. The combination is.
The attachment parsing failure was treated as a detection signal, not a pass. A file that returns empty streams and missing trailer dictionaries is not a file that was checked and cleared. It is a file that was not successfully analyzed at all. That distinction matters.
The incident was escalated before any user opened the attachment. The email was quarantined and the file was flagged for further investigation. IRONSCALES advanced malware and URL attack protection correlates behavioral signals across the message, sender history, and attachment behavior, so a parser crash is not the end of the investigation. It is the beginning.
| Type | Indicator | Context |
|---|---|---|
| Sender email | pubcodirector[@]gmail[.]com | Free Gmail account, first-time sender, high risk |
| Attachment name | HLLK_CloudFlare_ io - Yahoo D2S.2024.12.25.docx.pdf | Double-extension, brand name mixing, date in filename |
| Attachment hash (MD5) | cfe261d328a4adae00cc7543e6f957cc | Malformed file, parser crash confirmed |
| Relay IP | 209[.]85[.]220[.]41 | Google outbound mail pool (mail-sor-f41.google.com), not blockable broadly |
| Subject pattern | HLLK_PERI_Agreement_2026.03.24 | Internal-convention mimicry with date suffix |
CISA has specifically warned that malicious actors continue to exploit file format parsing gaps in email security tools, including techniques that rely on malformed documents to bypass sandbox analysis (see CISA cybersecurity advisories). The Microsoft Digital Defense Report 2024 similarly flagged that attackers increasingly use obfuscated or structurally abnormal files to defeat automated scanning (Microsoft Digital Defense Report 2024).
Parse failure is not a pass. Any attachment that produces parser errors, empty streams, or missing structural headers should be escalated automatically rather than defaulted to clean. Audit your email security stack's behavior on malformed files specifically. Vendors rarely test their tools against deliberately broken documents.
Double-extension filenames are a high-confidence signal on their own. Hunt your mail logs for filenames matching the pattern *.docx.pdf, *.xlsx.pdf, *.jpg.exe, or similar combinations. Cross-reference against first-time sender status. The naming pattern alone justifies manual review regardless of AV verdict.
Free-account sender plus AP pretext plus attachment is a distinct attack profile. None of these elements require technical sophistication. Train AP staff specifically on the pattern: external vendor, audit language, specific dollar amount, attachment they did not request.
Authentication passes are table stakes, not clearance. SPF, DKIM, and DMARC passing from a free Gmail account means the attacker knows how to use Google's mail infrastructure. Layer sender history, first-time sender flags, and behavioral signals on top before any external attachment reaches a financial inbox.
The attachment in this case may never have delivered a traditional payload at all. A malformed file that gets a target to call the "sender" to discuss the audit, or to forward the email to AP, or to reply with internal financial records, does not need to contain malware to succeed. The pretext is the attack. The broken file just makes sure the scanner does not notice.