The Empty PDF Was Bait for a Phone Call

The attachment was a PDF. It was also completely empty. Its MD5 hash came back as d41d8cd98f00b204e9800998ecf8427e, the well-known signature of a zero-byte file, which means there was nothing inside it to open, render, or execute. A malware scanner had nothing to scan. A sandbox had nothing to detonate.

That was the whole idea.

The message reached the mailbox of a sales executive at a compliance and data-archiving company, one of twenty-nine unrelated external recipients on a single blast. The subject read like routine commerce, an order acknowledgement marked approved. The body pointed the reader at a US phone number. Between the broken file and the friendly prompt to call, the campaign was engineering a specific reflex: a busy person sees a document that clearly failed to arrive, assumes a technical hiccup, and picks up the phone to sort it out. The payload was never code. It was the conversation waiting on the other end of that call.

A Broken File Is a Feature, Not a Bug

Most phishing analysis starts by asking what the attachment does. Here the attachment does nothing, and that absence is the tradecraft. A zero-byte PDF cannot carry a macro, a link, or an exploit, so it sails past every content-inspection control an email stack can throw at it. There is no malicious string to match, no embedded URL to detonate, no script to flag.

What it carries instead is a story. An empty or corrupted document is exactly what a legitimate file looks like when a transfer goes wrong, and that plausibility is what the attacker is buying. The recipient is meant to read the failure as innocent, not hostile, and to resolve it the way the message suggests: by calling. This is a telephone-oriented attack, the pattern the industry has come to call TOAD, and it belongs to the same family as vishing. Once the target is on the line, the fraud runs live, off the record, and outside anything your mail gateway can see. The 2024 Verizon Data Breach Investigations Report notes that the median time for someone to fall for a phishing message is measured in seconds, and a ringing phone compresses that window even further.

The Sending Domain Had No SPF to Fail

The blast came from a real secondary-school domain in Hong Kong, sent through Gmail relay infrastructure. The domain is a genuine institution, most likely a compromised or complicit account rather than attacker-owned property, which makes it a victim in its own right as much as a delivery vehicle.

Critically, that domain publishes no Sender Policy Framework record at all. SPF is the DNS list of servers authorized to send mail for a domain, and when it is absent there is nothing for a receiving server to check the message against. You cannot fail a test that was never written. DKIM added to the confusion rather than resolving it: the signature passed at an intermediate ARC hop, then failed final verification on a body-hash mismatch, and DMARC landed somewhere between none and a best-guess pass depending on which relay you asked. The net effect is a message with no trustworthy authentication story that still reached the inbox, because a domain with no policy triggers no rejection.

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

Mass distribution was the tell that this was spray, not spear. Twenty-nine recipients across unrelated companies and individuals is not a targeted operation. It is a wide net cast for whoever calls back, and volume is the attacker's friend when the follow-up is a manual phone scam.

Mapping to MITRE ATT&CK

The tradecraft lines up with a few techniques in the MITRE ATT&CK framework:

• T1566 Phishing and T1566.001 Spearphishing Attachment cover the delivery: a socially engineered email whose hook is a file, even though the file is deliberately hollow.
• T1598 Phishing for Information covers the callback objective. The attacker is not dropping malware, but fishing for a phone conversation in which the victim volunteers money, credentials, or account access.

Indicators of Compromise

Where Detection Has to Move

Content inspection was never going to catch this, because there is no content. Reputation was shaky at best, because the sending domain is a real school with no policy to score against. Detection has to read intent instead of artifacts: an attachment that weighs nothing, a message that steers the reader toward a phone number rather than a link, a sending domain with no SPF that is a poor match for the commercial subject line, and a broad unrelated distribution list that no legitimate order confirmation would ever use together.

That relationship-level reading is what Themis, the Adaptive AI analyst on the IRONSCALES platform, is built to do, weighing sender behavior, attachment anomalies, and callback signals the way a trained analyst would instead of waiting for a signature. It is the layer that flags a phone-number payload when every server-level check either passes on a technicality or has nothing to check. The Microsoft Digital Defense Report 2024 documents the same industry shift toward abusing trusted services and human trust rather than breaking software, and the FBI's 2023 Internet Crime Report ranks the losses from these social-engineering scams among the heaviest of any category. Across 35,000+ security professionals at 17,000+ organizations, the campaigns that hurt most are increasingly the ones with no malware at all.

The Takeaway

A file that contains nothing can still be the most dangerous thing in the inbox, because the payload has moved off the wire and onto the phone. Treat a broken or empty attachment paired with a call-us prompt as a live callback attempt, not a delivery glitch, and verify order or invoice questions through a channel you already trust rather than a number the message hands you. See how much of this slips past a gateway that only inspects what a file contains, and start reading what the message is actually trying to make someone do.

CISA's guidance on recognizing and stopping phishing early is a solid reference for building that reflex across a team: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one