How to detect and respond to a BEC attack

The email gateway is doing its job. Spam is blocked. Malware is quarantined. Phishing links are flagged before they reach the inbox. By every metric the dashboard shows, the organization is protected.

And yet, somewhere inside a corporate network right now, an attacker may be sitting inside a thread with the CFO, patiently waiting for the right moment to redirect a wire transfer.

That's Business Email Compromise (BEC), and the filters aren't built to stop it.

Here's the uncomfortable truth that most email security vendors don't want to lead with: BEC attacks succeed not because defenses are weak, but because BEC was designed to look like a legitimate conversation.

According to Eye Security's 2026 incident response report, organizations without managed detection capabilities experience a median BEC dwell time of over 24 days. This is enough time for an attacker to map a finance team, study ongoing transactions, and strike at exactly the right moment. The FBI's IC3 2024 Annual Report recorded nearly $2.8 billion in BEC losses across 21,442 incidents, making it second only to investment fraud in total financial damage and far ahead of ransomware in dollar impact.

The organizations that fare best against BEC aren't necessarily those with the most expensive filters. They're the ones that have stopped treating BEC as a delivery problem and started treating it as a behavioral one. They've shifted from blocking at the edge to detecting in the flow, and they've built response protocols that don't assume the attack hasn't already landed.

Why BEC is a different kind of threat  

To understand why BEC defeats conventional security stacks, it helps to understand what conventional security stacks are built for.

Email security platforms are fundamentally signature-based and content-aware. They look for known malicious links, attachments carrying payloads, spoofed sending domains that don't match SPF or DKIM records, and patterns that resemble previously cataloged phishing campaigns. Essentially, they're optimized for threats that carry a weapon.

BEC carries no weapon. There's no malware, no attachment, no link to a credential-harvesting page. A BEC email is a perfectly legitimate message: correctly authenticated, sent from a real account or a convincingly registered lookalike domain, containing nothing but text.

What BEC exploits isn't a technical vulnerability. It exploits the psychology of organizational trust.

Consider how a typical BEC scenario unfolds. An attacker targets a mid-size manufacturing company. They spend two to three weeks in reconnaissance, studying LinkedIn profiles, scraping the company website, monitoring public-facing email formats, and sometimes reading compromised inboxes to understand ongoing projects, vendor relationships, and the informal language used in financial communications. Then they compose an email.

It doesn't say "click here to claim your prize." It says: "Hi Sarah, following up on the Meridian contract. Our banking details have changed ahead of Q4 close. New routing below. Can you update this in the system before Thursday?" It's signed with the CFO's name. The sending address is c-f-o@meridian-partners.com, not meridian.com, but close enough that a busy AP coordinator doesn't catch the hyphen.

No filter stops this. It passes SPF. It passes DKIM. It contains no payload. The threat is the content itself, and the content is indistinguishable from legitimate correspondence unless someone is looking for behavioral signals that most organizations aren't instrumented to detect.

The detection gap: What organizations are missing  

The gap isn't in prevention. It's in observation.

Most organizations have invested heavily in perimeter controls but have almost no visibility into behavioral anomalies within their email environment. Here are the signals that BEC attacks reliably emit, and that most teams consistently miss.

Linguistic pattern deviation  

Every executive has a writing fingerprint. The CEO who writes in complete sentences doesn't suddenly switch to clipped, urgency-laden fragments. The VP of Finance who always includes a greeting doesn't send bare-bones payment instructions with no preamble. AI-assisted behavioral analysis can model these patterns and flag deviations, but it requires baselining, which requires intent. Most organizations haven't done it.

Request-context mismatch  

BEC attacks frequently involve requests that are structurally unusual for the supposed sender. A CEO who has never directly contacted Accounts Payable suddenly emailing them about a wire transfer. A CFO requesting a payment outside the normal procurement workflow. A vendor sending updated banking details in isolation, with no reference to a specific invoice or PO number. Each of these is a contextual anomaly, detectable if someone is looking, invisible if not.

Timing and urgency signals  

