Entra ID: attacks and defense in cloud IAM

Entra ID is Microsoft's cloud-native identity and access management platform, formerly known as Azure Active Directory. Entra ID serves as the central authentication broker for Microsoft 365, Azure, and thousands of third-party SaaS applications. It handles OAuth 2.0, OpenID Connect, and SAML-based flows, issuing access tokens and refresh tokens that grant access to protected resources. Every user, service principal, managed identity, and application registration lives inside an Entra ID tenant. This makes the tenant boundary a critical security perimeter. Attackers who compromise a privileged identity in Entra ID can move laterally across cloud workloads, escalate to Global Administrator, and persist silently through federated identity configurations or rogue OAuth application consents. Understanding Entra ID is not optional for any team defending a Microsoft cloud environment. Its attack surface covers authentication protocols, role assignments, conditional access policies, hybrid identity connectors, and inter-tenant trust relationships. Each of these represents a distinct threat vector that requires specific detection and hardening work.

Detecting attacks against Entra ID starts with the Microsoft Entra audit logs and sign-in logs, both available through the Azure portal and forwardable to a SIEM via Diagnostic Settings or the Microsoft Graph API. Key events to monitor include role assignment changes (AuditLogs, category DirectoryManagement), application consent grants (event 'Consent to application'), and the creation of new service principals or credentials. Sign-in logs expose impossible travel, unfamiliar sign-in properties, and token replay anomalies. The Identity Protection risk events feed surfaces leaked credentials, malicious IP sign-ins, and anomalous token activity. For Pass-Through Authentication (PTA) abuse or AD FS token forgery, correlate Entra sign-in events with on-premises domain controller logs, specifically Event ID 4624 and 4648. Monitor for changes to Conditional Access policies (AuditLogs, resource type Policy) since attackers with Policy.ReadWrite.ConditionalAccess permissions can silently disable MFA enforcement. Alert on any new federated domain addition or changes to the tenant's authentication method, as these are common persistence mechanisms after initial compromise.

Red Team operators targeting Entra ID typically begin with tenant enumeration using tools such as AADInternals or ROADtools to map users, domains, and application registrations without authentication. Device Code Flow phishing is a well-documented initial access technique: the attacker tricks a victim into authenticating via a device code, then captures a valid refresh token scoped to Microsoft Graph. From there, operators enumerate role assignments and target service principals holding privileged API permissions (Application.ReadWrite.All, RoleManagement.ReadWrite.Directory). Privilege escalation often leverages forgotten app registrations with client secrets or certificates stored in code repositories. Persistence is commonly achieved through adding credentials to existing high-privilege service principals or registering a new federated identity provider. To harden an Entra ID tenant, enforce Phishing-Resistant MFA (FIDO2 or certificate-based), restrict device code flow via Conditional Access, apply the principle of least privilege to all service principal API permissions, and enable Privileged Identity Management (PIM) for all Entra roles. Continuous review of OAuth consent grants and regular audit of service principal credentials are non-negotiable controls.