#14.4 Identity Provider and Privileged Credential Compromise

Playbook ID: PB-IDP | Default severity: SEV-2 (escalate to SEV-1 the moment federation config, token-signing material, a directory-sync account, a Global Admin or Domain Admin assignment, or krbtgt is implicated) | Owner: Incident Commander

#When to run this

• A verified domain's authentication type changes, a federation trust is added or modified, or a new token-signing certificate or issuer appears — outside an approved change record.
• A Global Administrator, Privileged Role Administrator, Enterprise Admin, Domain Admin or AWS management-account principal appears outside the change window (T1098 Account Manipulation).
• Entra ID Protection reports a high risky user holding a privileged role, or any risky sign-in on a break-glass account.
• A Purview Audit record for the activity Consent to application carrying IsAdminConsent: True.
• AWS: a GuardDuty credential-exfiltration finding on a privileged role; an IAM OIDC provider created or modified; a role minting IAM users or access keys.
• AD: DCSync-pattern replication from a non-DC principal, AD CS certificate-template modification, or krbtgt activity (T1556 Modify Authentication Process).
• A fraudulent account-recovery or MFA re-enrolment request at the service desk, or one split across two contacts — the CISA AA23-320A pattern.

Not this playbook: a single non-privileged SaaS takeover (14.3 PB-ATO); mailbox fraud and payment diversion (14.2 PB-BEC); a grant issued to a breached vendor's app (14.5 PB-SUPPLY); an admin abusing rights legitimately given (14.6 PB-INSIDER). If encryption is already running, 14.1 PB-RANSOM leads — but run this in parallel, because identity services are now a deliberate ransomware target, not collateral damage.

#What you are dealing with

Every other playbook in this chapter assumes you can log in to fix things. This one does not. The console you would use to contain the attacker may be one the attacker also holds, and the chat channel where you would coordinate almost certainly single-signs-on through the thing you are about to declare untrustworthy. Plan the first hour assuming the adversary is reading over your shoulder.

Sophos found 79% of ransomware attacks began with an identity-based approach, despite 97% of victims having some MFA (Sophos 2026). Microsoft reports 97% of identity attacks are password attacks, and that phishing-resistant MFA blocks over 99% of them even when the attacker already holds valid credentials (MDDR 2025). So attackers stopped fighting the credential and started stealing what the credential produces: AiTM reverse-proxy kits capture the session token after genuine MFA completes (Group-IB), and vishing is now the #2 initial infection vector at 11% of Mandiant investigations (M-Trends 2026). MFA was not bypassed. It was made irrelevant. Nor are you racing someone typing — CrowdStrike measured eCrime breakout time averaging 29 minutes, fastest observed 27 seconds (CrowdStrike 2026 GTR).

The mistake teams make is nearly always the same: reset the password, watch the sign-in fail, write "contained" in the ticket. Microsoft is blunt about consented apps — "Normal remediation steps (for example, resetting passwords or requiring multifactor authentication (MFA)) aren't effective against this type of attack, because these apps are external to the organization" (illicit consent grants). A reset does not touch an OAuth grant, does not touch an application's own session cookie — "Microsoft Entra ID can't directly revoke a session token issued by an application" (revoke user access) — and does not touch an access token that, in a Continuous Access Evaluation session, lives up to 28 hours (CAE). It does lock out the real user, who calls the service desk, which tells the building something is wrong. Takeaway: the containment primitive here is revocation, not rotation — and rotation without revocation is worse than nothing, because it tips off the adversary while leaving them logged in.

#Roles for this incident

**Step markers: EVIDENCE degrades or destroys evidence. TIP-OFF tips off the adversary.

#Phase 1 — Detection and Triage

# Needs Security Administrator + IdentityRiskEvent.Read.All + IdentityRiskyUser.ReadWrite.All.
# Confirming compromise is not cosmetic — it raises the user to high risk, itself a CAE critical event.
Connect-MgGraph -Scopes "IdentityRiskEvent.Read.All","IdentityRiskyUser.ReadWrite.All"
Get-MgRiskyUser -Filter "RiskLevel eq 'high'" | Format-Table UserDisplayName, RiskDetail, RiskLevel
Confirm-MgRiskyUserCompromised -UserIds "<id1>","<id2>"

