ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett Academy • Lesson 103 • Hunting Playbook Series

Hunting Playbook: Malicious Inbox Rules in Microsoft Defender XDR.

The user said emails were missing.

Customers had replied. Invoices had arrived. Password reset messages had been sent.

But nothing appeared in the inbox.

Agent Foskett knew this was not just an email problem.

It was a post-compromise persistence problem.

Start Lesson 103 Back to Academy
Agent Foskett Academy lesson hunting malicious inbox rules in Microsoft Defender XDR
Lesson overview

Learn how to hunt for malicious inbox rules created after mailbox compromise, including hidden forwarding, deletion rules, suspicious move rules and post-compromise mailbox persistence.

Identify suspicious inbox rule activity
Review forwarding, deletion and move rules
Correlate mailbox changes with identity activity
Build a post-compromise investigation timeline

Why malicious inbox rules matter

Malicious inbox rules are often created after account compromise. They allow attackers to hide evidence, forward messages, delete alerts and monitor business conversations without needing to remain actively signed in.
They hide evidenceAttackers create rules that delete, move or archive messages so the user does not see password resets, warnings, invoices or replies.
They support business email compromiseMailbox rules can forward invoices, supplier replies and executive conversations to attackers or hide them from the real user.
They create quiet persistenceEven after the initial sign-in, a forwarding or deletion rule may continue operating silently until someone reviews mailbox configuration.

The malicious inbox rule hunting workflow

Agent Foskett investigates malicious inbox rules by treating the mailbox as a crime scene: what changed, who changed it, and what messages were affected?
1. Confirm the user symptomStart with what the user noticed: missing email, unexpected forwarding, vanished replies or customers claiming they already responded.
2. Review mailbox rule activityLook for inbox rule creation, updates, forwarding actions, deletion actions and suspicious rule names.
3. Check identity activityCorrelate mailbox rule changes with suspicious sign-ins, impossible travel, unfamiliar IP addresses and unusual authentication patterns.
4. Identify forwarding and deletion logicLook for rules that redirect messages externally, delete messages, move them to hidden folders or target specific subjects and senders.
5. Build the timelineCombine sign-ins, rule changes and message activity into a clear post-compromise sequence.
6. Decide containment actionsDisable malicious rules, revoke sessions, reset credentials, review MFA, inspect OAuth grants and check whether other mailboxes were affected.

Step 1 — Review recent cloud activity for mailbox rule changes

Start by looking for activity that indicates inbox rules were created or modified. The exact field values can vary between tenants and workloads, so the hunt looks across action and activity names.
step-1-mailbox-rule-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
let TimeFrame = 14d;
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where ActionType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
   or ActivityType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
| project Timestamp, AccountDisplayName, AccountId, ActionType, ActivityType, IPAddress, Application, RawEventData
| order by Timestamp desc

Step 2 — Search for forwarding or redirect behaviour

Attackers often use forwarding, redirection, deletion or subject-based rules. Searching the raw rule data can expose suspicious rule conditions and actions.
step-2-forwarding-redirect-rules.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
let TimeFrame = 30d;
let SuspiciousRuleTerms = dynamic(["forward", "redirect", "delete", "invoice", "payment", "password", "mfa", "verify"]);
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where ActionType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
   or ActivityType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
| extend RuleData = tostring(RawEventData)
| where RuleData has_any (SuspiciousRuleTerms)
| project Timestamp, AccountDisplayName, IPAddress, ActionType, ActivityType, RuleData
| order by Timestamp desc

Step 3 — Identify accounts with recent suspicious rule changes

Summarising rule activity helps scope the investigation. One user changing many rules, or many users changing rules from the same IP address, deserves closer review.
step-3-accounts-with-rule-changes.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
let TimeFrame = 30d;
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where ActionType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
   or ActivityType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
| summarize RuleChangeCount = count(), SourceIPs = make_set(IPAddress, 20), Applications = make_set(Application, 20), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by AccountDisplayName
| order by RuleChangeCount desc

