Agent Foskett Academy • KQL Academy • Module 13 • Lesson 156 • Cloud & SaaS Investigation

Lesson 156 — A New Inbox Rule Appeared After the Sign-In

Module 13 has followed suspicious data downloads, unusual geography and OAuth application activity. Now the investigation pivots into Exchange Online.

Minutes after the suspicious sign-in sequence, a new inbox rule appears in the user's mailbox. Inbox rules are normal productivity features, but attackers can abuse them to hide security notifications, move replies away from the inbox or redirect messages. In this lesson we use KQL to identify the rule, inspect what it was configured to do and correlate the mailbox change with the identity timeline.

The existence of an inbox rule is not the finding. The rule's timing, conditions and actions tell us whether it matters.

Begin the Investigation Back to KQL Academy

Agent Foskett KQL Academy Exchange Online inbox rule investigation

Your case file

At 3:22 PM, Exchange Online audit telemetry records a new inbox rule for alex.wilson@contoso.com shortly after suspicious cloud authentication activity.

✓ Find inbox-rule changes

✓ Inspect rule actions

✓ Compare with mailbox history

✓ Correlate the rule with sign-ins

Case briefing

CASE FILE User: alex.wilson@contoso.com 14:34 — OAuth consent granted ↓ 14:47 — application authentication observed ↓ 15:08 — suspicious cloud activity continues ↓ 15:22 — NEW INBOX RULE CREATED ↓ Rule parameters require inspection ↓ THE QUESTION Was this a legitimate mailbox preference, or was the rule created to persist, conceal or redirect attacker-controlled activity?

Investigation objective

Use Exchange Online audit data in OfficeActivity and Microsoft Entra SigninLogs to identify inbox-rule creation or modification, extract the rule's actions, establish whether this behaviour is normal for the mailbox and place the change inside the wider authentication timeline.

Investigator's rule

A rule is configuration, not intent. Forwarding, moving, deleting or marking messages as read may be legitimate. Determine what the rule actually does and who controlled the session when it was created.

Stage 1 — find inbox-rule creation and modification

Start with Exchange workload audit events for the target user. Keep the operation, source IP, user agent and raw parameters so the rule can be reconstructed.

1234567891011121314

let TargetUser = "alex.wilson@contoso.com";
OfficeActivity
| where TimeGenerated > ago(7d)
| where OfficeWorkload == "Exchange"
| where UserId =~ TargetUser
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| project TimeGenerated,
          UserId,
          Operation,
          ClientIP,
          UserAgent,
          Parameters,
          ResultStatus
| order by TimeGenerated asc

Search more than one operation

Inbox-rule activity can be represented by different Exchange audit operations depending on how the rule was created or changed. Inspect the operations available in your tenant rather than relying on one exact event name.

Keep Parameters intact first

The Parameters field can contain the rule name, destinations, actions and other configuration. Preserve the raw structure before extracting individual values.

Stage 2 — inspect what the rule actually does

Expand the rule parameters and focus on actions that can redirect, conceal or alter message handling.

12345678910111213141516171819

let TargetUser = "alex.wilson@contoso.com";
OfficeActivity
| where TimeGenerated > ago(7d)
| where OfficeWorkload == "Exchange"
| where UserId =~ TargetUser
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| mv-expand Parameter = Parameters
| extend ParameterName = tostring(Parameter.Name),
         ParameterValue = tostring(Parameter.Value)
| where ParameterName has_any
      ("Name", "ForwardTo", "ForwardAsAttachmentTo",
       "RedirectTo", "DeleteMessage", "MoveToFolder",
       "MarkAsRead", "StopProcessingRules")
| project TimeGenerated,
          Operation,
          ParameterName,
          ParameterValue,
          ClientIP
| order by TimeGenerated asc

Forwarding changes the risk

ForwardTo, ForwardAsAttachmentTo or RedirectTo can create a direct path for messages to another recipient. Validate the destination before describing it as external or unauthorised.

