Every Signature Passed. The Bank Details Were Fake.

A vendor email landed in the accounts-payable queue at a company that runs scheduling and payment technology for public-safety and off-duty law-enforcement programs. It passed SPF. It passed DKIM. It passed DMARC under a strict reject policy. Every cryptographic signal a mail server can check came back clean, which is exactly what you would expect from a real vendor you have paid before.

The message asked the finance team to change where that vendor's money goes.

Specifically, it instructed accounts payable to mark the existing remittance address inactive, add a new one, select ACH as the payment method, and use a supplied routing number and account number at a national bank. The account did not belong to the vendor. This was payment redirection running through a trusted, authenticated channel, and the authentication is precisely what made it dangerous.

The Ask, Not the Attachment

There was no malware here. No credential-harvesting page, no macro-laden document, no fake login portal. The entire attack was a set of instructions aimed at a routine business process.

That is the signature of modern business email compromise. The attacker did not need to break anything technical. They needed one person in finance to update a payment record. The email walked the reader through it step by step: deactivate the current remit-to address, add the new one, switch to ACH, enter the new banking details. It read like a normal vendor housekeeping notice, the kind an AP clerk processes dozens of times a month without a second thought.

The banking numbers themselves were the payload, and I will not reproduce them here. Broadcasting attacker-supplied routing and account details helps no one and can seed the next fraud. The technique is what matters: a plausible request to redirect legitimate outbound payments into an account the sender controls, timed and worded to slip inside an ordinary finance workflow.

Why Every Check Passed

The uncomfortable part of this case is the authentication. The message came from a legitimate, long-established vendor domain and was signed correctly for that domain, so SPF, DKIM, and DMARC all passed under a reject policy. There was no spoofing to detect, because nothing was spoofed.

That points to one of two things: a compromised mailbox inside the real vendor, or an abused authenticated sending channel tied to that vendor's infrastructure. Either way, the fraudulent mail left an authorized server for a domain that genuinely owns it. This is vendor email compromise, and it is the reason authentication results are the wrong thing to trust when money is on the line. SPF, DKIM, and DMARC answer one question: did this message leave a server authorized to send for this domain. They say nothing about whether the human intent behind it is honest. A perfect authentication verdict on a payment-change request is not reassurance. It is the absence of one specific attack, dressed up as proof of trustworthiness.

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

The Link That Lied About Where It Went

The message also carried two "click here" links styled as supporting paperwork, a W9 and related documents. The visible anchor text displayed Google Drive addresses, the sort of link a finance team sees constantly and clicks without hesitation. The underlying href did not go to Google.

Both links resolved through an unrelated marketing-tracking redirect at cd47x04.na1.hubspotlinks[.]com before reaching their destination. In this case the final landing pages were the same Drive documents and scanned clean, so the links were not the fraud mechanism. They were camouflage, a way to make the message feel routine and legitimate while the real objective sat in the banking instructions. The anchor-text-versus-destination mismatch is a reliable tell on its own: what a link says and where it actually points should never diverge in a genuine vendor notice.

Mapping to MITRE ATT&CK

The tradecraft maps cleanly to a handful of techniques in the MITRE ATT&CK framework:

• T1566.002 Spearphishing Link covers the Google-Drive-styled links routed through a tracking redirect to disguise their true path.
• T1656 Impersonation covers the abuse of a trusted vendor identity to make a fraudulent payment request look routine.
• T1534 Internal Spearphishing captures the trusted-relationship angle: a message that arrives from a known, authenticated business partner and exploits that standing relationship rather than a cold approach.

Indicators of Compromise

Detection and What to Watch For

Reputation and authentication checks were never going to stop this. The domain was real, the signatures were valid, and the links resolved to clean documents. Detection has to move to intent and context: a payment-detail change arriving as an unsolicited request, banking instructions embedded in the body, an anchor-text destination that does not match its label, and a reply path steered toward a plausible internal-looking alias rather than a known contact.

This is where IRONSCALES adds a layer static gateways miss. Themis, the Adaptive AI analyst on the IRONSCALES platform, weighs the relationship between the sender, the request, and the recipient the way a trained analyst would, flagging a bank-detail change from a vendor even when every server-level check passes. Across 35,000+ security professionals and 17,000+ organizations, that behavioral read is what catches the fraud the authentication stack waves through. The 2024 Verizon Data Breach Investigations Report names pretexting, mostly BEC, as the top social-engineering incident type, with a median BEC transaction near $50,000, and the Microsoft Digital Defense Report 2024 documents the same shift toward abusing trusted services rather than breaking them. The FBI's 2023 Internet Crime Report has long ranked business email compromise among the costliest categories of online crime, and payment redirection like this is exactly how those losses accrue.

The Takeaway

A passing authentication result is not permission to trust a payment request. Treat any change to banking or remittance details as a verbal-verification event: confirm it using a phone number already on file, never one supplied in the message, and never the reply address in the request. The signatures in this case were genuine, and the instructions were still fraud. Pair that out-of-band habit with behavioral detection and you close the gap this campaign was built to exploit. CISA's guidance on recognizing and stopping phishing early is a solid reference for building that reflex across a finance team: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one