What happens when a supplier account is compromised and used to redirect a wire transfer?

How a supplier account takeover turns into payment redirection

Once a supplier account is compromised, the attacker can use the trusted relationship itself as the payload. The strongest version of this attack is not a noisy break-in, it is a believable continuation of an existing commercial thread, often with familiar language, timing, and invoice references that make the payment change feel routine.

That is why this fraud path is often effective in procurement and accounts payable workflows: the request arrives through a channel that already carries authority. If the organisation does not validate the change outside the compromised channel, the transfer can be rerouted before anyone realises the supplier was no longer speaking for itself.

Why the payment destination change is so dangerous

The practical danger is loss of control over the payment instruction, not just account access. A single compromised supplier mailbox or portal login can let an attacker alter bank details, request urgent settlement, or insert a new beneficiary while preserving the appearance of legitimacy.

That matters because payment systems and business workflows tend to optimise for speed and continuity. If staff rely on the fact that the message came from a known contact, the fraud may pass initial review even when the destination account, wording, or urgency does not match normal change-control expectations.

The downstream impact can extend beyond the transfer itself. Organisations may face fraud recovery delays, contract disputes, supplier tension, and internal process review after the fact. In some cases the real harm is reputational, because the business appears to have accepted a payment change without confirming it through an independent trust path.

What organisations should treat as the real control failure

The control failure is usually not “an email was spoofed”, it is “a trusted communication path was allowed to authorise a financial change by itself.” That means the important question is whether payment redirection requests are verified through a separate, pre-established channel and whether beneficiary changes are subject to hold-and-confirm steps.

Where the supplier account is itself the compromised asset, the organisation should assume the attacker can see the same context the real supplier sees. Any validation that depends on replying to the same thread, using the same portal session, or trusting a familiar signature is structurally weak once access has been lost.

Risk and Threat Considerations

This scenario combines fraud risk, operational disruption, and trust abuse. The attacker is exploiting a legitimate business relationship rather than forcing a technical outage, which makes the change harder to spot and more likely to survive normal approval habits.

Failure mechanism: The organisation accepts a payment instruction from a channel that has already been compromised, so the attacker can substitute new bank details or a new beneficiary while preserving the appearance of an authentic supplier request.

Impact: Funds can be transferred to the wrong destination, recovery may be slow or incomplete, and the organisation may need to manage customer, supplier, and audit consequences after the fact.

Practitioner Guidance

What to verify: Treat any request to change payment details as a high-risk event and confirm it through an independent callback or previously verified out-of-band process. If the request arrives through the same mailbox, portal, or contact chain that may be compromised, do not treat channel continuity as proof of legitimacy.

Decision rule: If the request changes bank details, beneficiary name, or settlement instructions, pause payment until a second approver confirms the change against trusted records. If the supplier relationship is already unusual, urgent, or late in the cycle, raise the verification bar rather than lowering it.

Practitioner takeaway: The key judgement is to separate commercial familiarity from authentication of the payment change, because the attacker’s advantage is that the request looks normal precisely when the trust relationship has already been captured.

Related resources from NHI Mgmt Group

• What happens when a developer account is compromised and used to push changes through GitHub and CI/CD into production?
• What happens when a compromised Slack account is used to access sensitive conversations and files?
• What happens when a compromised government email account is used to manipulate trusted workflows?
• What happens after a compromised email account is used to distribute malware to other diplomatic offices?