Business email compromise — universally abbreviated as BEC — is the single most financially destructive category of cybercrime tracked by the FBI. According to the FBI's Internet Crime Complaint Center (IC3), BEC attacks generated $2.9 billion in reported losses in 2023 alone, far exceeding ransomware, data breaches, and every other category. The reason is straightforward: BEC attacks do not require malware, zero-day exploits, or sophisticated technical infrastructure. They exploit trust, urgency, and the gap between how organizations think their financial processes work and how those processes actually function under pressure.
This guide is written for IT directors, security engineers, and financial controllers who need to understand what BEC attacks look like in practice, how to implement technical controls that materially reduce exposure, and what to do when an attack succeeds despite those controls. We will cover email authentication, conditional access, detection mechanisms, user training that goes beyond checkbox compliance, and incident response procedures specific to wire fraud recovery.
What Business Email Compromise Actually Is
BEC is a category of targeted social engineering attack in which a threat actor impersonates a trusted party — typically a senior executive, vendor, attorney, or HR representative — to manipulate an employee into transferring funds, redirecting payments, or disclosing sensitive information. The defining characteristic that separates BEC from generic phishing is precision: these attacks target specific individuals within an organization, reference real business relationships, and often demonstrate knowledge of internal processes that suggests prior reconnaissance or mailbox compromise.
BEC attacks do not depend on malware delivery. There is no malicious attachment to detonate in a sandbox, no URL pointing to a credential harvesting page (in most variants), and no indicators of compromise that your EDR will flag. The attack is the email itself — a well-crafted message that exploits the recipient's trust in the apparent sender and creates urgency that bypasses normal verification procedures.
Why BEC Losses Dwarf Ransomware
The IC3's 2023 report logged $2.9 billion in BEC losses against $59.6 million in reported ransomware losses — though the FBI cautions that its ransomware figure excludes lost business, downtime, remediation, and unreported incidents, so the gap reflects how completely each crime is reported as much as its true cost. This is not because ransomware is less prevalent — it is because BEC attacks result in direct financial transfers that are difficult to reverse, while ransomware payments are often negotiated down, covered by insurance, or declined entirely. When a CFO wires $800,000 to a fraudulent account based on a spoofed email from the CEO, that money is typically moved through a chain of accounts within hours and is functionally irrecoverable.
Common BEC Attack Types
BEC attacks follow several well-documented patterns. Understanding these variants is essential for building detection rules and training programs that address real threats rather than hypothetical scenarios.
CEO Fraud (Executive Impersonation)
The attacker impersonates a C-suite executive — most commonly the CEO or CFO — and instructs a subordinate to initiate a wire transfer, purchase gift cards, or process a payment. The message typically emphasizes urgency ("I need this handled before end of business today") and confidentiality ("Keep this between us until the deal closes"). The spoofed sender address may use a lookalike domain (fortress-mssp.com vs. fortressmssp.com) or may originate from a genuinely compromised executive mailbox.
Invoice Manipulation
The attacker compromises or impersonates a vendor and sends a legitimate-looking invoice with modified payment details — typically a changed bank account number. Because the invoice references a real project or purchase order, accounts payable processes the payment without escalation. This variant is particularly effective against organizations with high invoice volumes where individual payment verification is impractical under current workflows.
Attorney Impersonation
The attacker poses as external legal counsel and contacts an employee — often in finance — with an urgent request related to a confidential matter such as an acquisition, litigation settlement, or regulatory response. The legal context creates both urgency and a plausible reason for secrecy, which effectively neutralizes the recipient's instinct to verify through normal channels.
Payroll Diversion
The attacker impersonates an employee and contacts HR or payroll to request a change to direct deposit information. The fraudulent bank account receives the employee's next paycheck (or several) before the legitimate employee notices the discrepancy. This variant has lower per-incident losses but is extremely common because it requires minimal reconnaissance — just an employee name and a plausible email.
Data Theft (W-2 and PII Harvesting)
Rather than requesting funds directly, the attacker impersonates an executive and requests sensitive employee data — W-2 forms, tax identification numbers, personnel records. This data is then used for identity theft or sold on criminal marketplaces. This variant typically spikes during tax season (January through April) and targets HR departments specifically.
Technical Prevention: Email Authentication
The first layer of BEC defense is email authentication — the trio of SPF, DKIM, and DMARC. These protocols do not prevent all BEC attacks, but they eliminate the simplest and most common spoofing vectors. Organizations that have not implemented these controls are leaving the front door unlocked.
SPF (Sender Policy Framework)
SPF allows domain owners to publish a DNS TXT record specifying which IP addresses and mail servers are authorized to send email on behalf of their domain. When a receiving mail server processes an inbound message, it checks whether the sending server's IP address matches the SPF record for the domain in the envelope-from address. If it does not match, the message fails SPF validation.
Critical implementation detail: your SPF record must account for every legitimate sending source — your primary mail server, marketing platforms (Mailchimp, HubSpot), transactional email services (SendGrid, Amazon SES), ticketing systems, and any SaaS application that sends email using your domain. An incomplete SPF record forces you to use a soft fail (~all) policy, which provides minimal protection. The goal is a hard fail (-all) policy that explicitly rejects unauthorized senders.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to outbound email headers, allowing recipients to verify that the message was not modified in transit and that it originated from an authorized sender. The sending server signs a hash of specified headers and body content using a private key; the corresponding public key is published in DNS. The receiving server retrieves the public key and validates the signature.
DKIM protects against message modification, not just sender spoofing. If an attacker intercepts and modifies a legitimate email — changing wire instructions in an invoice, for example — DKIM validation will fail. This makes DKIM particularly valuable for protecting financial communications.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC ties SPF and DKIM together and adds a critical policy layer: it tells receiving mail servers what to do when authentication fails. A DMARC policy of p=reject instructs receiving servers to discard messages that fail both SPF and DKIM alignment. This is the only DMARC policy that provides actual protection — p=none (monitoring only) and p=quarantine are stepping stones, not destinations.
The path to p=reject requires careful preparation:
- Start with p=none and configure aggregate (rua) and forensic (ruf) reporting to identify all legitimate email sources for your domain
- Inventory and authorize every service that sends email as your domain — this step takes weeks, not hours, for most organizations
- Move to p=quarantine once you are confident all legitimate sources pass authentication
- Advance to p=reject after monitoring quarantine reports confirms no legitimate mail is being blocked
- Apply to subdomains using the sp= tag — attackers frequently spoof subdomains (billing.yourdomain.com) when the apex domain is protected
DMARC reporting data should be analyzed using a dedicated platform — raw DMARC XML reports are not human-readable at scale. Services like Valimail, dmarcian, or open-source tools like parsedmarc provide the visibility needed to maintain authentication posture over time.
Technical Prevention: Conditional Access and MFA
Email authentication prevents external spoofing of your domain. It does nothing to prevent attacks originating from a genuinely compromised mailbox — which is the more dangerous BEC variant. If an attacker obtains valid credentials for your CFO's Microsoft 365 account, every email they send will pass SPF, DKIM, and DMARC perfectly because it is coming from your infrastructure.
Multi-Factor Authentication (MFA) Enforcement
MFA is a baseline control against mailbox compromise: Microsoft research indicates that MFA blocks over 99% of automated account-compromise attacks. But implementation details matter enormously:
- Eliminate SMS-based MFA — SIM swapping attacks make SMS verification fundamentally unreliable for high-value accounts. Use FIDO2 security keys (YubiKey), Microsoft Authenticator with number matching, or TOTP applications
- Enforce MFA for all users, no exceptions — the C-suite accounts that are most targeted are often the same accounts that request MFA exemptions. This is the exact inversion of where protection is needed most
- Enable MFA for legacy protocols — or better, disable legacy authentication entirely. Protocols like IMAP, POP3, and SMTP AUTH do not support modern MFA and represent a bypass path that attackers actively exploit
- Implement phishing-resistant MFA — adversary-in-the-middle (AiTM) frameworks like Evilginx2 can intercept and replay session tokens from standard MFA flows. FIDO2/WebAuthn is resistant to these relay attacks because authentication is bound to the legitimate domain origin
Conditional Access Policies
Conditional access policies in Microsoft Entra ID (formerly Azure AD) or equivalent identity platforms add contextual controls beyond simple authentication. For BEC prevention, the following policies are essential:
- Block legacy authentication protocols — create a policy that blocks all connections using legacy authentication clients across all cloud applications
- Require compliant or hybrid-joined devices — limit mailbox access to managed devices, preventing access from attacker-controlled endpoints
- Named location restrictions — restrict high-privilege account access to expected geographic locations. A CFO who has never traveled to Eastern Europe should not be authenticating from Bucharest
- Sign-in risk policies — integrate with Microsoft Entra Identity Protection (or equivalent) to require step-up authentication or block access when sign-in risk is elevated
- Session controls — enforce sign-in frequency limits and disable persistent browser sessions for sensitive applications to reduce the window of session token theft
Detection: Catching BEC in Progress
Prevention controls reduce attack surface. Detection controls catch what prevention misses. For BEC, detection focuses on identifying signs of mailbox compromise and anomalous email behavior before financial damage occurs.
Impossible Travel Detection
Impossible travel alerts trigger when a user authenticates from two geographic locations within a timeframe that makes physical travel between them impossible — for example, a login from New York at 2:00 PM followed by a login from Lagos at 2:15 PM. Microsoft Entra Identity Protection generates these alerts natively, but they require tuning: VPN usage, mobile device IP changes, and corporate proxy egress points all generate false positives that must be baselined.
Effective impossible travel detection requires correlating authentication logs with HR travel data. If your CFO is attending a conference in London, a London authentication is expected. If they are not, it demands immediate investigation.
Mailbox Rule Manipulation
After compromising a mailbox, attackers almost always create inbox rules to hide their activity. The most common patterns include:
- Auto-delete rules — rules that permanently delete incoming messages containing keywords like "fraud," "unauthorized," "wire," or "suspicious" to prevent the legitimate user from seeing warnings
- Auto-forward rules — rules that silently forward all incoming mail (or mail matching specific criteria) to an external address, allowing the attacker to monitor communications without maintaining persistent access
- Move-to-folder rules — rules that redirect messages from specific senders (IT security, finance, the person being impersonated) to obscure folders like RSS Feeds or Deleted Items
Monitor for these indicators using proactive security monitoring that includes audit log analysis. In Microsoft 365, the unified audit log records New-InboxRule, Set-InboxRule, and Set-Mailbox (for forwarding) operations. Alert on any inbox rule creation that includes forwarding to external domains or deletion actions, and investigate immediately.
Mail Flow Anomalies
Beyond rule manipulation, monitor for behavioral indicators of compromise:
- Sudden increase in external email volume from a specific mailbox, particularly to new recipients
- Email sent during unusual hours — a CFO who never sends email at 3:00 AM sending wire authorization at 3:00 AM warrants investigation
- Changes to mail forwarding or delegation at the mailbox level (distinct from inbox rules)
- Access from new devices or clients — particularly Thunderbird, IMAP clients, or email clients not standard in your environment
- OAuth application consent — attackers use malicious OAuth applications to gain persistent mailbox access that survives password resets
User Awareness Training That Actually Works
Most security awareness training programs fail to prevent BEC because they train employees to recognize obvious phishing — misspelled URLs, Nigerian prince scenarios, generic "Dear Customer" messages. BEC attacks bear no resemblance to these examples. Effective BEC awareness training must be uncomfortable, realistic, and operationally specific.
What Effective Training Covers
- Real BEC examples from your industry — not generic case studies. Show employees actual (anonymized) BEC emails that targeted organizations like yours. The FBI IC3 publishes case summaries; use them
- Process verification, not email inspection — train employees that the defense against BEC is not identifying a fraudulent email by visual inspection (attackers are too good at this) but following verification procedures regardless of apparent sender identity. "If someone asks you to change wire instructions, call them at a known phone number. Every time. No exceptions."
- Executive-specific training — the C-suite must participate. Executives are both the most impersonated and the most targeted. Executive exemption from security training programs is a critical vulnerability
- Simulated BEC exercises — conduct tabletop exercises where finance teams receive simulated BEC emails during normal business operations and measure response. Not as a punishment mechanism, but as a process validation exercise
Procedural Controls
Technical and training controls must be reinforced by procedural controls that make BEC exploitation mechanically difficult:
- Dual authorization for wire transfers above a defined threshold — two people from different departments must approve
- Out-of-band verification for any change to payment instructions — call the vendor at a previously established phone number, not the number in the email requesting the change
- Payment change cooling period — implement a mandatory 24-48 hour delay before processing changed banking information for existing vendors
- Callback verification for new vendors receiving payments above a threshold — verify banking details via phone using contact information from a signed contract, not from email correspondence
Incident Response for BEC: The Critical First Hours
When a BEC attack succeeds and funds are transferred, time is the single most important variable in recovery. The window for wire recall is measured in hours, not days. Having an incident response plan that addresses BEC specifically is essential — generic IR plans rarely include the financial recovery procedures that matter most in these scenarios.
Immediate Actions (First 1-2 Hours)
- Contact your bank immediately — request a wire recall or SWIFT recall message. Domestic wires can sometimes be reversed within 24 hours. International wires move faster and are harder to recover, but immediate notification gives the best chance
- File an IC3 complaint at ic3.gov — report immediately so the FBI's Recovery Asset Team can attempt to freeze the funds through the Financial Fraud Kill Chain (FFKC); speed is decisive. In 2025 the program froze about $679 million of roughly $1.16 billion in attempted theft across 3,900 cases — a 58% success rate (FBI IC3 2025 Internet Crime Report). The $50,000-minimum, within-72-hours, and SWIFT-recall criteria apply specifically to international wires
- Contact law enforcement — file a report with your local FBI field office. For NYC-area organizations, the New York field office has a dedicated cyber squad
- Preserve evidence — do not delete the fraudulent email. Export it with full headers. Screenshot any related communications. Preserve audit logs from your email platform
Containment (Hours 2-24)
- If a mailbox was compromised: immediately reset the password and revoke all active sessions. Review and remove any attacker-created inbox rules or mail forwarding. Check for OAuth application grants and revoke any that are unauthorized. Check for persistence via mail delegation
- Review authentication logs to determine the scope of compromise — was only one mailbox affected, or did the attacker access additional accounts?
- Search for related BEC activity — if the attacker compromised one mailbox, they likely sent fraudulent messages to other internal and external recipients. Identify and recall those messages
- Notify affected parties — if the attacker impersonated your organization to external parties (vendors, clients), notify those parties immediately to prevent further losses
Recovery and Hardening
After containment, the focus shifts to understanding how the attack succeeded and closing the gaps. This is where a structured post-incident review process becomes valuable — the same rigor applied to ransomware recovery applies to BEC, even though the technical indicators differ.
- Root cause analysis — determine whether the attack used external spoofing (indicating email authentication gaps) or a compromised mailbox (indicating credential or access control failures)
- Authentication review — verify DMARC policy is at p=reject, review SPF/DKIM configuration, confirm MFA is enforced across all accounts
- Process review — evaluate whether existing financial controls were followed or bypassed, and strengthen verification procedures accordingly
- Insurance notification — if you carry cyber insurance with social engineering coverage, notify your carrier within the policy's required timeframe. Note that many policies distinguish between "computer fraud" and "social engineering fraud" with different coverage limits
How Fortress MSSP Addresses BEC Risk
BEC prevention requires layered controls that span email infrastructure, identity management, network architecture, monitoring, and organizational process. No single tool or product eliminates BEC risk. Our approach integrates multiple service lines to address the problem comprehensively:
- Architecture hardening — we assess and harden your email infrastructure, implement DMARC/DKIM/SPF with p=reject enforcement, configure conditional access policies, eliminate legacy authentication protocols, and deploy phishing-resistant MFA across your environment
- Proactive security monitoring — continuous monitoring of authentication logs, mailbox rule changes, mail flow anomalies, impossible travel alerts, and OAuth application consent events. We do not wait for users to report suspicious emails — we detect compromise indicators before the financial damage occurs
- Security assessments — our email security assessments include simulated BEC exercises that test your organization's technical controls, user awareness, and financial verification procedures under realistic conditions. We identify gaps in all three layers and provide specific, actionable remediation guidance
- Incident response support — when a BEC attack succeeds, our team assists with mailbox containment, evidence preservation, wire recall coordination, and post-incident hardening. The speed of initial response is the primary determinant of financial recovery — having a team that has handled these incidents before makes a material difference
BEC is not a technology problem that a technology product solves. It is an operational security challenge that requires technical controls, procedural rigor, and ongoing vigilance. The organizations that avoid catastrophic BEC losses are the ones that implement verification processes before they are needed and enforce them without exception — including when the apparent sender is the CEO on a Friday afternoon asking for an urgent wire.
View our pricing for email security assessments, architecture hardening, and managed security services, or schedule a consultation to discuss your organization's BEC exposure. We bring practitioner-level expertise to a problem that most security vendors try to solve with a spam filter.