ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett • Microsoft Defender XDR • Inbox Rules

The Inbox Rule Hid The Evidence

The email was gone.

No deletion alert. No warning. No sign of the message in the inbox.

After a suspicious sign-in, a new inbox rule appeared.

Messages were quietly moved out of sight before anyone knew to investigate.

The evidence was not deleted. It was hidden.

This Agent Foskett investigation explores how defenders can use Microsoft Defender XDR, Exchange telemetry and KQL to uncover inbox rules used to conceal suspicious email activity after account compromise.

Discuss mailbox investigations Back to Investigation Hub
Agent Foskett investigates hidden inbox rules in Microsoft Defender XDR
Briefing summary

Inbox rules can be used to quietly move, delete, forward or hide messages after a mailbox is compromised. The investigation should not stop because the email is no longer visible.

Find suspicious inbox rule changes
Correlate rule creation with sign-ins
Pivot back to EmailEvents and clicks
🚨 A missing email is not proof the risk is gone.
Attackers can use inbox rules to hide security alerts, password reset messages, bank replies, invoice conversations and warning emails from the user and the help desk.
Book a security review →

Why hidden inbox rules matter

Inbox rules are useful for normal mailbox automation, but in a compromise they can become a quiet persistence and concealment technique.
They hide conversationsRules can move messages about invoices, password resets, MFA prompts or security alerts into folders the user never checks.
They preserve attacker controlA rule can keep the attacker informed, suppress warnings or make the mailbox appear normal while the compromise continues.
They change the timelineThe important question becomes: was the rule created before or after the suspicious sign-in, email delivery, click or OAuth consent?

First hunt: find inbox rule activity

Start by looking for mailbox rule operations. In many Microsoft 365 environments, Exchange and mailbox activity can surface in CloudAppEvents when the right auditing and Defender visibility are available.
find-inbox-rule-activity.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
CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "Create")
| project Timestamp,
          AccountDisplayName,
          AccountObjectId,
          ActionType,
          IPAddress,
          Application,
          RawEventData
| order by Timestamp desc
What to reviewLook for rule names, folder moves, delete actions, forwarding targets, suspicious keywords and whether the activity came from an unexpected IP address.
Why it mattersInbox rules created shortly after risky sign-ins can indicate attacker activity rather than normal user mailbox management.
Best next pivotCorrelate the rule timestamp with sign-in telemetry, email delivery, user clicks and any outbound forwarding behaviour.

Second hunt: search for suspicious rule keywords

Attackers often hide messages by matching words that would expose the compromise. Common targets include invoice, payment, password, MFA, security, bank, payroll and verification messages.
suspicious-inbox-rule-keywords.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
CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType has_any ("InboxRule", "New-InboxRule", "Set-InboxRule")
| extend RuleData = tostring(RawEventData)
| where RuleData has_any ("invoice", "payment", "password", "mfa", "security", "bank", "payroll", "verification")
| project Timestamp,
          AccountDisplayName,
          ActionType,
          IPAddress,
          Application,
          RuleData
| order by Timestamp desc

When an inbox rule deserves deeper investigation

Not every rule is malicious. The context around the rule tells the story. Focus on whether the rule matches compromise behaviour, unusual timing or suspicious mailbox activity.
Messages moved awayRules that move emails to RSS feeds, archive, deleted items or unusual folders can hide important evidence from the user.
Suspicious subjects targetedRules matching invoice, payment, password reset, MFA, bank or security terms should be reviewed carefully.
Created after risky accessA rule created shortly after impossible travel, unfamiliar device use or suspicious OAuth consent is a much stronger signal.

Third hunt: correlate inbox rules with suspicious sign-ins

The mailbox rule is important, but the timing is what makes it suspicious. Correlate the rule creation time with sign-in activity for the same account.
inbox-rule-to-signin-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
let RuleEvents = CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType has "InboxRule"
| project RuleTime = Timestamp, AccountDisplayName, RuleAction = ActionType, RuleIP = IPAddress, RawEventData;
RuleEvents
| join kind=leftouter (
    AADSignInEventsBeta
    | where Timestamp > ago(30d)
    | project SignInTime = Timestamp, AccountDisplayName, IPAddress, City, Country, DeviceTrustType
) on AccountDisplayName
| where SignInTime between ((RuleTime - 2h) .. (RuleTime + 2h))
| order by RuleTime desc