Concealment can be quieter

Rules that delete, move or mark selected messages as read may be used to hide replies, alerts or password-reset notifications. The conditions and targeted messages are as important as the action.

Stage 3 — establish the mailbox's rule-change baseline

Look back across the previous 30 days. A user who routinely manages inbox rules presents a different baseline from a mailbox that has never recorded a rule change.

123456789101112

let TargetUser = "alex.wilson@contoso.com";
OfficeActivity
| where TimeGenerated > ago(30d)
| where OfficeWorkload == "Exchange"
| where UserId =~ TargetUser
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| summarize RuleChanges=count(),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated),
            SourceIPs=make_set(ClientIP, 50)
          by bin(TimeGenerated, 1d)
| order by TimeGenerated asc

First-seen behaviour matters

A first observed rule change during an active compromise investigation deserves more attention than a familiar recurring administrative pattern.

Baseline does not approve the rule

Even if the user has created rules before, the new rule still needs to be evaluated by destination, conditions, source and timing.

Stage 4 — correlate the rule with the suspicious sign-in

Return to Entra sign-in telemetry and examine the authentication context around the rule-creation time.

12345678910111213141516

let TargetUser = "alex.wilson@contoso.com";
let RuleTime = datetime(2026-08-18 15:22:00);
SigninLogs
| where TimeGenerated between (RuleTime - 45m .. RuleTime + 30m)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          ClientAppUsed,
          DeviceDetail,
          AuthenticationRequirement,
          ConditionalAccessStatus,
          ResultType
| order by TimeGenerated asc

Source consistency is useful

If the Exchange audit event and suspicious sign-in share a source IP and close timing, the correlation becomes stronger. Differences can also be meaningful and should be investigated rather than ignored.

Do not confuse correlation with attribution

Matching IP and time can connect events to a session pattern, but it still does not prove who was physically operating the session.

Stage 5 — build the mailbox-compromise timeline

Combine sign-ins and Exchange events into one chronological view. This shows whether the inbox rule appeared as part of the same suspicious cloud sequence.

1234567891011121314151617181920212223242526272829

let TargetUser = "alex.wilson@contoso.com";
let StartTime = datetime(2026-08-18 14:30:00);
let EndTime = datetime(2026-08-18 16:00:00);
union
(
    SigninLogs
    | where TimeGenerated between (StartTime .. EndTime)
    | where UserPrincipalName =~ TargetUser
    | project TimeGenerated,
              EvidenceType="Sign-in",
              Activity=AppDisplayName,
              Source=IPAddress,
              Detail=strcat(tostring(Location),
                            " | CA=", tostring(ConditionalAccessStatus))
),
(
    OfficeActivity
    | where TimeGenerated between (StartTime .. EndTime)
    | where OfficeWorkload == "Exchange"
    | where UserId =~ TargetUser
    | where Operation in ("New-InboxRule", "Set-InboxRule",
                          "UpdateInboxRules", "MailItemsAccessed")
    | project TimeGenerated,
              EvidenceType="Exchange",
              Activity=Operation,
              Source=ClientIP,
              Detail=tostring(Parameters)
)
| order by TimeGenerated asc

Look around the rule

Mailbox access immediately before or after creation can help explain the sequence. Follow relevant Exchange operations rather than treating the configuration event in isolation.

The next pivot is the destination

If the rule forwards or redirects mail, the destination becomes a new investigation entity. Determine whether it is internal, external, known, approved and actually used.

Agent Foskett's mailbox-rule timeline

14:34 OAuth consent granted ↓ 14:47 Application activity ↓ 15:08 Suspicious cloud session continues ↓ 15:22 NEW INBOX RULE ↓ PARAMETERS EXPANDED forward / redirect / delete / move reviewed ↓ 30-DAY BASELINE rule behaviour compared with history ↓ SIGN-IN CORRELATION IP + location + device + policy reviewed ↓ ASSESSMENT Rule creation is consistent with the compromise timeline Purpose must be determined from its actual actions

