Stopping a $3.2M Vendor-Impersonation Wire 4 Minutes Before Send

A $3.2M wire to a long-term vendor was queued for release when Phoenix detected a domain registered 18 days earlier. Human reviewers had seen the invoice three times and approved it.

Background

It was a Thursday in late September — Q3 close week, one of the busiest periods for the finance team. The invoice had arrived eight days earlier and moved through three levels of review without a flag. It referenced a real contract, a real vendor name, and a two-month email thread. The only change was a note, buried in paragraph three, updating bank account details "following our banking partner switch."

What Happened

The finance manager who approved the final sign-off had worked with this vendor for three years. The invoice amount — $3,212,000 — was large but within normal range for their Q3 settlement. She had no reason to pause. The wire was queued for the 3:01 PM processing window.

What nobody noticed: the sender domain was zenith-vendor-corp.com, not zenithvendorcorp.com. One hyphen, registered 18 days before the attack.

Timeline

2:47 PM	Invoice approved by finance manager; outbound wire queued for 3:01 PM window
2:49 PM	Phoenix flags domain zenith-vendor-corp.com (18 days old) and beneficiary account not seen in 24 months of transaction history
2:51 PM	Dual-control hold triggered automatically; wire frozen before processing
2:52 PM	Phoenix investigator calls finance manager to explain the hold
2:58 PM	Callback to vendor CFO on file phone number: vendor had sent no invoice and was unaware
3:01 PM	Wire processing window passes. Funds never leave.
3:40 PM	Attacker kit reverse-engineered; IOCs shared with 14 peer institutions

How We Responded

1. Domain + beneficiary fingerprinting. Phoenix cross-referenced the sender domain against a 24-month baseline of all vendor communications. A domain registered 18 days earlier with a new beneficiary account triggered a critical-risk wire score within 90 seconds of approval.
2. Automated dual-control hold. No human needed to make a judgment call. When the risk score crossed threshold, the wire was automatically placed on hold — buying the team the minutes they needed to investigate.
3. Out-of-band vendor verification. Our investigator called the vendor's CFO on the phone number in Zenith's own vendor master file — not any number from the email thread. The vendor had sent no invoice. The attacker had intercepted and spoofed an existing thread.
4. IOC sharing with peer institutions. We reverse-engineered the attacker kit — phishing infrastructure, BEC playbook, lookalike domain pattern — and shared indicators with 14 peer banks and the FS-ISAC within the same afternoon.

What Almost Went Wrong

The wire auto-clears without dual-control review for transfers under $3M. The attacker had likely originally planned a $2.9M wire, but inflated the amount to match the actual contract value — which accidentally pushed it over the threshold Phoenix monitors. A $2.9M attempt would have cleared automatically. The attacker's own greed saved Zenith.

Outcome

• Funds lost: $0
• Response time: 4 minutes
• Peer banks notified: 14
• Detection latency: 90 seconds post-approval

Key Takeaways

• BEC attackers study your vendor relationships. They know your invoice cycles, your approval chains, and your Q3 deadlines — often from prior email compromise.
• A domain registered in the last 30 days sending a high-value invoice is a bright red flag. This rule alone would have stopped this attack before human review ever saw it.
• Out-of-band verification must use contact details from your own systems — never from the email being questioned.
• Dual-control thresholds need to be tuned regularly. Attackers know where your auto-clear limits are.