Fourth hunt: pivot back to delivered email and clicks

If the rule was hiding messages, go back to the email timeline. Search for delivered messages and URL clicks around the same account and timeframe.
inbox-rule-to-email-clicks.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
EmailEvents
| where Timestamp > ago(30d)
| where RecipientEmailAddress has "user@contoso.com"
| project EmailTime = Timestamp,
          NetworkMessageId,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          DeliveryAction,
          ThreatTypes
| join kind=leftouter (
    UrlClickEvents
    | project ClickTime = Timestamp, NetworkMessageId, Url, ActionType
) on NetworkMessageId
| order by EmailTime desc

What a hidden inbox rule can prove

An inbox rule does not prove compromise by itself. It proves mailbox behaviour changed. When that change aligns with suspicious access, delivered phishing, clicks or forwarding, the story becomes much stronger.
Possible concealmentThe rule may have been created to hide warnings, replies, invoice messages, security alerts or password reset emails.
Possible persistenceThe attacker may use rules to monitor or influence mailbox activity after the initial access event.
Possible business riskIf the hidden messages involve payments, approvals, password resets or customer communication, the impact may extend beyond the mailbox.

The Agent Foskett investigator mindset

Do not stop because the message is missing. Do not stop because the inbox looks clean. A clean inbox can be a clue when a rule is doing the cleaning.
Ask what changedWas a new rule created, modified or enabled after a suspicious sign-in or phishing email?
Follow the mailboxReview rules, forwarding, deleted items, archive folders, sign-ins, OAuth grants, delivered email and user clicks together.
Correlate weak signalsA suspicious sign-in, a hidden rule, a delivered email and a later click can explain what a single alert might miss.

How GEMXIT approaches mailbox investigations

GEMXIT helps organisations use Microsoft Defender XDR and Microsoft 365 telemetry to investigate suspicious mailbox behaviour, user clicks and account compromise workflows.
We review mailbox visibilityWe help check whether mailbox auditing, Defender telemetry and investigation data are available when suspicious activity occurs.
We build hunting logicWe help connect CloudAppEvents, EmailEvents, UrlClickEvents, identity telemetry and endpoint telemetry into practical investigation workflows.
We improve response readinessWe help teams understand when to disable rules, reset credentials, revoke sessions, remove OAuth grants, purge emails and review affected users.
The email vanished. The rule explained why.
GEMXIT helps organisations investigate Microsoft Defender XDR mailbox telemetry, hidden inbox rules, suspicious sign-ins, user clicks and KQL hunting workflows.
Contact GEMXIT

Final thought

The inbox looked clean.

The suspicious email was not where anyone expected it to be.

The user thought it had disappeared.

But the rule told the story.

A mailbox rule had moved the evidence before the investigation started.

The evidence was not missing. It had been redirected.
At GEMXITWe help organisations investigate Microsoft Defender XDR, Microsoft Sentinel, Entra ID, mailbox telemetry, email threats, user clicks and real-world security operations workflows.
Agent Foskett mindsetThe question is not only: “Where did the email go?”

It is: “What moved it, when, and who created the rule?”

Continue the investigation with The Inbox Rule Was Created At 2:13AM, The Link Was Clicked After The Email Was Delivered, The User Clicked Accept And Gave Away The Entire Mailbox, EmailEvents KQL Guide, Investigating EmailEvents in Microsoft Defender XDR, Microsoft Defender KQL Threat Hunting Complete Guide, Microsoft Defender and the GEMXIT Security Review.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

The Inbox Rule Hid The Evidence

This Agent Foskett investigation explains how Microsoft Defender XDR, CloudAppEvents, EmailEvents, UrlClickEvents and KQL can help defenders investigate hidden inbox rules after suspicious mailbox activity.

Microsoft Defender XDR inbox rule investigation

GEMXIT helps organisations investigate mailbox compromise, hidden inbox rules, suspicious forwarding, delivered phishing emails, user clicks and Microsoft Defender Advanced Hunting telemetry.

CloudAppEvents, EmailEvents and UrlClickEvents threat hunting

CloudAppEvents can help defenders review mailbox rule activity while EmailEvents and UrlClickEvents help connect hidden messages to delivered email and user interaction timelines.