Threat Intelligence

The Invoice Attachment Was Empty. The Attack Was Not.

Written by Audian Paxson | Oct 30, 2025 11:00:00 AM
TL;DR An email impersonating a billing contact at a legitimate IT services provider demanded $10,505.25 in overdue invoices and threatened service restriction. It passed SPF, DKIM, and DMARC through Amazon SES infrastructure, and every visible link resolved to real vendor pages. The attached PDF was zero bytes, returning the canonical empty-file MD5 hash d41d8cd98f00b204e9800998ecf8427e. Behavioral anomalies, including the empty attachment, duplicated body content, formatting errors in the signature block, and first-time sender status, were the only detection surface.
Severity: High Invoice-Fraud Phishing MITRE: T1566.001 MITRE: T1656 MITRE: T1583.006 MITRE: T1657

The PDF claimed to contain overdue invoices totaling $10,505.25. It contained nothing. Zero bytes. No pages, no text, no embedded objects. Its MD5 hash was d41d8cd98f00b204e9800998ecf8427e, the canonical fingerprint of an empty file, one of the most recognized hashes in digital forensics. Every incident responder who has ever hashed a null artifact knows that string by heart.

Yet the email carrying this empty file passed every authentication check a modern email stack performs. SPF passed. DKIM passed for both the sender domain and Amazon SES. DMARC passed. The sender domain belongs to a legitimate U.S. data center and IT services provider. Every visible link in the message resolved to real pages on the provider's website. Microsoft SafeLinks wrapped the URLs, analyzed them, and found nothing malicious. From a gateway perspective, this email was clean.

An Invoice With Nothing Inside

The message arrived with a subject line referencing a specific invoice number, a past-due total of $10,505.25, and the phrase "First Past Due Reminder." The body text demanded payment, warned that services would be restricted if the balance was not resolved within 20 days, and escalated to a collections threat. The language matched the cadence of legitimate accounts receivable communications from managed IT vendors.

An [EXTERNAL] origin banner was present, but external banners are only useful when the content behind them looks suspicious. The sender domain was real, the branding was real, and the payment portal link pointed to a legitimate customer account page.

The attached file was named in a pattern consistent with automated billing systems: a vendor prefix, document type, and a long numeric string resembling a timestamp. Recipients accustomed to receiving PDF invoices from IT vendors would have no reason to question the format. The file was simply empty.

Why Every Authentication Check Passed

The email was sent through Amazon Simple Email Service (SES). The sending IP 54[.]240[.]64[.]201 belongs to Amazon's SES infrastructure. SPF passed because 54[.]240[.]64[.]201 is an authorized sender for amazonses[.]com. DKIM passed twice: once for the IT services provider's domain and once for amazonses[.]com. DMARC passed because the header From: domain aligned with the DKIM signature.

SPF, DKIM, and DMARC answer one question: "Was this email sent by a server authorized to send on behalf of this domain?" If an attacker compromises a legitimate SES account or gains access to any authenticated sending path, the answer is yes. The authentication is technically correct. The email is still fraudulent.

According to the 2024 Verizon Data Breach Investigations Report, phishing remains a leading initial access vector in confirmed breaches, and the human element is present in a majority of all breaches. Attacks that pass authentication while relying on social engineering pressure, like an overdue invoice from a trusted vendor, sit squarely in both categories.

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

The Anomalies Scanners Could Not See

The gateway had no malicious payload to detect. The PDF was empty. The links were clean. The authentication was valid. But four behavioral anomalies were visible to any system capable of looking beyond content:

First-time sender. The billing contact address had never communicated with the recipient organization before. For a "past due reminder" implying an existing business relationship, this is a contradiction. A first invoice from a new vendor is expected. A past-due follow-up from a sender with no communication history is not.

Zero-byte attachment. The file was literally empty. Whether this represents a failed payload delivery, an engagement-testing probe, or a social engineering tactic designed to prompt the recipient to reply asking for a resend, the result is the same: an email that claims to attach invoices but delivers nothing.

Duplicated body content. The entire message body was repeated, a rendering artifact consistent with misconfigured sending tools that concatenate HTML and plain-text parts incorrectly. Legitimate billing platforms do not produce this.

Signature block formatting errors. The sender's name appeared as a single run-together string with no space between first and last names. Professional billing systems generate properly formatted signature blocks. This suggests the email was assembled outside the provider's standard billing workflow.

