# [HIGH] Microsoft Patches Entra ID Role Flaw That Enabled Service Principal Takeover **Source:** The Hacker News **Published:** 2026-04-28 **Article:** https://thehackernews.com/2026/04/microsoft-patches-entra-id-role-flaw.html **Curated:** Analyst-reviewed 2026-04-28 ## Threat profile Silverfort disclosed a privilege-escalation flaw in Microsoft **Entra ID's Agent ID Administrator** role — a built-in role introduced for managing **AI agent identities** in Microsoft's new agent-identity platform. The role had **excessive scope** that allowed an Agent ID Administrator to: - Manage / take over **service principals** that weren't AI-agent-related. - Reset secrets / certificates on those service principals. - Effectively pivot from "AI-agent identity" to "any service principal in the tenant." Service principals frequently hold: - Privileged Microsoft Graph permissions (`Directory.ReadWrite.All`, `Mail.ReadWrite`, `Files.ReadWrite.All`). - Cloud-resource access (Azure RBAC roles tied to subscriptions / management groups). - Application authentication for production systems. A compromised Agent ID Administrator → service principal takeover → tenant-wide privilege escalation is the kind of exposure that turns "lateral movement in cloud" into "global admin in 2 hops." We've upgraded severity to **HIGH** because: - Most enterprises are now adding Entra ID agent roles for Microsoft Copilot Studio / AI agent integrations. - Default delegation patterns in Entra ID often put Agent ID Administrator on user accounts that aren't otherwise privileged. - Service principal takeover is a well-known persistence and privilege-escalation pattern (Solorigate / Midnight Blizzard / Storm-0501 all used variants). ## Indicators of Compromise - _No CVE listed in the article excerpt; Silverfort's research blog should have full timeline + impact detail._ - Hunt focus: who currently holds the Agent ID Administrator role; what changed on service principals (especially secret/certificate resets) since the role was introduced. ## MITRE ATT&CK (analyst-validated) - **T1078.004** — Valid Accounts: Cloud Accounts - **T1098** — Account Manipulation - **T1098.001** — Additional Cloud Credentials (the secret-reset attack) - **T1098.003** — Additional Cloud Roles - **T1556** — Modify Authentication Process - **T1606.002** — Forge Web Credentials: SAML Tokens (downstream — what attackers do after SP takeover) ## Recommended SOC actions (priority-ordered) 1. **Audit Agent ID Administrator role assignments.** Pull every account holding this role; question every assignment that doesn't have an explicit AI-agent-platform justification. 2. **Audit service principal secret / certificate changes** in the affected window (since Agent ID Administrator was rolled out — check Microsoft's deployment timeline). 3. **Apply the Microsoft patch / role-scope tightening** as soon as it's available in your tenant. Microsoft's tenant-side fixes typically roll out automatically; confirm via tenant admin centre. 4. **Rotate any service principal secret / cert** that was reset / re-created since the role was introduced. Treat all such changes as suspect. 5. **Build SP-takeover detection as a permanent rule** — credential-add events on service principals from non-administrative actors is high-fidelity. 6. **Continuous-access policies** on service principals that require step-up auth or just-in-time access for credential management. ## Splunk SPL — Entra ID role assignment changes (Agent ID Administrator) ```spl index=azure sourcetype="azure:audit" OperationName IN ("Add member to role","Remove member from role","Update role") Properties.targetResources{}.modifiedProperties{}.newValue="*Agent ID Administrator*" | stats values(initiatedBy.user.userPrincipalName) AS who_made_change, values(targetResources{}.userPrincipalName) AS target_users, values(initiatedBy.user.ipAddress) AS source_ips, earliest(_time) AS firstTime, latest(_time) AS lastTime by OperationName | sort - lastTime ``` ## Splunk SPL — service principal credential additions ```spl index=azure sourcetype="azure:audit" OperationName IN ("Update application","Add service principal credentials", "Update service principal","Add owner to service principal", "Update application - Certificates and secrets management") | eval target_app = mvindex('targetResources{}.displayName',0) | stats values(initiatedBy.user.userPrincipalName) AS who_made_change, values(initiatedBy.user.ipAddress) AS source_ip, count, earliest(_time) AS firstTime, latest(_time) AS lastTime by target_app, OperationName | sort - count ``` ## Splunk SPL — service principal sign-ins from new IPs ```spl index=azure sourcetype=azure:signin isInteractive=false servicePrincipalName=* | stats values(ipAddress) AS source_ips, dc(ipAddress) AS unique_ips, earliest(_time) AS firstSeen, latest(_time) AS lastSeen, count by servicePrincipalName, appId | where unique_ips > 2 | sort - count ``` ## Defender KQL — Entra ID role-assignment audit ```kql AuditLogs | where Timestamp > ago(180d) | where OperationName in~ ("Add member to role","Remove member from role","Update role") | extend ModifiedProps = tostring(TargetResources[0].modifiedProperties) | where ModifiedProps has "Agent ID Administrator" or ModifiedProps has "AgentID" | project Timestamp, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), InitiatorIP = tostring(InitiatedBy.user.ipAddress), Target = tostring(TargetResources[0].userPrincipalName), ModifiedProps | order by Timestamp desc ``` ## Defender KQL — service principal credential changes ```kql AuditLogs | where Timestamp > ago(180d) | where OperationName has_any ("Update application","Add service principal credentials", "Update service principal","Add owner to service principal", "Add application credentials") | extend AppName = tostring(TargetResources[0].displayName), InitiatorUpn = tostring(InitiatedBy.user.userPrincipalName), InitiatorIp = tostring(InitiatedBy.user.ipAddress) | project Timestamp, OperationName, AppName, InitiatorUpn, InitiatorIp, TargetResources | order by Timestamp desc ``` ## Defender KQL — service principal sign-ins anomaly ```kql AADServicePrincipalSignInLogs | where Timestamp > ago(60d) | summarize signins = count(), uniqueIPs = dcount(IPAddress), ips = make_set(IPAddress, 30), countries = make_set(Country, 30), firstSeen = min(Timestamp), lastSeen = max(Timestamp) by ServicePrincipalId, ServicePrincipalName, AppId | where uniqueIPs > 2 or array_length(countries) > 1 | order by signins desc ``` ## Why this matters for your SOC The Agent ID Administrator flaw is part of a broader **2025-2026 trend of "AI agent identity"** — every cloud-identity vendor is shipping new role types for managing AI agent / autonomous-tool identities, and **the role definitions are not getting the same scrutiny as classic admin roles**. The lessons: 1. **Audit any new "AI agent" / "agent identity" / "Copilot admin" role** in your IDP. Question what it can actually do, who's assigned, and whether least-privilege has been applied. 2. **Service principal takeover is the dominant 2025-2026 cloud-pivot pattern.** Build SP-takeover detection as a permanent rule. 3. **Continuous-access** + **PIM (Privileged Identity Management)** for new role types should be standard from day one, not retrofitted after a CVE. Run the Agent-ID-Administrator role-audit query this week; the tenant change-log is short enough that a manual review is feasible. If nobody who holds it has a clear AI-agent-platform reason, remove the role.