Mailbox security: finding what an attacker leaves behind

When an attacker gets into a mailbox, resetting the password does not necessarily end the problem. Attackers who know what they are doing leave something behind: a rule, a forwarding address, a delegate, an app with permission to read mail. These are persistence mechanisms, and they are the reason a “fixed” account can be leaking mail a month later. This guide lists the places to look, shows how to look read-only, and explains how to clean up without destroying evidence.

Where attackers leave a foothold

Mechanism	What it does	Survives a password reset?	Where it lives
Inbox rule	Forwards, redirects, deletes, or hides messages	Yes	The mailbox
Mailbox forwarding	Sends a copy of every message to another address	Yes	The mailbox object
Delegate or full-access permission	Lets another account open the mailbox	Yes	The mailbox permissions
Send-as or send-on-behalf permission	Lets another account send as this user	Yes	The mailbox permissions
Consented application	An app granted permission to read mail, with its own token	Often yes	The tenant’s application list
Mail flow (transport) rule	Alters or copies mail tenant-wide	Yes	Tenant mail flow settings
Legacy protocol enabled	Allows sign-in that bypasses MFA	Yes	Per-mailbox protocol settings
An extra sign-in method	The attacker registered their own MFA device	Yes	The user’s security info

The last row catches people out. If an attacker registers their own authenticator on the account, the next time you reset the password they simply sign in again. After any suspected compromise, review the user’s registered authentication methods.

Read-only inspection

Run these from an Exchange Online PowerShell session after Connect-ExchangeOnline. Every command below only reads.

Inbox rules

Get-InboxRule -Mailbox user@example.com |
  Select-Object Name,Enabled,Priority,ForwardTo,ForwardAsAttachmentTo,RedirectTo,DeleteMessage,MoveToFolder,SubjectContainsWords

What deserves suspicion: any rule that forwards or redirects outside the organisation, any rule that deletes mail, a rule with a blank or one-character name, and a rule that moves messages to a folder like RSS Feeds, Archive or Conversation History. A rule that matches words like “invoice”, “payment” or “bank” is worth an immediate look. Rules can also be hidden from the normal view by editing the mailbox directly, so a clean list is reassuring but not conclusive.

Forwarding at the mailbox level

Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } |
  Select-Object DisplayName,PrimarySmtpAddress,ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

ForwardingSmtpAddress can name an outside address directly. DeliverToMailboxAndForward set to true means the user still receives the mail, so nothing appears broken to them. That is exactly why forwarding is attractive to attackers.

Delegates and permissions

# Full access to the mailbox, excluding inherited entries
Get-MailboxPermission -Identity user@example.com |
  Where-Object { $_.AccessRights -like "*FullAccess*" -and -not $_.IsInherited } |
  Select-Object User,AccessRights

# Send-as permissions
Get-RecipientPermission -Identity user@example.com | Select-Object Trustee,AccessRights

Every name that appears is a question: why does this account have access, and who approved it?

Permissions can also be granted on a single folder, which is easy to miss because the mailbox-level lists above will not show it. A folder grant on the Inbox is enough to read everything that arrives:

Get-MailboxFolderPermission -Identity "user@example.com:\Inbox" | Select-Object User,AccessRights

Expect to see the default entries and any deliberate delegates. An unfamiliar user, or the “Default” entry holding rights beyond what you expect, is worth explaining.

Protocols per mailbox

Get-CASMailbox -ResultSize Unlimited |
  Where-Object { $_.ImapEnabled -or $_.PopEnabled } |
  Select-Object DisplayName,ImapEnabled,PopEnabled

Anyone with IMAP or POP enabled who does not need it is a user whose password can be used without an MFA prompt, unless legacy sign-in is blocked tenant-wide. Blocking it tenant-wide is the real fix; per-mailbox changes are belt and braces.

Mail flow rules

Get-TransportRule | Select-Object Name,State,Priority,WhenChanged,Comments

Sort by WhenChanged. A rule that blind-copies mail to an external address, or that rewrites a message, which nobody can account for, is a serious finding because it affects every mailbox.

What changed, and when

