A leaked Azure service-principal secret let an attacker self-assign Global Administrator, elevate to root-level resource access, harvest keys, and plant persistence across 26 application registrations. The incident exposed how Azure permission data is fragmented across Entra roles, Azure RBAC, Key Vault policies, bearer keys, and Microsoft Graph permissions, making full impact analysis difficult. #EntraID #AzureRBAC #KeyVault #MicrosoftGraph #ServicePrincipal
Keypoints
- The attack began with a leaked service-principal client secret that was exposed for about two weeks before it was abused.
- The attacker moved from first sign-in to Global Administrator in about two and a half minutes by abusing a Graph permission that allowed directory role management.
- They then used Azure RBAC escalation to gain User Access Administrator at the root scope and self-assigned Owner-class access.
- The attacker harvested storage account keys, Event Hub root keys, and Key Vault access by using legitimate Azure API calls.
- Persistence was established by adding attacker-controlled client secrets to 26 application registrations.
- The article argues that Azure permissions are split across five disconnected planes, so incident response must check all of them to understand true exposure.
- Key defenses include monitoring cross-plane bridges like elevateAccess, disabling shared keys where possible, and enabling the right diagnostic logs before an incident.
MITRE Techniques
- [T1078 ] Valid Accounts – The attacker used a leaked service-principal credential to sign in legitimately and begin escalation (‘First valid sign-in as the service principal’).
- [T1098 ] Account Manipulation – The attacker added themselves to roles and created persistence by modifying identities and access settings (‘Add member to role (self)’, ‘Attacker-controlled client secrets added to 26 application registrations’).
- [T1068 ] Exploitation for Privilege Escalation – Used here in the sense of abusing an overly powerful permission path to gain higher privileges quickly (‘A service principal grant itself GA’, ‘RoleManagement.ReadWrite.Directory… lets the application assign any directory role to anyone’).
- [T1528 ] Steal Application Access Token – The attacker abused a leaked service-principal secret, which is an application credential used to authenticate and access Azure (‘leaked service-principal client secret’).
- [T1087 ] Account Discovery – The attacker enumerated identities and resources during reconnaissance (‘enumerate ARM, poke at Graph, list storage and Key Vault’).
- [T1484 ] Domain or Tenant Policy Modification – The attacker changed directory-wide role membership and tenant-level access settings (‘grant themselves User Access Administrator at the root scope’, ‘Global Administrator’).
- [T1098.003 ] Additional Cloud Roles – The attacker self-assigned Global Administrator and User Access Administrator permissions across Azure control planes (‘grant themselves User Access Administrator at the root scope’, ‘Global Administrator’).
- [T1552.001 ] Credentials in Files – The article does not indicate a file, but it does show exposed long-lived secrets being replayed from infrastructure; if interpreted strictly, this technique is only partially implied and not directly evidenced. (‘leaked service-principal client secret’).
- [T1528 ] Cloud Service Dashboard or API Abuse – The attacker used legitimate Azure and Graph APIs for escalation and key retrieval (‘Microsoft.Authorization/elevateAccess/action’, ‘storageAccounts/listKeys’).
Indicators of Compromise
- [Credential ] Initial access – leaked service-principal client secret; attacker-controlled client secrets added to 26 application registrations
- [API action / Activity ] Privilege escalation and key harvest – Microsoft.Authorization/elevateAccess/action, storageAccounts/listKeys, Event Hub listKeys, vaults/accessPolicies/write
- [Azure identity / role names ] Compromised permissions – Global Administrator, User Access Administrator, Owner, Privileged Role Administrator
- [Infrastructure / network sources ] Replay origins for the stolen credential – commercial VPN ranges, Tor exit nodes, hosting providers in the US, Germany, Sweden, Hong Kong, and the Netherlands
- [Cloud resources ] Targeted resources – four storage accounts, two Event Hub namespaces, three Key Vaults, 26 application registrations
- [Logs / telemetry sources ] Places where evidence was found – Entra audit logs, Azure Activity logs, AzureDiagnostics, Microsoft Graph activity logs
Read more: https://www.sysdig.com/blog/no-single-pane-of-glass-anatomy-of-an-azure-permission-takeover