Table of Contents
The email announced the recipient's account was 40 days past due and demanded immediate payment. Attached were two PDFs: a one-page invoice for $47,320.00 with ACH and wire remittance instructions, and a completed IRS W-9 form with a taxpayer identification number. The payment instructions directed funds to a personal account at a national bank. Every document was clean. No macros, no scripts, no embedded links. The attack was pure social engineering.
Authentication That Agreed and Disagreed With Itself
The message was sent from no-reply@system-alert.marketghor[.]com through Amazon SES infrastructure at IP 23[.]251[.]232[.]12. On the original hop, SPF passed, DKIM passed, and DMARC passed for system-alert.marketghor[.]com. The attacker had configured just enough DNS to authenticate outbound mail from a purpose-built domain.
But a downstream relay at esa3.hc3244-53.iphmx[.]com (IP 139[.]138[.]34[.]191) broke alignment. SPF returned a softfail. DKIM failed. DMARC failed. The recipient gateway saw two conflicting authentication stories for the same message: one passing, one failing.
Mixed authentication signals are an underappreciated detection gap. Gateways that anchor on the original hop see a clean message. Gateways that anchor on the final hop see a failure. The attacker does not need both to pass. They need the ambiguity to prevent a confident block.
The Invoice Package That Answered Every Question
The invoice PDF (invoice #AJA2600C672, account 65317590) was generated by HeadlessChrome, a programmatic rendering engine that produces clean, scannable documents with no executable content. Sandbox detonation tools found nothing to flag because there was nothing to detonate.
The remittance instructions listed a personal account for "[Vendor Name]" at a national bank, not a corporate account. This is a significant red flag that automated AP verification workflows should catch: the beneficiary was an individual, not a business entity matching the invoicing company.
The second PDF was a completed W-9 with a TIN. For accounts payable teams that require vendor tax documentation before processing first-time payments, this attachment removes the most common objection. The W-9 looks real. It proves nothing about the legitimacy of the vendor relationship.
The Reply-To and the Forwarding Instruction
Responses were routed to an address at bandbadvisers[.]com, a typosquatted advisory domain separate from the sending address. The email also instructed the recipient to forward remittance confirmation to a specific mailbox at a regional healthcare system. That system publishes DMARC p=none, meaning forwarded messages sent in its name would face no authentication enforcement. This forwarding instruction could serve as a secondary social engineering vector, creating a paper trail that makes the payment appear internally validated.
See Your Risk: Calculate how many threats your SEG is missing
Indicators of Compromise
| Type | Indicator | Context |
|---|---|---|
| Sender Domain | system-alert.marketghor[.]com | SES-backed sending domain |
| Sender Email | no-reply@system-alert.marketghor[.]com | From address |
| Reply-To Domain | bandbadvisers[.]com | Typosquatted advisory domain |
| Sending IP | 23[.]251[.]232[.]12 | Amazon SES origin |
| Relay IP | 139[.]138[.]34[.]191 | Downstream relay (iphmx.com) |
| Invoice PDF | Invoice #AJA2600C672, Account 65317590 | HeadlessChrome-generated, no scripts |
| W-9 PDF | Completed IRS W-9 form | Legitimacy amplifier, not a verification artifact |
MITRE ATT&CK Mapping
| Technique | ID | Relevance |
|---|---|---|
| Phishing: Spearphishing Attachment | T1566.001 | Invoice + W-9 PDF attachments as primary payload |
| Internal Spearphishing | T1534 | Forwarding instruction to healthcare system mailbox |
| Masquerading: Match Legitimate Name or Location | T1036.005 | Vendor impersonation with complete payment documentation |
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.