Microsoft has issued an urgent warning that a maximum-severity vulnerability in its Entra ID identity and access management (IAM) platform has been exploited in real-world attacks, and the company has shipped a patch. When the identity plane itself is the target, everything downstream — Microsoft 365, Azure workloads, federated SaaS, and every user session those systems protect — is potentially exposed.
Identity is the perimeter. A maximum-severity flaw in Entra ID is not just another patch Tuesday item; it is a direct path to tenant compromise. Defenders need to treat this as an incident-response scenario, not a routine update: patch immediately, then hunt backward for signs the flaw was used before you closed it.
Why This Matters
Entra ID (formerly Azure Active Directory) is the authentication backbone for the majority of enterprise cloud environments. Attackers who can subvert token issuance or validation in Entra ID can:
- Impersonate any user, including Global Administrators, without valid credentials
- Bypass MFA entirely, because MFA enforcement happens at the same layer being attacked
- Mint or manipulate tokens to access Exchange Online, SharePoint, Teams, and Azure Resource Manager
- Establish durable persistence via service principals and application consent grants that survive password resets
Because Microsoft has confirmed exploitation in attacks, assume sophisticated actors — including the nation-state and ransomware-affiliate groups that routinely target identity infrastructure — have working exploit paths. The window between patch availability and mass exploitation of identity flaws is historically measured in days.
Technical Analysis
Affected Platform
- Product: Microsoft Entra ID (cloud identity and access management platform)
- Severity: Maximum severity rating assigned by Microsoft
- Exposure: All tenants relying on Entra ID for authentication and token issuance are in scope until Microsoft's service-side fix is confirmed applied and tenant-side hardening is validated
For cloud-delivered services, Microsoft typically deploys fixes service-side, but defenders must not assume the work is done. Tenant-level configuration — legacy authentication, overly permissive app registrations, stale service principal credentials — determines how much damage an identity flaw can do even after the underlying bug is closed.
How This Class of Attack Works
Maximum-severity Entra ID flaws in this category generally center on token validation or issuance weaknesses — a defect that lets an attacker craft, replay, or escalate tokens that the platform improperly trusts. From a defender's perspective, the observable attack chain looks like this:
- Exploitation of the validation flaw — the attacker obtains or forges a token accepted by Entra ID-protected resources without passing normal credential/MFA checks
- Anomalous resource access — token used against Graph API, Exchange Online, or Azure management endpoints, often from unfamiliar IP ranges or hosting providers
- Privilege consolidation — the attacker enumerates directory roles, adds credentials to service principals, or grants OAuth consent to a malicious application
- Persistence — new app registrations, added federated domains, or modified authentication methods ensure re-entry even after the flaw is patched
The critical defensive insight: even after Microsoft closes the vulnerability, the artifacts attackers created while it was open remain valid until revoked. Post-patch hunting is mandatory.
Exploitation Status
- Confirmed active exploitation in attacks, per Microsoft's warning
- Cloud-service-side patch deployed by Microsoft; tenants must verify and complete tenant-side hardening
- Treat as an active incident: hunt for compromise indicators from the period before patch confirmation
Detection & Response
The highest-fidelity detections for identity-plane exploitation live in Entra ID sign-in and audit logs. Focus on impossible combinations: successful authentications without corresponding MFA claims, token use from anomalous infrastructure, and sudden privilege or consent changes.
Sigma Rules
---
title: Entra ID Anomalous Token Use From Suspicious Infrastructure
id: 3f8a2c41-7b9e-4d15-a6c2-8e1f0b3d5a77
status: experimental
description: Detects successful Entra ID sign-ins originating from hosting providers, VPN exits, or anonymizer infrastructure where the authentication used a token without an interactive MFA claim — a pattern consistent with forged or replayed token abuse.
references:
- https://www.bleepingcomputer.com/news/microsoft/microsoft-warns-of-max-severity-entra-id-flaw-exploited-in-attacks/
- https://attack.mitre.org/techniques/T1550/001/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.defense_evasion
- attack.t1550.001
- attack.initial_access
logsource:
product: azure
category: signin
detection:
selection_anomalous_network:
network_location_detail|contains:
- 'hosting'
- 'vpn'
- 'tor'
- 'proxy'
selection_no_mfa:
authentication_requirement: 'singleFactorAuthentication'
condition: selection_anomalous_network and selection_no_mfa
falsepositives:
- Users on corporate VPN egress points registered as hosting ranges
- Service accounts with legacy authentication
level: high
---
title: Entra ID Privileged Role or Service Principal Credential Addition
id: 9c1e5b28-4a6d-4f83-b2e7-5d9a0c1f6e33
status: experimental
description: Detects additions of credentials to service principals or assignments of privileged directory roles in Entra ID — common persistence actions after identity-plane compromise.
references:
- https://attack.mitre.org/techniques/T1098/
- https://attack.mitre.org/techniques/T1098.001/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.privilege_escalation
- attack.t1098
logsource:
product: azure
category: auditlogs
detection:
selection:
operation_name|contains:
- 'Add service principal credentials'
- 'Add member to role'
- 'Add eligible member to role'
- 'Add app role assignment to service principal'
- 'Consent to application'
condition: selection
falsepositives:
- Legitimate application onboarding and role administration — baseline expected admin activity and alert on deviations
level: high
---
title: OAuth Consent Grant to Newly Registered Application
id: 61d4f7a0-2c8b-4e59-9a31-7f2c6d0e8b44
status: experimental
description: Detects consent grants to applications registered within a short window, a hallmark of illicit consent-grant persistence following identity compromise.
references:
- https://attack.mitre.org/techniques/T1550.001/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1550
logsource:
product: azure
category: auditlogs
detection:
selection:
operation_name: 'Consent to application'
result: 'success'
condition: selection
falsepositives:
- Users consenting to legitimate third-party SaaS — restrict via admin consent workflow
level: medium
KQL Hunting — Microsoft Sentinel
This query joins sign-in anomalies against audit-log persistence actions in the same tenant window, surfacing accounts that authenticated from unusual infrastructure and then performed high-impact directory changes.
// Hunt: anomalous token-based sign-ins followed by persistence actions
let lookback = 14d;
let SuspiciousSignins =
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType == "0"
| where AuthenticationRequirement == "singleFactorAuthentication"
| extend IPClass = tostring(parse_json(NetworkLocationDetails)[0].NetworkNames)
| where IPClass has_any ("hosting", "vpn", "proxy", "tor")
or IPAddress !in (dynamic([])) // populate with known corporate egress ranges
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), IPs=make_set(IPAddress), Apps=make_set(AppDisplayName) by UserPrincipalName, CorrelationId;
let PersistenceActions =
AuditLogs
| where TimeGenerated > ago(lookback)
| where OperationName has_any ("Add service principal credentials", "Add member to role", "Consent to application", "Add federated domain")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| summarize Actions=make_set(OperationName), ActionTime=min(TimeGenerated) by Actor;
SuspiciousSignins
| join kind=inner (PersistenceActions) on $left.UserPrincipalName == $right.Actor
| project UserPrincipalName, FirstSeen, LastSeen, IPs, Apps, Actions, ActionTime
| order by ActionTime asc;
A second, broader sweep for risky service principal changes:
// Sweep: all credential/consent/role changes in the exposure window, with actor context
AuditLogs
| where TimeGenerated > ago(14d)
| where OperationName has_any ("Add service principal credentials", "Update application", "Add member to role", "Consent to application", "Add owner to application")
| mv-expand TargetResources
| extend Target = tostring(TargetResources.displayName)
| extend ActorUPN = tostring(InitiatedBy.user.userPrincipalName), ActorIP = tostring(InitiatedBy.user.ipAddress)
| project TimeGenerated, OperationName, ActorUPN, ActorIP, Target, Result
| order by TimeGenerated desc;
Velociraptor VQL
On endpoints, hunt for processes interacting with cloud token endpoints in ways consistent with token theft or replay tooling — specifically non-browser processes pulling tokens or accessing token cache locations.
-- Hunt for non-browser processes accessing token cache / cloud auth endpoints
SELECT Pid, Name, Exe, CommandLine, Username,
RemoteIP, RemotePort, Status
FROM netstat()
WHERE (RemoteIP =~ '20\.' OR RemoteIP =~ '40\.' OR RemoteIP =~ '52\.' OR RemoteIP =~ '13\.')
AND RemotePort = 443
AND NOT Exe =~ '(?i)(msedge|chrome|firefox|iexplore|Teams|OUTLOOK|OneDrive|SearchApp|svchost)\.exe'
-- Hunt for processes opening Primary Refresh Token / WAM token cache artifacts
SELECT Pid, Name, Exe, CommandLine, Username
FROM pslist()
WHERE CommandLine =~ '(?i)(tbres|TokenBroker|Microsoft.AAD.BrokerPlugin|cloudap|PrimaryRefreshToken|roadtx|ROADtools|AADInternals)'
Verification & Hardening Script
# Entra ID post-patch verification and hardening audit
# Run with Global Reader / Global Admin. Requires Microsoft.Graph module.
Connect-MgGraph -Scopes "Directory.Read.All","Policy.Read.All","AuditLog.Read.All" -NoWelcome
# 1. Review service principal credentials added in the last 30 days (persistence check)
$cutoff = (Get-Date).AddDays(-30)
Get-MgServicePrincipal -All | ForEach-Object {
$sp = $_
foreach ($cred in $sp.KeyCredentials) {
if ($cred.StartDateTime -gt $cutoff) {
Write-Host "[ALERT] New key credential on SP '$($sp.DisplayName)' ($($sp.AppId)) added $($cred.StartDateTime)"
}
}
foreach ($cred in $sp.PasswordCredentials) {
if ($cred.StartDateTime -gt $cutoff) {
Write-Host "[ALERT] New password credential on SP '$($sp.DisplayName)' ($($sp.AppId)) added $($cred.StartDateTime)"
}
}
}
# 2. Audit privileged role assignments changed recently
Get-MgDirectoryRole -All | ForEach-Object {
$role = $_
Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id -All | ForEach-Object {
Write-Host "[ROLE] $($role.DisplayName) -> $($_.AdditionalProperties.userPrincipalName)"
}
}
# 3. Flag OAuth consent grants in the exposure window
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $($cutoff.ToString('yyyy-MM-ddTHH:mm:ssZ'))" -All |
Where-Object { $_.ActivityDisplayName -match 'Consent to application|Add service principal credentials' } |
Select-Object ActivityDateTime, ActivityDisplayName,
@{n='Actor';e={$_.InitiatedBy.user.userPrincipalName}}, Result |
Format-Table -AutoSize
# 4. Verify legacy authentication is blocked (token flaws + legacy auth = bypass path)
$policies = Get-MgIdentityConditionalAccessPolicy -All
$legacyBlocked = $policies | Where-Object {
$_.Conditions.ClientAppTypes -contains 'exchangeActiveSync' -or
$_.Conditions.ClientAppTypes -contains 'other'
}
if (-not $legacyBlocked) {
Write-Host "[WARN] No Conditional Access policy blocking legacy authentication clients — create one now"
}
# 5. List federated domains for tampering (attackers add federated domains for re-entry)
Get-MgDomain -All | Where-Object { $_.AuthenticationType -eq 'Federated' } |
Select-Object Id, AuthenticationType, IsVerified
Write-Host "`nAudit complete. Investigate every [ALERT] entry before declaring the tenant clean."
Remediation
- Confirm Microsoft's service-side fix is applied. Microsoft patches Entra ID centrally, but verify via the Microsoft 365 Message Center and the official Microsoft Security Response Center advisory for this issue that your tenant is no longer exposed. Do not skip tenant-side validation.
- Assume pre-patch compromise and hunt accordingly. Pull 30+ days of Entra ID sign-in and audit logs. Search for the persistence artifacts enumerated above: new service principal credentials, consent grants, role additions, and federated domain changes. Revoke any credential you cannot attribute to a change ticket.
- Rotate secrets on privileged service principals. Any app credential that existed during the exposure window should be treated as potentially exfiltrated and rotated on a priority basis, starting with apps holding
Application.ReadWrite.All,Directory.ReadWrite.All, orRoleManagement.ReadWrite.Directory. - Enforce phishing-resistant MFA for all privileged accounts (FIDO2/passkeys or certificate-based auth). Token-layer flaws sidestep weaker MFA; hardware-bound credentials raise the floor.
- Block legacy authentication tenant-wide via Conditional Access. Legacy protocols do not support modern token protections and remain the easiest re-entry path after an identity incident.
- Enable an admin consent workflow so users cannot self-authorize application consent. Illicit consent grants are the most common persistence mechanism observed after identity-plane attacks.
- Continuous Access Evaluation and token protection: enable CAE and require token binding where supported, limiting the usefulness of any stolen or forged token outside its intended session.
- Review Microsoft's advisory and any CISA directives for remediation deadlines. Federal civilian agencies will be bound by CISA BOD/KEV timelines if this flaw is cataloged; treat those dates as your deadline even in the private sector.
The Bottom Line
A max-severity, actively exploited flaw in the identity plane is a compromise-until-proven-otherwise event. Microsoft's patch closes the door going forward — your job is to find out who walked through it while it was open. Audit your tokens, your service principals, and your consent grants, and do it before the next wave of opportunistic exploitation builds on the access early attackers already established.
Related Resources
Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.