Table of Contents
An email with the subject "ACH payment" arrived at the accounts receivable team of a global flavoring company. The sender was at a natural products company. SPF passed. DKIM passed. DMARC passed. Composite authentication returned reason=100. The gateway had no reason to intervene.
The entire message payload was a single PNG image. No text in the body. No links. No macros. No attachments to detonate in a sandbox. Just 63,801 bytes of image data that rendered perfectly for human eyes and returned nothing for text-based scanners.
Full Authentication, Zero Provenance
At the final delivery hop, the email from carlaburbo@a-private-company[.]example passed every authentication check. SPF validated because a-private-company[.]example authorized its mail servers. DKIM passed under the domain's selector2 signing key. DMARC aligned. The SCL score was 1.
But the original authentication results told a different story. Authentication-Results-Original showed dkim=none and dmarc=none. The message had no DKIM signature when it was first created. The ARC chain at i=2 returned cv=fail, meaning the forwarding chain of trust was broken.
What happened between origin and delivery? The M365 infrastructure signed the message on behalf of the sender at the relay hop. The sending account's mail server added DKIM and SPF alignment that the original message never had. This is the signature pattern of a compromised account: the attacker sends through the victim's infrastructure, and the infrastructure vouches for the message automatically.
The Image as the Entire Attack Surface
The attachment, image002.png, was the only content. No URLs meant no link scanning. No document attachments meant no macro analysis or sandbox detonation. The PNG carried no extractable text metadata, so OCR-dependent scanning would need to render and read the image to identify its content.
Most gateways do not apply OCR to every image attachment in real time. The image likely contained payment instructions or account details, rendered as a visual document that a human in accounts receivable would process manually. Put the payload where the machines are not looking.
Cross-Company Invoice Context
The sender CC'd their own company's accounts payable address (ap@a-private-company[.]example), reinforcing the appearance of a legitimate inter-company payment communication. The "ACH payment" subject line targeted the recipient's AR workflow directly. For an AR team accustomed to processing vendor payments, this email matched the expected pattern: a known vendor name, a payment reference, and an attached document.
The sending account was compromised. The person behind the email was not who the authentication said it was.
What Behavioral Detection Identified
Themis, the IRONSCALES Adaptive AI engine, flagged this message at 54% confidence. The first-time sender pattern between these two organizations, the image-only payload with no extractable text, and the discrepancy between original authentication (dkim=none, dmarc=none) and final-hop authentication (full pass) are behavioral signals that surface-level authentication checks miss. One mailbox was quarantined based on these signals.
The gateway saw a fully authenticated message from a real company. The behavioral layer saw a compromised account sending an opaque payload to an AR team it had never contacted before.
See Your Risk: Calculate how many threats your SEG is missing
Indicators of Compromise
| Type | Indicator | Context |
|---|---|---|
| Sender Email | carlaburbo@a-private-company[.]example | Compromised account at natural products company |
| Sender Domain | a-private-company[.]example | Full SPF/DKIM/DMARC pass at final hop |
| CC Address | ap@a-private-company[.]example | Sender's own AP team, reinforces legitimacy |
| Attachment | image002.png (63,801 bytes, image/png) | Image-only payload, no OCR text extracted |
| Authentication (Final) | SPF=pass, DKIM=pass (selector2), DMARC=pass, compauth=100 | Full authentication at delivery |
| Authentication (Original) | dkim=none, dmarc=none | No DKIM signature at message origin |
| ARC Validation | i=2, cv=fail | Chain of trust broken on forwarding |
| SCL | 1 | Low spam confidence despite ARC failure |
MITRE ATT&CK Mapping
| Technique | ID | Relevance |
|---|---|---|
| Phishing: Spearphishing Attachment | T1566.001 | Image-only PNG attachment as invoice fraud payload |
| Valid Accounts | T1078 | Compromised email account with full domain authentication |
| Masquerading: Match Legitimate Name or Location | T1036.005 | Legitimate vendor identity used for cross-company invoice fraud |
Related attacks
| Attack | What happened |
|---|---|
| The Invoice That Originated from the Wrong Continent | An invoice fraud email passed SPF from a legitimate domain but carried an x-originating-ip from South Korea with no PTR record. |
| The Payoff Letter With a Blank Body, a Trust Account, and a Token That Said 'bypasszix' | A payoff letter from a law firm domain arrived with a blank email body and payment instructions embedded in a PDF. |
| The Remit-Change Email That Came With Full Bank Details and a PDF Nobody Could Read | A retail analytics vendor sent a payment update email with ACH routing, wire routing, and account numbers directly in the body. |
| The $47,320 Invoice That Came With a W-9 and a Personal Bank Account | A payment diversion attack bundled a $47,320 invoice with ACH/wire remittance instructions pointing to a personal bank account. |
| The Reply-To Was One Letter Off: How a Typosquat Domain Turned a Gmail BEC Into a Payment Diversion | A Gmail-authenticated BEC used a typosquat Reply-To domain and a hidden HTML mailto mismatch to impersonate a steel distributor's credit manager. |
Explore More Articles
Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.