No Text, No Links, No Forms: How an Image-Only ACH PDF Bypassed DLP for Payment Diversion

The subject line read: "Signed ACH draft authorization." The body read: "Please see attached." The attachment was a 250 KB PDF titled "2026 06 03 signed auto debit.pdf."

Static analysis of the PDF returned clean. No JavaScript. No OpenAction. No embedded links. No AcroForm fields. What the scanner could not see, because there was nothing text-based to parse, was a scanned JPEG embedded in the PDF container carrying visual bank account and routing numbers, a signature block, and direct-debit authorization language. The financial payload existed entirely as pixels.

How an Image XObject Defeats Text-Layer Inspection

PDF parsers extract text from content streams and ToUnicode maps. They index link annotations and form field definitions. They flag JavaScript and embedded executables. What they do not do, by default, is run optical character recognition on image objects.

The PDF in this case contained a single image XObject, a JPEG scan of a signed authorization form. No text stream. No AcroForm. No annotations. When the attachment scanner processed the file, it found an image inside a PDF, confirmed no executable or link content, and returned a clean verdict. From the scanner's perspective, the verdict was accurate. There was genuinely nothing technical to flag.

The routing numbers and account numbers the attacker wanted the victim to process were present in the image. They were simply invisible to the inspection layer that produced the clean verdict. This is the defining characteristic of image-based phishing: the payload is real, the scanner result is accurate, and the gap between those two facts is the attack surface.

MITRE ATT&CK T1566.001 applies to the attachment-based delivery. T1036 (masquerading) covers the sender's impersonation of an in-domain controller identity from an external address. T1657 (financial theft) is the operational objective: redirect an ACH payment to attacker-controlled banking details embedded in the image.

The First-Time Sender as a Behavioral Signal

The From address was ARiggins@rusindustrial[.]com. The domain is real: registered in 2014, actively maintained, with published SPF, DKIM, and a DMARC policy of p=quarantine. Authentication headers from the initial relay showed SPF/DKIM/DMARC pass. The message then traversed a content-sanitization relay (votiro-relay2.prod.votiro.com, hosted on AWS in Ashburn, VA) before reaching the recipient's mail platform. That relay rewrote the message in a way that broke DKIM body-hash verification for downstream ARC authentication results, a normal behavior for content-disarm services and not evidence of spoofing.

The issue was not that the domain was fraudulent. It was that this sender had never emailed this recipient organization before. A first-time external sender presenting themselves as an internal financial controller with an ACH authorization attached is a behavioral anomaly regardless of how clean the authentication chain looks.

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

There was a secondary signal in the signature block: the cell number carried an area code (+1-918) that did not match the company's publicly known geographic footprint. That mismatch is not proof of fraud, but it is the kind of detail that independent verification would surface before any payment instruction is acted on.

Business email compromise operations have iterated toward image-based payloads precisely because text-based controls have matured. Wire fraud instructions embedded in attached images predate image-only PDFs. The Jan 20, 2025 case in this series documented full bank routing numbers delivered as a 6MB image attachment. The ACH variant here is the same pattern applied to a scanned authorization form: the attacker does not need to compromise the sending domain or forge authentication headers if the financial instruction travels as an image that scanners cannot read.

Why Clean Authentication Does Not Authorize the Payment

The domain rusindustrial[.]com has real authentication infrastructure. DMARC p=quarantine means the domain owner has taken steps to protect their sending identity. A DKIM pass from that domain confirms the message was submitted by an authorized sending server for that domain.

None of that verifies that the person who submitted the message had authority to authorize a payment on behalf of the recipient's organization. Authentication answers "did this message come from this domain?" It does not answer "is this ACH instruction legitimate?" Those are different questions, and accounts payable workflows that conflate them are the gap this attack class exploits.

IRONSCALES flagged the combination: minimal body text, financial subject line, first-time external sender claiming an internal identity, image-only PDF attachment with no inspectable financial content, and mixed authentication signals post-sanitizer relay. The attack is a phishing pattern that exploits the authentication-versus-authorization gap: the email is technically legitimate, but the instruction inside it is not. Behavioral context (who is this sender, have they contacted us before, does this communication pattern match how internal controllers operate) is what distinguishes a processed payment from a prevented loss.

Accounts payable teams receiving ACH authorization forms from external senders should verify through a known-good phone number before any processing, regardless of what the scanner verdict says about the attachment.

Indicators of Compromise