Lesson 47 — A New Inbox Rule Appeared
The password had been changed.
The suspicious sign-in had been investigated.
It would have been tempting to call the incident contained.
Then the mailbox audit evidence showed something else.
A new inbox rule had been created shortly after the suspicious access.
Agent Foskett now had another question:
Was the rule normal mailbox housekeeping — or evidence that somebody had manipulated the mailbox after gaining access?
The account changed after access
Correlate the rule creation with the identity timeline, inspect its parameters and determine whether messages were being hidden, moved or deleted.
Case briefing
Investigation objective
Use mailbox audit telemetry to identify newly created inbox rules, inspect their parameters and correlate suspicious mailbox changes with the account-compromise timeline.
Investigator's rule
A mailbox rule is not malicious simply because it exists. Timing, conditions, actions and surrounding identity evidence determine whether it belongs in the incident.
Stage 1 — search for inbox rule creation
CloudAppEvents
| where Timestamp > ago(7d)
| where AccountId =~ "alex@contoso.com"
| where ActionType in ("New-InboxRule", "Set-InboxRule")
| project Timestamp,
AccountId,
ActionType,
IPAddress,
UserAgent,
RawEventData
| order by Timestamp asc
Start with creation and modification
A malicious rule may be created once and modified afterwards. Search for both new-rule and rule-change activity around the compromise window.
Preserve RawEventData
The audit event can contain the details needed to understand the rule. Keep the raw event available before narrowing the investigation to individual parameters.
Stage 2 — inspect the rule parameters
CloudAppEvents
| where Timestamp > ago(7d)
| where AccountId =~ "alex@contoso.com"
| where ActionType in ("New-InboxRule", "Set-InboxRule")
| extend RuleData = tostring(RawEventData)
| project Timestamp,
ActionType,
IPAddress,
UserAgent,
RuleData
| order by Timestamp asc
What is the rule looking for?
Inspect conditions such as sender, subject keywords or other matching criteria. Rules targeting security notifications, payment messages or replies can be especially important in a compromise investigation.
What does the rule do?
Look for actions that move, delete, mark as read or otherwise reduce the chance that the user will notice selected messages.
Stage 3 — think like the attacker
| Rule behaviour | Why the SOC should care |
|---|---|
| Move messages to another folder | Important replies or warnings may disappear from the user's normal inbox view. |
| Delete matching messages | Evidence of fraud, security alerts or correspondence may be suppressed. |
| Mark messages as read | The user may be less likely to notice new activity. |
| Target finance-related keywords | The rule may support business email compromise or payment fraud. |
| Target security notifications | The rule may be intended to conceal account-security activity. |
The rule name may be boring on purpose
Names such as “RSS Feeds”, “Archive” or “Notifications” can blend into a mailbox. Judge the rule by its behaviour and timing, not by whether the name sounds suspicious.
Normal rules exist too
Users legitimately create inbox rules every day. A defensible finding explains why this specific rule is connected — or not connected — to the incident.
Stage 4 — correlate the rule with the sign-in timeline
Timing alone is not enough
A rule created five minutes after suspicious access is significant, but strengthen the finding with additional correlation such as IP address, user agent and the rule's actual behaviour.
Sequence builds the story
Phishing, credential entry, successful authentication and mailbox manipulation form a much stronger incident narrative when the timestamps align.
Stage 5 — compare mailbox activity from the suspicious IP
let SuspiciousIP = "203.0.113.77";
CloudAppEvents
| where Timestamp > ago(1d)
| where AccountId =~ "alex@contoso.com"
| where IPAddress == SuspiciousIP
| project Timestamp,
ActionType,
Application,
IPAddress,
UserAgent,
RawEventData
| order by Timestamp asc
Do not investigate the rule in isolation
The same session may have performed other mailbox or cloud actions. Review nearby activity to understand whether the rule was one step in a larger sequence.
Look for attacker objectives
Mailbox manipulation may support persistence, concealment, fraud or monitoring of a business conversation. The rule itself can reveal what the attacker cared about.
Stage 6 — scope rule changes across the account
CloudAppEvents
| where Timestamp > ago(30d)
| where AccountId =~ "alex@contoso.com"
| where ActionType has "InboxRule"
| project Timestamp,
ActionType,
IPAddress,
UserAgent,
RawEventData
| order by Timestamp asc
Establish whether the rule is new
Historical rule activity can help distinguish a long-standing user configuration from a change that appeared only after the suspected compromise.
Look for multiple rule operations
An attacker may create, test, modify and later remove a rule. The audit history may preserve those changes even when the rule is no longer visible in the mailbox.
Stage 7 — distinguish persistence from concealment
Use precise language
If the evidence shows a rule moving messages, say that. Do not call it “persistence” automatically unless the rule's function and the wider incident support that interpretation.
Containment must include mailbox state
Identity remediation should be accompanied by review of malicious or unauthorised mailbox configuration so the account is not left with attacker-created changes.
Stage 8 — build the evidence chain
Stage 9 — write the investigation finding
Lesson 47 key takeaways
- Inbox rules are normal features that can also be abused after account compromise.
- Search for both rule creation and modification events.
- Preserve the raw audit data so rule parameters can be reviewed.
- Investigate what the rule matches and what action it performs.
- A harmless-looking rule name does not make the behaviour harmless.
- Correlate rule creation with suspicious authentication and other mailbox activity.
- IP address, user agent and timing can strengthen attribution.
- Historical rule activity helps establish whether the change is genuinely new.
- Do not use labels such as persistence or concealment unless the evidence supports them.
- Containment should include removal or remediation of unauthorised mailbox changes.
Module 5 — Email & Phishing: From Message to Compromise
Lesson 47 investigated a new inbox rule after suspicious account access. Lesson 48 looks at another mailbox configuration that can quietly expose future messages: external forwarding.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 5: Email & Phishing: From Message to Compromise
Investigate suspicious inbox rules in Microsoft Defender XDR
Lesson 47 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate newly created or modified inbox rules using Microsoft Defender XDR Advanced Hunting and mailbox audit evidence.
Detect post-compromise mailbox manipulation with KQL
Use CloudAppEvents to identify New-InboxRule and Set-InboxRule activity, inspect raw rule parameters, correlate mailbox changes with suspicious sign-ins and determine whether a rule represents legitimate configuration or unauthorised post-compromise activity.