The audit log is where you find out when a rule or permission appeared. Searching for the relevant operations over a recent window:

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
  -Operations New-InboxRule,Set-InboxRule,Set-Mailbox,Add-MailboxPermission `
  -ResultSize 500

Results depend on what your licence retains and on audit being enabled. If the search returns nothing for a window you expected to cover, find out whether that is “nothing happened” or “nothing recorded”; they mean very different things.

Reading the output: a hypothetical walk-through

Suppose the finance lead’s mailbox is the one you are worried about, and the rule listing returns this (invented for illustration):

Name   Enabled ForwardTo                     DeleteMessage MoveToFolder
----   ------- --------                      ------------- ------------
.      True    {SMTP:archive-sync@mail-box.example}  False
Old    True                                   True

Read each row as a question. The first rule has a name consisting of a single full stop, which nobody types by accident, and it forwards to an outside address on a domain the business has no relationship with. That is a finding on its own. The second rule is called “Old” and deletes messages. Its conditions are not shown in this view, so you would inspect them next. The point of the exercise is to match each rule to a person and a reason; a rule nobody can explain is treated as hostile until proven otherwise.

Then ask when the first rule appeared. The audit search above, filtered to the user and to rule-creation operations, tells you the time and the sign-in session that made it. Compare that time with the user’s sign-in history. If the rule was created from an address the user never uses, you have a date for the compromise, and everything the account sent or received since that date needs reviewing. If nothing in the log explains the rule, say so in your notes rather than guessing.

Consented applications and sign-in methods

Application consent is the hardest persistence to see, because it lives in the identity service rather than in the mailbox. Review, in the Entra enterprise applications area, which applications hold mail-read or full-mailbox permissions and who consented. Remove any you cannot explain. Then restrict future consent, so the list stops growing without anyone noticing.

For the account itself, look at the registered authentication methods and remove any device or number the user does not recognise. Then confirm the sign-in logs for that user show no activity from places or devices they do not use.

Cleaning up without destroying evidence

The order matters.

1. Record first. Export or screenshot the rules, forwarding, permissions, applications and methods you found, with timestamps.
2. Contain. Block sign-in or reset the password and revoke sessions, as described in business email compromise.
3. Remove the foothold. Delete the malicious rules and forwarding, remove unexplained permissions, revoke the consented application, remove the unfamiliar authentication method.
4. Verify from outside. Send a test message and confirm it is not copied anywhere. Re-run the read-only commands and confirm the lists are as expected.
5. Widen the search. If one mailbox was compromised, assume the attacker also looked for the next one. Review other mailboxes that received mail from it or that share a permission relationship.

Cleaning up is not finished until the cause is addressed. If the user was phished, the next phish will do the same thing, and the controls in conditional access are how you make the repeat less likely to succeed.

Hardening so it is harder next time

• Block automatic external forwarding at the organisation level, and list the exceptions with owners.
• Alert on new forwarding and delete rules. An alert at creation time turns a month-long leak into a same-day event.
• Disable protocols nobody uses, and block legacy sign-in tenant-wide.
• Restrict who can add permissions to a mailbox, and review shared-mailbox access on a schedule.
• Block interactive sign-in for shared mailboxes. They should be opened through delegated access, not through a password somebody holds.
• Restrict user consent to applications and route requests through an administrator.
• Keep auditing on, and practise searching it. The first time you use the audit log should not be during an incident.

How this fails

• **A clean Get-InboxRule is taken as proof.** It is not; rules can be hidden. Combine it with the audit log and the forwarding check.
• Only the compromised mailbox is examined. The attacker may have moved to others.
• The audit log has nothing in it. Either auditing was never searched or the retention is shorter than the window you need. Find out before an incident.
• Persistence removed, cause ignored. The same phishing message arrives again.
• Over-cleaning. Deleting everything unusual, including legitimate forwarding that a business process depends on, creates a second outage.
• No record of what was done. Without a log you cannot tell an insurer, a customer or a regulator what you did and when.

What to do next

Run the forwarding and transport-rule checks this week; they take minutes and often surface something. Then use the email security readiness assessment to see which of the mailbox controls you can say are in place. If you are building a response procedure, business email compromise has the first-hour runbook that these checks fit into.