A legitimate company. A genuine account. A fraudulent request.

An email arrives from a supplier your business has worked with for years.

The address is correct. The signature is familiar. The message sits inside an existing conversation about an invoice you were already expecting to pay.

There is one change: the supplier has updated its bank details.

Your colleague checks the sender, recognises the invoice and processes the payment.

Everything about the relationship is genuine. The payment instruction is fraudulent.

This illustrative scenario captures a difficult feature of business email compromise: an attacker can use access to a real organisation’s mailbox to redirect payments between that organisation and its customers.

The attacker does not have to create trust from scratch. The relationship has already done that work.

The attacker inherits the conversation

We often describe phishing as something a careful person should be able to spot. An unfamiliar sender. An odd domain. An unexpected attachment. A request that feels out of place.

Those checks remain useful. But consider what happens when an attacker gains access to a genuine business mailbox.

Previous messages may reveal who handles payments, which invoices are outstanding and how the supplier normally communicates. Microsoft describes compromised accounts being used to gather information about trusted contacts and support payment redirection and further attacks.

In our example, the attacker can make the request fit an existing business process. The invoice is expected. The amount is familiar. The recipient has a reason to respond.

The fraudulent element might occupy only one sentence in an otherwise accurate message.

That matters because familiar details reinforce one another. A correct invoice number makes the sender appear credible. A genuine sender makes the new bank details appear credible. An existing conversation makes the whole exchange feel routine.

Yet none of those facts establishes who authorised the change.

Three questions that should remain separate

A useful way to examine this problem is to separate three decisions:

Does this organisation exist?
The supplier is a legitimate business with a real trading history.

Did this message come through its account?
The message may have been sent using the supplier’s genuine mailbox.

Is this particular instruction authorised?
The supplier’s authorised employee may know nothing about it.

Evidence supporting the first two questions cannot, by itself, answer the third.

This distinction extends beyond payments. A genuine account might request access to a shared folder, ask for confidential documents or direct a customer towards a new sign-in page. Each action needs assurance appropriate to its consequences.

The central mistake is allowing confidence in the relationship to become automatic approval of the request.

What threat intelligence can tell you

External intelligence can add valuable context.

A request may introduce a domain associated with phishing, infrastructure linked to malicious activity or an email address with credible evidence of abuse. Those observations can give a person a concrete reason to pause and investigate.

But there is a harder version of our scenario.

The attacker sends from the genuine mailbox. There is no link. No attachment. No new domain. Just a request to change payment details.

A reputation lookup against the supplier’s domain could return no adverse findings and still tell you very little about the legitimacy of that instruction.

That is a limit of the available evidence. An external service generally cannot determine who is operating a supplier’s mailbox merely by examining its address.

A favourable assessment of an email address or domain should never be treated as authorisation for a transaction.

Equally, evidence of abuse involving one account should not automatically become a claim that the entire organisation is malicious. The supplier may also be a victim.

Useful intelligence needs to be precise about what was observed, when it was observed and what conclusion the evidence supports.

Verify the change through a separate route

For the recipient, an important point of intervention is the requested change.

An established supplier requesting payment to an established account is one situation. The same supplier requesting a new destination introduces a fact that needs independent verification.

At this stage you should be verifying payment changes in person or through a known telephone number. The word known matters: contact details supplied in the suspicious request could lead straight back to the attacker.

Replying to the same email thread also leaves the verification inside the potentially compromised channel.

A practical process should make clear:

• Which changes require independent verification.

• Where staff obtain previously verified contact details.

• Who can approve a change after verification.

• How the outcome is recorded before anyone acts.

A second approver can help, but only if they examine meaningful evidence. Two people reading the same convincing email can reach the same incorrect conclusion.

These controls should be routine enough that invoking them does not feel like accusing a longstanding supplier of dishonesty.

Give people a decision they can actually make

“Be vigilant” leaves a great deal unanswered.

What should someone check? What evidence would change the decision? When should they stop? Who can resolve the uncertainty?

A more useful approach connects a specific observation to a specific action:

A payment destination has changed. Confirm it using the supplier contact already held in your records before updating the account.

Or:

This request introduces a domain associated with observed phishing activity. Pause the interaction and refer it for review.

These are different findings requiring different responses. Good decision support preserves that distinction.

Microsoft’s own guidance on business email compromise similarly recommends procedures to authenticate financial or data requests and moving high-risk transactions into more authenticated systems.

The objective should be to make the required check clear at the moment someone is being asked to act.

What this means for trust intelligence

At ThreatPrevent, our focus is bringing high-confidence intelligence signals into everyday business decisions.

That requires being clear about what a signal can establish. Evidence associated with a domain, IP address or email address can inform a decision. Its value depends on relevance, freshness and the strength of the underlying evidence.

It also requires recognising when a decision needs something beyond external intelligence: independent confirmation, account investigation or an established approval process.

In the supplier scenario, the relationship can remain trusted while a particular instruction is challenged.

A genuine company and a genuine account are reasons to recognise the sender. A consequential change still needs its own evidence.