Azure privilege escalation rarely involves a single dramatic exploit. The typical path is a chain of small misconfigurations, each unremarkable in isolation, that combine to move an attacker from a low privileged foothold to control of an entire subscription. Knowing the most common chains gives defenders a sensible starting point, because the same patterns appear in tenant after tenant once you know what to look for.

From User To Application

A common chain begins with a standard user account that holds owner permissions on an application registration. The user adds a new client secret to the application, authenticates as the application and inherits whatever permissions the application holds. If the application has API permissions to read directory data, the attacker now reads directory data. If the application has subscription contributor rights, the attacker now manages the subscription. Reviewing who owns what application registration is unglamorous and pays dividends. A capable Azure pen testing engagement should map these ownership relationships explicitly.

Managed Identities Become A Currency

A managed identity assigned to a virtual machine is convenient and dangerous in equal measure. Any user who can run code on that virtual machine gets the managed identity token. If the managed identity has reader permissions on the entire subscription, every contributor on the virtual machine quietly becomes a reader on the subscription. Audit your managed identity assignments and grant the minimum permissions that the workload requires. Avoid blanket subscription level assignments wherever possible.

Expert Commentary

William Fieldhouse, Director of Aardwolf Security Ltd

The most efficient escalation chain I have followed in a cloud assessment moved from a contributor role on a single resource group to subscription owner in three steps. Each step exploited a feature working exactly as documented. The misconfiguration was in the role assignments, not the platform.

Audit Logging Is The Safety Net

Even the best privilege management strategy benefits from honest audit logging. Activity logs in Entra ID and resource logs across the subscription tell you what actually happened, which is essential for investigation when something goes wrong. Forward the logs to a destination where they survive long enough to be useful and where they cannot be tampered with by someone who compromised the tenant. Sending the logs to a separate Azure tenant or to a third party platform provides an additional layer of protection against tampering. The attacker who compromises the primary tenant cannot easily reach the audit data, which preserves the evidence needed for investigation and recovery.

Custom Roles Hide Surprises

Custom RBAC roles tend to be defined in a hurry to solve a specific problem and never revisited. Many custom roles include broad action verbs that, on a closer reading, allow far more than intended. A role that grants permission to write any resource property includes the ability to assign access policies. Treat custom roles as security boundaries and review them with the same care as identity policies. Engage a best pen testing company to run privilege escalation paths across both built-in and custom roles in the tenant.

Cloud privilege escalation is mostly about diligence rather than cleverness. The patterns are knowable. The discipline is the bit that takes work. Cloud privilege escalation is mostly about diligence. The patterns are knowable and the defences are well documented. Worth the discipline to apply them consistently. Cloud security is a shared responsibility model in name and a fully owned responsibility model in practice. The configuration choices that matter live on your side of the line, regardless of how the provider markets the platform.