Runbook: Identity Anomaly Alert¶

Runbook Metadata¶

Overview¶

What triggers this runbook: Authentication anomalies including: impossible travel (same account authenticated from two geographically distant locations within impossible timeframe), MFA bypass attempts, authentication from Tor exit nodes or known bad IPs, large numbers of failed authentication attempts followed by success, or UEBA anomaly score breach.

Why this matters: Compromised credentials are the most common initial access vector. Early detection and response to credential compromise can prevent escalation to data exfiltration, ransomware deployment, or persistent access.

Common causes:

Triage Steps (Tier 1) — Target: 10 minutes¶

Step 1: Immediate Context¶

• [ ] 1.1 Note the alert type: ☐ Impossible travel ☐ Tor/bad IP ☐ MFA anomaly ☐ Brute force success ☐ UEBA spike
• [ ] 1.2 Identify affected account: ________
• [ ] 1.3 Identify authentication locations/IPs:
• Location 1: _ at _ UTC
• Location 2: _ at _ UTC
• Distance/time feasibility: ☐ Impossible ☐ Improbable ☐ Possible

Step 2: Quick Enrichment¶

Run in SIEM — replace {USER} and {TIMERANGE}:

// Last 24h authentication events for user
SigninLogs
| where UserPrincipalName == "{USER}"
| where TimeGenerated > ago(24h)
| project TimeGenerated, IPAddress, Location, ResultType, ResultDescription,
          AuthenticationRequirement, ClientAppUsed, DeviceDetail
| order by TimeGenerated desc

// Active sessions for the account right now
AADNonInteractiveUserSignInLogs
| where UserPrincipalName == "{USER}"
| where TimeGenerated > ago(1h)
| summarize count() by IPAddress, Location, AppDisplayName

• [ ] 2.1 Is the suspicious IP a known Tor exit node or commercial VPN? (check TIP)
• [ ] 2.2 Does the user have a travel record or remote work request on file?
• [ ] 2.3 Are there other alerts on this account in the past 30 days?
• [ ] 2.4 What applications/data did the account access from the suspicious location?

Step 3: Contact the User (if safe to do so)¶

• [ ] 3.1 Contact user via secondary channel (phone, Slack, in-person — NOT email to the potentially compromised account)
• [ ] 3.2 Ask: "Did you authenticate from [Location] at [Time]?"
• ☐ Yes, confirmed legitimate → Close as FP, document explanation
• ☐ No, I was not there → Confirmed compromise → ESCALATE IMMEDIATELY
• ☐ Cannot reach user → Treat as unconfirmed compromise → Escalate

Step 4: Triage Decision¶

If: User confirms activity as legitimate (travel, VPN use)
→ CLOSE as False Positive — document in ticket

If: User denies activity OR cannot be reached + suspicious indicators
→ ESCALATE to Tier 2 — do NOT pre-contain without approval

If: Active malicious session confirmed + critical account
→ DECLARE INCIDENT + emergency containment

Investigation Steps (Tier 2)¶

Step 5: Scope the Compromise¶

// All activity from the suspicious IP
SigninLogs
| where IPAddress == "{SUSPICIOUS_IP}"
| where TimeGenerated > ago(7d)
| summarize Users=dcount(UserPrincipalName), Apps=make_set(AppDisplayName)
    by IPAddress, Location

// What did the account access after compromise?
AuditLogs
| where InitiatedBy contains "{USER}"
| where TimeGenerated > ago(7d)
| where Result == "success"
| project TimeGenerated, ActivityDisplayName, TargetResources
| order by TimeGenerated asc

• [ ] 5.1 Were any other accounts authenticated from the same suspicious IP? (pivot indicator)
• [ ] 5.2 Did the account access privileged resources or download data?
• [ ] 5.3 Were any new email rules, forwarding rules, or OAuth grants created?
• [ ] 5.4 Check for MFA method changes (attacker adding their own MFA device)
• [ ] 5.5 Identify dwell time: first suspicious event timestamp = ____

Containment Actions¶

Playbook Trigger: Account Compromise — Immediate Actions¶

Execute in sequence with approval:

1. Revoke all active sessions (soft containment — user loses active logins, can re-authenticate)
2. Azure AD: Revoke-AzureADUserAllRefreshToken -ObjectId {USER_OBJECT_ID}

3. This can be done without manager approval

4. Reset password (forces re-authentication on all devices)

5. Requires user notification immediately after

6. Coordinate with helpdesk

7. Disable account (if active threat or cannot reach user)

8. Requires Tier 2 lead + Manager approval

9. Notify manager of the action

10. Block suspicious IPs/domains (if C2 or attacker infrastructure identified)

11. Submit to network team for firewall block

12. Add to SIEM watchlist

13. Remove suspicious OAuth grants or email rules (if attacker established persistence)

14. Audit all OAuth grants for the account
15. Review and remove unauthorized email forwarding rules

Post-Containment Investigation¶

After containment, determine:

• [ ] Was any data accessed or downloaded?
• [ ] Were any other accounts or systems used by this account during the compromise?
• [ ] What was the initial access vector? (phishing, password spray, credential dump?)
• [ ] Are there other accounts with similar compromise indicators?

Regulatory Considerations¶

If the compromised account had access to:

Engage legal/compliance immediately if any regulatory data may have been accessed.

References¶

• T1078 — Valid Accounts
• T1621 — Multi-Factor Authentication Request Generation
• CISA: Phishing Guidance
• Related: RB-002 — Endpoint Malicious Behavior

RB-001 v1.1 | Reviewed: 2025-Q4 | Next review: 2026-Q4