Agent Foskett • Microsoft 365 • Inbox Rule Investigation

The Inbox Rule Was Created At 2:13AM

The login itself did not trigger panic.

MFA succeeded. The account was not immediately disabled. No malware alert fired.

But at 2:13AM, a new inbox rule quietly appeared inside the mailbox.

The rule forwarded messages externally, moved replies into hidden folders and reduced the chance the user would notice suspicious activity.

This Agent Foskett investigation looks at how Microsoft 365 telemetry, OfficeActivity logs, AuditLogs and KQL can expose hidden mailbox persistence and post-authentication compromise behaviour.

The attacker did not need to stay logged in. The inbox rule continued doing the work for them.

Discuss your environment Back to Investigation Hub

Agent Foskett SpoofedDomain EmailEvents Microsoft Defender KQL investigation

Briefing summary

Inbox rules can become a hidden persistence mechanism after account compromise. GEMXIT investigates suspicious mailbox forwarding behaviour, hidden rules and post-authentication activity across Microsoft 365 environments.

Detect suspicious inbox rules

Investigate forwarding and hidden folders

Correlate mailbox activity with sign-ins

What happened

A user account showed a successful Microsoft 365 login. Nothing immediately looked catastrophic. But shortly afterwards, a suspicious inbox rule appeared and began forwarding messages externally.

The login looked normal The sender display name and message content appeared familiar, which is exactly what makes spoofed email so effective.

The inbox rule appeared afterwards EmailEvents and AuthenticationDetails showed sender mismatch, spoofing indicators or authentication results that did not match the visible message.

The persistence stayed hidden The important evidence was not in the email body. It was in the telemetry: SpoofedDomain, EmailEvents, AuthenticationDetails and delivery outcome.

Why SpoofedDomain and EmailEvents matter

Attackers rely on trust. Microsoft Defender helps security teams test whether that trust is real, inherited, misconfigured or completely faked.

Display names can lie A user sees a friendly name. Defender sees the sender address, sender domain, mail-from domain, authentication result and delivery action.

DMARC fail may still be delivered A failed authentication result does not always mean the message was blocked. Policy, forwarding, allow rules and delivery settings can still allow exposure.

Context completes the picture The real question is not only whether spoofing was detected. It is whether the message was delivered, clicked, replied to or used to start identity compromise.

First hunt: find spoofed or mismatched sender domains

Start with EmailEvents. Look for messages marked as spoof, or where the visible sender domain does not align with the mail-from domain.

OfficeActivity
| where TimeGenerated > ago(14d)
| where Operation in ("New-InboxRule", "Set-InboxRule")
| project TimeGenerated,
          UserId,
          Operation,
          Parameters,
          ClientIP,
          UserAgent,
          ResultStatus
| order by TimeGenerated desc

What to review Look for mismatched domains, spoof indicators, suspicious subjects, unusual sender infrastructure and messages delivered to high-value users.

Why it matters Spoofed emails often rely on the user trusting what they see, while the underlying message headers tell a different story.

Best next pivot Pivot into AuthenticationDetails, delivery action, URL clicks, related messages and any sign-in activity after user interaction.

Second hunt: investigate suspicious forwarding behaviour

Forwarding rules can quietly move sensitive emails outside the organisation while remaining mostly invisible to the user.

OfficeActivity
| where TimeGenerated > ago(30d)
| where Operation in ("Set-Mailbox", "New-InboxRule")
| where Parameters has "Forward"
| project TimeGenerated,
          UserId,
          Operation,
          Parameters,
          ClientIP,
          ResultStatus
| order by TimeGenerated desc

What to review Look for dmarc=fail, spf=fail, dkim=fail, compauth failures and delivered messages where authentication did not align.

Why it matters Authentication failures do not always mean compromise, but they do tell you the sender identity needs investigation.

Best next pivot Check whether the email was delivered, quarantined, clicked, forwarded or part of a wider campaign.

Third hunt: correlate mailbox activity with suspicious sign-ins

Mailbox persistence investigations should not stop at the inbox rule itself. Correlating suspicious sign-ins can reveal how the compromise occurred.

SigninLogs
| where TimeGenerated > ago(14d)
| join kind=inner (
    OfficeActivity
    | where Operation == "New-InboxRule"
    | project UserId, RuleCreated = TimeGenerated, ClientIP
) on $left.UserPrincipalName == $right.UserId
| project TimeGenerated,
          RuleCreated,
          UserPrincipalName,
          IPAddress,
          Location,
          ConditionalAccessStatus,
          ClientIP
| order by RuleCreated desc

What to review Look for URL clicks, allowed click actions, suspicious domains, repeated clicks and users interacting with spoofed messages.

Why it matters The risk often begins after delivery. A click can lead to credential harvesting, MFA session theft or malware delivery.

Best next pivot Pivot into SigninLogs, device telemetry, new inbox rules, risky sign-ins and post-click Microsoft 365 activity.

What this kind of activity can indicate

SpoofedDomain and EmailEvents findings are not just email problems. They can be the first sign of a wider identity or business email compromise attempt.

Business email compromise Attackers may impersonate executives, suppliers, finance teams or internal users to trigger payment, approval or data disclosure.

Credential harvesting Spoofed emails often lead users to fake Microsoft 365 login pages designed to capture credentials or session tokens.

MFA session theft Adversary-in-the-middle phishing can capture a session after the user completes MFA, making the email investigation an identity investigation.

Misconfigured legitimate senders Not every DMARC failure is malicious. Some reveal third-party senders, marketing tools or SaaS platforms that are not correctly aligned.

Weak domain protection Domains without strong SPF, DKIM and DMARC enforcement are easier for attackers to abuse or imitate.

Delivered risk The most important question may be simple: did the spoofed or failed-authentication email reach a user?

How GEMXIT approaches spoofed email investigations

At GEMXIT, we do not stop at whether an email was flagged. We look at sender authentication, delivery, user interaction and post-click identity behaviour together.

We inspect the message evidence EmailEvents, AuthenticationDetails, sender domains, delivery action and NetworkMessageId help explain what really happened.

We follow the behaviour UrlClickEvents, SigninLogs, Defender telemetry and audit data help determine whether the user interacted and what happened next.

We improve prevention The outcome should improve SPF, DKIM, DMARC, Defender policies, user reporting and KQL hunting visibility.

Final thought

The login was only the beginning.

At GEMXIT We help organisations investigate Microsoft 365 persistence, suspicious inbox rules, forwarding behaviour and post-authentication compromise activity using Microsoft Defender, Sentinel and KQL.

Agent Foskett mindset The important question is not only:

“Was the login successful?”

It is:

“What changed afterwards?”

Continue the investigation with The Session Token Never Expired, The User Passed MFA But It Wasn't Really Them, The Login Came Through A Trusted Device, MFA Session Hijacking and The After-Hours Download.

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