Step 4 — Correlate mailbox rule changes with suspicious sign-ins

A suspicious inbox rule is more serious when it appears soon after an unusual sign-in. This query creates a six-hour window around the rule change.
step-4-correlate-rule-changes-signins.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
let TimeFrame = 30d;
let RuleChanges =
    CloudAppEvents
    | where Timestamp > ago(TimeFrame)
    | where ActionType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
       or ActivityType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
    | project RuleTime = Timestamp, AccountDisplayName, RuleChangeIP = IPAddress, RuleAction = ActionType, RuleActivity = ActivityType, RawEventData;
let SignIns =
    IdentityLogonEvents
    | where Timestamp > ago(TimeFrame)
    | project SignInTime = Timestamp, AccountUpn, SignInIP = IPAddress, Location, SignInAction = ActionType, FailureReason;
RuleChanges
| join kind=leftouter SignIns on $left.AccountDisplayName == $right.AccountUpn
| where SignInTime between ((RuleTime - 6h) .. (RuleTime + 6h))
| project RuleTime, SignInTime, AccountDisplayName, RuleChangeIP, SignInIP, Location, RuleAction, RuleActivity, SignInAction, FailureReason
| order by RuleTime desc

Step 5 — Look for mailbox access after rule creation

After a rule is created, attackers may read mail, search the mailbox, access attachments or monitor future responses. Post-rule activity helps confirm impact.
step-5-mailbox-access-after-rule.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let TimeFrame = 30d;
let RuleChangeUsers =
    CloudAppEvents
    | where Timestamp > ago(TimeFrame)
    | where ActionType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
       or ActivityType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
    | summarize FirstRuleChange = min(Timestamp) by AccountDisplayName;
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| join kind=inner RuleChangeUsers on AccountDisplayName
| where Timestamp >= FirstRuleChange
| summarize PostRuleActivity = count(), ActivityTypes = make_set(ActivityType, 30), Applications = make_set(Application, 20), SourceIPs = make_set(IPAddress, 20), FirstActivity = min(Timestamp), LastActivity = max(Timestamp) by AccountDisplayName, FirstRuleChange
| order by PostRuleActivity desc

Step 6 — Build the malicious inbox rule timeline

The timeline is where the investigation becomes understandable. It shows whether a suspicious sign-in happened before a rule was created and what happened next.
step-6-malicious-inbox-rule-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
let TimeFrame = 30d;
let TargetUser = "user@contoso.com";
let RuleActivity =
    CloudAppEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountDisplayName =~ TargetUser
    | where ActionType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
       or ActivityType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "CreateInboxRule")
    | project Timestamp, EventType = "Mailbox rule activity", Account = AccountDisplayName, IPAddress, Detail = strcat(ActionType, " ", ActivityType);
let SignInActivity =
    IdentityLogonEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountUpn =~ TargetUser
    | project Timestamp, EventType = "Identity sign-in", Account = AccountUpn, IPAddress, Detail = strcat(ActionType, " ", FailureReason);
union RuleActivity, SignInActivity
| order by Timestamp asc

Common malicious inbox rule behaviours

These are the patterns Agent Foskett looks for when reviewing mailbox rules after a compromise.
External forwardingMessages are redirected to an external mailbox controlled by the attacker.
Silent deletionMessages containing words such as password, invoice, MFA, payment or alert are deleted before the user notices.
Hidden movementMessages are moved to Archive, RSS, Junk or obscure folders to hide them from the user.
Subject-based targetingRules target invoices, bank details, payment requests, password resets or executive conversations.
Sender-based targetingRules target specific customers, executives, suppliers or IT service desks.
Rule cleanupAttackers may remove rules after use, leaving only audit and telemetry evidence behind.

Common false positives

