SharePoint AiTM phishing: detection and response in Defender XDR

The SharePoint domain looked legitimate. Investigate the same identity after the click to expose the rest of the campaign.

Microsoft's Defender Security Research Team documented a multi-stage campaign in January 2026. According to Microsoft, the attackers sent a phishing message from an address at a trusted organization, used a SharePoint URL as the lure, moved victims into an adversary-in-the-middle sign-in flow, created inbox rules and then used compromised mailboxes for more phishing and BEC activity.

I am treating that report as the source of the campaign facts. The hunting approach below comes from previous Microsoft-focused MDR and incident-response work. It is defensive guidance, not a customer incident or independent campaign research.

What Microsoft actually reported

Microsoft described this sequence:

1. A phishing email came from an address at a trusted organization that was likely already compromised.
2. The lure used a SharePoint URL and familiar document-sharing language.
3. The URL redirected users to a credential prompt. Microsoft identified the next stage as AiTM activity.
4. The attacker signed in from another IP address and created an inbox rule that deleted incoming mail and marked messages as read.
5. The compromised mailbox sent more than 600 phishing messages to internal and external contacts and distribution lists.
6. The attacker monitored replies, answered questions about whether the message was legitimate and deleted evidence from the mailbox.
7. Microsoft identified more compromised users through landing-page and sign-in IP patterns.

Those are Microsoft observations from this campaign. They should not be generalized into a fixed timeline or a universal AiTM playbook.

The operational lesson is narrower: a trusted collaboration link can be the first visible part of an identity and mailbox incident. Email, identity and Exchange telemetry need to be investigated together.

Why containment has four parts

A password reset changes a credential. It does not automatically settle every active session or remove persistence added after sign-in.

Microsoft's remediation guidance covered four separate actions:

1. Revoke active session cookies.
2. Reset the affected password.
3. Revoke MFA setting changes made by the attacker.
4. Delete suspicious inbox rules.

I would add an investigation step around sent mail, deleted items, archive activity, forwarding configuration and recipients of messages sent from the account. That does not change Microsoft's campaign findings. It turns them into a practical scope checklist.

Hunt 1: SharePoint links where the warning was bypassed

Start with inbound SharePoint links where UrlClickEvents records IsClickedThrough == true. Microsoft defines that field as the user selecting Continue anyway on a Safe Links warning page and reaching the original URL. This hunt does not include every ordinary or allowed click. Allow-list known internal SharePoint hosts and expected senders after you understand the baseline.

let lookback = 24h;
EmailUrlInfo
| where Timestamp > ago(lookback)
| where UrlDomain endswith "sharepoint.com"
    or UrlDomain endswith "sharepoint-df.com"
| join kind=inner (
    EmailEvents
    | where Timestamp > ago(lookback)
    | where EmailDirection == "Inbound"
    | project NetworkMessageId, RecipientEmailAddress, SenderFromAddress, Subject
) on NetworkMessageId
| join kind=inner (
    UrlClickEvents
    | where Timestamp > ago(lookback)
    | where IsClickedThrough == true
    | project ClickTime = Timestamp, NetworkMessageId, Url, AccountUpn, ActionType
) on NetworkMessageId, Url
| project ClickTime, AccountUpn, RecipientEmailAddress,
    SenderFromAddress, Subject, Url, UrlDomain, ActionType
| order by ClickTime desc

A hit means a user continued through a Safe Links warning for a SharePoint link. It does not establish that the destination was malicious or that a session was stolen.

Hunt 2: risky sign-ins after the click

The next query correlates those warning-bypass events with current EntraIdSignInEvents records. In the current schema, RiskLevelAggregated uses 50 for medium and 100 for high. RiskState uses 4 for at risk and 5 for confirmed compromised. The table requires Microsoft Entra ID P2. Validate availability and retention in your tenant before scheduling the query.

let lookback = 24h;
let sharePointClicks =
    EmailUrlInfo
    | where Timestamp > ago(lookback)
    | where UrlDomain endswith "sharepoint.com"
        or UrlDomain endswith "sharepoint-df.com"
    | join kind=inner (
        UrlClickEvents
        | where Timestamp > ago(lookback)
        | where IsClickedThrough == true
        | project ClickTime = Timestamp, NetworkMessageId, Url, AccountUpn
    ) on NetworkMessageId, Url
    | project ClickTime, AccountUpn, Url;
let riskySignIns =
    EntraIdSignInEvents
    | where Timestamp > ago(lookback)
    | where RiskLevelAggregated in (50, 100)
        or RiskState in (4, 5)
    | project SignInTime = Timestamp, AccountUpn, IPAddress,
        Application, RiskLevelAggregated, RiskState, City, Country;
sharePointClicks
| join kind=inner riskySignIns on AccountUpn
| where SignInTime between (ClickTime .. (ClickTime + 2h))
| project AccountUpn, ClickTime, SignInTime, Url, IPAddress,
    Application, RiskLevelAggregated, RiskState, City, Country
| order by ClickTime desc

The two-hour window is a hunting choice, not a timing claim from Microsoft. Tune it against your own telemetry and expected travel, VPN and proxy behavior.

Hunt 3: mailbox rules and forwarding changes

Microsoft reported an inbox rule that deleted mail and marked it as read. Hunt mailbox changes independently, then pivot by account and time into the correlated click and sign-in results.

CloudAppEvents
| where Timestamp > ago(24h)
| where ActionType in~ (
    "New-InboxRule",
    "Set-InboxRule",
    "Set-Mailbox"
)
| extend Parameters = tostring(RawEventData.Parameters)
| where Parameters has_any (
    "DeleteMessage",
    "MarkAsRead",
    "ForwardTo",
    "RedirectTo",
    "ForwardingSmtpAddress"
)
| project Timestamp, AccountDisplayName, AccountId, AccountObjectId,
    IPAddress, ActionType, Parameters
| order by Timestamp desc

Do not force a join between an object ID and a UPN. Normalize identity keys first. Tenant schemas and connectors differ, and an invalid join can hide the activity it is meant to find.

A response sequence that does not wait for perfect attribution

When the evidence supports compromise, containment should start before the campaign has been fully reconstructed:

1. Disable or restrict the affected identity according to the incident runbook.
2. Revoke active sessions.
3. Reset the password and review registered authentication methods.
4. Remove malicious inbox rules and mailbox forwarding.
5. Review sent, deleted and archived messages.
6. Find recipients of follow-on messages and search for the same lure, URL and sender pattern.
7. Preserve the sign-in, email and audit evidence needed for the investigation.

Microsoft also recommends Conditional Access, continuous access evaluation, FIDO2 passwordless sign-in, network protection and stronger anti-phishing controls. Those controls reduce risk, but they do not remove the need to investigate a mailbox once the identity has been used.

What I would test next

Run the three hunts separately before turning them into an analytics rule. Check whether the expected account identifier survives each connector, whether service accounts create legitimate rules, and whether safe-link rewrites change the URL used for correlation.

Then run a tabletop exercise with one identity moving through email, sign-in and mailbox telemetry. The goal is simple: prove that the team can revoke sessions, find persistence and identify downstream recipients without inventing certainty from a single alert.

For related behavior-first hunts, see the Tsundere Bot note and the Sliver C2 guide.

Sources

• Microsoft Defender Security Research Team: Resurgence of a multi-stage AiTM phishing and BEC campaign abusing SharePoint
• Microsoft Defender XDR: UrlClickEvents table
• Microsoft Defender XDR: EntraIdSignInEvents table