Authenticated Sender, Forged Instructions: How a Remittance Update Passed Every Check

SPF passed. DMARC passed. Composite authentication scored 100. The sending IP resolved to Oracle Cloud Email Delivery in Frankfurt. The domain, shoppertrak[.]com, has been registered since 1997 and belongs to Tyco Fire & Security GmbH. Every authentication signal said this email was legitimate.

The email asked the recipient to update their payment records with new bank routing numbers and a new account number. No invoice was referenced. No dollar amount was stated. Just: "Please update your records with the payment information below."

That single sentence is the entire payload. And it passed every check.

Anatomy of a Remittance Diversion

Business Email Compromise (BEC) comes in several forms. The most visible is invoice fraud, where attackers fabricate a specific bill and demand immediate payment. Remittance diversion is quieter and often more damaging. Instead of requesting a one-time payment, the attacker asks the target to change the standing bank details on file for a vendor. If successful, every future payment to that vendor flows to the attacker's account until someone notices.

According to the FBI's IC3 2024 Internet Crime Report, BEC accounted for over $2.9 billion in reported losses. Remittance diversion is a significant contributor because the lag between compromise and detection can stretch for weeks or months.

This attack followed the classic remittance diversion playbook:

The email body contained explicit wire transfer instructions: ACH routing number, wire transfer routing number, account number, and a BIC/SWIFT code. It also provided a lockbox mailing address for check payments. The instructions pointed to JPMorgan Chase, N.A. in New York. No invoice number or amount accompanied the request.

The attachment (9125PANDR000059_71017945_12072020.pdf, 22KB) was a single-page PDF generated by Oracle Analytics Publisher. Its content was rendered as an embedded image object rather than extractable text. Standard PDF text extraction returned nothing. No embedded files, no JavaScript, no hyperlinks in the raw PDF structure. The visual content of the PDF could only be read by a human or by OCR.

The ask was minimal and procedural: update your records. No urgency language. No deadline. No threat. This deliberate restraint is a hallmark of sophisticated payment fraud, designed to blend into routine accounts payable workflows rather than trigger suspicion.

See Your Risk: Calculate how many threats your Secure Email Gateway is missing

Why Every Scanner Said "Clean"

The authentication results on this email were as strong as they get:

• SPF: Pass. The sending IP 147[.]154[.]189[.]195 is explicitly authorized for shoppertrak[.]com.
• DKIM: Not signed. No DKIM signature was present on the message.
• DMARC: Pass. The alignment check passed based on SPF.
• Composite Authentication (compauth): 100. Microsoft's own trust scoring gave this email a perfect score.
• SCL: 1. Low spam confidence.

The relay chain confirmed the message originated from Oracle's EU-Frankfurt data center (smtp4.email.eu-frankfurt-1.ocs.oraclecloud[.]com) and was delivered through Microsoft's inbound protection stack. Nothing in the delivery path was anomalous.

The Verizon 2024 Data Breach Investigations Report found that social engineering, including BEC, remains one of the most common breach patterns. When infrastructure is legitimate and authentication is clean, the only detection surface left is content and context.

The Image-Based PDF: Invisible to Text Scanners

Oracle Analytics Publisher generates reports as image-based PDFs: the page content is a rasterized image embedded in a PDF container. Security scanners attempting text extraction find an image XObject and nothing else. No text strings. No URLs. No parseable content.

Many email security gateways rely on text extraction to flag suspicious attachment content. Keywords like "routing number," "wire transfer," or "update your records" would trigger heuristic rules if they appeared as text. Rendered as pixels inside an image, they are invisible.

MITRE ATT&CK T1566.001 (Spearphishing Attachment) documents malicious attachments as a delivery mechanism. This attachment contains no executable code, no macros, and no exploit. It is a static image of payment instructions. But the image-based format is itself the evasion technique. IBM's 2024 Cost of a Data Breach Report found that BEC attacks carry among the highest per-incident costs, precisely because they bypass technical controls and rely on human action.

The Gap Between Authentication and Verification

The SOC analysis of this case surfaced a critical finding: "authenticated sender domain but content couldn't be independently verified." This is the core problem.

Authentication answers one question: did this email come from infrastructure authorized by the claimed sending domain? Yes. Oracle Cloud Email Delivery is authorized to send for shoppertrak[.]com. SPF includes it. DMARC passes.

Authentication does not answer a second question: are the payment instructions legitimate? The routing numbers, the account number, none of these can be validated by authentication protocols. The SOC could not confirm whether these remittance details were genuine ShopperTrak banking information or attacker-supplied diversion coordinates. That ambiguity is the weapon.

This maps to MITRE ATT&CK T1036.005 (Masquerading: Match Legitimate Name or Location) and T1657 (Financial Theft). The attacker, whether through a compromised account, an abused third-party service, or an exploited sending channel, leveraged ShopperTrak's authenticated infrastructure to deliver content that no automated system could independently validate.

For the target organization, a multi-brand retail operations firm whose finance team was flagged as a VIP recipient, this email would have appeared entirely routine. An AR department updating payment details. A PDF with banking information. A recognized vendor name in the From header. Themis, the IRONSCALES Adaptive AI analyst, returned null confidence on this email. The case was escalated to analyst review, where it was confirmed as phishing. That outcome reflects the genuine difficulty: when authentication is perfect and the payload is a static image, human judgment becomes the decisive layer.

What Defenders Should Prioritize

Separate authentication from content trust. SPF, DKIM, and DMARC prove origin. They do not prove intent. Any process that treats a fully authenticated email as inherently safe is vulnerable to this class of attack. CISA's phishing guidance reinforces that authentication alone is insufficient for trust decisions.

Require out-of-band verification for remittance changes. When any sender, even a known vendor with perfect authentication, requests a change to stored banking details, verify through a phone number from your vendor master record. Not a phone number from the email. Not a reply to the email. A completely independent channel.

Inspect image-based PDFs with OCR. If your email security stack cannot perform optical character recognition on PDF attachments in real time, image-based payment instructions will pass through unexamined. This is a measurable gap worth testing in your BEC protection evaluation.

Flag remittance updates with missing context. A payment instruction with no invoice number, no dollar amount, and no reference to a specific transaction is structurally incomplete. AP teams should treat missing context as a risk signal, not a simplification.

---

Indicators of Compromise