Security researchers have uncovered misconfigurations and API vulnerabilities in Microsoft Azure that could expose critical secrets, including VPN keys, and grant over-privileged access through built-in roles.
These issues, if exploited, could let attackers with minimal permissions pivot from read-only accounts to accessing internal cloud and on-premises infrastructure, establishing a concerning new attack chain in enterprise cloud environments.
Misconfigured Azure Built-In Roles
Azure’s native RBAC (Role-Based Access Control) model is designed to delegate permissions through “roles” with a specific set of allowed actions granted over defined “scopes.”
Ideally, granular service-specific roles help minimize risk by granting only needed permissions, while generic roles, like “Reader” or “Contributor,” apply permissions broadly across resources.
However, researchers found that several supposedly service-specific built-in roles quietly include the wildcard “*/read” permission.
According to the Report, this permission, intended for generic Reader roles, actually grants read access to all resources within a given scope far beyond what role descriptions suggest.
For example, the “Managed Applications Reader” is described as granting access only to managed app resources and JIT requests.
In practice, it also grants the “*/read” permission, inheriting the same resource-wide visibility as the broader Reader role.
This over-assignment of permissions is not isolated: at least ten built-in roles, including “Log Analytics Reader” and “Monitoring Contributor,” similarly expose wide-reaching read access, misleading administrators into assigning more privilege than intended.
Researchers demonstrated that these over-privileged roles allow users to enumerate sensitive infrastructure metadata, hunt for credentials in automation scripts, assess network configurations, and even map out privilege escalation routes by reading role assignments.
The risk is pervasive because these roles are assigned not only to users, but also to service principals, managed identities, and groups.
API Design Flaw Leads to VPN Key Exposure
The problem is compounded by an Azure API vulnerability. Azure’s permissions are enforced in part by HTTP method: “GET” requests are allowed for read actions, while sensitive secret-retrieval operations (such as listing storage or database keys) are typically implemented as “POST” requests, and thus protected.
However, an oversight by Azure developers led to an API endpoint for retrieving VPN Gateway pre-shared keys (PSKs) to be implemented with a GET request instead of POST.
This flaw meant that anyone granted an over-privileged Reader-equivalent role could not only discover internal cloud information, but also directly extract the VPN PSK.
Because the Site-to-Site connection type in Azure VPN Gateway requires only this key, an attacker could use it to gain a foothold in connected on-premises networks drastically widening the potential impact of a compromised account.
Microsoft initially classified the overly broad roles issue as low severity and declined to fix it, instead updating documentation to clarify the risk.
However, the VPN PSK leak was acknowledged as a significant threat and fixed, requiring a more restrictive permission to access the secret.
To mitigate these risks, security professionals are urged to audit their use of built-in Azure roles and avoid assigning any of the identified over-privileged roles.
Instead, organizations should create custom roles with tailored permissions and apply them at the narrowest possible scope.
Since Microsoft has not addressed the role misconfiguration beyond documentation, ongoing vigilance and proactive permission management are essential for organizations operating in Azure.
Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant updates
