Business Email Compromise: A 10-Step Investigation Guide for Forensic Investigators

Business Email Compromise (BEC) is the simplest, most lucrative, most underestimated email scam in the cyber-criminal arsenal. According to the FBI’s Internet Crime Complaint Center, BEC has accounted for billions of dollars in reported losses over the past decade, with average losses per victim well into the tens of thousands and headline cases running into the millions. Most BEC intrusions don’t require advanced malware or zero-day exploits — they rely on social engineering, a compromised mailbox, and a malicious forwarding rule. If you work in DFIR, threat intelligence, or run an Office 365 environment of any size, you will see one.

This guide is a practical, end-to-end framework for investigating BEC in Office 365 / Microsoft 365 (where most BEC activity lands today) and applies equally well to other modern email environments. It walks through scope, evidence collection, detection of the most common attacker behaviours, and the configuration changes that close the front door for next time.

The 10-step framework

1. Investigation Kickoff — define scope, list questions, run the checklist.
2. Preparation & Collection — what logs exist, who can pull them, how to extract.
3. Forwarding Rules — the single most common BEC TTP.
4. Login Activity — suspicious sign-ins, MFA errors, brute force.
5. Permission Changes — mailbox delegation, role-group additions, new accounts.
6. OAuth2 Abuse — malicious app consent that bypasses passwords entirely.
7. Evasion Techniques — purge rules, audit-log disable, eDiscovery abuse.
8. Assess Data Accessed or Exfiltrated — MailItemsAccessed, forwarding output.
9. Threat Intelligence, Phishing Emails & Malware — subject lines, themes, domains, malware families.
10. Recommendations — the prevention checklist.

Step 1: Investigation Kickoff

BEC investigations usually start with a small, scary signal — someone wired money to the wrong account or a customer says we asked them to update banking details we never asked them to update. Your job is to scope from that single signal. The kickoff produces three things: a list of investigative questions, a checklist of actions, and a defined scope.

The questions to answer

The checklist

Non-exhaustive but high-leverage. Print it, walk down it.

• Kickoff: Scope defined.
• Collection: Retention window confirmed (90 days E3, 365 days E5). Admin Audit Log, UAL, Message Trace Log collected.
• Forwarding rules: Names noted. Folders flagged (RSS, Archive, Junk Email, Conversation History). External recipients flagged.
• Login activity: Suspicious IPs / countries. Brute-force attempts. Username-guess events.
• Permission changes: New users. Users added to admin role groups. New mailbox-folder permissions.
• OAuth2 abuse: Unexpected applications, recent consent grants, admin-consented apps.
• Evasion: Audit log disabled, items shared externally, eDiscovery alerts.
• Data accessed: Threat-actor sessions identified. Messages accessed. Data exfiltrated by forwarding rule. Impact analysis.
• Threat intel: Sender / receiver domains. Email headers. Email content (attachments, links, fake signatures).
• Recommendations: Strong password policy, MFA, mailbox audit logging, block external forwarding.

Step 2: Preparation & Collection

Three logs do the heavy lifting in an Office 365 BEC investigation: the Unified Audit Log (UAL), the Administrator Audit Log, and the Message Trace Log. Permissions and collection method matter as much as which logs you pull — if you wait until you need them to figure out either, you’ve lost time.

Unified Audit Log (UAL)

The UAL is the centralised source for Office 365 events — at least 76 categories, including Azure, Exchange, SharePoint, OneDrive, and Skype. It is the most important log in any BEC investigation.

Permissions. You need View-Only Audit Logs or Audit Logs in Exchange Online. A clean minimum-privilege pattern:

1. Create a user in admin.microsoft.com.
2. Assign the Global Reader role.
3. In the Exchange admin center, create a new role group, add the Audit Logs role.
4. Add the user to the new group.

What to extract. Three options:

• The complete UAL (best for a complete timeline; can take a long time on large tenants).
• Specific RecordTypes (groups of related events — e.g. all Exchange logging, all Azure logging). Faster.
• Specific artifacts (forwarding rules, login events, etc.). Triage only — don’t investigate exclusively from this.

How to extract. The Security & Compliance Center caps at 5,000 sorted / 50,000 unsorted records per query — functionally useless on real BEC cases that often have millions of events. The Office 365 Management API has limited history depth. PowerShell’s Search-UnifiedAuditLog is the reliable mechanism, and several open-source wrappers around it (such as the Office 365 Extractor on GitHub) handle the pagination and 5,000-record cap automatically by re-running the cmdlet in time slices:

