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.
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 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.
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
| 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 |
| 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 |