A PDF Invoice Contained Bank Details for a Money-Mule Account

No malware. No credential-harvesting page. Just a PDF with a bank account number and a story designed to make paying it feel urgent and safe.

What the Attack Looked Like

The email arrived as an invoice notification for $1,199.00, due the same day it landed. The body referenced a PayPal-affiliated payment platform and included language warning the recipient that "a payout from your PayPal account is unusual," framing the message as a security alert rather than a routine bill. That framing was intentional: it pushed the recipient toward acting immediately to resolve a supposed security event.

A phone number, 1 (970) 303-2384, appeared in the body labeled as PayPal Account Support. Independent checks confirmed this is not an official PayPal support number. Any recipient who called to "verify" the invoice would have reached the attacker.

The call-to-action link in the body, labeled "Make payment," displayed a destination at app[.]grey[.]co/invoices/..., a legitimate fintech invoicing platform. The underlying href ran through a SendGrid tracking redirect before reaching that destination. The email delivery path was entirely conventional: the message transited SendGrid's outbound infrastructure and entered Microsoft 365 without triggering reputation filters.

The attached PDF, invoice-4779.pdf, was generated by wkhtmltopdf at a timestamp embedded in the document metadata. The file carried no embedded JavaScript, no macros, and no active code. Its scanner verdict was clean. Inside the document, however, a bank payment block listed specific U.S. routing and account numbers at Lead Bank in Kansas City, Missouri, combined with a mismatched payee name. That combination, a domestic bank routing path paired with a foreign-origin payee identity, is the textbook signature of a money-mule receiving account.

Why It Bypassed Defenses

Social engineering worked through layered legitimacy signals. The sending domain passed DMARC via SPF alignment: SendGrid's outbound IP was authorized by the sending domain's SPF record, and the envelope domain aligned with the header From domain. DMARC was configured at p=reject for the receiving domain but passed for the sending domain, so no quarantine action fired. DKIM failed, but DMARC passed on SPF alignment alone, which is sufficient for a passing composite result.

The PDF itself was content-clean. Attachment scanners look for exploits, scripts, and obfuscated executables. A two-page PDF with static text and bank coordinates contains none of those. The fraud payload was the text of the document, not executable content inside it.

The "Make payment" CTA resolved to a legitimate invoicing platform. Link-reputation checks would have found a real, functional website. The malicious content, the bank details inside the PDF and the fraudulent phone number in the body, were one layer removed from the links a scanner would follow.

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

How It Was Caught

Themis flagged the message for multiple combined signals: first-time sender to the mailbox, urgency framing tied to a financial transaction, a payment CTA with a SendGrid tracking redirect obscuring the final path, and a phone number embedded as a verification mechanism. Community-based intelligence from the IRONSCALES platform confirmed the phishing classification. Post-analysis of the PDF attachment revealed the mule-account payment block.

Defender Takeaways

Attachment scans do not catch payment-instruction fraud. A clean malware verdict on a PDF means the file carries no executable threat. It says nothing about the legitimacy of bank account details printed in the document. Finance teams need a separate control: any PDF containing new bank routing or account numbers should require out-of-band vendor verification before payment is authorized, regardless of what the attachment scanner returned.

Fake support phone numbers are a control-bypass. The attacker placed a fraudulent contact number in the email body to intercept any verification call. Train finance and AP staff: always verify banking changes using a number sourced from the vendor's official website or a prior verified communication, never from a number inside the invoice in question. This technique aligns with Business Email Compromise payment-diversion patterns documented in FBI IC3 advisories.

DMARC pass via SPF alignment is not a content endorsement. A DMARC pass (with DKIM failing) confirms that the sending platform was authorized to deliver on behalf of the domain. It does not confirm that the invoice is real, that the payee is legitimate, or that any bank details listed in attachments should be trusted. Treat authenticated delivery as one weak positive signal, not as a clean-bill-of-health for financial action.

Urgency plus security pretext is a reliable BEC escalation pattern. The framing of "unusual payout" turns a routine invoice into a perceived security incident. That framing pressures recipients to act without standard verification steps. Phishing simulations that include financial urgency as a variable are more predictive of real-world susceptibility than generic lure simulations.

---

Indicators of Compromise