This SOP handles Entra ID Identity Protection alerts for impossible travel, unfamiliar sign-in properties, or risk elevated to Medium/High — as well as direct reports of account takeover. The most damaging post-compromise actions (inbox forwarding rules, OAuth app grants, admin role assignment) happen within minutes of a successful login, so depth assessment runs simultaneously with containment.
Target: initial assessment within 10 min; full containment (sessions revoked, MFA cleared, sign-in blocked) within 20 min of confirming compromise.
◈ Table of Contents
📋
PHASE 00 — QUICK REFERENCE
METADATA| SOP ID | SOP-04 |
| Owner | T1 SOC Analyst (triage) · T2 if inbox rules, OAuth grant, or admin role compromise found |
| Trigger | Entra ID Identity Protection alert · Sentinel rule · Impossible travel · Unfamiliar sign-in · MFA fatigue / push bombing report |
| Time Targets | Assessment: < 10 min · Containment: < 20 min from confirmation · Depth check: parallel to containment |
| Escalate To | T2 + Privacy/Legal if: inbox rule forwarding externally confirmed · OAuth grant to unknown app · Admin role assigned by attacker · Data exfil suspected |
| Tools Required | portal.azure.com (Entra ID) · security.microsoft.com · Microsoft Sentinel |
| Recovery Rule | Do NOT re-enable sign-in until: password reset out-of-band AND MFA re-registered AND endpoint confirmed clean |
🔍
PHASE 01 — VALIDATE & SCORE THE ALERT
TARGET: < 10 MIN01
Pull Sign-in History + Run Impossible Travel Math
KQL REQUIRED
◈ Steps
- 1Get the UPN from the alert. Run the full 24h sign-in history to see the exact login sequence:
KQL — FULL SIGN-IN HISTORY FOR COMPROMISED ACCOUNT (last 24h)
// Replace [email protected] with the flagged account UPN
SigninLogs
| where TimeGenerated >= ago(24h)
| where UserPrincipalName =~ "[email protected]"
| project
TimeGenerated, UserPrincipalName, IPAddress, Location,
AppDisplayName, ClientAppUsed, DeviceDetail,
ResultType, ResultDescription,
RiskLevelDuringSignIn, ConditionalAccessStatus,
AuthenticationRequirement
| order by TimeGenerated desc
- 2Find the two logins generating the impossible travel alert. Calculate: how many minutes between Login A (known location) and Login B (anomalous location)?
- 3Run the impossible travel KQL to automate this check across consecutive successful logins:
KQL — IMPOSSIBLE TRAVEL DETECTION (consecutive successful logins)
SigninLogs
| where TimeGenerated >= ago(24h)
| where UserPrincipalName =~ "[email protected]"
| where ResultType == "0" // successful logins only
| order by TimeGenerated asc
| extend
NextTime = next(TimeGenerated),
NextLocation = next(Location),
NextIP = next(IPAddress)
| extend TimeDiffMin = datetime_diff('minute', NextTime, TimeGenerated)
| where Location != NextLocation and TimeDiffMin < 180
| project TimeGenerated, Location, IPAddress,
NextTime, NextLocation, NextIP, TimeDiffMin
- 4Check Entra ID risk score:
portal.azure.com → Microsoft Entra ID → Security → Identity Protection → Risky sign-ins. Find the sign-in. Note Risk level and Risk state. - 5FP check: Is the anomalous IP a known corporate VPN exit node or a datacenter IP (not a residential IP)? Check:
Entra ID → Security → Conditional Access → Named Locations— is that IP in a trusted range? - 6If risk = Low AND IP is trusted corporate VPN → FP. Dismiss in Identity Protection. Close ticket. Otherwise proceed to Phase 2.
🔬
PHASE 02 — DEPTH ASSESSMENT
RUN IN PARALLEL WITH PHASE 302
Check Inbox Rules, OAuth Grants, MFA Changes, Role Assignments
KQL REQUIRED
◈ Steps
- 1Check for malicious inbox rules (forwarding all email to attacker-controlled address — data exfil via email). This is the most common post-compromise action.
KQL — INBOX RULE CREATION (data exfil indicator)
CloudAppEvents
| where TimeGenerated >= ago(48h)
| where AccountId =~ "[email protected]"
| where ActionType in (
"New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| project TimeGenerated, AccountId, ActionType, RawEventData
| order by TimeGenerated desc
- 2If inbox rule found: check
RawEventDataforForwardToorRedirectTofields pointing to external domains. If external forwarding confirmed → escalate to T2 + Privacy/Legal immediately. - 3Check for MFA method changes (attacker re-registered their own device for MFA — persistence):
KQL — MFA METHOD CHANGES + AUTH UPDATES
AuditLogs
| where TimeGenerated >= ago(48h)
| where OperationName in (
"User registered security info",
"User deleted security info",
"Admin registered security info for user",
"Update StsRefreshTokenValidFrom")
| where TargetResources[0].userPrincipalName =~ "[email protected]"
| project TimeGenerated, OperationName, InitiatedBy,
TargetResources, Result
| order by TimeGenerated desc
- 4Check for OAuth consent grants (attacker tricks user or tenant into granting their malicious app access to mailbox/files):
KQL — OAUTH APP CONSENT GRANTS
AuditLogs
| where TimeGenerated >= ago(48h)
| where OperationName in (
"Consent to application",
"Add delegated permission grant",
"Add app role assignment to service principal")
| where InitiatedBy.user.userPrincipalName =~ "[email protected]"
| project TimeGenerated, OperationName, TargetResources, Result
| order by TimeGenerated desc
- 5Check for admin role assignment:
portal.azure.com → Entra ID → Users → [user] → Assigned roles. Was any admin role (Global Admin, Exchange Admin, SharePoint Admin) assigned in the last 48h? If yes → escalate to T2 immediately.
Escalate to T2 and notify IR Lead immediately if ANY of these are found: inbox forwarding rule, OAuth grant to unknown app, admin role assigned. These indicate active data exfil or persistence — do not handle as T1.
🔒
PHASE 03 — FULL CONTAINMENT — ENTRA ID
DO STEPS IN ORDER — DO NOT SKIP03
Revoke Sessions → Clear MFA → Block Sign-in → Delete Rules
ENTRA ID ACTION
◈ Steps — Execute in This Exact Order
- 1Revoke all active sessions:
portal.azure.com → Entra ID → Users → [user] → Revoke sessions(button visible in the user overview panel). This terminates all active tokens. The attacker loses access within seconds. - 2Block sign-in:
Entra ID → Users → [user] → Edit properties (pencil icon) → Account status → Block sign-in = Yes → Save. This prevents re-authentication even with valid credentials. - 3Clear all MFA methods:
Entra ID → Users → [user] → Authentication methods → Delete all methods(delete each method individually — phone, authenticator app, FIDO2, etc.). This ensures the attacker cannot re-authenticate with any MFA device they registered. - 4Delete malicious inbox rules (if found in Phase 2): Open Exchange Online Admin Center or run PowerShell via Defender Live Response / Cloud Shell:
Get-InboxRule -Mailbox "[email protected]" | Where-Object {$_.ForwardTo -ne $null -or $_.RedirectTo -ne $null} | Remove-InboxRule -Confirm:$false - 5Revoke OAuth grants (if found in Phase 2):
Entra ID → Enterprise Applications → [app name] → Users and groups → Remove [user]. Also:Entra ID → App registrations → [app] → API permissions → Removeif attacker registered the app. - 6Mark as confirmed compromised in Identity Protection:
Entra ID → Security → Identity Protection → Risky users → [user] → Confirm user compromised. This feeds the risk engine and tightens future CA enforcement for this account.
Revoking sessions (step 1) terminates the existing token but the attacker can re-auth if they still have the password. Block sign-in (step 2) is what stops re-authentication. Both must be done.
🖥️
PHASE 04 — DEFENDER ENDPOINT CHECK
VERIFY ENDPOINT NOT ALSO COMPROMISED04
Check User's Devices in Defender XDR
DEFENDER ACTION
◈ Steps
- 1Identify enrolled devices:
Entra ID → Users → [user] → Devices. List all devices. Note which ones are compliant vs non-compliant vs unregistered. - 2For each device:
security.microsoft.com → Devices → [device name]. Check Risk level and Alerts tab. Any active High/Critical alerts? - 3If endpoint has active alerts: trigger SOP-03 for that device. Do NOT re-enable the user account until the endpoint is confirmed clean.
- 4Check the device timeline around the time of the anomalous sign-in:
Devices → [device] → Timeline. Was there unusual process activity, new file drops, or network connections at that time? - 5If the anomalous sign-in was from a different device than the user's enrolled device — that means an attacker device was used. The user's own endpoint may be clean, but confirm before re-enabling.
🔓
PHASE 05 — RECOVERY & RE-ENABLE
DO NOT SKIP GATE CHECKS05
Out-of-Band Verify → Reset Password → Re-enable
ENTRA ID ACTION
◈ Gate Checks — All Must Pass Before Re-enable
- 1Confirm user identity out-of-band: phone call to known number, verified Teams message from their enrolled device, or manager confirmation. Do NOT confirm via email to the compromised mailbox.
- 2Confirm endpoint is clean (Phase 04 passed — no active Defender alerts on the user's devices).
- 3Confirm all malicious inbox rules and OAuth grants have been deleted.
◈ Recovery Steps
- 4Reset password:
Entra ID → Users → [user] → Reset password → Require change at next sign-in = ON. Copy the temporary password. Deliver it via the out-of-band channel only (phone or verified Teams — not email). - 5Un-block sign-in:
Entra ID → Users → [user] → Edit properties → Account status → Block sign-in = No → Save. - 6Direct user to
aka.ms/mfasetupto re-register their MFA methods. User must complete this before accessing any corporate resource. - 7Monitor sign-in logs for 24h post-recovery:
Entra ID → Users → [user] → Sign-in logs. Look for any new anomalous login attempts. If new suspicious activity appears within 24h — re-block and escalate.
✅
PHASE 06 — CLOSE
FINAL STEPS06
Data Exfil Assessment + Ticket Close
CLOSE
◈ Steps
- 1Determine data exfil window: if inbox forwarding rule was active, how long? Check rule creation timestamp vs deletion timestamp. All emails received in that window were exfiltrated. Log this for Privacy/Legal.
- 2If exfil is confirmed → notify Privacy/Legal/DPO. Depending on jurisdiction and data type this may trigger a breach notification requirement.
- 3Identify CA policy gap: why did this sign-in succeed? No sign-in risk policy blocking High risk? No MFA for that app? No geo-block on unusual country? Document gap as follow-up remediation item.
- 4Document: affected UPN, attack vector (impossible travel / credential harvest / MFA fatigue), compromise depth, containment actions taken, recovery timeline, data exfil determination, CA gap.
Closure Checklist
- Sessions revoked, sign-in blocked, all MFA methods deleted
- Inbox forwarding rules deleted (if found)
- OAuth grants revoked (if found)
- Admin role removed (if assigned by attacker)
- Endpoint confirmed clean or SOP-03 triggered
- Password reset out-of-band, MFA re-registered before re-enable
- Data exfil window documented, Privacy/Legal notified if applicable
- CA policy gap identified and logged as remediation item
This SOP pairs directly with SOP-01 (Phishing), SOP-02 (Brute Force), and SOP-03 (Malware) — account compromise is usually downstream of one of those three. Full SOP library at cyberhawkthreatintel.com/sops
◈ Stay Connected
Follow CyberHawk Threat Intel for threat intelligence, deployment guides and hands-on SOC tooling content.
"They can't exploit you if you are the Exploit."