# Tenant-wide OAuth grant inventory — Microsoft's documented method.
.\Get-AzureADPSPermissions.ps1 | Export-Csv -Path "Permissions.csv" -NoTypeInformation

#Phase 2 — Containment

Containment here is one burst, not a series of tidy-ups. Contain piecemeal and, in Mandiant's words, "the responders 'tip their hand' to the attacker," who abandons the burned infrastructure and persists on footholds you never found (Aldridge, Remediating Targeted-threat Intrusions). Plan every step, then execute them together.

# On-prem AD first. The password is reset twice to mitigate pass-the-hash under replication delay.
Disable-ADAccount -Identity johndoe
Set-ADAccountPassword -Identity johndoe -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<random1>" -Force)
Set-ADAccountPassword -Identity johndoe -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<random2>" -Force)

# Then Entra. Privileged Authentication Administrator is required for admin accounts.
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
$User = Get-MgUser -Search UserPrincipalName:'johndoe@contoso.com' -ConsistencyLevel eventual
Revoke-MgUserSignInSession -UserId $User.Id   # kills refresh tokens and browser session cookies
Update-MgUser -UserId $User.Id -AccountEnabled:$false
Get-MgUserRegisteredDevice -UserId $User.Id -All | ForEach-Object {
    Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false
}

# Quarantine from OUTSIDE the compromised account: an SCP lives in the management account,
# so an attacker holding admin in the member account cannot detach it. The target may be
# a root (r-*), an OU (ou-*), or a 12-digit account ID — but attaching at the root does not
# widen the blast radius to the management account. An SCP at any level, root included, has
# no effect on users or roles in the management account and no effect on service-linked
# roles. If the compromised principal is a management-account principal, this command
# attaches cleanly and contains nothing: use an in-account deny on that principal instead.
aws organizations attach-policy --policy-id p-examplepolicyid111 --target-id <account-or-ou-id>

Then set each compromised key to Inactive with aws iam update-access-key — AWS's documented rotation sequence deactivates before deleting, and for a compromised key you want the usage history preserved. The revoke-sessions action attaches an inline policy named AWSRevokeOlderSessions to the role; the equivalent you can write yourself is a Deny * on * conditioned on aws:TokenIssueTime being earlier than the moment you chose.

#Phase 3 — Eradication

#Phase 4 — Recovery

#Phase 5 — Post-Incident

#Decision points

#Communications and notification triggers

Internal comms run by phone, not email — CISA is explicit that users of potentially compromised systems should be notified by phone, precisely to avoid tipping off an adversary reading the mailbox. The clocks here are triggered by what the identity plane gave access to, not by the identity compromise itself: personal data reached through a compromised admin account starts the GDPR Article 33 72-hour clock from awareness; a regulated service starts the NIS2 24-hour early warning and, for financial entities, DORA's 4-hour-from-classification clock; a public company opens the SEC materiality track immediately. If you federate to customers, or you are somebody's identity provider, downstream notification duties begin the moment federation integrity is in doubt. Chapter 15 holds every clock, recipient and template.

#Automation notes

Automate freely — these gather and enrich, they do not act: log export and hashing, privileged-role diffing against baseline, OAuth grant inventory and AllPrincipals triage, risky-user enumeration, evidence snapshots, timeline assembly, paging the roster to the out-of-band bridge.

Automate behind a scoped, rate-limited gate: session revocation and credential reset for a single non-Tier-0 identity flagged by a confirmed high-risk detection, capped per hour, logged and reversible.

Require a named human approver, every time: tenant-wide revocation; any federation or token-signing change; deleting an OIDC provider (there is no disable operation, and "Deleting an OIDC provider does not update roles that reference it. Any attempt to assume such roles will fail"); attaching a quarantine SCP; disabling any account holding a privileged role; the krbtgt reset. The governing rule: automation may gather, enrich, correlate and recommend without approval; it may act only where the action is reversible, scoped and rate-limited. The documented failure mode of AI-assisted triage is worth quoting to your team — "the agent acts on a confident hallucination before a human sees it" (Panther). Here, the hallucination is "contained."

#Pitfalls