A Compromised Vendor Account Sent an ACH Redirect With a Fabricated Closure Deadline and Mismatched Phone Numbers

TL;DR An attacker operating through a compromised vendor account sent an ACH banking-change request to a construction firm's accounts payable contact. The message fabricated a same-day deadline (account scheduled for closure today) to create urgency without any supporting documentation or prior invoice context. The email was relayed through a legitimate third-party email signature service, which explained the absence of DKIM and the non-matching relay IP in the SPF pass. The attacker's most actionable tell: two copies of the same signature block appeared in the message, and the phone numbers in the two blocks differed by one digit.
Severity: High Bec Vendor Fraud Ach Redirect MITRE: T1566.001 MITRE: T1534

The email arrived from a vendor account that had been in active use since before the start of the millennium. The domain it came from was first registered in February 2000. The sending address passed SPF. DMARC passed with a quarantine-level enforcement policy. The message looked, from the outside, like routine business correspondence between a contractor and a construction company.

Inside the message was a request: update the ACH banking details on file. The account, the vendor explained, was scheduled for closure that same day.

There was no invoice attached. No prior context for the request. No reference to an outstanding payment or a specific billing cycle. Just the claim, and the deadline.

A 26-Year-Old Domain, Compromised

The sending domain was registered in February 2000, making it 26 years old at the time of the incident. Domains with that kind of age carry institutional reputation weight. Threat-intelligence databases do not flag 26-year-old domains. Reputation scoring systems treat them as established. Gateway defenses that apply stricter scrutiny to young or newly registered domains apply lighter scrutiny to domains with decades of traffic history.

This is the exact dynamic that makes compromised-legitimate sender accounts valuable to attackers. The vendor's email account had been in use, likely across years of routine correspondence. A message originating from that account is not functionally different from any of the legitimate messages that preceded it, from the perspective of a receiving mail server.

The authentication picture reinforced this. The message was relayed through a third-party email signature service, which explained two otherwise potentially suspicious characteristics: the absence of DKIM and the relay IP in the SPF evaluation. Email services that append formatted signatures to outbound messages do so by routing the message through their own infrastructure. DKIM is typically not present or belongs to the relay domain rather than the original sender domain. The relay IP is that of the signature service, not the sender's mail server. Both are artifacts of the relay configuration, not indicators of malicious activity. SPF passed because the signature service's sending infrastructure was authorized.

The vendor contact appeared in the From header, and the email was addressed to a named accounts payable contact at a construction company.

The Fabricated Same-Day Deadline

The message requested a change to the ACH banking information associated with the vendor's account, asking the recipient to provide either an updated ACH authorization form or a voided check. The urgency mechanism was a single line: the account was scheduled for closure that day, March 31, 2026.

See Your Risk: Calculate how many threats your SEG is missing

This framing follows the standard business email compromise playbook for vendor payment fraud. The deadline eliminates the most common friction point in banking-change verification: "I'll check on this tomorrow." March 31 is a quarter-end date, which adds plausibility to financial account administration activity. An accounts payable contact who receives this message at quarter end, from a vendor they know, carries a legitimate cognitive reason to treat the timing as believable.

There was no prior invoice context, no outstanding balance reference, and no purchase order number. The absence of these elements is a consistent marker of ACH redirect attacks. The attacker cannot fabricate a convincing AP context because they do not have access to the real billing history. The request stands alone, relying entirely on the urgency framing and the apparent legitimacy of the sending account.

The Tell: Two Signatures, Two Phone Numbers

The message contained two copies of the vendor's signature block, both attributed to the same named contact. The phone number in the first copy was 651.906.0[XXX]. The phone number in the second copy was 651.905.0[XXX]. The two numbers differ by a single digit in the exchange.

This mismatch is the clearest forensic artifact in the case. When a third-party signature service appends its formatted block to a message, it may duplicate an existing signature already in the message body, particularly if the attacker's injected content included its own version. The attacker did not have the correct direct-dial number and substituted one that differed by one digit. When the signature service appended the actual account's signature from its stored template, both versions appeared in the delivered message.