These are not signals a Secure Email Gateway evaluates. Gateways inspect content: URLs, attachments, headers, reputation scores. Behavioral signals like communication history, attachment plausibility, and template formatting consistency require a different detection layer entirely.

The AWS Tracking Chain

Every link in the email body followed the same routing pattern. The visible anchor text displayed a legitimate vendor URL. The underlying href first routed through Microsoft SafeLinks (safelinks[.]protection[.]outlook[.]com), then to awstrack[.]me (Amazon SES click tracking), and finally to the real vendor page. A tracking pixel from awstrack[.]me was also embedded in the message body, confirming the sender was using SES open-tracking to monitor recipient engagement.

This tracking infrastructure is not inherently malicious. Amazon SES provides it as a standard feature for transactional and marketing email. But in context, the attacker (or the compromised account operator) was actively monitoring which recipients opened the email and clicked through. For a zero-payload probe, that telemetry is the entire point. The empty PDF and the urgent invoice language exist to drive opens. The tracking chain exists to record them. The IRONSCALES platform identified this behavioral pattern, flagging the mismatch between a high-urgency payment demand and a zero-content attachment alongside the first-time sender signal.

MITRE ATT&CK Mapping

StepActionMITRE Technique
1Attacker sends invoice email through Amazon SES using a legitimate IT services provider domainT1583.006
2Email impersonates a billing contact at the provider with fabricated invoice detailsT1656
3Spearphishing attachment (zero-byte PDF) delivered via emailT1566.001
4Payment demand for $10,505.25 with service restriction threatT1657

Zero-Byte Invoice IOCs

TypeIndicatorContext
Email[sender]@tierpoint[.]comSender address (name anonymized)
Domaintierpoint[.]comLegitimate IT services provider domain used in attack
Domainamazonses[.]comSES sending infrastructure, DKIM-signed
IP54[.]240[.]64[.]201Amazon SES sending IP
Domainawstrack[.]meSES click/open tracking domain
Hash (MD5)d41d8cd98f00b204e9800998ecf8427eZero-byte PDF attachment (canonical empty-file hash)
URLhxxps://safelinks[.]protection[.]outlook[.]com/...SafeLinks wrapper in link chain

What to Do Before the Next Empty Attachment Lands

  1. Monitor for zero-byte and near-zero-byte attachments. An attachment that exists but contains nothing is never legitimate business communication. Build detection rules or alert thresholds for files under 100 bytes attached to financial-themed messages.
  1. Weight first-time sender signals in financial contexts. A past-due invoice from a sender with no prior communication history is a logical contradiction. Behavioral analysis that cross-references sender history against the urgency and financial nature of the request catches what authentication cannot.
  1. Inspect AWS tracking chains in unexpected contexts. SES tracking links and pixels are routine in marketing email. They are unusual in vendor billing communications. If an invoice email routes through awstrack[.]me, it was sent via Amazon SES, not the vendor's standard billing platform. That infrastructure mismatch is worth investigating.
  1. Do not rely on link destination analysis alone. Every link in this email resolved to a legitimate vendor page. URL scanning returned clean verdicts. The threat was not in where the links pointed but in what the email asked the recipient to do.
Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 35,000+ security professionals. Each post breaks down a real attack. What it looked like, why it worked, and what to do about it.

Related attacks

Attack What happened
Sign Here, Get Phished: Inside an Adobe Sign Lure With a Multi-Hop Redirect to Credential TheftAn Adobe Sign e-signature lure routed recipients through a multi-hop redirect chain ending at fameklinik[.]com.
When the Safety Wrapper Becomes the Disguise: Brazilian NF-e Phishing via Safe Links RewriteA Portuguese-language invoice lure authenticated through a compromised Brazilian domain used is.gd to hide its payload.
The Email That Shipped With Its Template Tokens Still In It (And Still Worked)An attacker's mail merge failed.
DocuSign Plus Invoice: A 12-Day-Old Domain and an esvalabs Redirect Chain That Scanners MissedA phishing campaign combined DocuSign branding with an invoice thread pretext, sent from a 12-day-old privacy-protected domain via Amazon SES.
When the Phishing Kit Ships Early: Exposed Template Variables Reveal Attack InfrastructureA premature phishing kit deployment exposed raw template variables in the subject line and a placeholder URL.