# Generic pattern: walk N-minute windows, page until empty
$start = (Get-Date).AddDays(-30); $end = Get-Date; $win = New-TimeSpan -Minutes 60
while ($start -lt $end) {
    $next = $start + $win
    Search-UnifiedAuditLog -StartDate $start -EndDate $next -ResultSize 5000 |
        Export-Csv -Path "ual.csv" -Append -NoTypeInformation
    $start = $next
}

For minimum useful coverage extract these RecordTypes at a minimum:

For single-account triage, HAWK is a useful PowerShell tool — it pulls CAS mailbox info, login events with IPs, mailbox audit, forwarding info, inbox-rule info, mailbox stats, and Azure auth logs in one pass.

Administrator Audit Log

Records Exchange Online PowerShell cmdlets executed by administrators. Only extract this if the UAL is unavailable — the UAL contains everything the Admin Audit Log does. On older or non-UAL-enabled tenants, pull it with:

Search-AdminAuditLog -StartDate 09/17/2020 -EndDate 10/02/2020 |
    Export-Csv output.csv -NoTypeInformation -Append

Message Trace Log

Tracks email messages as they move through Exchange Online. Required to determine whether a message was received, rejected, deferred, or delivered — and what was done to it before it reached its final state. Required role groups: Organization Management, Compliance Management, or Help Desk.

For data older than 7 days you must specify a value for date range, delivery status, message ID, sender, or recipient. PowerShell extraction (Microsoft’s pattern):

