The Zero Byte PDF: A Lure With No File Inside

The mail header said it out loud: filesize=0.

The message announced a PDF titled Statement of Investment Selection. It was addressed to a senior private banking officer at a regional private bank and copied to colleagues in the same group, four mailboxes in the tenant altogether. The document at the center of the pretext, the only reason for the email to exist, was declared zero bytes in the message's own attachment metadata.

There was no payload to sandbox. No macro, no embedded object, no malformed structure. There was no file. What arrived instead was a filename, a signed and expiring link into Apple's content delivery network, and an implicit instruction: click through to see the statement you were promised.

An Attachment That Exists Only as a Filename

Apple Mail's large attachment feature does not put big files in the message. It uploads them to iCloud and writes a header describing what the recipient should expect: here, the filename, a MIME type of application/pdf, filesize=0, and an expiry timestamp. Mail clients render that description as something attachment shaped, so the user sees a document tile with a real name and a download prompt. The bytes, if any exist, sit on a CDN behind a URL stuffed with authentication, expiry, and checksum parameters (o, v, x, a, e, k, ckc, ckz).

That is the whole trick. A conventional malicious attachment gives a security stack something to hold: bytes to hash, structure to parse, behavior to emulate. A remote attachment reference gives it a string. Attachment analysis has nothing to analyze, and URL reputation has nothing to condemn, because the host is Apple.

Two File Sizes That Do Not Agree

This is where the case gets strange. The header IRONSCALES parsed for this mail item declares the PDF at zero bytes. The public facing iCloud attachment page shown to recipients carries its own size claim in a URL parameter, sz=42817405, or roughly 42.8 MB. Two claims about the same named file, disagreeing by the entire file.

We cannot confirm either one. No attachment content ever reached IRONSCALES, because the object lived entirely off platform on Apple infrastructure. The honest reading is not that the file was empty, and not that it was 42.8 MB. It is that the message shipped two contradictory claims about a document nobody in the mail path could see, then expected the recipient to settle the contradiction by clicking. To the target, none of that was visible: a private banking officer saw a statement they had reason to expect, a familiar correspondent, and a download button.

The Signature That Broke Between Hops

The message left a consumer webmail account through Gmail's own outbound infrastructure, and at that first relay hop the authentication was immaculate: SPF pass, DKIM pass with a verified gmail[.]com signature, DMARC pass under a policy of none.

By the time it crossed the bank's Mimecast relay into the Microsoft tenant, all of that was gone: SPF softfail against sending IP 170[.]10[.]132[.]61, DKIM fail, DMARC fail with no action taken, and compauth=none reason=405. Only one of those is suspicious. The SPF softfail is ordinary mail plumbing, because the connecting address belongs to the bank's own security gateway rather than to Gmail, and is not authorized to send for the original domain.

The DKIM failure carries the real weight. A DKIM signature covers selected headers plus a hash of the body, so when a relay rewrites URLs in that body, exactly what link protection does, the hash stops matching and the signature breaks. DMARC needs at least one aligned, passing identifier to return a pass, and with SPF softfailing on the relay hop and DKIM invalidated in transit there was nothing left to align. The one signal that genuinely vouched for this sender at origin was unusable exactly where policy got enforced.

A Thread That Already Existed

This was not a cold approach. The sending account had prior correspondence history with these mailboxes and was not a first time sender. An earlier message in the same thread carried a reply style subject naming the same PDF, and the delivery that mattered arrived with an empty subject line behind the external banner.

The download element in the body was labeled in Spanish and paired with a limited availability notice, telling the reader the link would stop working after a stated cutoff. Deadline pressure is the oldest lever in the phishing toolkit, and here it did double duty, because an expiring cloud link really is ephemeral. By the time anyone analyzed it, it could legitimately be gone.

The platform flagged the message as impersonation, but no specific impersonated identity was recorded, and there is no evidence naming one. The verifiable social engineering was simpler than a named lookalike: a known correspondent, a subject line already sitting in the mailbox, and a financial document a private banking officer would plausibly be waiting for. The 2024 Verizon Data Breach Investigations Report puts the median time to click a phishing link at 21 seconds. The FBI's 2023 Internet Crime Report ties more than $2.9 billion in reported losses to business email compromise, and this recipient holds exactly the role those losses travel through.

What stopped it was none of the things the message had already defeated. Not attachment inspection, which had no bytes. Not URL reputation, which saw Apple. Not authentication, which had already failed. The verdict came from behavior: a consumer webmail sender pushing a financial deliverable at a money movement role, a named document with no retrievable content, and a cloud proxy link as the only way forward. Themis, the Adaptive AI analyst inside the IRONSCALES platform, weighed that pattern against what the wider community had seen and pulled the message from all four mailboxes.

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

Indicators of Compromise

MITRE ATT&CK Mapping

• T1566.002 Phishing: Spearphishing Link for delivery through a cloud hosted link dressed as an attachment.
• T1566 Phishing for the broader social engineering approach built on an existing thread.
• T1656 Impersonation for the abuse of an established correspondent relationship, noting that no specific impersonated identity was recorded.

Closing the Remote Attachment Gap

Three changes make this class of lure much harder to land.

Treat a remote attachment reference as a link, not an attachment. If a message advertises a document whose metadata shows no content, the security decision is a URL decision, and it has to hold up when the host is a major cloud provider with a spotless reputation. The CISA phishing guidance is blunt about this: controls that depend on recognizing bad infrastructure fail when the infrastructure is good.

Do not read the last hop's authentication result as the whole story. A DKIM failure at final delivery can mean hostile modification, or it can mean your own gateway rewrote the body, and both look identical in a header dump. Correlate the origin hop against the final hop before drawing a conclusion.

Put the behavioral layer where authentication cannot reach. Financial roles get approached through familiar threads carrying plausible documents, which is why business email compromise protection has to weigh sender relationship, recipient role, and content type together instead of grading domains. None of the signals that convicted this message lived in a hash.

The attacker who built this understood something defenders keep underestimating. You do not need a payload if you can get someone to go looking for one.