The mismatch would not survive a verification call to either number. A recipient who called the first number before processing the request would reach a different outcome than one who called the second. The presence of two different phone numbers for the same person, in the same email, is a functional indicator that at least one of them was fabricated.

Detection Without a Malicious Link

IRONSCALES Adaptive AI flagged this message at 68% confidence with no malicious URL present. The detection was based on behavioral signals: a first-contact message to an accounts payable target, a sensitive financial-process request, fabricated time pressure, and the structural mismatch between a request of this type and the absence of any supporting documentation.

Email spoofing detection for compromised sender accounts cannot rely on authentication failures because there are none. The detection challenge is distinguishing a legitimate vendor banking update from a fraudulent one when both originate from the same sending infrastructure and pass the same authentication checks. The Adaptive AI's behavioral model built this signal from contextual patterns across the full message, not from any single technical indicator.

Defensive Verification Is the Primary Control

For vendor ACH redirect fraud, the attack surface is not a technical vector. It is an administrative process. The defense is equally non-technical.

Require a verified out-of-band callback before processing any banking change. Call the vendor at a known contact number, sourced from the original signed contract or a publicly listed number, never from the requesting email. This single control makes display-name-level and compromised-account impersonation attacks ineffective for ACH fraud.

Treat banking-change requests with no invoice context as elevated risk. A change request that arrives without a reference to an outstanding payment, a PO number, or an explicit billing context is structurally inconsistent with how legitimate vendor banking updates typically occur.

Flag duplicate signature blocks with numeric mismatches. Content analysis that identifies two instances of the same signature in a single message body, with differing contact numbers, should surface the message for human review regardless of authentication status.

The Verizon DBIR 2026 identifies vendor email compromise as one of the highest-value social engineering attack classes in terms of per-incident financial impact. MITRE ATT&CK T1566.001 covers spearphishing with attachments, but the broader T1534 covers internal targeting patterns consistent with BEC. CISA guidance on BEC recommends independent verification of all payment-change requests. The Microsoft Digital Defense Report 2024 notes that financially motivated BEC continues to outpace malware-delivery attacks in total reported losses.

Two phone numbers in one email. One of them was fabricated. That is the artifact this attack left behind.

---

TypeIndicatorContext
Phone651.906.0[XXX]Signature block version A; attacker-supplied number (differs from legitimate contact)
Phone651.905.0[XXX]Signature block version B; CodeTwo-appended copy from legitimate account template
Relay IP91.220.146.21CodeTwo email signature service relay; authorized outbound relay for sender domain
Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 35,000+ security professionals. Each post breaks down a real attack. What it looked like, why it worked, and what to do about it.

Related attacks

Attack What happened
The Reply-To Was One Letter Off: How a Typosquat Domain Turned a Gmail BEC Into a Payment DiversionA Gmail-authenticated BEC used a typosquat Reply-To domain and a hidden HTML mailto mismatch to impersonate a steel distributor's credit manager.
The $19,500 Invoice From a Domain That Didn't Exist Last WeekAn invoice fraud campaign delivered a $19,500 bill payment reminder through SendGrid from a domain registered days earlier.
Three Domains, One CEO: How a Payroll Group BEC Used Mailjet to Bypass Every FilterA CEO impersonation attack targeted a payroll distribution group using Mailjet infrastructure, three separate domains for sending, reply capture.
Past Due Invoice, Future Wire Fraud: How a BEC Campaign Passed Every Authentication CheckA BEC invoice diversion attack impersonated a known vendor contact through SendGrid, passed SPF/DKIM/DMARC.
One Missing Letter, One Stolen Payment: A Reply-To Typosquat That Beat the Spam ScoreA typosquatted Reply-To domain misspelled 'Missouri' as 'Missuori' to intercept invoice payments.

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.