Investigating Business Email Compromise (BEC): A Practical Approach

What is Business Email Compromise (BEC)?

Business Email Compromise (BEC) is a type of cybersecurity attack where attackers impersonate a trusted party (such as the CEO) via fraudulent email, often leading to unauthorized fund transfers, payroll fraud, or exposure of sensitive information. BEC continues to be the most financially devastating cybercrime, with global losses surpassing $50 billion since 2013 and nearly $3 billion reported in the United States in 2023, according to the FBI.

Unlike broad phishing campaigns, BEC attacks are typically targeted, subtle, and driven by social engineering. The primary goal is to manipulate employees, often those in finance, human resources, or executive roles, into transferring money or disclosing confidential data under false pretenses.

In this blog, we walk through a practical, technical workflow for investigating a suspected BEC incident using real world telemetry such as email headers, authentication logs, file access, and behavioral signals.

Trigger: What Initiated the Investigation?

A BEC investigation typically starts when an anomaly is observed. Common triggers include:

• A user reports a suspicious or context-free message, such as “Are you in the office?” or “I need a quick favor.”
• A financial transaction request deviates from standard procedures or comes from an unexpected sender.
  A vendor suddenly changes payment instructions without prior coordination.
• A detection system flags anomalous behavior such as impossible travel, legacy authentication, or the creation of new mailbox rules.

Pro tip: Always retrieve the original email directly from the user’s mailbox using your email platform’s message trace or eDiscovery tools. Avoid relying on emails that have been forwarded to IT or security teams. Forwarded messages often strip or reformat critical metadata, including:

• The full Received: header chain that reveals hop-by-hop mail server routing.
• Authentication results like SPF, DKIM, and DMARC verdicts.
• X-Headers such as X-MS-Exchange-CrossTenant-AuthAs or X-Google-DKIM-Signature, which can provide insights into the sending infrastructure.
• MIME boundaries and encoding schemes, which may be altered or flattened during forwarding.

Losing these details can significantly reduce your ability to confirm spoofing, domain misalignment, or message tampering. In forensic investigations, always preserve the message in its original form, ideally as an .eml or .msg file, before beginning deeper analysis.

Step-by-Step Investigation Workflow

Step 1: Examine the Email Header and Authentication Artifacts

Start by collecting the full raw headers of the original email. Focus on the following components:

Return-Path

This should align with the sender’s domain. A mismatch between the visible “From” address and the Return-Path may indicate spoofing. For example, an email claiming to be from ceo@company.com but with a Return-Path of ceo@externaldomain.io is suspicious.

SPF (Sender Policy Framework)

SPF verifies whether the sending IP address is authorized to send on behalf of the domain in the Return-Path. A proper SPF record is configured in the DNS TXT record of the domain, and looks like this:

• PASS: The sender IP is authorized.
• FAIL: The IP is not authorized. Investigate further.
• SOFTFAIL or NEUTRAL: These may still allow spoofed emails to pass depending on the receiving mail server’s policy.

DKIM (DomainKeys Identified Mail)

DKIM ensures the integrity of the email content and verifies it was not modified in transit. It uses a cryptographic signature tied to the sender’s domain. The public key is published in DNS, and the mail server signs the message with the private key.

• A passing DKIM result confirms the message was signed and not altered.
• A missing or failing DKIM may indicate tampering or poor domain hygiene.
  

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC aligns SPF and/or DKIM with the domain in the “From” address and tells the recipient how to handle failures. The record is published in DNS as:

• p=reject tells recipients to reject emails that fail alignment.
• p=quarantine places them in the spam folder.
• p=none allows delivery but logs the incident.
  

Example Findings from a Suspicious Email:

Interpretation: SPF fails, DMARC is not defined, and DKIM passes. Because DMARC is absent, there is no policy enforcing alignment, making this message more likely to be fraudulent. SPF failure is a key indicator that the IP is spoofed.

Step 2: Investigate Sender Identity and Intent

Determine whether the email originated from a legitimate source or was designed to impersonate one. BEC attacks often leverage one of the following methods:

• Spoofed domain: The “From” address is forged to appear legitimate but was never authorized by the domain owner. Spoofing often bypasses naive header inspection, which is why SPF, DKIM, and DMARC validation is essential.
• Legitimately compromised account: The attacker has obtained valid credentials for a real user and is sending messages from within the trusted email platform. In this case, the sender’s domain, headers, and authentication results may all appear normal. Investigators must rely on behavioral anomalies such as login geography, device fingerprinting, or irregular timing.
• Lookalike domain: The attacker registers a domain visually similar to a legitimate one, relying on character substitution or typosquatting. For example:
  
  • micros0ft.com instead of microsoft.com (digit 0 instead of letter o)
  • rnicrosoft.com instead of microsoft.com (r and n together appear like m)
  • support-cornpany.com where "cornpany" uses an r and n instead of m
    