The rule was only one line in the audit log. Its parameters told us what the attacker may have been trying to achieve.

Your evidence board

Evidence	What it supports	Weight
New inbox rule created after suspicious authentication	Places a mailbox configuration change inside the compromise timeline.	Strong context
Forward or redirect action to an unapproved external address	Supports possible message collection or persistence.	Very strong when validated
Delete, move or mark-as-read actions targeting security-related messages	May support concealment of attacker activity.	Strong when rule conditions confirm it
Rule source matches suspicious sign-in context	Strengthens correlation between authentication and mailbox change.	Strong
No previous rule changes in baseline	Shows the behaviour is unusual for the mailbox.	Supporting evidence
Inbox rule alone	Does not prove malicious intent or successful message forwarding.	Insufficient alone

Write the finding like an investigator

Example: Exchange Online audit telemetry recorded creation or modification of an inbox rule for alex.wilson@contoso.com shortly after suspicious authentication and cloud activity. The rule event was reviewed by operation, source IP, user agent and configuration parameters, including any forwarding, redirect, deletion, movement or mark-as-read actions. Historical Exchange audit activity was examined to determine whether similar rule changes were normal for the mailbox, and Entra sign-ins surrounding the event were correlated by time and source context. The timing and configuration may support mailbox persistence or concealment if the rule directs messages to an unauthorised destination or suppresses security-relevant mail. Rule creation alone does not prove that messages were successfully forwarded or accessed by another party; subsequent mailbox and message-flow evidence should be reviewed.

Lesson 156 key takeaways

Use Exchange workload events in OfficeActivity to investigate inbox-rule changes.
Search multiple relevant rule operations because audit representation can vary.
Preserve and then expand the Parameters field.
Inspect forwarding, redirect, deletion, movement and mark-as-read actions.
Validate destinations before calling them external or unauthorised.
Compare rule creation with the mailbox's historical behaviour.
Correlate Exchange audit events with Entra sign-in context.
Matching IP and timing strengthen correlation but do not prove human attribution.
Rule creation and successful message forwarding are separate evidence questions.
Use the rule's destination and conditions as pivots for the next stage of investigation.

Module 13 — follow the mailbox evidence

Lesson 156 establishes that a new inbox rule appeared inside the suspicious cloud timeline. Next, we follow the most important possible consequence: messages begin forwarding outside the organisation.

Next: Lesson 157 — The Mailbox Started Forwarding Messages Externally.

Continue your KQL investigation training

Module 13 follows users, sessions, applications and data through Microsoft 365 and cloud services.

KQL Academy Lesson 155 — The Application Accessed Data Without the User Microsoft Sentinel Academy Agent Foskett Academy

🔎 KQL Academy — Module 13: Advanced Cloud & SaaS Investigation

Following users, sessions, applications and data through Microsoft 365 and cloud services.

⬅ Previous lesson

Lesson 155 — The Application Accessed Data Without the UserInvestigate non-interactive application access after OAuth consent.

✅ Current lesson

Lesson 156 — A New Inbox Rule Appeared After the Sign-InInvestigate Exchange Online inbox-rule creation and determine whether its actions support persistence or concealment.

Next lesson

Lesson 157 — The Mailbox Started Forwarding Messages ExternallyFollow forwarding evidence and determine whether mailbox content was redirected beyond the organisation.

Investigate Exchange Online inbox rules with KQL

Lesson 156 of the Agent Foskett KQL Academy uses Microsoft Sentinel, Exchange Online audit data and Microsoft Entra sign-ins to investigate inbox-rule creation after suspicious authentication.

Hunt suspicious mailbox rules in Microsoft 365

Learn how to identify inbox-rule changes, inspect forwarding and concealment actions, establish a mailbox baseline and correlate Exchange configuration changes with suspicious identity activity.