What happens when attackers use compromised vendor accounts to request payment changes?

How compromised vendor accounts turn a simple payment request into a payout diversion

Attackers abuse the trust attached to a real vendor relationship. The request often looks routine, lands in a familiar mailbox thread, and names a genuine company contact or domain, so the change can be processed before anyone notices that the bank details, remittance address, or payment workflow have been swapped.

The key failure is not technical sophistication so much as trust placement. Payment operations often rely on sender authenticity and continuity of the conversation, but a compromised vendor account gives the attacker a believable identity channel to issue a high-impact instruction. Once the payment route is changed, the next invoice or scheduled transfer can go to the attacker.

In practice, this is a supply chain trust abuse problem as much as an email security problem. The attacker does not need to fully compromise the buyer’s environment if they can alter the payment instructions at the vendor side and preserve the appearance of legitimacy long enough for finance staff to act on it.

Why the fraud often survives initial review

These requests succeed when the review process checks whether the sender is real, but not whether the instruction is independently verified. If the vendor mailbox or account is already compromised, the message can bypass informal trust checks, and the change may be accepted because it arrives through an established relationship rather than through a new or obviously suspicious channel.

That makes the decision point operational, not just technical: do staff verify payment changes using a separate trusted path, or do they rely on the same communication channel that may already be under attacker control? When the answer is the latter, the attacker can blend into normal invoice processing and redirect funds with minimal friction.

For organisations with recurring payments, the impact can extend beyond one transfer. A changed payment instruction can persist across multiple invoices, vendors, or even subsidiaries if the update is copied into downstream systems without a fresh validation step.

Controls such as PCI DSS v4.0 and the CSA Cloud Controls Matrix are relevant where payment environments depend on least privilege, vendor governance, and strong account handling, but the practical issue is still whether a payment change can be approved without an independent verification path.

What the downstream business impact usually looks like

The immediate consequence is payment diversion, but the operational damage can be wider. Finance teams may need to reverse transfers, freeze related payments, notify counterparties, and investigate whether other vendor records were changed in the same way. If the attacker used a real vendor account, the fraud can also strain relationships because the legitimate supplier may be unaware that its account was the source of the request.

There is also a concentration effect. A single compromised vendor mailbox can affect many customers at once, especially where the vendor services multiple organisations or where shared invoice processes are reused across regions and business units. That is why these incidents often become supply chain events rather than isolated account fraud cases.

From a control perspective, the most important question is whether payment changes are treated as high-risk events with separate approval, callback, or hold procedures. If they are treated as ordinary administrative updates, the organisation is effectively trusting an attacker-controlled channel at the point where money leaves the business.

Risk and Threat Considerations

Compromised vendor accounts are attractive because they combine social legitimacy with operational reach. The attacker does not need to invent a fake vendor from scratch; they can exploit an existing relationship, preserve the expected tone and context, and convert a routine payment update into a direct financial loss.

Failure mechanism: The attacker uses a trusted vendor identity to submit changed bank or remittance details, and the organisation processes the request without an out-of-band verification step or approval control strong enough to detect the compromise.

Impact: Funds are redirected to attacker-controlled accounts, legitimate invoices may remain unpaid, and the same trust path can be reused to affect multiple customers or repeated payments before the fraud is detected.

Practitioner Guidance

What to verify: Treat any payment change, new bank account, or remittance update as a high-risk event even when it arrives from a familiar domain. The deciding evidence is not whether the sender looks real, but whether the change was confirmed through an independent callback number, signed instruction, or other pre-established verification path.

Common mistake: Many teams harden their email filtering but leave the payment workflow itself unchanged. That reduces obvious spam, but it does not stop a compromised vendor account from issuing a plausible request that fits the normal business process.

Practitioner takeaway: The control that matters most is not message authenticity in isolation, it is whether a payment instruction can be executed without a separate trust check that the attacker cannot easily impersonate.

Related resources from NHI Mgmt Group

• What happens when attackers use compromised email accounts and university identities to target recruitment teams?
• What happens when attackers use a compromised vendor account to send phishing links?
• What happens when attackers compromise an employee inbox and use the existing thread to request payment?
• What happens when attackers use compromised identity or access paths to move from initial access to deeper compromise?