• Homograph Attacks Using Unicode Characters
  
  • Attackers can exploit visually identical characters from different writing systems to create deceptive domains that look like legitimate ones. These are called homograph attacks and are commonly used in BEC scams to trick recipients into trusting fake sender addresses.
  • For example, the domain аррӏе.com (using Cyrillic characters) looks nearly identical to apple.com but represents different Unicode code points. While it appears the same to most users, it points to a completely different destination on the internet.

How These Domains Appear in DNS

Since the Domain Name System (DNS) supports only ASCII characters, these Unicode domains are encoded into an ASCII-compatible format called Punycode. This conversion allows the domain to be resolved by DNS servers even though it contains non-ASCII characters. For example:

When viewed at the DNS or network layer, you see the Punycode version (xn--80ak6aa92e.com), not the Unicode domain.

Decoding Punycode to Unicode

To detect potential homograph domains, you can decode Punycode back to its Unicode form using tools or scripts. Below is a simple Python example using the built-in IDNA codec:

This process reveals the exact Unicode characters used, enabling analysts to identify visually deceptive characters that bypass simple string comparisons.

Action points:

• Use WHOIS and DNS tools to inspect domain creation dates, registrars, and MX records.
• Use idna decoding tools to inspect Punycode-encoded domains and reveal Unicode spoofing.
• Maintain internal allowlists of known domains and alert on near-match lookalikes.

Step 3: Behavioral Signals and Authentication Logs

Once you suspect a BEC attack, it is critical to analyze behavioral telemetry and authentication logs to confirm account compromise or malicious activity. Common data sources include:

• Identity provider logs (e.g., Azure AD sign-in logs, Okta)
• Security Information and Event Management (SIEM) systems
• Audit trails from email platforms (e.g., Microsoft 365 Unified Audit Logs, Google Workspace reports)

Key Areas to Investigate

1. Multi-Factor Authentication (MFA) Status

• Was MFA enforced for the compromised mailbox?
  Absence of MFA significantly increases risk of credential theft leading to unauthorized mailbox access.
• Check for recent changes to MFA settings or bypass events.
  Some attackers attempt to disable MFA or use stolen tokens to evade this protection.
  

2. Login Anomalies

Look for suspicious sign-in activity including:

• Authentication from unfamiliar IP addresses or IP ranges, especially those originating from foreign countries unrelated to the user’s normal work locations.
• Unusual timeframes or login times inconsistent with user behavior or timezone.
  Rare or new user agents and devices—for example, a login from a browser or operating system not previously seen for this account.
• Concurrent sessions that exceed normal usage patterns.

Such anomalies can indicate credential theft, session hijacking, or use of automated tools.

3. Creation and Modification of Inbox Rules

Inbox or mail flow rules are a favorite tactic for attackers who have compromised a mailbox. These rules enable persistent control and stealthy exfiltration. Common malicious mailbox rules include:

• Automatic forwarding of all or selected emails to external addresses, especially free email providers (Gmail, Yahoo, etc.).
• Filtering, moving, or deleting emails containing keywords such as “invoice,” “wire transfer,” “payment,” or “purchase order.”
• Suppressing notifications or alerts to prevent the victim or security teams from noticing suspicious activity.

Example of a suspicious mailbox rule JSON snippet:

Such a rule silently forwards critical financial communications to the attacker, enabling them to intercept invoice requests or payment instructions.

4. Additional Behavioral Indicators

• Mailbox export activities: Check for exports or downloads of mailbox data (e.g., PST exports, eDiscovery requests) that could indicate data theft.
• Unusual calendar activity: Attackers may manipulate meeting requests to hide activity or trick users into clicking malicious links.
• OAuth token grants: Examine consent logs for suspicious third-party applications granted mailbox access.
  

Investigative Best Practices

• Correlate authentication anomalies with mailbox rule changes to pinpoint suspicious timeline overlaps.
• Use automated detection rules or UEBA (User and Entity Behavior Analytics) to identify deviations from baseline behavior.
• Prioritize remediation on accounts lacking MFA or showing evidence of rule creation for auto-forwarding or deletion.

Step 4: Cross-Check Against Business Processes

BEC attacks frequently exploit weaknesses or gaps in business workflows. As part of your investigation, validate whether the suspicious communication aligns with established business procedures and logic. Key questions to consider:

• Was the request related to a legitimate, known project or business process?
• Did the request follow documented approval workflows or change management policies?
• Did the communication introduce a new payment beneficiary, bank account, or request a rush transfer without standard verification?
• Is the tone, email signature, and language consistent with prior legitimate communications from the same sender or department?

To identify deviations, compare the suspicious request against trusted baselines such as vendor master data, procurement approval flows, payment request forms, and historical email templates. Any deviation from these established norms should raise suspicion and be treated as a potential manipulation vector.

Step 5: Assess Lateral Impact and Mailbox Exposure

