invoice fraud / vendor account change — methodology

what evidence exists and how fast it dies

the first 10 minutes

1. stop the wire or ach if humanly possible — call the bank, not email.
2. save the suspicious email and any prior legit vendor thread as .eml — do not forward.
3. preserve the attached pdf exactly as received — hash before opening in a reader.
4. pull the vendor master record: approved remittance account, last change date, who approved.
5. export mail gateway quarantine for the invoice number and both sender domains — 14 days back.
6. search ap mailbox for the same invoice id, attachment hash, or lookalike domain across all threads.
7. photograph or save the wire / ach confirmation with timestamp and beneficiary account.
8. notify finance to freeze further outgoing payments to that vendor pending review.
9. pull whois for the sender domain and any homoglyph lookalike — grab at triage time.
10. begin the path below.

the path

1. 1. email header analyzer

   fraudulent .eml as saved — never forwarded. surfaces lookalike from (apex-industrlal.com vs apexindustrial.com), external reply-to redirect, dmarc fail, and spf pass on attacker-controlled envelope.why first: invoice fraud starts with a believable vendor email. header identity fields separate the lookalike domain from the real vendor before you touch the attachment.

2. 2. email thread reconstructor

   fraud .eml plus legitimate vendor thread. maps in-reply-to / references chains — the cole fixture hijacks a real COLE-INV-7721 thread with a forged reply on a homoglyph domain.why second: 'revised remittance instructions' only works if the message looks like it belongs in an existing invoice conversation. thread reconstruction proves whether the parent message-id actually exists in your saved set.

3. 3. email header chain analyzer

   deep parse of received hops and origin ip. the cole pack enters from 198.51.100.55 through mail.apex-industrlal.com — external relay, not the vendor's normal mx path.why third: lookalike domains pass spf because the attacker owns the envelope domain. hop timing and origin ip expose infrastructure the real vendor never used.

4. 4. pdf object explorer

   attached invoice pdf before opening in a reader. maps object tree, info dictionary, and xref layout — flags incremental append structure on the tampered remittance block.why fourth: ap teams open pdfs immediately. structural map first avoids executing anything embedded and shows whether the file is a single export or a stitched revision.

5. 5. pdf forensics

   full pdf scan — two xref sections, dual startxref pointers, info metadata vs visible content. confirms incremental update on COLE-INV-7721 before author-level diffing.why fifth: a wiring-block swap is almost always an incremental append. xref count is the fast signal that the pdf changed after initial creation.

6. 6. pdf author revision metadata analyzer

   info snapshots across xref sections. cole fixture shows author drift (maria chen → pdfsharp generator), producer chain flip (adobe pdf library → pdfium), and moddate after the legit send window.why sixth: the on-screen invoice number matches — metadata revision history does not. author/producer drift across xref sections is the document-side smoking gun.

7. 7. document metadata genealogy tracer

   fraudulent pdf, original pdf, and both source docx branches. links template clusters, creator_transfer edges, and incremental_pdf flags across the full artifact set.why seventh: invoice disputes are multi-file. the fraudulent docx lastModifiedBy (pdfsharp) disagrees with maria chen on the legitimate branch while both claim the same invoice id.

8. 8. metadata inconsistency finder

   cross-file pass on pdf + docx set. surfaces producer mismatches, post-send modified dates, author network divergence, and timeline gaps between email send and document modtime.why last: builds the inconsistency report finance and counsel need — one table tying email thread timing to document metadata drift before wire recall windows close.

common false leads

• spf passed so the email is legitimate — spf validates the envelope on the lookalike domain the attacker controls, not the vendor domain ap recognizes.
• the reply chain looks real — in-reply-to headers are trivially forged to sit on top of a genuine vendor thread.
• the invoice number and amount match — fraud swaps the wiring block, not the line items ap already approved.
• the pdf looks identical on screen — incremental edits append a new xref section; visual diff misses metadata drift.
• vendor confirmed the bank change by phone — callback fraud uses lookalike numbers. verify against the master record on file, not the number in the email signature.

what we can tell you, what we can't

we can tell you:

• header-level proof of lookalike domain and reply-to redirect
• thread hijack indicators across fraud and legitimate .eml sets
• incremental pdf structure and author/producer revision drift
• cross-file metadata genealogy across pdf and docx branches
• timeline inconsistencies between email send and document modified dates

we can't tell you:

• recover the wire or ach — that is the bank's job within recall windows
• whether ap followed internal dual-approval policy — audit and counsel territory
• attribute the actor — fbi ic3 / law enforcement territory
• live vendor bank verification — you need the master record from your erp

handing it off

• finance / treasury: wire confirmation, beneficiary account mismatch proof, recall request in writing, freeze on further vendor payments pending review.
• law enforcement (fbi ic3): original .eml set, preserved pdfs with sha-256, header analysis output, lookalike domains, hop origin ip.
• outside counsel: metadata inconsistency report, preservation log — what you saved, when, hashes of all exports.

further reading

• FBI IC3 · business email compromise alerts
• CISA · business email compromise
• MITRE ATT&CK · phishing

reference investigation