Understanding Identity & Token Compromise in Entra ID
Modern identity attacks rarely exploit software vulnerabilities, they exploit trust. From forged Microsoft tokens and OAuth abuse to device-code phishing and help-desk social engineering, attackers are bypassing traditional security controls by targeting identities, applications, and token lifecycles. Join us for a deep dive into six real-world incidents, including Storm-0558, Midnight Blizzard, Scattered Spider, and Storm-2372, and learn how to build practical detections using Microsoft Entra ID Sign-in Logs, Audit Logs, and Identity Protection telemetry.
Details
About this event
Every major identity breach of the last three years, Storm-0558's forged Microsoft tokens, Midnight Blizzard's pivot through Microsoft's own corporate tenant, Scattered Spider's help-desk social engineering against retail and insurance giants, Storm-2372's device-code-phishing campaigns, has one thing in common: none of them required malware, and none of them exploited a software vulnerability. They exploited trust decisions, a signing key, an OAuth consent grant, a help-desk agent, a forgotten test application.
This session walks six named, primary-sourced incidents and reverse-engineers them into six deployable detection rules built entirely on Entra ID sign-in logs, audit logs, and Identity Protection telemetry, the identity-layer equivalent of the Sysmon config every SOC already runs on the endpoint. We'll cover the layered token model that explains why revoking a password doesn't revoke a token, four live attack-chain scenarios, and an honest accounting of what these rules still can't catch. Built for SOC analysts, detection engineers, and threat intel practitioners who are strong on endpoint telemetry and thin on identity.
Key Takeaways
The password was never the real control. Every technique covered defeats MFA or bypasses authentication entirely by targeting a trust decision, not a cryptographic weakness, detection has to shift from "did the user authenticate correctly?" to "does this token's behavior match this identity's normal pattern?"
The visibility gap is almost never collection, it's two specific log sources everyone forgets. Service-principal sign-in logs and the Consent to application audit event, filtered for high-risk scopes, would have given early detection on four of the six incidents covered.
Revoking a password does not revoke a token. The layered token model (password → MFA approval → access/refresh token → Primary Refresh Token) means each layer requires a different detection and revocation strategy, and the higher layers survive the response actions most playbooks stop at.
Audit your forgotten OAuth apps before an attacker does. The single most consistent thread across the incidents, including the one that hit Microsoft's own tenant, is standing, unreviewed privilege on an app registration nobody has looked at in years.