Business Email Compromise (BEC) is the costliest cybercrime category tracked by the FBI — not because of spectacular technical exploits, but because it weaponizes trust, process, and human judgment. The FBI's IC3 reported over $2.9 billion in BEC losses in 2023 alone, and the actual number is significantly higher because most incidents go unreported. For professional services firms, law offices, and financial companies in NYC, BEC is not a theoretical risk — it is a routine threat.
This guide walks through the investigation and recovery process for a BEC incident, with a focus on Microsoft 365 environments, which represent the majority of enterprise deployments.
In 2024, the FBI's IC3 received 21,442 business email compromise complaints totaling $2.77 billion in reported losses — an average near $129,000 per reported incident — making BEC the second-costliest cybercrime category that year (FBI IC3 2024 Internet Crime Report). IC3 and FinCEN identify recurring BEC variants including vendor-invoice fraud, real estate and wire-transfer fraud, payroll redirection, and W-2/data requests — each exploiting trusted email workflows to redirect funds.
How BEC Is Typically Discovered
Unlike ransomware, which announces itself dramatically, BEC is designed to remain invisible for as long as possible. Discovery usually happens through one of four vectors:
- Wire transfer failure or bank alert: A transferred payment does not arrive at the expected vendor account. The bank or receiving institution flags the transaction.
- Vendor complaint: A vendor calls asking why their invoice has not been paid — while your records show it was paid weeks ago to an account you believe to be theirs.
- Employee suspicion: A finance employee notices something off about an email — subtle domain difference, unusual urgency, uncharacteristic tone from a known executive.
- Security tool alert: An EDR or SIEM rule fires on a new OAuth application grant or an anomalous login from an unusual IP or geography.
Immediate Response: Do Not Log Out the Attacker
This is the counterintuitive first rule of BEC response: do not immediately force-sign-out the compromised account. The attacker has likely created persistence mechanisms — inbox rules that forward copies of emails to an external address, hide replies from the victim, or delete emails matching certain subjects. If you terminate the attacker's session without first documenting these rules, you lose critical forensic evidence about what the attacker was doing and for how long.
Instead, the first action should be read-only documentation: screenshot all inbox rules, all forwarding settings, all OAuth application grants, and all recent sign-in locations from the Microsoft 365 admin portal and Entra ID (formerly Azure AD). Only after this documentation is complete should you revoke active sessions and change credentials.
Microsoft 365 Investigation Workflow
Unified Audit Log
The Microsoft 365 Unified Audit Log (UAL) is your primary evidence source. Access it through the Microsoft Purview compliance portal or via PowerShell using Search-UnifiedAuditLog. The UAL captures: mailbox access events (including access by other users or applications), email rule creation and modification, file access in SharePoint and OneDrive, OAuth application consent grants, and admin activity.
Start by querying the compromised account's activity for the 90 days prior to discovery. Look for: logins from unusual countries or IP ranges, new inbox rules created (especially those with ForwardTo, RedirectTo, Delete, or MarkAsRead actions), and any mail delegation grants.
Message Trace
Microsoft 365 Message Trace (under Exchange admin center) shows you every email sent and received by an account, including emails that were deleted. Run a message trace covering the suspected compromise window. Look for: emails sent from the account that the user did not write, emails received and immediately deleted (indicating attacker inbox rules at work), and communication patterns with external domains that are typosquats of your vendors.
OAuth Application Review in Entra ID
A common persistence mechanism in BEC is the attacker granting consent to a malicious OAuth application that has access to the victim's mailbox. This survives password resets and MFA changes. Review all OAuth app consents in Entra ID under Enterprise Applications. Look for recently consented applications, applications with Mail.Read, Mail.ReadWrite, or Mail.Send permissions granted by the compromised user, and applications from unknown publishers.
Account Takeover vs. Email Spoofing
Not all BEC involves actual account compromise. Some BEC uses domain spoofing (sending from a domain that looks like yours but is not) or display name spoofing (changing the visible From name without changing the actual email address). These are important to distinguish because the remediation path differs significantly. A true account takeover requires incident response, credential reset, session revocation, and audit log review. A spoofing attack requires DMARC/DKIM/SPF hardening and user awareness.
Wire Recall and Financial Recovery
If a fraudulent wire transfer has occurred, time is the critical variable. Contact your bank immediately and ask for a wire recall under the SWIFT gpi protocol. The probability of recovery drops sharply after 24 hours as funds are moved through intermediary accounts. Simultaneously, file a complaint with the FBI IC3 and request a Financial Fraud Kill Chain (FFKC) referral — IC3 has relationships with financial institutions and can sometimes freeze funds in transit if the complaint is filed within hours of the transfer.
Recovery and Hardening Steps
After evidence preservation, the recovery sequence is: revoke all active sessions for the compromised account, reset password and re-enroll MFA (using phishing-resistant FIDO2 if possible), remove all malicious inbox rules and forwarding addresses, revoke unauthorized OAuth application consents, review all mailbox delegates, and audit any emails sent from the account during the compromise window for downstream victims (vendors, clients, employees who may have received fraudulent instructions).
Post-incident hardening should include reviewing your Microsoft Secure Score improvements: enforcing MFA across all accounts, enabling DMARC with a reject policy, configuring alerts for new inbox rules, and implementing Conditional Access policies that block authentication from unexpected geographies. A post-incident review with your security team should address the process failures that allowed the BEC to succeed — typically, a wire transfer process that lacked a phone-based confirmation step.