BEC
Business Email Compromise (BEC): The Four Variants and Why a Password Reset Isn't Enough
BEC is a business-logic attack, not a malware attack. The adversary doesn't drop a payload your EDR can catch; they log in with valid credentials and abuse the same mail features your employees use every day. That's why business email compromise investigation is hard, why BEC slips past controls tuned to find malicious binaries, and why the reflexive fix, reset the password, almost never ends the intrusion. The session, the inbox rules, the OAuth grants, and the attacker's MFA method all outlive the credential you just changed.
This guide breaks down the four canonical BEC variants (plus the payroll sibling), how to investigate each, and the eviction checklist that actually removes the attacker. BEC is one of the most common follow-on objectives of an identity compromise, so it sits squarely inside the broader practice of investigating identity-based attacks.
The four BEC variants
BEC is a family, not a single technique. The variants share an entry point, a compromised or impersonated identity, but diverge in what the attacker does with the mailbox. Knowing which variant you're looking at tells you where to hunt and who to notify.
1. Classic mailbox compromise. The attacker gains access to a single mailbox and reads quietly. The goal is reconnaissance: learn the org chart, the tone of internal email, the cadence of vendor invoices, and which approvals route through whom. This is the patient variant. It often runs for weeks before any fraudulent action, and the only early signals are sign-in anomalies and the hidden rules the attacker sets up to stay quiet (MITRE T1114, email collection).
2. Invoice / payment fraud. The monetization step. The attacker either injects a malicious attachment with altered banking details, or, more dangerously, performs thread replacement: hijacking a real, in-progress invoice conversation with a vendor and replying from the legitimate mailbox with new wire instructions. Because the email comes from a trusted internal account inside a thread the recipient already trusts, it sails past both technical controls and human suspicion. This is where the money actually leaves.
3. OAuth-scaled BEC (consent-grant abuse). Instead of (or alongside) stealing the password, the attacker tricks the user into granting consent to a malicious OAuth application, or registers one themselves. The app gets a refresh token with mailbox scopes and reads or sends mail through the API, with no interactive sign-in required. This is the variant that survives a password reset cleanly, because the grant is an independent credential. It also scales: one consent-abuse pattern can be replayed across many tenants (MITRE T1098, account manipulation).
4. Internal phishing follow-on. Once inside, the attacker uses the compromised mailbox to phish laterally, sending payment requests, credential-harvesting links, or consent prompts to colleagues, partners, and customers who trust the sender. This is how one compromised account becomes ten, and how BEC jumps organizational boundaries into your supply chain.
The payroll-diversion sibling. A close cousin of invoice fraud: instead of redirecting a vendor payment, the attacker emails HR or payroll posing as an employee and requests a change to direct-deposit details before the next pay run. Same business-logic abuse, different beneficiary. Treat it as a BEC variant with a finance/HR notification path.
How to investigate BEC
The most common entry point into all of these is an adversary-in-the-middle phishing kit that steals a live session token and bypasses MFA, so a BEC investigation often starts where AiTM phishing detection leaves off. Wherever it starts, work the evidence in tiers: Observed (directly seen in logs), Correlated (multiple sources agree), Assessed (analyst judgment), and state your confidence on each conclusion.
Scope a rolling ~7-day window
Don't anchor to the single alerting sign-in. BEC unfolds over days, and the reconnaissance phase predates the fraud. Pull all authentication and mailbox activity for the account over a rolling seven-day window, wider if the first anomaly is old. You're reconstructing a timeline, not confirming one event.
Correlate multi-IP / multi-geo sign-ins
Pivot on the sign-in logs and look for the same account authenticating from multiple IPs, ASNs, or geographies in a window too tight for physical travel. A valid session appearing from a new ASN without a corresponding fresh interactive authentication is a strong token-theft signal, the hallmark of a session relayed through a phishing proxy. Label each suspect sign-in Observed; the impossible-travel conclusion is Correlated.
Hunt hidden inbox and forwarding rules
This is the highest-value step and the one most often skipped. Attackers create inbox rules that auto-forward mail to an external address, or that move messages containing words like "invoice," "payment," "wire," or their own display name straight to Deleted Items or an obscure folder, so the victim never sees the replies to the fraud. Enumerate every rule on the mailbox, including hidden and client-side rules, and treat any external-forwarding or auto-delete rule as Observed evidence of compromise (MITRE T1564.008, hidden rules).
Review OAuth grants and consents
List every OAuth application with a grant on the account and on the tenant. Look for recently consented apps, apps with broad mailbox scopes (Mail.Read, Mail.Send), unverified publishers, and grants that don't match anything the user would knowingly install. A malicious grant is the persistence mechanism a password reset will miss entirely.
Pull the mailbox audit logs
Mailbox audit logging records mail-item access, sends, rule creation, and folder moves. Use it to confirm what the attacker actually read and sent, not just that they were present. This is what separates an Assessed "probably exfiltrated the invoice thread" from an Observed "accessed these specific items."
| Hunt step | Primary signal | Evidence tier | MITRE |
|---|---|---|---|
| 7-day sign-in scope | Multi-IP / multi-geo auth | Correlated | - |
| Token-theft check | Session without fresh interactive auth | Correlated | - |
| Inbox / forwarding rules | External forward, auto-delete on keywords | Observed | T1564.008 |
| OAuth grants | Broad mailbox scopes, new consent | Observed | T1098 |
| Mailbox audit logs | Mail-item access, sends | Observed | T1114 |
Why a password reset isn't enough
Resetting the password invalidates one thing: the ability to perform a fresh interactive sign-in with the old credential. It does nothing to the persistence the attacker has already established. Three mechanisms routinely survive a reset:
- Active sessions and refresh tokens. The attacker is holding a live session cookie or refresh token obtained at compromise time. Until you explicitly revoke it, that token keeps minting access to the mailbox regardless of the new password.
- Inbox and forwarding rules. A reset doesn't touch mailbox configuration. The auto-forward rule keeps shipping mail to the attacker, and the auto-delete rule keeps hiding the evidence, long after the credential changes.
- OAuth grants and attacker-registered MFA. A consented app holds its own refresh token, independent of the password. And if the attacker registered their own MFA method, an authenticator app, a phone number, during the dwell, the new password plus their MFA gets them right back in, now as a "compliant" sign-in.
A password reset on its own is the security equivalent of changing the front-door lock while the attacker still has a copy of the key, a window propped open, and the mail forwarded to their address.
The full eviction checklist
Eviction is an ordered operation. Revoke access first so the attacker can't react while you clean up, then remove persistence, then close the door with a credential reset. Skipping or reordering steps leaves a gap.
- Revoke all sessions and refresh tokens. This is step one, not the password. Kill every active session and invalidate refresh tokens so stolen tokens stop working immediately.
- Remove malicious inbox and forwarding rules. Delete every external-forwarding, auto-delete, and keyword-hiding rule you found. Document them first, they're evidence, and they tell you what the attacker was hiding.
- Revoke OAuth grants. Remove every suspicious app consent on the user and review tenant-level grants. This closes the API-based persistence a password reset can't touch.
- Audit registered MFA methods. Enumerate every MFA method on the account and remove any the user doesn't recognize. An attacker-registered method turns your reset into their re-entry.
- Then reset the password and require re-registration of MFA through a trusted channel.
- Notify finance, AP, and HR on the money variants. For invoice/payment fraud, alert accounts payable and the affected vendor so pending wires can be held or recalled, recovery is time-critical and measured in hours. For payroll diversion, notify payroll before the next run to reverse the direct-deposit change.
Run these as a sequence, confirm each step, and only then consider the account clean. A partial eviction is often worse than none: it tells the attacker you're watching while leaving them a way back in.
Takeaway
BEC defeats malware-centric defenses because it abuses business logic with valid credentials, and it defeats the reflexive password reset because persistence lives in tokens, rules, grants, and MFA, not the credential. A correct response is an ordered eviction that revokes access before it resets it, paired with a money-trail notification the moment fraud is in play. The hard part isn't knowing these steps; it's holding the judgment about which variant you're facing, what's normal for this account, and when to act, exactly the human intelligence Cade captures and applies, embedded in the ServiceNow and security tooling your team already runs.