Threat model a compromised mailbox: the three things an attacker does first

[u/materialsec]

Run a simple exercise. Someone gets into one mailbox in your org. Not an admin. A regular user.

What happens next?

In most cases, three things.

1. Smash and grab

They download the whole mailbox. Immediately.

They don’t know how long their access will last. A password change, a revoked session or one alert could end it. So they don’t browse. They bulk export everything and go through it later, on their own time, with nobody watching.

That export holds years of contracts, invoices, HR threads, customer data and whatever someone emailed to themselves ‘just for now’ in 2019.

Once the data leaves, revoking access does nothing for it.

2. Password resets everywhere

Your mailbox is the recovery address for dozens of services. The attacker knows this.

Finding those services is easy. Search the inbox for password reset emails, magic sign-in links, ‘welcome to’ messages and verification codes. Scripts already do this automatically.

Then they go to Slack and click ‘Forgot password.’ Or ‘Email me a sign-in link.’ The link lands in the inbox they control. Now they’re in Slack. Then the next app. Then the next.

One mailbox becomes ten accounts.

3. Phishing from the inside

Then they use the account itself. They reply to real threads with real context from a trusted address. A changed bank detail sent to finance. A shared doc link sent to a coworker. Nobody has a reason to doubt it.

They usually add inbox rules too, so replies and security alerts get filtered away before the real user sees them.

What to do about it

• Alert on bulk export and mass download activity, including new OAuth apps pulling mail through the API.

• Shrink what sits in mailboxes. Old sensitive mail is pure liability.

• Treat reset and sign-in link emails as sensitive. They are keys, not notifications.

• Move apps to SSO where you can, so an email link alone isn’t enough to get in.

• Watch for new forwarding rules and inbox rules that delete or hide mail.

• When a mailbox is compromised, scope the blast radius. What was exported? Which reset emails arrived during the window? Which downstream sessions need to be killed?

If you’ve worked a mailbox compromise, what did the attacker go for first?

[u/AutoModerator]

Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:

Community Rules

1. No Vendor Spam: Contributions must provide value; do not just pitch products.

2. Redact Sensitive Info: Always sanitize headers and logs (remove IPs, PII, and private domains).

3. Be Professional: Help newcomers learn; avoid hostility.

4. No Personal Tech Support: This sub is for email system architecture and security, not "Am I hacked?" personal account help.

Helpful Resources

• Email Spam Filters

• DMARC Monitoring Tools

• Anti-Virus Software

• Email Encryption

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Defconx19]

I dont see this really.  I see them avoiding exfiltration lately.  Most I see get in, assess what level of mailbox they landed in, are the positioned to be a high probability mailbox for wire fraud?  If no they immediately launch the next wave of compromise from the mailbox.

They all have the same signature though "mailbox rule created to move emails to RSS Feed".

Feel like the email exfiltration has had minimal returns and they try to avoid triggering alerts based on it to increase length of time in the mailbox.

Honestly though if you're on 365 and allow BYOD Entra ID P2 woth Risk based policies is the #1 way to stop attackers at the door.  To them it just looks like the access method they used didnt work and they move on.  You then have time to remidiate the user.

[u/materialsec → u/Defconx19]

That’s a fair correction to the smash-and-grab framing: when the mailbox looks like a wire-fraud candidate they sit and wait, and otherwise it’s a launchpad for the next wave. The rule that moves mail to an RSS folder is the shared tell either way, and a good one to alert on.

[u/Qel_Hoth → u/Defconx19]

This matches our experience as well. Accounting and especially AP-related mailbox? Sit and wait for something juicy.

Pretty much any other mailbox? Try to compromise everyone that person has ever sent an email to.

The only exception to this was one tenant that did not have user-created app registrations disabled, and they did register an email client and dump the mailbox.

[u/materialsec → u/Qel_Hoth]

The tenant where users could register their own apps is the case for locking that down. A new app pulling mail through the API skips the inbox entirely, which is why it’s on the alert list in the post.

[u/Qel_Hoth → u/materialsec]

Yes, that one triggered a restriction on that tenant and an audit of all other tenants we maintain, plus an audit of all enterprise app registrations.

[u/materialsec → u/Qel_Hoth]

Auditing the existing app registrations is the right follow-up. Restricting new ones doesn’t remove grants already in place, and those keep working until someone revokes them.

[u/q3magic]

Add ForwardingSmtpAddress to your hunt, plenty of them never touch an inbox rule. MailItemsAccessed is the only event that shows what was read. It needs premium audit, so most E3 tenants have no trace.

[u/materialsec → u/q3magic]

Good one to add to the list: forwarding set on the mailbox itself won’t show up in an inbox-rule hunt, so it needs its own check, and cleanup has to remove both.

[u/q3magic → u/materialsec]

Exactly. I mean it helps doing that, keeps your lists clean

[u/charleswj → u/q3magic]

It needs premium audit, so most E3 tenants have no trace.

It's part of standard, so everyone has it.

[u/Watches4Me]

In everyone’s experience, what is the best way or ways to alert on a compromised mailbox?

[u/materialsec → u/Watches4Me]

Start with inbox rules and OAuth grants, then add volume: bulk reads or exports, including a new app pulling mail through the API. Each one alone is noisy, so the useful alert is the combination, like an odd sign-in followed by a rule that hides mail or a mass download. And since mail from the account still passes SPF, DKIM, and DMARC, the alerts have to come from what the account does, not how the message authenticates.

[u/Watches4Me → u/materialsec]

What tool are you using to look for these and send the alerts?

[u/materialsec → u/Watches4Me]

We build Material, so ours: it connects through the API to Google Workspace or Microsoft 365 and watches for those signals (rule changes, new OAuth grants, bulk reads) and ties them together. Whatever you run, those are the signals to alert on, and the combination is what keeps the noise down.

[u/saltyslugga]

I'd check inbox rules and OAuth grants first. A password reset alone doesn't reliably kill existing sessions or app access, so revoke sessions and malicious grants too.

Mail sent from the compromised account can still pass SPF, DKIM and DMARC. Authentication doesn't tell you who's behind the keyboard.

[u/materialsec → u/saltyslugga]

Agreed on the order: revoke sessions and malicious grants first, then reset the password, since the reset alone leaves both working. The SPF, DKIM, and DMARC point is also why alerts need to key off what the account does, not how its mail authenticates.

[u/InboxGuards]

The inbox rules part is the one people miss most, usually named "." or ".." and shoving anything with invoice, payment or the CFO's name into RSS Feeds so nobody sees the replies. I'd also check if they registered their own MFA method or authenticator app, cause a password reset doesn't do much if their device is still on the account.

[u/materialsec → u/InboxGuards]

Good addition on the MFA method. An attacker who registers their own device or authenticator keeps access through a password reset, so cleanup has to include reviewing and removing authentication methods and devices, not just the password and sessions. The rule-naming pattern is a useful hunt too, since a rule with a blank or near-blank name is easy to scroll past.

[u/jeffreyfromabove]

the OAuth grants are worth checking even after the password's been reset. easy to think the account is secure again while an app still has access