Business Email Compromise Incident Response
Prevvi Team
Client
A Massachusetts property management company
Industry
Real Estate & Property Management
What was delivered
- Incident containment
- Session and credential revocation
- Malicious inbox-rule removal
- OAuth application review
- Privilege reduction
- Post-incident hardening
Business email compromise does not announce itself. An attacker who gets into an executive mailbox works quietly: reading, forwarding, and waiting for the right invoice to intercept. When a property management company discovered signs that an executive’s Microsoft 365 mailbox had been compromised, Prevvi ran the response: containment, eviction, investigation, and hardening.
The challenge
An executive mailbox is the most valuable real estate in a small company’s tenant. It holds payment conversations, vendor relationships, and the authority to make requests that people act on without question. The immediate priorities in any mailbox compromise are fixed:
- Cut off the attacker’s access, including sessions that survive a password change
- Find and remove any persistence they left behind
- Understand what happened while they had access
- Close the doors they came through
Speed matters at every step, because an active attacker who notices a response will accelerate toward their goal.
What we delivered
Prevvi executed the full response on the Microsoft 365 tenant:
- Password reset and session revocation for the affected account, invalidating every active token so the attacker’s open sessions died with the password
- Tenant-wide MFA actions, ensuring multi-factor authentication stood between stolen credentials and every account
- Malicious inbox-rule removal. Attackers plant forwarding and deletion rules so victim replies vanish before the user sees them. We found and removed them.
- OAuth application review, checking for rogue app consents that would grant mailbox access independent of the password
- Administrative privilege review, reducing standing admin rights across the tenant
- Account activity investigation, reconstructing what the account did during the compromise window
- Security control recommendations and backup and recovery recommendations, turning the incident into a hardening roadmap
How we approached it
Containment before forensics
The first minutes went to eviction: reset credentials, revoke every session, and verify MFA enforcement. Investigation matters, but not while the attacker still has a live session. Modern cloud attacks survive password changes through open tokens, which is why session revocation, not the password reset, is the step that actually closes the door.
Hunt for persistence, not just presence
Removing the attacker’s access is not enough; the standard BEC playbook plants mechanisms that keep working afterward. Inbox rules that forward mail externally or silently delete security notifications, and OAuth app grants that hold their own access tokens, both survive a password reset. We swept for both and removed what we found.
Fix the class of problem, not the instance
The investigation fed directly into hardening: fewer standing administrative privileges, MFA verified everywhere, monitoring of email rules, and independent backup recommendations so the organization’s data protection no longer depended solely on native retention. The goal was for this attacker’s technique, and the next one’s, to have nowhere to land.
What is business email compromise?
Business email compromise, or BEC, is an attack in which criminals gain control of, or convincingly impersonate, a legitimate business email account and use it for fraud. The typical pattern:
- Entry through phished or stolen credentials, often tested quietly before use
- Reconnaissance: reading mail to learn vendors, payment rhythms, and who requests wire transfers
- Persistence: inbox rules and app grants that keep access and hide activity
- The strike: a fraudulent payment request or intercepted invoice, sent from the real account at a believable moment
BEC needs no malware and often triggers no antivirus alert, which is why identity controls, MFA, session monitoring, restrictive rules on auto-forwarding, and least-privilege administration are the defenses that matter.
The outcome
The compromise was contained, persistence mechanisms were removed, and the Microsoft 365 environment came out measurably harder than before the incident: stronger authentication posture, reduced privileged access, and clear recommendations for backup and ongoing monitoring. The organization also gained something less tangible: a tested playbook and a partner who has run it. The same controls are the backbone of our cybersecurity services, and our small business cybersecurity checklist covers the preventive side in depth.
Key takeaways
- A password reset without session revocation does not evict a cloud attacker.
- Always sweep inbox rules and OAuth grants after a mailbox compromise; that is where persistence hides.
- Use the incident’s momentum to fix the class of weakness, not just the affected account.
- Executive mailboxes deserve the tightest controls in the tenant, because they are the highest-value target in it.
Frequently asked questions
Reset the password AND revoke every active session immediately. In Microsoft 365, open sessions and tokens survive a password change, so the session revocation is the step that actually evicts the attacker. Then verify MFA is enforced before moving on to investigation.
Inbox rules are persistence and cover. Attackers add rules that forward mail to an external address or silently delete replies and security notifications, so the fraud continues working even after the password changes. Sweeping and removing malicious rules is a mandatory step in any mailbox compromise response.
Attackers can trick a user into consenting to a malicious application that receives its own access tokens to the mailbox. That access survives password resets and MFA. Reviewing and revoking suspicious app consents closes a persistence door that many responses miss entirely.
The controls that matter most are MFA on every account, least-privilege administration, restrictions on auto-forwarding, monitoring of new inbox rules and app consents, and user awareness around payment-change requests. BEC uses no malware, so identity controls, not antivirus, are the defense.
Many cyber policies cover BEC-related fraud, but insurers increasingly require documented controls such as MFA and payment-verification procedures, and claims can be denied when the application answers do not match reality. Verifying your controls before an incident protects both your environment and your coverage.
Have a similar project in mind?
Talk to a real engineer about your environment: no sales script, just straight answers on how we would approach it.