BEC emails disproportionately arrive on Friday afternoons, before public holidays, or during known executive travel periods. The urgency framing is deliberate: "before end of business," "I'm in a meeting and can't take a call," "please handle this directly and don't copy anyone else." It's designed to short-circuit normal verification behavior. Organizations that track message timing and flag unusual urgency framing stop far more attacks than those that don't.

Domain and display name anomalies

The most sophisticated BEC attacks use legitimate compromised accounts. But the majority still rely on lookalike domains and display name spoofing, registering domains with character substitutions (rn for m, vv for w), hyphens, or country-code variations. Display name spoofing, where the visible sender name is "Mark Evans, CFO" but the actual sending address is an unrelated Gmail account, remains remarkably effective because most email clients display the name prominently and bury the actual address.

Thread injection patterns

A growing BEC technique involves inserting a malicious actor into an existing legitimate email thread, either by compromising an account or by harvesting thread history and spoofing a reply. These attacks are particularly dangerous because the thread provides authentic context that makes the fraudulent message seem natural. Detecting them requires conversation-level analysis, not just message-level scanning.

A practical detection framework  

Effective BEC detection operates at three layers simultaneously.

Layer 1: Technology signals  

This is the most automatable layer. It includes domain similarity analysis against a set of known vendors and partners, display name/sending address mismatch detection, behavioral AI that baselines communication patterns for key personnel, out-of-band request detection (financial requests that arrive outside normal workflow systems), and thread anomaly detection. None of these catch everything in isolation; they exist to generate signals that feed the next layer.

Layer 2: Process controls  

Technology signals only matter if processes exist to act on them. This means mandatory out-of-band verification for any payment instruction change, wire transfer, or vendor banking update, regardless of how the email looks. It means clear escalation paths that don't create pressure on employees to simply comply with executive requests. It means regular tabletop exercises so that when an AP coordinator gets a flagged email, they know exactly what to do and feel empowered to do it.

Layer 3: Human vigilance  

The last line of detection is a trained, empowered workforce. Employees who understand that BEC attacks exploit urgency and authority, and who feel safe saying "I'd like to verify this before proceeding," are the single most effective deterrent that no technology can replicate. This isn't about blaming employees when attacks succeed; it's about designing a security-first organizational culture where verification is normalized, not treated as an insult to the person being verified.

The response playbook  

BEC response breaks into two distinct scenarios. Responding to a detected BEC attempt differs significantly from responding when someone in the organization has already interacted with one. Both require structured, rehearsed protocols.

When BEC is detected before interaction   

The first 15 minutes:

The priority is isolation and verification, not reflexive action. When an email has been flagged as a suspected BEC attempt, the first step is to quarantine the message before additional recipients see it. The apparent target and their manager should be alerted simultaneously. The apparent sender shouldn't be contacted via email because that channel may be compromised. An out-of-band method works best: phone, in-person, or a separate verified communication platform.

If the email came from an internal account (suggesting account compromise), a forced password reset and session revocation should be triggered immediately. The IT security team should begin account forensics, reviewing login history, mail forwarding rules, and any recent email rule changes, which are a common persistence mechanism.

The first hour:

The blast radius needs to be determined. Who else received the email? Was it part of a thread? Are there other accounts in the organization that the attacker may have accessed? Log reviews are essential. If this is an account compromise event, mass forwarding rules are a red flag for data exfiltration. Relevant business units that may have received or acted on similar messages should be notified.

Documentation should begin immediately: timestamps, email headers, the full message content, and all internal communications about the incident. This will be needed for law enforcement and potentially for insurance claims.

The first 24 hours:

A report should be filed with relevant authorities (in the U.S., IC3; in other jurisdictions, the appropriate national cybercrime unit). If a vendor is involved, either as the apparent sender or as a target of impersonation, they should be notified directly so they can warn their own customers. Executive leadership should be briefed. Payment authorization controls should be reviewed and tightened in the immediate term.

A post-detection review is essential: How was this detected, how long was the email in the environment before detection, and what controls would have caught it earlier? Findings should be documented and detection rules updated accordingly.

When someone has already interacted with a BEC email   

