When Your Security Vendor Sends You a Fake Invoice: Proofpoint Impersonation, Amazon SES, and a wkhtmltopdf PDF with Live Wire Instructions

Your security vendor just sent you an invoice. Nearly $90,000, due immediately, with a 10% discount that expires today. The attached PDF has a Citibank routing number, a live beneficiary account, and wire transfer instructions that look completely legitimate. The only problem: your security vendor never sent it.

This is the new face of business email compromise. Attackers no longer just impersonate CFOs or vendors your finance team has never heard of. They impersonate the vendor your organization trusts to stop attacks in the first place.

The Anatomy of the Attack: Three Brands, One Payload

The message arrived in the inbox of a controller at a financial services organization with the subject line "[EXTERNAL] Proofpoint Inc Payment Reminder." The display name read "Proofpoint Inc Accounting Department." The authenticated sending address was info@onlineimmigrant[.]com, a registered immigration services domain with no connection to Proofpoint.

That gap between the display name and the authenticated sender is the entire attack surface. Everything else is scaffolding designed to make the recipient look past it.

The email was structured as a forwarded conversation chain, three apparent parties:

1. Proofpoint Inc (top-level message), demanding urgent payment of nearly $90,000 for a renewal invoice, with a same-day deadline for a 10% discount
2. Zelis Payments (embedded forwarded section with full Zelis branding, logos, and a portal login prompt), presenting a "Provider Payment Alert" showing the financial services organization as the named payer
3. The recipient's own institution (referenced in the forwarded context), lending familiarity and creating the impression that the invoice had already been reviewed internally

The billing contact address listed in the top-level message, billing@zelispayments-proofpoint[.]com, did not resolve to any legitimate domain. It was a constructed hybrid identity, fusing two brand names into a single fraudulent contact point that neither company owns.

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

How Amazon SES Laundered the Sending Reputation

The message originated from Amazon SES infrastructure in the eu-west-2 region (d218-16.smtp-out.eu-west-2.amazonses[.]com, IP 23.249.218[.]16). It transited a Mimecast secure email gateway before entering the Microsoft 365 mail path.

At the Mimecast relay layer, the message passed SPF (SES is an authorized sender for the onlineimmigrant[.]com envelope domain), passed DKIM for both onlineimmigrant[.]com and amazonses[.]com, and cleared DMARC because the gateway honored the p=none policy on the sending domain. From the gateway's perspective, the mail was technically clean.

At the final Microsoft receiver, the picture changed: SPF softfail, DKIM body hash mismatch on both signatures, and DMARC failure for header.from=onlineimmigrant[.]com. The message had passed gateway authentication while failing end-receiver authentication, a split authentication result that SEGs frequently resolve in the message's favor, since the gateway's ARC chain asserts that the mail was valid when it entered.

This is SPF and DKIM being weaponized through an authorized ESP. The attacker registered a legitimate domain, provisioned an Amazon SES account, configured proper DKIM signing for that domain, and used SES's trusted IP range to gain relay-level authentication passes. The sending domain's reputation was borrowed, not built, a technique the Verizon 2026 DBIR notes is increasingly common in financially motivated BEC campaigns, which account for only 3% of incidents but a disproportionate share of financial loss.

DMARC at p=none meant that even the final authentication failure triggered no enforcement action, the message was delivered regardless.

The wkhtmltopdf Invoice: A PDF That Text Scanners Cannot Convict

Two attachments arrived with the message. The first was a W-9 form, a trust-building artifact common in vendor impersonation attacks that signals a legitimate business relationship. The second was the payload.

Proofpoint_Invoice_519f4be00d0d460b8927ef1a4eb4c72f.pdf contained a professional-looking invoice header claiming to be from PROOFPOINT INC, 925 W Maude Ave, Sunnyvale, CA 94085, the company's actual address, with a balance due of nearly $90,000 and wire transfer instructions directing payment to a Citibank account (routing number 031100209, SWIFT CITIUS33, and a live beneficiary account number). The instructions specified that the beneficiary was a named account holder.

Static analysis returned clean. There were no embedded scripts, no active content, no macros, no obfuscated JavaScript, no PE executables. The file was exactly what a text scanner looks for in a legitimate invoice.

