Image-Only Invoice Fraud: How Attackers Hide Mule Bank Accounts from Every Text Scanner

The invoice looked routine. A modest four-figure sum. A familiar supplier name. A JPEG attached. The accounts-payable team at a specialty ingredients company received it from what appeared to be a consumer email address with years of legitimate sending history. SPF passed. DKIM passed. DMARC passed.

Inside the JPEG was a complete set of wire-transfer instructions pointing to a mule bank account at HSBC Australia. No scanner reading the message body or headers would ever see them.

The OCR Evasion Design: Why the JPEG Was the Entire Attack

Standard email security architecture processes text. It reads headers, subject lines, body content, and extracts URLs. When a gateway applies optical character recognition (OCR) to attachments, it is looking for malicious links or keywords in embedded text. This attack was built around the assumption that OCR would fail, or be absent entirely.

The attachment was a single JPEG image file. The payment instructions, including an account number, BSB routing code, reference number, and recipient name, were rendered as part of the image, not as text overlaid on it or embedded in metadata. An automated system trying to extract the account number would need to successfully OCR an image designed to look like a scanned invoice, distinguish the relevant numeric fields from decorative layout elements, and cross-reference those numbers against a known-bad database.

Most gateway OCR implementations do none of this. They look for URLs and phone numbers in free text. A bank account number embedded in an invoice JPEG triggers nothing.

Compromised Sender, Clean Headers, Zero Gateway Signal

The email originated from a legitimate account at a major Australian consumer ISP. This account was not spoofed. An attacker had compromised the account through credential theft and was using it as a sending relay.

Consumer ISP email addresses carry a different trust profile than newly registered domains. An account established years before the attack has a sending history, passes all authentication checks, and in many organizations would be treated no differently from a known vendor contact. The recipient domain had no prior contact history with this specific address, but nothing in the authentication layer signaled a problem.

Account takeover via credential phishing is one of the most common ways attackers obtain sending infrastructure with genuine reputation. Consumer ISP accounts are targeted because they are numerous, often protected by weak or reused passwords, and less likely to have enterprise-grade MFA enforced.

The Payment Instruction Layer: What Was Inside the Image

The JPEG contained a formatted invoice layout. The payment fields specified an account at HSBC Bank Australia, identified by a BSB routing number and account number. The reference field included a plausible supplier invoice code. The dollar amount was sized to fall below thresholds that typically trigger additional approval workflows at mid-size organizations, a deliberate choice that kept the request within normal AP-processing range.

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

The attacker's goal was not a large wire transfer. It was a transfer that would be processed without escalation. The invoice amount and format were calibrated to match what a busy AP clerk would approve as routine. The brand referenced in the subject line is a well-known Australian food and beverage company, lending the request additional contextual plausibility within a food-industry supply chain.

IRONSCALES Adaptive AI flagged this at 53% confidence, labeling it "Image-Based Attack." The signal came not from reading the embedded account details but from the combination of a first-contact sending address, an image-only attachment with no body text providing context, and a subject line that carried payment-context keywords without a corresponding text payload.

Why Invoice Fraud Persists Despite Awareness

The Verizon DBIR 2026 reports that phishing is used as initial access in 16% of breaches, but payment fraud variants cause disproportionate financial damage because they do not require follow-on malware. The attack ends at the wire transfer. There is no payload to sandbox, no C2 to block after the fact.

The FBI IC3 2024 report recorded more than $2.9 billion in Business Email Compromise (BEC) and related payment fraud losses. Image-based invoice fraud sits at the intersection of BEC and payment redirection: a socially engineered request delivered by a compromised account, designed to transfer funds to attacker-controlled infrastructure before anyone notices.

MITRE ATT&CK T1566.001 covers spearphishing attachments as an initial access technique. The IBM Cost of a Data Breach 2024 report shows that social engineering attacks including phishing and pretexting cost organizations an average of $4.88 million per incident, and image-based variants delay detection by removing the text layer that most response workflows depend on. IRONSCALES platform data shows that gateways miss roughly 67.5 phishing emails per 100 mailboxes monthly, with image-based attacks among the most consistently bypassed.

Stopping the Image Invoice Before the Transfer

Accounts-payable fraud of this type requires two things to succeed: a message that clears technical filters, and a human who processes the payment without independent verification. Cutting either one breaks the attack chain.

On the technical side, behavioral analysis of the sender-recipient relationship, combined with image-content anomaly detection that flags invoice-pattern images from first-contact senders, is more reliable than OCR text extraction. The absence of a text body alongside an image attachment is itself a high-confidence signal worth acting on.

On the human side, any payment instruction arriving via email that differs from an established vendor banking record should require a second-channel confirmation, a phone call to a number on file, not a reply to the invoice. This is particularly true for payments referencing unfamiliar account numbers or routing codes.

The attack worked because it was designed to look like something that did not require a second look. That is exactly the design AP teams should train for.

---