This is the harder scenario, and the one most response plans underserve. "Interaction" can mean opening the email, clicking a link, replying to the attacker, or at worst, completing a financial transaction.

If the interaction was a reply or a click (no transaction yet):

The first 15 minutes are critical. The employee's device should be isolated immediately if a link was clicked, with credential compromise assumed until proven otherwise. A password reset should be forced on their email account and any systems accessed in the period following the click. Active sessions should be revoked. Outbound email from that account should be reviewed for any data the attacker may have sent to themselves.

If the employee replied to the attacker and provided any information, even seemingly innocuous details like confirming the right contact or a payment amount, that should be treated as intelligence the attacker will use in follow-up communications to others in the organization. Relevant colleagues should be alerted that they may receive a highly targeted follow-on attempt referencing real internal details.

If a financial transaction has been initiated:

Time is the single variable that determines recovery. Wire transfers can sometimes be recalled if action is taken within hours. The moment a potentially fraudulent transaction is suspected, the CFO should be notified immediately and the bank's dedicated wire recall team contacted, not general customer service. Many financial institutions have emergency recall procedures operating on a different SLA than standard disputes.

The receiving bank should also be notified if it can be identified from the wire details. International transfers are harder to recall but not impossible. FinCEN and equivalent bodies in other jurisdictions can intervene in some cases, particularly when reported within 72 hours of the transaction.

Attempting to quietly reverse the situation without logging it is a mistake. The documentation trail matters enormously for insurance recovery and law enforcement investigation.

First 24 hours after a completed transaction:

An emergency report should be filed with IC3, specifically requesting a Financial Fraud Kill Chain (FFKC) intervention. This is a joint FBI/FinCEN mechanism with a documented track record. In 2023, the FFKC was triggered on 3,008 incidents representing $758 million in potential losses, and a monetary hold was placed on $538 million, a 71% success rate. In 2024, the rate held at 66% across $848 million in attempted recoveries. FinCEN's own guidance notes the program has greater success when transfers are reported within 72 hours of the transaction.

The cyber insurance carrier should be engaged immediately because most policies have specific notification requirements that, if missed, can affect the ability to claim. A full forensic review of the affected accounts should be initiated to look for forwarding rules that redirect copies of emails, calendar entries that may have been planted to facilitate future attacks, and any changes to email signatures or auto-reply settings. Credentials should be rotated broadly, not just for the directly affected account.

Finally, the employee who interacted with the email should be debriefed carefully and compassionately. BEC attacks are engineered by professionals to defeat rational people under time pressure. Blame is counterproductive. Understanding exactly how the attack was convincing is how defenses improve for the next attempt.

Where this is heading?

Current BEC attacks are already more sophisticated than those of 2020, and the trajectory is clear. Generative AI has removed the last reliable tell that non-native language use once provided: the awkward phrasing, the unusual formality, the subtle errors that once helped trained employees spot impersonation. Today's BEC emails are linguistically indistinguishable from authentic correspondence.

The next frontier is multimodal BEC. In February 2024, a finance worker at engineering firm Arup was deceived into wiring $25 million after joining a video conference where every other participant, including the CFO, was a deepfake. This was not an isolated incident. According to CrowdStrike's 2025 Global Threat Report, vishing attacks surged 442% from the first to the second half of 2024. These aren't edge cases previewing some distant threat; they're the current state of play for organizations that haven't updated their verification protocols beyond email.

The detection-first, response-ready posture is the only durable model. Filters will continue to fail against threats that don't carry payloads. But behavioral anomaly detection, grounded in baseline modeling, supported by layered human and process controls, and backed by rehearsed response protocols, adapts as attacks evolve.

The organizations that understand this aren't waiting to see whether their next BEC email gets blocked. They're operating with the assumption that some will get through, and they've built the systems, processes, and muscle memory to catch it anyway.

eProtect is a cloud-based email security and archiving solution that provides an additional layer of security for email accounts. The solution offers advanced threat detection mechanisms that can secure on-premise and cloud email accounts from evolving email threats. eProtect is the security solution that powers Zoho Mail, a platform that millions of users trust.