If the investigation confirms mailbox compromise, expand your scope to assess the attacker’s lateral movement, persistence, and data exfiltration capabilities:

• Review internal communications to identify other user accounts or departments that interacted with the compromised mailbox. This helps detect potential spread or collusion.
• Analyze mailbox access logs for unusual activity such as large IMAP/POP downloads, mailbox export operations (e.g., PST exports), or bulk email deletions.
• Investigate cloud storage usage—examine OneDrive, SharePoint, or other integrated platforms for anomalous access to sensitive files like contracts, invoices, or HR documents.
• Check for credential reuse by cross-referencing compromised account credentials across other enterprise systems, increasing the risk surface.
  

Indicators of lateral movement or persistence may include:

• The attacker sends new BEC emails internally to propagate the attack or confuse detection.
• Unauthorized OAuth token grants or app password creation that maintain access even if the password is reset.
  

Containment and Remediation

Based on your findings, execute an appropriate containment strategy:

• Reset compromised passwords immediately and revoke all active sessions and refresh tokens. Simply changing the password is not sufficient because attackers can maintain persistent access using valid authentication tokens or active sessions issued before the password reset. Revoking these tokens ensures all sessions are terminated and the attacker must reauthenticate with the new credentials.
• Disable or remove malicious inbox rules that automatically forward, delete, or suppress emails to prevent ongoing data exfiltration or stealthy communication interception.
• Notify impacted vendors, customers, and internal stakeholders about the breach and any changes to payment details to prevent fraudulent transactions and maintain trust.
• Report the incident to relevant authorities, such as the FBI’s Internet Crime Complaint Center (IC3), especially if financial losses have occurred, to aid in investigation and potential recovery.
• Educate users and teams on recognizing BEC tactics and enforcing safe email practices to reduce the risk of future attacks.

BEC Attack Prevention Tips

To reduce risk and strengthen defenses, implement the following best practices:

• Enforce multi-factor authentication (MFA) on all email and critical system accounts.
• Block automatic email forwarding to external domains, which attackers often use for data exfiltration.
• Deploy DMARC policies with reject or quarantine enforcement to prevent spoofed emails from reaching users.
• Conduct regular security awareness training focused on verifying payment and wire requests via secondary channels such as phone calls.
• Continuously monitor login behavior, mailbox rule changes, and unusual email activity using security analytics platforms or SIEM integrations.

Final Thoughts

Business Email Compromise is less about malware and more about deception, social engineering, and exploiting trust within organizations. Effective investigation demands not only technical expertise analyzing telemetry and authentication data but also a solid understanding of business context and communication patterns.

A layered defense combining strong technical controls, user education, and clear financial policies is your best strategy to prevent and detect these attacks early.

Frequently Asked Questions (FAQ)

What is Business Email Compromise (BEC) and how does it work?

Business Email Compromise is a targeted cyberattack where threat actors impersonate a trusted party—like a CEO or vendor—via email to trick employees into transferring money or sharing sensitive data. These attacks rely heavily on social engineering and are typically difficult to detect because they mimic normal business communication.

How is BEC different from phishing attacks?

While phishing is often broad and generic, BEC attacks are targeted, context-aware, and involve impersonation of known individuals or organizations. BEC relies more on deception and psychological manipulation than malicious links or attachments.

What are the first signs of a BEC attack?

Early signs of BEC include vague or urgent emails from executives, unexpected requests to change payment instructions, and detection alerts such as mailbox rule changes or logins from unusual locations. Suspicious sender domains and missing or failing email authentication (SPF, DKIM, DMARC) are also key indicators.

How can you investigate a suspected BEC email?

To investigate a BEC email, start by retrieving the original message—not a forwarded copy—and analyze the full headers, including Return-Path and authentication results. You should also review behavioral signals like login anomalies, mailbox rules, and OAuth token activity to identify compromise or intent.

What tools or logs help confirm BEC account compromise?

Authentication logs from identity providers like Azure AD or Okta, audit trails from email platforms like Microsoft 365, and SIEM alerts are essential for confirming BEC compromise. Look for MFA bypasses, unusual IP logins, and the creation of inbox rules that enable stealthy access.

Can BEC attacks spread laterally within an organization?

Yes, once an account is compromised, attackers often move laterally by messaging other employees or accessing shared resources. Analysts should check for unauthorized OAuth grants, credential reuse, and mailbox exports that may indicate data theft or persistence.

What are the most effective ways to prevent BEC attacks?

Key BEC prevention measures include enforcing multi-factor authentication, blocking external email forwarding, deploying DMARC with a reject policy, and educating users on how to verify unusual requests. Monitoring login patterns and mailbox rule changes also helps detect attacks early.

What metrics show the impact of a strong BEC investigation and response?

SOC teams that implement structured BEC detection and investigation workflows often see a reduction in dwell time and mean time to respond (MTTR). Faster containment of mailbox compromises reduces financial risk and limits potential data exposure.