do {
    Write-Host "Processing - Page $Page..."
    $Batchfile = Get-MessageTrace -StartDate (Get-Date).AddDays(-7) `
        -EndDate (Get-Date) -PageSize 5000 -Page $Page |
        Select Received,*Address,*IP,Subject,Status,Size
    $Batchfile | Export-Csv c:\FILE-$PAGE.csv -NoTypeInformation
    $Page++
} until ($Batchfile -eq $null)

Step 3: Forwarding Rules

Email forwarding rules are the defining BEC TTP. A threat actor compromises a mailbox, creates an inbox rule that BCCs every incoming message (or just messages matching keywords like invoice, payment, wire) to an external address, and frequently moves the BCC’d copies into a hidden folder so the user never notices. The compromised account’s password can be reset and the threat actor still has full read access to the mailbox.

Detect new forwarding rules

Detect rules being modified

Properties on active rules

• DeliverToMailboxAndForward — messages are forwarded to another mailbox.
• ForwardingSMTPAddress — ProxyAddress fallback.
• ForwardingAddress — mail-enabled forwarding target.
• SentTo, BlindCopyTo, ForwardTo — destination fields.

Malicious vs expected

Large organisations have many legitimate forwarding rules. Two heuristics narrow the field:

• External recipient. Forwarding to a non-corporate domain — especially when paired with subject keywords like invoice, payment, wire, banking — is a red flag. Confirm with the IT admin and the mailbox owner before clearing.
• Hidden folder destination. The threat actor’s preferred hiding spots are RSS Feeds, Archive, Junk Email, and Conversation History. Most users never look at these. A rule that BCCs externally and moves the source message to RSS Feeds is malicious until proven otherwise.

MITRE mapping

• T1114.002 — Email Collection: Remote Email Collection.
• T1114.003 — Email Collection: Email Forwarding Rule.

Step 4: Login Activity

Every login generates a UAL event with the IP, user agent, and timestamp. Three lenses produce most of your initial-access leads.

Suspicious logins

Beyond the operation itself, three fields make or break the analysis:

• IP address & geolocation. Logins from countries where the company has no presence and no VPN exit are red flags by default.
• UserAgent. A new device or non-corporate client signing in is worth a second look.
• Time-of-day. Sign-ins outside the user’s normal working hours, especially overnight, often correlate with threat-actor activity.

MFA errors

If a threat actor has the password but not the second factor, MFA generates events you can pivot on:

Brute force

After identifying a brute force, the next question is whether it succeeded — look for a successful login immediately after a burst of failures from the same source IP. Caveat: sync activity (mobile clients, etc.) generates patterns that mimic brute force; it’s almost always a false positive there.

MITRE mapping

• T1110.001–004 — Brute Force (Password Guessing, Cracking, Spraying, Credential Stuffing).
• T1078.001–004 — Valid Accounts (Default, Domain, Local, Cloud).

Step 5: Permission Changes

Once a threat actor is in, they often need more privileges than the compromised account has — or they want a back door that survives a password reset. Permission changes show up clearly in the UAL.

Watch the high-privilege admin roles in particular — any addition to these warrants a review:

• Billing administrator
• Conditional Access administrator
• Exchange administrator
• Global administrator
• Helpdesk (Password) administrator
• Password administrator
• Security administrator
• SharePoint administrator
• User administrator

New user accounts are another persistence vector — a threat actor creates a low-profile account, often in a cloud-only configuration, that survives long after the original compromise is cleaned up. Search for the Added user operation in the UAL, and cross-reference the admin.microsoft.com/AdminPortal/Home#/users dashboard against an HR / IT-admin–provided list of expected users. Anything in the dashboard that’s not on the expected list deserves a hard look.

MITRE mapping

• T1136.002 — Create Account: Domain Account.
• T1136.003 — Create Account: Cloud Account.

Step 6: OAuth2 Abuse

OAuth abuse is the BEC adaptation that bypasses passwords and MFA entirely. The threat actor sends a phishing link that prompts the user to grant a (malicious) third-party application permission to access their mailbox, contacts, files, etc. The user accepts; the application gets a token; the threat actor reads the mailbox indefinitely without ever needing the password.

Detect it in the UAL

The application name lives under the ID field of the Consent to application or Add app role assignment grant to user events. Open the Consent to application event and look at ConsentAction.Permissions — you’ll see the exact permission set granted. A typical malicious app asks for things like:

Contacts.Read User.Read Mail.Read Notes.Read.All
MailboxSettings.ReadWrite Files.ReadWrite.All openid profile

That set lets the app read all mail, contacts, OneNote notes, mailbox settings, and OneDrive files — effectively full read on the user’s data.

Review what apps are assigned

Two ways to enumerate applications:

• https://myapps.microsoft.com — user-visible app list. The default apps in any tenant are listed in the source guide; anything beyond that — especially apps with names like Easy Mailbox Viewer, Auth0 Provisioning, Magnet Forensics, etc. that look enterprise-flavoured but were never deployed by the org — needs review.
• Azure portal → user → Applications — admin view; click into any suspicious app and choose View Granted Permissions.

Tenant-wide enumeration

For an at-scale view, run Get-AzureADPSPermissions.ps1. It dumps every delegated permission (OAuth2PermissionGrants) and every application permission (AppRoleAssignments) in the tenant to CSV — perfect for hunting unexpected apps that were quietly consented to.

MITRE mapping

• T1550.001 — Use Alternate Authentication Material: Application Access Token.

Step 7: Evasion Techniques

BEC threat actors don’t want to be found, so they cover their tracks. Four behaviours come up repeatedly.

Purge / delete rules for forwarded emails

Alongside the BCC-to-external rule, threat actors often create a second rule that auto-deletes (or trashes) any incoming reply matching specific terms. The classic pattern: send a fake invoice from the compromised account, then auto-delete every reply so the real user never sees the conversation.

Audit log disabled by user

Disabling the audit log is itself an audit event:

eDiscovery abuse for evidence deletion

eDiscovery is a legitimate compliance tool — it’s also a fast way for an attacker with privileges to hard-delete evidence (phishing emails, replies, etc.) across the tenant.

Alternate authentication methods

OAuth abuse (Step 6) is itself an evasion technique — once the application access token exists, password resets and MFA prompts don’t affect it.

MITRE mapping

• T1562.001 — Impair Defenses: Disable or Modify Tools.
• T1550.001 — Use Alternate Authentication Material: Application Access Token.

Step 8: Assess Data Accessed or Exfiltrated

The single hardest question the victim will ask is what did they see. The honest default answer is assume everything in the compromised mailbox. With the right logs you can sometimes do better.

MailItemsAccessed

Captured in the UAL under two RecordTypes:

• Sync access — recorded when a desktop Outlook (Windows or Mac) syncs the mailbox.
• Bind access — recorded when an individual message is opened. Includes the message’s InternetMessageId — that’s how you tie a UAL event back to a specific email.

Open-source helpers exist that wrap both the UAL queries and the Message Trace lookups for this workflow — useful when you’re working through dozens of sessions.

Workflow:

1. Identify threat-actor sessions. Search MailItemsAccessed for the victim email account or known-malicious IP. The output is a list of SessionIds and IPs — cross-reference your IOCs from earlier steps to mark sessions as legitimate vs threat-actor. The OperationCount field counts bind operations aggregated within a 2-minute window. Some sessions have no SessionId — that means legacy authentication was used.
2. Identify InternetMessageIDs. Pull the MessageIDs out of the threat-actor session events. These uniquely identify each accessed email.
3. Resolve to email metadata. Search the Message Trace Log for each InternetMessageID — that returns the email’s metadata (from / to / subject / date). Then pivot into ComplianceSearch in the Compliance Center for content review.

Limitations:

• Sync events don’t always fire reliably — in practice, full Outlook syncs sometimes leave no Sync access record at all. Don’t treat the absence of a sync event as proof the mailbox wasn’t synced.
• Get-MessageTrace only goes back 10 days; Start-HistoricalSearch works further back but is slow.
• MailItemsAccessed is Office 365 E5 only. No E5 license, no per-message data.

Identify data exfiltrated

Active forwarding rules are the most common exfiltration channel; the property list is the same as Step 3 (DeliverToMailboxAndForward, ForwardingSMTPAddress, ForwardingAddress, SentTo, BlindCopyTo, ForwardTo). Search the UAL for events tied to a malicious forwarding rule, collect the InternetMessageIDs of every forwarded message, then resolve metadata via Message Trace as above — that gives you the impact-assessment list.

Documents shared externally

Filter out internal accounts; focus on external recipients of secure links.

eDiscovery alerts

Suspicious eDiscovery queries should be cross-checked with whoever in the org legitimately oversees legal/compliance.

Step 9: Threat Intelligence, Phishing Emails & Malware

You hunt initial-access artefacts last, not first — intrusion analysis works backwards once the active compromise is contained. By the time you’re here you already know a lot about the actor’s behaviour; this step is about closing the loop on how they got in.

Initial-access categories

• Phishing — often pure social engineering with no link or attachment, just a manipulative request. Begins with a benign “hello” or “urgent request” and evolves over multiple replies into a fraudulent wire-transfer request.
• Spearphishing attachment — fake invoices used as social-engineering lures (often without malware), or actual malware-bearing attachments. Industry research has shown roughly half of BEC-related malware samples are detectable by public multi-AV scanners; the rest typically require reverse engineering or sandbox analysis.
• Spearphishing link — the most common observed technique. Disguised as “Click to View Document” redirecting to a credential-harvesting page, or directly downloading malware. Hover the link, capture the URL, pivot on hosting infrastructure.
• Trusted relationship — the threat actor compromises one organisation, reads the email between them and their clients, then emails real clients from the legitimate compromised account requesting a payment with new bank details. Look for emails referencing “new” or “switching” bank accounts.
• Valid accounts — password spraying, brute force, credential stuffing against weak / re-used passwords.
• OAuth abuse — covered above (Step 6).

Hunting characteristics

Subject lines. Generic, urgency-driven, frequently combined with a victim’s first name. Sample list: Request, Overdue, Confirmation, Payments, Confidential, Urgent, Action Required, Account Suspended, Password Confirmation, Reconfirm Password, Voicemail from [Phone Number], VM from [Phone Number], Sign-in attempt, Invoice.

Themes. Spoofed brands — Microsoft, OneDrive, OneNote, SharePoint, Outlook, DropBox, DocuSign, Apple, PayPal, Amazon, DHL. Topics — password / account resets, file-sharing notifications, fake voicemails, geopolitical / seasonal hooks (COVID-19 wire-change requests, tax-season lures).

Attachments. Even non-malware attachments are intelligence gold — fake invoices contain names, phone numbers, dates, and bank account numbers. Country codes on phone numbers (e.g. +234 = Nigeria) hint at origin. Bank account numbers can be passed to the receiving bank to flag the account and possibly recover funds.

Domains. Typo-squatting (ITcornpany[.]com with r+n for m), TLD swaps (.com → .co), look-alike role addresses (info@, billing@) on fake domains. Free webmail (Gmail in particular) is heavily used by BEC actors — it’s free, fast to set up, and often bypasses corporate spam filters.

Security-themed domains. Threat actors pad domain names with words like secure, ssl, portal, server to make them look operational: relay-secure-smtp[.]com, secure-email-gateway[.]cc, mx-secure-email-server[.]cc.

Header spoofing / display-name deception. A meaningful share of BEC emails have a Reply-To that differs from From, and many spoof the target organisation’s own domain in the From field. The display name shows only the human name in most clients — users don’t see the underlying domain at a glance.

Commodity malware seen in BEC

BEC actors rarely write custom malware — they buy or download commodity RATs and keyloggers. Names that come up repeatedly:

Threat actors often don’t bother hiding the file extension — common naming patterns are Purchase Order.rar or Purchase Order.rar.pdf (double-extension lure).

Victimology and attribution

Targeting is opportunistic, not strategic. CFOs, CEOs, and accounts-payable staff are favoured because they have authority to move money — a direct request from the CEO to wire a large sum for a confidential deal rarely gets challenged. Organisation size and sector don’t matter much; small businesses get hit just as often as Fortune 500s.

Attribution is hard. Public reporting consistently places about half of BEC operators in Nigeria, but the broader population spans 50-plus countries and arrests have been made across the US, France, Italy, Japan, Kenya, Malaysia, and the UK. Publicly named actor clusters include Gold Galleon, Gold Skyline, Silver Terrier, Silver Spaniel, London Blue, Scattered Canary, Scarlet Widow, Silent Starling, Exaggerated Lion, Curious Orca, Ancient Tortoise, the Anuanuanuoluwa group, and Cosmic Lynx. Most rely on social engineering; Silver Terrier and Cosmic Lynx are documented combining commodity malware with social engineering for persistence.

Use estimative language in any attribution write-up — realistic probability, probable, highly probable, almost certain — and treat geography as one signal among many (capabilities, infrastructure, victims).

Don’t forget the malicious insider. Industry fraud surveys routinely find a meaningful share of corporate fraud is committed by internal actors, with a further chunk attributable to insider/outsider collusion. The same UAL artefacts you used for external compromise — suspicious IPs, brute-force markers, phishing observations — help assess insider involvement too.

MITRE mapping

• T1566 — Phishing; .001 Spearphishing Attachment, .002 Spearphishing Link.
• T1078.001–004 — Valid Accounts.
• T1199 — Trusted Relationship.
• T1190 — Exploit Public-Facing Application.

Step 10: Recommendations

The defensive list is short, blunt, and high-leverage. None of these are exotic; most BEC victims simply hadn’t enabled them yet.

Enable MFA — especially on admin accounts

Microsoft’s minimum-MFA list (apply broader if you can):

• Billing administrator, Conditional Access administrator, Exchange administrator, Global administrator, Helpdesk (Password) administrator, Password administrator, Security administrator, SharePoint administrator, User administrator.

Ensure mailbox audit logging is enabled for all accounts

The UAL has to be turned on in the Security & Compliance Center before queries can run against it. If it’s off, you have no centralised event source and your investigation is over before it starts.

Enforce a strong password policy

NIST’s current guidance:

• Minimum 8 characters, maximum at least 64.
• Allow all special characters but don’t require any specific class.
• Reject sequential / repetitive patterns (12345, aaaaaa).
• Reject context-specific values (the site name, etc.).
• Reject common passwords and dictionary words.
• Reject passwords from previous-breach corpuses (e.g. HIBP integration).

Forward Office 365 logging to a centralised location

Centralise into Splunk, Elastic, Sentinel — whatever you have. Improves retention beyond Microsoft’s 90/365-day windows and lets you correlate Office 365 events with endpoint, network, and identity telemetry.

Perform regular checks on (active) forwarding rules

Automate this. Run a script weekly that lists every active forwarding rule across every mailbox, with destination domains classified as internal vs external. New external destinations are the alert.

Block mail forwarding to external domains

Most organisations don’t need user-level external forwarding at all. Disable it via Exchange Online’s outbound spam policy — the single most effective per-feature kill switch against the dominant BEC TTP.

Disable legacy protocol authentication when appropriate

POP3, IMAP, SMTP basic-auth all bypass MFA by design. Block them via a Conditional Access policy. If older clients genuinely require basic auth, scope the exception to the specific accounts that need it — not the whole tenant.

Security awareness training

Phishing — especially spearphishing — is hard to stop technically. Recurring training that teaches users to spot pretexting, hover URLs, question unusual payment changes, and report suspicious emails closes the gap that filters can’t.

Quick-reference cheat sheet

Conclusion

BEC isn’t exotic. It’s a cheap, scalable, social-engineering scam built on top of legitimate email features — forwarding rules, OAuth consent, eDiscovery — and it’s the most likely email intrusion you’ll investigate this year. The 10-step framework above gives you a defensible, repeatable structure: scope the investigation, get the logs, follow the forwarding rules to the threat actor, characterise the data exposure, close the loop with threat intelligence, and harden the environment so it doesn’t happen again.

The two highest-leverage configuration changes are the same two changes you should make today regardless of whether you’re mid-incident: enable MFA on every admin role and block external mail forwarding at the organisation level. Everything else — UAL retention, password policy, awareness training — matters, but those two close most of the front door.