Not every inbox rule is malicious. Context matters.
Legitimate mailbox automationUsers often create rules to organise receipts, newsletters, alerts and recurring business email.
Shared mailbox workflowsTeams may use rules to route support tickets, sales enquiries or operational notifications.
Migration or admin activityMailbox migrations, admin scripts or support changes can create rule activity that looks unusual without context.

Evidence that increases suspicion

These findings make a mailbox rule investigation more serious.
Rule created after unusual sign-inA mailbox rule created shortly after impossible travel, unfamiliar IP activity or suspicious authentication is high risk.
Rule targets sensitive termsRules involving passwords, invoices, payment, MFA, bank details or executives deserve deeper investigation.
External recipient appearsForwarding or redirecting email to a personal or unfamiliar external address can indicate mailbox compromise.
User denies creating the ruleIf the user does not recognise the rule, treat it as a strong compromise indicator until proven otherwise.
Mailbox activity continues after rule creationPost-rule cloud activity may indicate the attacker continued monitoring the mailbox.
Other accounts show similar rulesMultiple mailboxes with similar rule names, conditions or forwarding destinations may indicate a broader campaign.

Investigation checklist

Use this checklist when hunting malicious inbox rules in Microsoft 365.
Which rule was created or modified?Record the rule name, conditions, actions, forwarding destination and creation time.
Who created it?Correlate the mailbox rule change with sign-in records, source IP addresses and application context.
What did the rule do?Identify whether it forwarded, redirected, deleted, moved or hid messages.
What messages were affected?Review the rule conditions and search for matching subjects, senders or message types.
Was the account compromised?Check credential theft, impossible travel, MFA changes, OAuth grants and mailbox access activity.
What containment is required?Remove malicious rules, revoke sessions, reset credentials, review MFA and check other mailboxes for similar behaviour.

Related Agent Foskett Academy lessons

Hunting Playbook: Impossible TravelInvestigate suspicious sign-in locations and impossible travel scenarios.
Hunting Playbook: Credential TheftInvestigate stolen credentials, suspicious sign-ins and identity compromise.
Investigating CloudAppEventsUse cloud application telemetry to review mailbox and SaaS activity.
Investigating IdentityLogonEventsReview identity sign-ins and authentication behaviour.
Building Reusable Hunting QueriesTurn mailbox investigations into repeatable hunting patterns.
Using let StatementsCreate reusable variables and named evidence blocks.

Coming next

The Hunting Playbook Series continues with OAuth abuse.
Lesson 104 — Hunting Playbook: OAuth AbuseNext, Agent Foskett investigates malicious OAuth app consent, excessive permissions, mailbox access and cloud persistence created without a traditional password sign-in.
Why this mattersMalicious inbox rules are often the bridge between credential theft and business email compromise. OAuth abuse is another way attackers maintain access after the initial compromise.

Final thought

A mailbox rule can be small, quiet and devastating.
Agent Foskett mindsetDo not only ask whether the attacker logged in. Ask what the attacker changed after they got there.
Post-compromise persistenceInbox rules allow attackers to keep receiving value from a mailbox even after the user has stopped noticing new symptoms.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Hunting Playbook Malicious Inbox Rules in Microsoft Defender XDR

Agent Foskett Academy Lesson 103 teaches defenders how to hunt for malicious inbox rules using Microsoft Defender XDR, Exchange Online telemetry, CloudAppEvents, mailbox rule changes and identity sign-in evidence.

Investigate malicious inbox rules with KQL and Microsoft Defender XDR

Malicious inbox rules are a common post-compromise technique used in Microsoft 365 business email compromise investigations. Defenders can detect forwarding, deletion, move rules and hidden mailbox activity by correlating mailbox telemetry and identity events.

Microsoft 365 malicious inbox rule investigation playbook

This hunting playbook explains how to investigate suspicious inbox rules, external forwarding, hidden deletion rules, compromised mailboxes, suspicious sign-ins and post-compromise persistence in Microsoft Defender XDR.

ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026