What are the signs that an email fraud attempt is likely to be BEC rather than a legitimate internal request?

Common warning signs include a lookalike sender address, display-name spoofing, unusual urgency, awkward phrasing, and a request that breaks normal process, such as changing payment details or asking for sensitive information by email. Messages may also include suspicious links or attachments. Any request that feels slightly off should be verified through a separate channel before action.

What makes BEC different from a routine internal email?

Business email compromise usually tries to exploit trust, timing, and routine workflow rather than technical malware alone. A legitimate internal request tends to match known contacts, expected business context, and normal approval paths. A BEC message often feels narrow, urgent, and process-breaking, especially when it asks you to move money, change payment instructions, or disclose information that should not travel by email.

Lookalike addresses and display-name spoofing matter because BEC often depends on a believable impersonation rather than a fully compromised mailbox. The message may appear to come from a known executive, supplier, or colleague, but subtle domain changes, reply-to mismatches, or unexpected sender infrastructure can expose the fraud before any action is taken.

Process deviation is one of the strongest indicators because BEC frequently pushes the recipient out of the normal control chain. A request that bypasses two-person review, asks for secrecy, or changes established payment or bank details is not just suspicious in tone, it is suspicious in function. Even when the wording is polished, the business logic can be wrong.

How the language and timing of the message reveal suspicion

Urgency is a classic pressure tactic because it reduces the chance of verification. Fraudulent messages often create a short fuse, invoke authority, or frame the request as confidential so the recipient acts before checking with the supposed sender through a separate channel. That pressure is especially telling when the request is outside the sender’s normal role or arrives at an unusual time.

Phrasing can also reveal that the message was written quickly, translated poorly, or assembled from reused fragments. Awkward grammar, unusual tone, missing context, and vague references to “the usual process” can all indicate an attempt to sound internally familiar without actually fitting the organisation’s communication patterns. A real internal request usually carries more contextual detail than a scammer can safely fake.

Attachments and links add another clue when they are not needed for the business purpose. A BEC attempt may include a document, invoice, or login prompt to pull the recipient into a secondary compromise path, but a legitimate internal request normally avoids unnecessary friction. If the ask could have been handled through an established workflow, the extra artifact deserves scrutiny.

What should happen before anyone acts on the request?

The practical test is verification outside the thread. If a request changes payee details, requests credentials or sensitive data, or asks for an exception to normal process, it should be confirmed through a known phone number, chat channel, or in-person contact method that is independent of the email itself. That preserves the integrity of the decision even when the message looks familiar.

Organizations get better detection when employees are trained to compare the request against the person’s role, the expected timing, and the expected approval path. If any one of those is off, treat the message as untrusted until confirmed. The goal is not to prove the sender is malicious in the abstract, it is to avoid letting a forged request trigger a financial or data-handling action.

Teams that handle payments, procurement, payroll, or vendor changes should be especially strict because those are the most common BEC targets. A message that attempts to redirect funds or alter account details should be treated as a control event, not just a suspicious email. The faster the verification happens, the less chance the fraud has to move from inbox to transaction.

Risk and Threat Considerations

BEC is dangerous because it weaponizes normal business trust, not because it needs advanced malware. Once a recipient accepts the sender as legitimate, the attacker only needs one successful action, such as a payment change, credential disclosure, or sensitive document transfer, to create real loss.

Failure mechanism: The attacker impersonates a trusted internal or external party, uses urgency or secrecy to suppress verification, and steers the recipient into bypassing normal approval or payment controls.

Impact: The result can be fraudulent transfer, account compromise, data exposure, or a follow-on intrusion if the message leads to credential capture or secondary access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1566 — Phishing	BEC commonly starts with deceptive email impersonation and social engineering.
Recommendation — Map suspicious mail to phishing techniques and hunt for impersonation indicators in email telemetry.
CIS Controls v8	CIS-9 — Email and Web Browser Protections	BEC is delivered through email and often uses malicious links or attachments.
Recommendation — Harden email handling controls and block suspicious links, attachments, and lookalike senders.
NIST CSF 2.0	PR.AA-05 — Manage identities and authenticators for users, services and devices	Verifying requests through a separate channel depends on trustworthy identity and authentication.
	RS.CO-02 — Communications to stakeholders are coordinated during incidents	Suspected BEC requires rapid internal escalation and coordination with finance and security.
Recommendation — Require verified identity before approving payment or data-change requests. Coordinate rapid escalation paths for suspected BEC and preserve evidence for response.

Practitioner Guidance

What to verify: Verify the sender independently whenever the request changes money movement, bank details, access, or confidential information. The most important question is not whether the email seems plausible, but whether the request matches the sender’s role and the approved business process.

Common mistake: Do not treat a familiar display name, an existing thread, or a polite tone as sufficient proof. BEC succeeds when teams confuse social familiarity with authorization.

Practitioner takeaway: If the message creates pressure to act before you verify, that pressure is itself part of the threat model, and the safest response is to pause and confirm through a separate channel before any business action.