The Remit-Change Email That Came With Full Bank Details and a PDF Nobody Could Read

The email asked the recipient to update their payment records. It provided ACH routing, wire routing, a full account number, and a SWIFT code, all directly in the body. No invoice number. No dollar amount. No prior thread. Just: "Please update your records with the payment information below."

The sender domain belonged to a retail analytics vendor. SPF and DMARC both passed under a p=reject policy, the strictest configuration available. The message was transmitted through Oracle Cloud Email Delivery infrastructure at 147[.]154[.]189[.]195. Nothing about the authentication chain raised a flag.

The Body Carried the Payload

The most unusual aspect of this attack is the placement of financial details. ACH routing, wire routing, and a full account number sat in plain text in the email body. Most invoice fraud campaigns embed payment instructions in PDF attachments to evade body-content scanning. This one did both: the details appeared in the message and in the attachment, ensuring the recipient saw them regardless of whether they opened the PDF.

The absence of context is the behavioral tell. Legitimate remittance updates reference a specific invoice, contract, or purchase order. They arrive within an existing thread or through an established payment portal. This message provided full banking coordinates with no transactional anchor, a pattern consistent with business email compromise payment diversion campaigns where the attacker needs the recipient to update records before the next payment cycle.

The PDF That Scanners Could Not Read

The attached PDF, 9125PANDR000059_71017945_12072020.pdf, was 22 KB and a single page. It was generated by Oracle Analytics Publisher and rendered its entire content as an image. No text layer. No selectable characters. No embedded URLs or JavaScript.

For automated scanners, this PDF was effectively blank. Text extraction returned nothing because there was nothing to extract. The file was technically clean: no macros, no links, no executable code. Every scanner that inspected it returned a clean verdict because the threat surface it was designed for (text analysis, link inspection, macro detection) simply did not exist in this file. The only way to analyze the content was OCR, and most email security gateways do not apply OCR to PDF attachments by default.

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

Where Authentication Ended and Behavior Began

DMARC p=reject passed. SPF passed. The sending infrastructure was legitimate Oracle Cloud infrastructure. Every technical gate gave this message a green light.

Themis flagged the behavioral pattern: an unsolicited email from a vendor domain with no prior communication history, containing full banking coordinates, referencing no specific transaction, and carrying an image-based PDF with no extractable content. The combination of signals, not any single indicator, triggered the detection.

Indicators of Compromise

MITRE ATT&CK Mapping