What happens when organisations rely only on reputation filters and malware sandboxing to stop business email compromise?

They miss a large share of attacks because many business email compromise emails contain no malware and use legitimate, or fully compromised, accounts. Reputation-based controls do little when the message is text only and the sender appears authentic. Organisations need layered detection for impersonation, credential phishing, account compromise, and social engineering across the full attack path.

Why reputation filters and sandboxing miss a large part of BEC

business email compromise is often a message-confidence problem, not a malware problem. If the email is plain text, arrives from a legitimate provider, or comes from a compromised account, reputation scores and sandbox detonation add little. The failure mode is that these controls are tuned for malicious payloads and bad infrastructure, while BEC commonly abuses trust, urgency, and identity.

That means the organisation can still be fully exposed even when gateway controls report a clean result. The defensive question is not whether the message contains malware, but whether the sender, reply path, request, and payment or credential workflow are suspicious.

What actually gets through when the email looks clean

Many BEC campaigns succeed by using stolen credentials, lookalike accounts, or conversation hijacking rather than an executable attachment. In those cases, the email can pass reputation checks because the sending domain is legitimate and the content is socially engineered rather than technically malicious. The TruffleNet BEC Attack, stolen AWS credentials is a good example of how compromised access can support business email abuse without relying on malware delivery.

Sandboxing is also weak here because there may be nothing dangerous to detonate. If the message contains a bank detail change, invoice request, payroll diversion, or executive instruction, the risk sits in the business process and the human decision point. That is why layered defence has to include impersonation detection, account compromise detection, and policy checks around high-risk requests.

Why layered detection has to cover the full attack path

A complete BEC defence chain looks beyond the inbox. You need controls that can spot anomalous sender behaviour, impossible travel or sign-in patterns, suspicious forwarding rules, unusual payment changes, and mismatches between the claimed requester and the normal approval path. When a campaign is text-only, the detection challenge shifts from malware analysis to authentication, authorization, and workflow integrity.

Useful internal navigation on the broader compromise patterns is available in The 52 NHI Breaches Report, which shows how credential theft and lateral movement can create downstream abuse. For a pure social-engineering example, Arup deepfake fraud 2024 illustrates how trusted-seeming instructions can bypass technical filters entirely.

How to think about the control gap in practice

Reputation filters and sandboxes still matter, but only as one layer. They are best at reducing commodity malware and known-bad infrastructure, not at judging whether a request is legitimate. BEC resilience depends on whether the organisation can validate the person, the channel, and the business event before action is taken. That usually means pairing email security with identity controls, payment verification, privileged access reviews, and user training aimed at behavioural cues, not just suspicious links.

For teams managing email and identity controls, CIS Controls v8 is a practical baseline for account management, audit logging, malware defence, and access control. If the organisation wants a broader detection and response view, MITRE ATT&CK Enterprise is useful for mapping credential access, lateral movement, and post-compromise activity that often sits behind BEC.

Risk and Threat Considerations

The main risk is false confidence: organisations may believe they are protected because their mail gateway is quiet, while the real attack path is moving through trusted accounts and human approval steps. That creates exposure to fraudulent payments, payroll diversion, invoice redirection, and secondary account compromise.

Failure mechanism: The control stack is optimised for malware and reputation signals, but BEC often uses clean text, legitimate infrastructure, or compromised accounts that do not trigger those checks. Attackers exploit trust in the message content, the sender identity, and the business process.

Impact: Requests can be approved and acted on before any technical alert appears, which increases the chance of financial loss, unauthorized access, and operational disruption. If the same trust path is reused, the attacker may also gain durable access to mailboxes, forwarding rules, or follow-on systems.

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 SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-5 — Account Management	BEC frequently abuses compromised or trusted accounts.
Recommendation — Harden account lifecycle controls and review anomalous access paths regularly.
MITRE ATT&CK	T1078 — Valid Accounts	BEC commonly uses legitimate or stolen accounts instead of malware.
	T1566 — Phishing	BEC often begins with deceptive messages that rely on social engineering.
Recommendation — Hunt for valid-account abuse and correlate it with suspicious mailbox activity. Detect phishing patterns that target credential capture and business impersonation.
NIST SP 800-53 Rev 5	AU-6 — Audit Review, Analysis, and Reporting	BEC detection depends on reviewing mailbox and sign-in anomalies.
	IA-5 — Authenticator Management	Compromised credentials are a common BEC enabler.
Recommendation — Correlate email and authentication logs to spot suspicious request chains. Rotate and govern authenticators that can be abused for mailbox takeover.

Practitioner Guidance

What to verify: Treat any request to change payment instructions, banking details, tax details, or credential flows as a workflow verification problem, not just an email-filtering problem. Verify the request through an independent channel that is already expected by policy.

What to prioritise: Put detection and response effort into account takeover signals, forwarding-rule anomalies, and approval-path exceptions, because those are the indicators that reveal BEC when malware is absent.

Common mistake: Do not measure email security success only by blocked-malware counts. A low malware volume can coexist with high BEC exposure if your controls do not inspect the legitimacy of the request itself.

Practitioner takeaway: If a control only judges whether an email looks suspicious, it will miss the BEC cases that matter most, so the defence has to validate identity, intent, and business process before trust turns into action.