From User Report to Token Revocation: A 60-Minute M365 Phishing Response Walkthrough

Kill Chain at a Glance

The defender side of the chain has five phases. Each phase has a target time-to-completion that, when met, materially reduces incident impact:

1. Report intake (minutes 0–5). A user reports a phishing email or a suspicious sign-in to the SOC. 2. Triage and scope (minutes 5–10). Determine whether credentials were submitted; identify the affected account and any session token issuance. 3. Containment via session and refresh-token revocation (minutes 10–30). Revoke active sessions and refresh tokens before any other action. 4. Consent and rule reversal (minutes 30–45). Reverse any OAuth consent grants or inbox rules created in the suspect window. 5. Recovery and notification (minutes 45–60). Reset the password, notify the user, document the incident.

The order matters. Resetting the password first, before revocation, leaves the attacker with a valid refresh token even after the new password is set. This is the failure mode most commonly cited in public M365 incident retrospectives.

Step-by-Step Walkthrough

**Minutes 0–5: Report intake.** A user-reported phishing message lands in the SOC queue from the Defender for Office 365 user-reported submissions feed, or a Defender XDR alert fires on a suspicious sign-in. The first triage question is whether the user authenticated. If the user filled in credentials and completed MFA on a phishing site or via device-code flow, treat the account as compromised pending containment.

**Minutes 5–10: Triage and scope.** Identify the user's UPN. Pull the last two hours of SigninLogs for that UPN. Note the suspect interactive sign-in. Pull the last two hours of AADNonInteractiveUserSignInLogs filtered to the same UPN — any non-interactive token redemption from a different IP, ASN, or country than the interactive sign-in is the most reliable indicator that a token has been stolen and is being used.

**Minutes 10–30: Containment.** Run the Microsoft Graph revokeSignInSessions action on the user. This invalidates active sessions and forces refresh-token re-issuance, breaking any in-flight attacker session. The same effect can be achieved through the Entra admin center or PowerShell. This step must happen before password reset; otherwise the existing refresh token survives the password change and the attacker keeps the session.

**Minutes 30–45: Reversal.** Pull AuditLogs for the affected UPN over the prior twenty-four hours, filtered to operations that establish persistence: Consent to application, Add delegated permission grant, Add service principal, Add owner to application, New-InboxRule, Update-InboxRule, Add-MailboxPermission, Add device. For every operation in the suspect window, reverse it. OAuth consent reversal happens via the Entra app registrations blade or Microsoft Graph. Inbox rules and mailbox permissions reverse via Exchange Online PowerShell. Device registrations reverse via the Entra admin center.

**Minutes 45–60: Recovery and notification.** Reset the user's password. Force re-enrollment of MFA if any was added or modified during the suspect window. Notify the user with a clear recap of what was done and what they should watch for. Document the incident with the join data, audit data, and reversal record for retrospective review.

Telemetry Per Step

Defender for Office 365 surfaces user-reported submissions in the Threat Explorer feed and via Microsoft Graph. Entra ID provides the interactive and non-interactive sign-in logs and the audit logs. Defender XDR's IdentityLogonEvents and CloudAppEvents tables provide the same data with one-click response actions attached. The shortest path through the chain uses Defender XDR for triage and Entra admin center for containment and reversal.

What Made the Path Succeed

Programs that have completed this chain inside an hour share three traits. They have the revocation runbook scripted, so containment is one command rather than a multi-step admin-center walkthrough. They have role-based access configured so the on-call IR analyst has the rights needed for revocation without escalation. They have the consent and rule audit query saved and parameterized, so reversal is a single re-run rather than a from-scratch hunt.

Choke Points

The most common stall points are: missed consent grants when the audit query is too narrow, missed inbox rules when only New-InboxRule is queried but the operator used Update-InboxRule to modify an existing one, and refresh-token-only persistence when the analyst resets the password before the revocation completes.

Detection and Response Notes

The query below joins the suspect interactive sign-in to any persistence-establishing audit operation in the same window. Every row in the output is something to reverse during the minutes 30–45 step.

// Drive consent and inbox-rule reversal: surface AuditLog operations
// that establish persistence in the window after a suspect interactive
// sign-in for the affected user.
let suspectWindow = 24h;
let suspectUser = "victim@example.com";   // parameterize per incident
let suspectSignin =
    SigninLogs
    | where TimeGenerated > ago(suspectWindow)
    | where UserPrincipalName =~ suspectUser
    | where ResultType == 0
    | project SigninTime = TimeGenerated, UserPrincipalName, IPAddress;
AuditLogs
| where TimeGenerated > ago(suspectWindow)
| where OperationName in ("Consent to application", "Add delegated permission grant",
                          "Add service principal", "Add owner to application",
                          "New-InboxRule", "Update-InboxRule",
                          "Add-MailboxPermission", "Add device")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| where Actor =~ suspectUser
| join kind=inner suspectSignin on $left.Actor == $right.UserPrincipalName
| project TimeGenerated, OperationName, Actor, TargetResources,
          SigninTime, SigninIP = IPAddress