Azure / Entra ID Token and Credential Harvesting Response
Controlled containment, access vector closure, and durable hardening for credential and token compromise incidents triggered by device code phishing, AiTM session hijacking, unauthorized OAuth consent, or PRT harvesting.
revokeSignInSessions). In scenarios where MFA is bypassed via AiTM (Adversary-in-the-Middle) phishing, phishing-resistant methods such as FIDO2 security keys or Certificate-Based Authentication (CBA) must be enforced. Review Entra ID Conditional Access policies to detect abuse of the device code authentication flow.Prepare
6 steps- Log sources active and routed
Entra ID `SigninLogs`, `AuditLogs`, and `AADNonInteractiveUserSignInLogs` must be streaming to Sentinel and retained for at least 90 days; this is directly related to refresh token lifetime
- Detection rules live
Device code anomaly, AiTM "Anomalous Token" alert, MFA request volume, and honey-app alarms (DR-AE-1/2/5/6/7/10/11) must be tuned and active in production
- Configuration baseline ready
Snapshots of application registrations, service principals, role assignments, and CA policies must be taken regularly; required for comparison at incident time
- Honey components deployed
An unused high-privileged decoy application and a fake Global Admin account; any access attempt against these components generates a high-confidence alert
- Escalation chain defined
SOC L1 → Entra/M365 Admin → IR Lead → CISO; approval authorities for token revocation and CA policy changes must be designated
- Decision gate
This playbook (PB-A) applies only to credential/session harvesting; if application secret addition, privileged role assignment, or Golden SAML evidence is detected, switch to the `azure-entra-id-yonetim-duzlemi` (PB-B) playbook