The PDF metadata told the real story: the file was produced by wkhtmltopdf, an open-source HTML-to-PDF conversion utility. No legitimate enterprise billing system generates invoices with wkhtmltopdf. Real Proofpoint invoices are generated by ERP and CPQ systems whose PDF metadata reflects those origins. This single metadata signal distinguishes a machine-generated fraud document from a corporate invoice, and it is a signal that almost no SEG inspects.

The FBI IC3's 2024 report documents BEC losses exceeding $2.9 billion, with wire fraud via fake invoices being the dominant loss vector. The wkhtmltopdf pattern is a direct evolution of that playbook: move the fraud payload entirely off-link, into a PDF that carries real-looking bank routing data and passes every automated scan.

Tracking Infrastructure and Redirect Chains

The message embedded a 1x1 tracking pixel hosted at gjvqpfr4.r.eu-west-2.awstrack[.]me, an Amazon SES open-tracking endpoint that notifies the sender the moment the email is rendered. This gave the attacker real-time confirmation that the target opened the message, enabling follow-up timing.

Links in the message body displayed www.citynational[.]com, the recipient organization's own institution, but routed through Mimecast protect redirect URLs (url.us.m.mimecastprotect[.]com). A separate link ultimately resolved through an awstrack tracking domain to zelispayments[.]com. Display text and actual destination were decoupled throughout, a deliberate technique to exploit the implicit trust recipients place in visible link text while routing clicks through obfuscating infrastructure.

Why This Gets Through: The Security Vendor Blind Spot

Vendor email compromise succeeds when recipients apply less scrutiny to senders they associate with security. Impersonating Proofpoint specifically is a calculated choice: a finance team member who receives what appears to be an invoice from their email security vendor is unlikely to treat it with heightened skepticism. The irony is load-bearing.

Traditional phishing defenses struggle here for structural reasons. The sending domain was legitimately registered. The ESP was authorized. Gateway authentication passed. The attachment contained no malware. The only reliable detection signals were behavioral and contextual: a display name that did not match the authenticated sender, a first-time sender with no prior correspondence history, PDF metadata inconsistent with enterprise billing systems, urgency and payment pressure in the body, and a fabricated hybrid-brand contact address.

IRONSCALES Adaptive AI and Themis analyze exactly this signal set. Rather than relying on authentication verdicts alone, Adaptive AI evaluates behavioral context, whether the sender has prior correspondence history with the recipient, whether the display name matches the authenticated domain, whether the combination of urgency, payment instructions, and attachment type matches known fraud patterns. The Phishing SOC Agent analysis flagged this message as high-risk across sender, body, and attachment dimensions simultaneously, classifying it as phishing and resolving it automatically.

BEC protection at the gateway layer, governed by DMARC enforcement and display-name mismatch detection, can eliminate the delivery vector. But the wkhtmltopdf payload problem, a clean PDF with a live wire instruction, requires content-layer intelligence that goes beyond static file scanning. IRONSCALES Advanced Malware and URL Protection examines PDF metadata, content structure, and sender context together, not in isolation.

Defensive Takeaways

The three layers this attack exploited map directly to three defensive improvements:

ESP reputation laundering: Enforce DMARC at p=reject for your own domain and treat p=none sender domains as structurally unenforced. Display name authentication, validating that the visible From name matches the authenticated domain, catches impersonation that DMARC alone does not.

PDF content inspection: Flag PDFs produced by wkhtmltopdf, LibreOffice, Chromium headless, or other conversion utilities when attached to messages containing payment language. Enterprise invoices do not come from HTML converters. This single metadata check eliminates a significant slice of invoice fraud that static scanners pass cleanly.

Wire instruction out-of-band verification: Any email containing bank routing numbers, wire transfer instructions, or ACH details, regardless of apparent sender, should trigger a mandatory out-of-band verification workflow before any payment action. CISA's guidance on recognizing and reporting phishing frames this as a procedural control that no technical filter can substitute for. The IBM Cost of a Data Breach 2024 documents BEC as among the costliest incident types precisely because the fraud succeeds after delivery, verification is the last line of defense.

---

Indicators of Compromise

---

MITRE ATT&CK Techniques