The PDF That Passed Every Scan Without Being Read

The attachment scanner said "clean." It was right about the file it scanned. It just never scanned the right file.

A phishing email targeting a regional healthcare system in Indianapolis carried a PDF attachment with a filename engineered to break automated analysis. The file extraction pipeline dutifully attempted to read Indianapolis_Live\r\nBroadcast_Digital Invitation.pdf, hit a zero-byte artifact at that path, and returned a verdict of clean. Meanwhile, the actual 376 KB PDF sat untouched in a base64-encoded sidecar file, its contents never examined.

The scanner did its job. It just operated on a decoy that the attacker built into the filename itself.

Two Bytes That Broke the Pipeline

The attack hinges on a pair of control characters: \r\n, a carriage return followed by a line feed. Injected into the middle of the PDF filename, these invisible bytes split what should be a single filename string into two fragments. When the file extraction engine attempted to resolve the path, it encountered a filename that terminated prematurely or resolved to a nonexistent location.

The result: a zero-byte file at the expected extraction path. The scanner evaluated that empty artifact, found nothing malicious (because there was nothing at all), and stamped it clean. The actual PDF content, all 376,261 bytes of it, was stored separately as a .b64 base64-encoded container. Standard automated pipelines do not perform the secondary decode-and-scan step required to inspect it.

This is not a vulnerability in any single product. It is a gap in how file extraction pipelines handle unexpected characters in attachment metadata. Every tool that relies on filename-path resolution to locate the file for scanning is susceptible. The attacker does not need to craft a sophisticated exploit. Two control characters are enough.

According to the Verizon DBIR 2024, email remains the primary initial access vector in over 90% of confirmed breaches. Attachment-based delivery, specifically T1566.001 (Spearphishing Attachment), continues to dominate because attackers find new ways to make files invisible to the tools designed to inspect them.

Authentication Collapsed Across Every Hop

The email arrived from an external partner-style domain, sent via a compromised or hijacked Microsoft 365 account. At the first relay hop, SPF passed, DKIM passed, and DMARC passed. The ARC seal at i=1 recorded all three as valid.

Then the message transited through a Cisco IronPort gateway and a Proofpoint-hosted mail exchange. By the time it reached the recipient's Microsoft 365 tenant, every authentication signal had failed. SPF returned SoftFail. DKIM could not verify the signature. DMARC failed with a policy of quarantine. The ARC chain at i=2 recorded the full breakdown, and compauth returned none with reason 451.

The Received-SPF header tells the story directly: "domain of transitioning ext[.]luye[.]com discourages use of 139[.]138[.]59[.]31 as permitted sender." Whether this reflects a compromised account relayed through unaligned infrastructure or a spoofed sender exploiting misconfigured forwarding, the end result is identical: the recipient's mail system had no trustworthy signal to validate who sent the message.

The FBI IC3 2024 Annual Report documented $2.9 billion in BEC losses, with healthcare among the most targeted sectors. The Microsoft Digital Defense Report 2024 noted a 53% year-over-year increase in identity-based attacks leveraging this kind of legitimate-to-malicious infrastructure pivot.

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

The Lure Was Minimal by Design

The email body contained a single sentence: "Please see info from Season 52, if able to join us." No urgency. No credential request. No embedded links beyond an auto-appended "Outlook for iOS" footer pointing to legitimate Microsoft shortlinks (aka[.]ms). The sender signed off as a named individual, and the message was composed on a mobile device.

This brevity is deliberate. Sparse lure text avoids triggering natural language processing filters that look for urgency signals, financial requests, or credential prompts. The entire social engineering payload is offloaded to the attachment itself: a PDF framed as a digital invitation for an Indianapolis broadcast event. The geographic targeting aligns with the recipient's location, adding a layer of plausibility that generic phishing templates lack.

The technique maps to T1036 (Masquerading) and T1027 (Obfuscated Files or Information). The PDF masquerades as a legitimate event invitation. The filename obfuscation ensures that even organizations with attachment scanning in place never inspect the actual content.

Detection Without the File

IRONSCALES flagged this message despite the clean attachment verdict. The Adaptive AI platform evaluated the full signal stack: DMARC failure at delivery, ARC chain collapse, elevated sender risk score, and behavioral anomalies inconsistent with the sender's historical patterns. The Themis engine returned a 76% phishing confidence rating based on structural and authentication signals alone.

This is the core lesson. When an attacker can make the payload invisible to file-level inspection, detection must come from everything else. Authentication state across relay hops. Sender reputation trajectory. Behavioral consistency. Community-sourced intelligence from organizations that have seen the same sender or the same technique. No single signal caught this email. The convergence of multiple degraded signals did.

The IBM Cost of a Data Breach Report 2024 found that AI-driven detection reduced breach costs by $2.2 million on average. In healthcare, where CISA has issued repeated advisories about phishing targeting patient data systems, the cost of a missed attachment extends well beyond financial loss.

What to Do About It

This is not theoretical. Three actions reduce exposure:

1. Audit your attachment pipeline for control character handling. Test what happens when filenames contain \r, \n, or \0. A zero-byte extraction result should trigger an alert, not a clean verdict.

1. Layer authentication failure into attachment risk scoring. A clean file verdict combined with DMARC failure, ARC collapse, and elevated sender risk should not produce a "deliver to inbox" decision. These signals must compound, not cancel each other out.

1. Require decoded inspection of base64 sidecar files. If your analysis environment stores attachment bytes as .b64 containers when filename parsing fails, those containers must be decoded and scanned as a mandatory secondary step.

The attachment was clean. The file was not. The difference between those two statements is where this attack lives.

IOCs From the CRLF Filename Attack

### MITRE ATT&CK Mapping