Security Awareness

Business Email Compromise and Payment-Change Verification

Recognize impersonation and mailbox compromise, verify sensitive requests independently, and coordinate fast action after a fraudulent payment.

Threat Intelligence Lab Published Updated 6 min read

BEC abuses business context, not just email appearance

Business email compromise uses a spoofed identity, a look-alike domain, or a genuinely compromised mailbox to make a request appear routine. The message may arrive inside a real invoice thread, refer to actual colleagues, and match the organization’s tone. Common goals include changing bank details, redirecting payroll, buying gift cards, releasing sensitive tax data, or persuading support staff to reset access.

Grammar and logos are weak signals because a legitimate account can send polished fraud. Focus on the requested action and its consequence. A change of beneficiary, payment destination, contact channel, authentication factor, or confidentiality instruction deserves verification even when the sender looks familiar. Human verification under pressure works by moving the decision to a channel and source of truth the requester does not control.

Business email compromise identity pathsSpoofed sender, look-alike domain, and compromised mailbox converge on a high-impact request.Different delivery paths, the same decision riskSPOOFED SENDERLOOK-ALIKE DOMAINSTOLEN MAILBOXCHANGE MONEY, DATA, OR ACCESSVerify the action, not only the message
Three BEC identity paths - Spoofing, look-alike domains, and compromised mailboxes can produce the same fraudulent request.

Make sensitive changes through a controlled workflow

Payment and account-detail changes should begin in an approved system, require evidence tied to an existing vendor record, and receive an independent second approval. Verification uses a known telephone number, supplier portal, or established contact—not a number, link, or reply address supplied in the change request. The verifier should state the known details and ask the contact to confirm the requested change rather than revealing all expected answers first.

Separate creation from approval and notify the existing contact when master data changes. Apply a cooling-off period or enhanced review for unusual destinations, currencies, urgency, or first-time payments. These controls protect honest staff too: instead of deciding whether an executive “sounds right,” they can follow a predictable process that remains mandatory for executives and emergencies.

Payment change validation layersFive stacked controls show known record, independent callback, dual approval, risk delay, and notification.A message starts a workflow; it does not replace oneEXISTING VENDOR RECORDINDEPENDENT CALLBACKSEPARATE APPROVERRISK-BASED DELAYCHANGE NOTIFICATION
Payment-change control layers - Known records, callback, dual control, delay, and notification constrain a payment change.

Triage the message and the account separately

Safe phishing triage examines sender domains, reply paths, headers, authentication results, URLs, attachments, and related messages. BEC adds an account investigation: review sign-ins, session activity, forwarding and inbox rules, delegated access, sent and deleted items, recovery changes, and connected-application grants. A clean-looking header does not exclude a compromised mailbox, and an external look-alike domain does not prove the internal account is safe.

Build a timeline from the earliest suspicious authentication or mailbox change through the financial request and any follow-up. Search for other recipients, vendors, affected conversations, and matching infrastructure. Preserve messages in their original form and record queries and timestamps. Coordinate technical findings with finance or procurement so investigators can connect mailbox activity to real payments and attempted changes.

Message and account investigation tracksMessage artifacts and account activity are investigated in parallel and joined with payment events on a timeline.Join communication evidence to business effectsMESSAGE TRACKheaders · domains · threadsACCOUNT TRACKsessions · rules · grantsINCIDENT TIMELINErequest · approval · payment · recovery
BEC investigation has two evidence tracks - Message evidence and account activity converge into one incident timeline.

Act quickly after a fraudulent payment

Contact the sending financial institution immediately through a known fraud channel and provide transaction details. Ask it to initiate recall or recovery procedures and coordinate with the receiving institution. Notify the organization’s legal, fraud, security, insurer, and law-enforcement contacts according to the incident plan. Speed matters, but staff should not use contact information from the fraudulent conversation.

In parallel, contain compromised accounts, revoke sessions and grants, reset credentials from trusted devices, preserve evidence, and warn affected partners through independent channels. Do not delete the message chain or let embarrassment delay escalation. Record times, contacts, reference numbers, destinations, and decisions. Payment recovery and technical containment are parallel workstreams; success in one does not make the other unnecessary.

Measure whether the process resists pressure

Test the full workflow with realistic but authorized exercises: a supplier bank change, an urgent executive request, a payroll update, and a mailbox compromise discovered after a transfer. Observe whether staff find a known contact, whether dual approval is truly independent, how quickly finance and security connect, and whether logs support a coherent timeline. Never surprise external suppliers with an exercise that could trigger real action.

Useful measures include percentage of sensitive changes independently verified, exceptions left open, time to report, time to contact the bank, and control failures corrected. Avoid ranking individuals by clicks or blame. A healthy system makes stopping easy, gives employees a safe escalation route, and treats adherence to verification as good performance—even when the request later proves legitimate.

Continue exploring
View all in Security Awareness