// 05.1 / Read
Why Identity IR
is Different
Endpoint IR isolates a machine, wipes it, rebuilds it. The threat is gone. Identity IR does not work this way. The attacker's access is not on a machine. It is in a token, an OAuth grant, or a service principal credential. These survive everything except explicit revocation.
// The Core Misconception
Password reset is not containment
Proofpoint confirmed in October 2025 that attackers routinely maintain access to compromised M365 environments after password resets and MFA resets by creating internal OAuth applications pre-reset. The OAuth tokens issued to these applications function as cryptographic keys that remain valid until explicitly revoked, regardless of credential changes. Access persisted in documented incidents for up to two years. Bastradamus documented in October 2025 that re-enabling an account after a password reset and account block actually re-enables previously issued tokens. The revocation must happen explicitly. It does not happen automatically.
Key Difference 01
Tokens Survive Credential Changes
An access token issued before the password reset remains valid until it expires, typically 60-90 minutes, or up to 28 hours for CAE-capable resources. A refresh token issued before the reset remains valid indefinitely until explicitly invalidated using the Graph API invalidateAllRefreshTokens endpoint. Password reset does not call this endpoint.
Key Difference 02
OAuth Grants Survive Everything
An OAuth consent grant persists until an administrator explicitly revokes it. Password reset, MFA reset, account block, account re-enable — none of these remove an OAuth grant. An attacker who created an internal OAuth application and issued tokens from it before the password reset still has those tokens and can continue to issue new ones until the grant and the application are both removed.
Key Difference 03
Service Principal Credentials Are Separate
If an attacker added a certificate or client secret to a service principal during the compromise window, those credentials persist independently of any user account changes. Rotating the user's password has no effect on service principal credentials. The backdoor the attacker created continues to function until the specific credential is removed from the service principal.
Key Difference 04
The Timeline Extends Further Back
Endpoint IR typically has a clear infection event. Identity IR often does not. An attacker may have had valid credentials for weeks before taking any detectable action. The investigation window must extend to the earliest plausible compromise date, not just the date an alert fired. Expel's 2026 Annual Threat Report confirms 68.6% of primary threat volume in 2025 was identity-based, with attackers often sitting undetected for extended periods.
Remediation Action
What It Addresses
What It Does NOT Address
Password Reset
Prevents new password-based authentication
Active sessions, refresh tokens, OAuth grants, SP credentials
MFA Reset
Removes existing MFA methods
Active sessions, refresh tokens, OAuth grants, SP credentials
Block Sign-In
Prevents new interactive sign-ins
Active access tokens until expiry, OAuth app tokens, SP credentials
Revoke All Sessions (Graph API)
Invalidates all refresh tokens for the user
OAuth app tokens from internal applications, SP credentials
Remove OAuth Grant and Delete App
Terminates app-level persistent access
SP credentials if separately added, role assignments if made
Full Revocation Sequence
All of the above plus SP credential rotation and role review
Nothing remaining if executed completely
Start here
// 05.2 / Read
The Revocation
Sequence
Order matters. Revoking in the wrong sequence can tip off the attacker before containment is complete, or leave persistence mechanisms active while you believe the incident is resolved.
The Principle
Contain before you communicate
An attacker watching their access disappear in real time will accelerate their objectives. If they have lateral movement options they have not yet used, a partial containment action that alerts them may trigger an escalation. Complete the full revocation sequence before notifying the affected user, before public disclosure, and before anything else that might signal to the attacker that you know. The sequence below assumes a single compromised user account as the entry point. Adjust based on what the investigation reveals about scope.
Identity Incident Revocation Sequence
Execute in order
01
Establish the investigation window first
Before touching anything, determine the earliest possible compromise date. Check SigninLogs for the first anomalous sign-in. Check AuditLogs for the first unexpected change. Check AADNonInteractiveUserSignInLogs for token activity before the anomalous sign-in. The window you establish determines how far back your evidence scope extends.
Do not skip this. Window determines scope. →
02
Identify all persistence mechanisms before revoking
Query AuditLogs for all changes made by or to the compromised account during the investigation window. Look for new app registrations, credential additions to service principals, role assignments, CA policy changes, OAuth consent grants, and new conditional access exclusions. You need a complete list before you start revoking. Revoking the user session without removing a backdoor SP leaves the attacker's access intact through a different path.
Map everything before you touch anything. →
03
Block sign-in on the compromised account
Set accountEnabled to false via Graph API or the Entra portal. This prevents new interactive sign-ins immediately. It does not revoke existing tokens. The attacker's active sessions continue until the next step. Do not reset the password yet if you need to preserve forensic artifacts from the account state.
04
Revoke all refresh tokens via Graph API
Call the revokeSignInSessions action or the invalidateAllRefreshTokens endpoint on the compromised user. This invalidates all refresh tokens. Existing access tokens remain valid until they expire, typically within 60-90 minutes. For CAE-capable resources the revocation propagates in near real-time via the backchannel. For non-CAE resources you must wait for token expiry or block at the resource level.
Tokens still valid for up to 90 min for non-CAE resources. →
05
Remove OAuth grants and delete backdoor applications
For every OAuth consent grant identified in step 02, remove the grant and then delete the application registration. Remove grants first. Deleting the app without removing the grant may leave orphaned tokens. Use the AuditLogs entries from step 02 to ensure you are removing everything created during the compromise window, including grants made by the user on behalf of applications they were manipulated into authorizing.
06
Rotate or remove service principal credentials
For every service principal that had credentials added during the investigation window, remove the specific credential that was added. Do not rotate all credentials on all service principals blindly. Identify the specific additions from AuditLogs and remove only those. Rotating the wrong credentials will break legitimate automation. Removing the attacker-added credential without verification of what legitimate credentials exist may have the same result.
07
Revert unauthorized role assignments and CA changes
Remove any directory role assignments made by or on behalf of the attacker. Revert any Conditional Access policy changes including new exclusions. Verify against your baseline configuration. Document every change you revert for the incident report.
08
Reset credentials and re-enable the account
Only after steps 03 through 07 are complete. Reset the password to a new strong credential. Require MFA re-registration. Re-enable the account. Note: re-enabling the account does not restore previously revoked refresh tokens. The user will need to re-authenticate from scratch. This is the intended outcome.
Continuous Access Evaluation (CAE): CAE-capable resources like Exchange Online and SharePoint can receive near real-time revocation signals from Entra ID via a backchannel. When you revoke sessions, CAE-capable resources stop accepting the user's token within seconds. Non-CAE resources continue to accept the token until it expires. The practical implication is that your revocation in step 04 is not instantaneous for all services. Monitor for continued access in AADNonInteractiveUserSignInLogs for up to 90 minutes after revocation on non-CAE resources.
// 05.3 / Read
Containment
Without Tipping Off
An attacker who detects that you know about the compromise will act. What they do in the next few minutes could be significantly worse than what they have already done. Containment sequencing is not just operational preference. It is a tactical decision.
The Threat Model
What the attacker knows and when
An attacker who is actively using a compromised session will notice when that session stops working. An attacker who has established dormant persistence may not notice until they next attempt to use it. The more active and sophisticated the attacker, the faster they will detect and respond to partial containment actions. Actions that tip them off include: password reset notification to the compromised email, any visible change to the user account in the Entra portal if the attacker has read access, revocation of a specific access token while other persistence paths remain active, and any public incident disclosure or user notification before containment is complete.
Containment Risk 01
Partial Revocation Triggers Escalation
If you revoke the user's session tokens but leave a backdoor service principal with AppRoleAssignment.ReadWrite.All active, an attacker monitoring their access will notice the session revocation and immediately use the service principal to assign Global Administrator to a new account before you identify and remove the SP. Complete the full persistence map before executing any revocation.
Containment Risk 02
User Notification Before Containment
If the attacker has access to the compromised user's email, any notification sent to that email is visible to the attacker. Password reset notifications, security alert emails, and IR status updates sent to the compromised mailbox all tip off the attacker before containment is complete. Communicate with the affected user via an out-of-band channel such as phone or a separate email address that was not part of the compromise scope.
Containment Risk 03
Visible Investigation Activity
If the attacker has read access to AuditLogs or the Entra portal, they can see your investigation queries in real time. Use a dedicated investigation account that has not had any activity in the compromised tenant recently. Avoid querying from the same account that is also making remediation changes. The attacker seeing a sudden burst of AuditLogs queries against their activity window is a clear signal that detection has occurred.
Containment Risk 04
Destroying Evidence Before Capture
Some revocation actions modify the state of objects you still need for forensic reconstruction. Deleting an application registration removes the audit trail for that specific object. Export all relevant AuditLogs entries, service principal details, and OAuth grant data before executing any deletion. The evidence you preserve now determines the quality of the incident timeline and any legal or regulatory reporting you may need to complete.
The Microsoft DART recommendation: Microsoft's Detection and Response Team recommends that all investigation activity during an active identity incident be conducted using cloud-only privileged accounts that are separate from the regular administrative accounts used day-to-day. These accounts should have no email, no Teams access, and no connection to the compromised identity landscape. The investigation account and the remediation account may be the same, but both should be accounts the attacker has not seen and cannot monitor.
// 05.4 / Read
Forensic
Artifacts
The logs that tell you what happened, what was accessed, and how long the attacker was present. Knowing which tables to query and which fields to trust is what separates a complete incident timeline from a guess.
The Log Retention Problem
You may not have the logs you need
Microsoft Entra ID sign-in logs retain for 7 days on free tier, 30 days on P1, and up to 90 days on P2 or with Log Analytics workspace forwarding. If an incident is detected 45 days after the initial compromise and you are on P1, the earliest sign-in logs are gone. Audit logs also have retention limits. The forensic timeline you can build is constrained by the retention configuration that was in place before the incident. This is one of the strongest arguments for forwarding logs to a SIEM with longer retention configured before an incident occurs, not after.
Log Table
What It Tells You in an IR Context
Default Retention
SigninLogs
When the attacker first successfully authenticated, from which IP, what MFA method was used or bypassed, CorrelationId for AiTM detection
7-30 days
AADNonInteractiveUserSignInLogs
Ongoing token usage after the initial compromise. Shows active use of stolen sessions even with no new interactive sign-ins. The primary table for post-AiTM activity.
7-30 days
AADServicePrincipalSignInLogs
Authentication activity for any backdoor service principals created during the compromise. Shows enumeration activity via AzureHound and API calls.
7-30 days
AuditLogs
Every directory change: credential additions, role assignments, consent grants, CA policy changes, app registrations. The primary persistence artifact log.
30 days
IdentityInfo
Snapshot of user and group attributes. Useful for establishing what the state of role assignments was at a specific point in time.
UEBA dependent
MicrosoftPurviewDLP
Data access and exfiltration events. If the attacker accessed sensitive files, emails, or SharePoint content, DLP events provide the evidence of what was touched.
90 days
// Reconstruct all changes made by or to a compromised account during the investigation window
let compromisedUPN = "petra.lindqvist@nordiccorp.se";
let windowStart = datetime(2026-04-01T00:00:00Z);
let windowEnd = datetime(2026-04-14T23:59:59Z);
AuditLogs
| where TimeGenerated between (windowStart..windowEnd)
| where InitiatedBy.user.userPrincipalName =~ compromisedUPN
or TargetResources[0].userPrincipalName =~ compromisedUPN
| project TimeGenerated, OperationName, Result, InitiatedBy, TargetResources, AdditionalDetails
| sort by TimeGenerated asc
// Track token revocation events and verify CAE enforcement
// Microsoft confirmed these OperationName values in April 2026
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in ("Revoke user sign-in tokens", "Invalidate all refresh tokens for a user")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result
| order by TimeGenerated desc
Microsoft Purview for data impact assessment: If the attacker had Mail.Read, Files.ReadWrite.All, or similar application permissions granted during the compromise window, you need to determine what they actually accessed. Microsoft Purview activity logs and the Unified Audit Log contain file access, email read, and download events. Correlate the timestamps from AADServicePrincipalSignInLogs against Purview activity logs to build the data impact timeline. This is the evidence base for regulatory disclosure decisions including GDPR breach notification requirements.
// 05.5 / Read
Recovery and
Hardening
Containment ends the active incident. Recovery restores normal operations. Hardening ensures the same attack path does not succeed a second time. All three are distinct phases with distinct actions.
Recovery Phase
Return to Known Good State
Reset compromised credentials using phishing-resistant MFA for re-enrollment. Require the affected user to re-authenticate from a managed compliant device. Verify all role assignments and permissions for the account match the documented baseline. Re-enable the account only after all persistence mechanisms have been confirmed removed. Document every change made during containment for the audit trail.
Recovery Phase
Verify No Lateral Movement Occurred
Query AADServicePrincipalSignInLogs for any service principal activity during the investigation window that cannot be attributed to legitimate automation. Check AuditLogs for role assignments, credential additions, and consent grants affecting accounts and applications beyond the initially compromised user. If the attacker used the initial access to compromise additional accounts or create additional persistence paths, each one requires its own revocation sequence.
Hardening
Close the Attack Path
Identify exactly how initial access was achieved. If AiTM phishing, enroll the affected user in FIDO2 or deploy phishing-resistant CA policies. If credential stuffing from a leaked database, enforce password manager usage and block reuse. If social engineering of helpdesk, implement verification callbacks and require manager approval for MFA resets on privileged accounts. The hardening action is specific to the attack path, not generic.
Hardening
Update Detection Rules
The incident revealed what your existing detection rules missed. Write the detection rule that would have caught this attack earlier. If an AiTM user agent rotation was the initial indicator, implement the KQL from Module 03. If an app role grant to a backdoor application was the persistence mechanism, implement the ApplicationManagement category alert. Every incident should produce at least one new detection rule.
The Post-Incident Report
What needs to be documented and why
For regulatory compliance, especially GDPR Article 33 which requires notification to the supervisory authority within 72 hours of becoming aware of a breach if personal data was involved, you need a documented timeline of: when the breach occurred, when it was detected, what data was accessible, what actions were taken and when. The investigation work in steps 01 through 07 of the revocation sequence is what produces this documentation. If you did not document the timeline during the incident, reconstructing it afterward from logs is significantly harder and the 72-hour window may have already passed.
Microsoft Identity Protection risk detection routing (April 2026): Microsoft updated its risk detection taxonomy. Route authenticatorPhishing for privileged users to high-priority IR immediately. Route passwordSpray to identity operations and check for pattern matches across other accounts with similar IP, ASN, and protocol signatures. Route suspiciousAPITraffic to teams responsible for app registrations, Graph permissions, and directory security. Route leakedCredentials to immediate account containment especially if the user has access to sensitive systems. Integrate these routing rules into your CA risk policies so automated containment begins before human review.
// 05.6 / Reinforce
Flashcards
Click to flip. Review Again flips back. Got It advances.
Card 1 of 10
// Tap to reveal answer
// Answer
Click card to flip
// 05.7 / Reinforce
IR Decision
Tree
Three active incident scenarios. Each one requires a specific decision at a specific point in the response. No explanations until you answer.
NordicCorp IR // 2026-04-14 09:12 UTCScenario 01
You confirm petra.lindqvist@nordiccorp.se was compromised via AiTM at 07:14 UTC today. It is now 09:12 UTC. AuditLogs shows AutomationSP was granted AppRoleAssignment.ReadWrite.All by petra at 07:51 UTC. Your first action should be:
Completing the persistence map first is the correct sequence. You know about AutomationSP but that does not mean it is the only persistence mechanism. If you block petra and revoke her tokens without removing AutomationSP, the attacker continues operating via the service principal. If you remove AutomationSP without checking for additional role assignments, backdoor apps, or CA exclusions, you may leave other paths active. The full map comes first. Any single revocation action before the map is complete risks tipping off the attacker while other paths remain open.
NordicCorp IR // 2026-04-14 10:45 UTCScenario 02
You have completed the persistence map. You found: AutomationSP with AppRoleAssignment.ReadWrite.All, one new app registration bd-app-7731 with RoleManagement.ReadWrite.All, one new OAuth grant to an external AI tool, and one CA policy exclusion added for petra's account. You are about to execute the revocation sequence. In what order do the following four actions happen? Choose the correct sequence.
Block and revoke first, then remove all persistence mechanisms, then reset credentials last. Resetting the password first does not remove any of the persistence mechanisms and may alert the attacker. Removing bd-app-7731 without first blocking petra leaves the session active and the attacker aware that you found the backdoor. The complete block plus revoke plus persistence removal plus CA exclusion removal should happen in rapid sequence before the attacker can respond, with credential reset as the final step once all paths are closed.
NordicCorp IR // 2026-04-14 12:30 UTCScenario 03
Revocation sequence is complete. You verify petra's account has no active sessions. You then check AADServicePrincipalSignInLogs and find AutomationSP authenticated successfully from a Romanian residential ISP 4 minutes ago. What does this tell you and what is the correct next action?
A successful AutomationSP authentication from a Romanian residential ISP 4 minutes after the revocation sequence confirms an active credential was not removed. Either the attacker added multiple credentials to AutomationSP and you only identified one, or you removed the wrong credential. Disable AutomationSP immediately. Pull the full credential history from AuditLogs using the Certificates and secrets management operation. Identify every credential addition during the investigation window. Remove all of them. Do not re-enable the SP until you can confirm only the legitimate credential remains and its owner is known.
// 05.8 / Test
Module
Quiz
20 questions. Pass at 15. IR sequencing, token revocation mechanics, containment tactics, forensic artifacts, and recovery actions.
out of 20
// 05.9 / Timed Assessment
Timed
Assessment
10 questions. 10 minutes. Active IR scenario. NordicCorp has an active identity incident. Make the right call at each step. Pass at 8.
// Assessment Parameters
Questions
10
Time Limit
10 minutes
Pass
8 / 10
10:00
Remaining