Wire Transfer PDF Invoice Passes DLP Gateway with Full Email Authentication

TL;DR A clean PDF invoice requesting $125,400 via wire transfer passed every DLP and authentication check. The sender domain is 20+ years old with a spotless reputation. The PDF contained real JP Morgan Chase routing and account numbers but zero JavaScript, zero links, and zero AcroForms. Only first-time-sender detection and community intelligence flagged the risk.

What Happened

A financial advisory firm sent what appeared to be a routine wire transfer invoice for $125,400. The email passed through a Check Point/Avanan DLP gateway without triggering a single alert. SPF, DKIM, and DMARC all returned passing results. The sender domain has been registered for over 20 years, placing it well outside the window where age-based heuristics would raise concern.

The attached PDF contained JP Morgan Chase routing number 021000021 and an account ending in ...3766. It carried no JavaScript, no embedded links, and no AcroForms. From a payload perspective, every scanner that inspected this file saw a clean document. The fraud was entirely social: a convincing invoice with real banking details, sent to prompt a wire transfer to an account controlled by the attacker.

Why It Matters

DLP gateways are built to catch data exfiltration and malicious payloads. When the payload is a static PDF with legitimate banking formatting and no executable content, DLP has nothing to intercept. The same applies to email authentication protocols. SPF, DKIM, and DMARC confirmed that the sending server was authorized for the domain. They did their job. The problem is that authentication answers "who sent this" but never "should you trust what they are asking you to do."

This is where behavioral signals become critical. The sender had never communicated with the target organization before. That single data point, first-time sender from an external domain requesting a six-figure wire transfer, is the highest-value signal in the entire email. No gateway evaluated it.

How IRONSCALES Caught It

Adaptive AI email security flagged this message through first-time sender analysis combined with community intelligence. While the PDF was clean and the authentication was flawless, the behavioral profile of the communication was anomalous. A new sender, a high-dollar payment request, and banking details embedded in a static PDF triggered escalation before the invoice reached the finance team.

The combination of sender reputation analysis, organizational communication history, and cross-tenant pattern matching surfaced what no single-layer gateway could detect on its own.

See Your Risk. Run a free phishing simulation to find out how many invoice fraud emails would reach your finance team today.

Indicators of Compromise

IndicatorTypeValue
Case IDInternal5bf5b4c78c847224c68c4349a45c0a48
Routing NumberBanking021000021 (JP Morgan Chase)
Account FragmentBanking...3766
Invoice AmountFinancial$125,400
PDF CharacteristicsAttachmentNo JS, no links, no AcroForms
Sender Domain AgeInfrastructure20+ years
SPFAuthenticationpass
DKIMAuthenticationpass
DMARCAuthenticationpass

MITRE ATT&CK Mapping

TacticTechniqueIDNotes
Initial AccessPhishing: Spearphishing AttachmentT1566.001Clean PDF invoice delivered via email
CollectionData from Information RepositoriesT1213Banking details embedded in PDF
ImpactFinancial TheftT1657Wire transfer request for $125,400
Defense EvasionTrusted RelationshipT1199Aged domain with established reputation
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
Crystal Reports Invoice Fraud with NULL Address Fields Routed Through Exclaimer RelayA Crystal Reports-generated PDF invoice with NULL placeholder address fields passed DKIM and DMARC but failed SPF through an Exclaimer relay.
The Reply-To Was One Letter Off: How a Typosquat Domain Turned a Gmail BEC Into a Payment DiversionA Gmail-authenticated BEC used a typosquat Reply-To domain and a hidden HTML mailto mismatch to impersonate a steel distributor's credit manager.
Portuguese Invoice Fraud with Same-Day Due Date and Reply-To MismatchA Portuguese-language invoice fraud email sent from Hotmail with full authentication carried a Reply-To address different from the sender.
The $47,320 Invoice That Came With a W-9 and a Personal Bank AccountA payment diversion attack bundled a $47,320 invoice with ACH/wire remittance instructions pointing to a personal bank account.
Every Authentication Check Passed. There Was Nothing to Scan. The Attack Was the Reply.A fully authenticated email with no links, no attachments, and no malicious content asked recipients to reply all.

Explore More Articles

Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.