Azure role misconfiguration exposes identity and network access

At a glance

What this is: This is an analysis of Azure RBAC roles and an API weakness that together can turn weak read access into exposure of cloud resources and VPN connectivity.

Why it matters: IAM teams should care because role labels, scope choices, and API permissions can silently expand the blast radius of otherwise low-trust identities across cloud and network boundaries.

By the numbers:

• Token Security found more than 400 built-in Azure roles that can be assigned across broad and narrow scopes.
• Token Security identified 10 built-in roles with an unnecessary */read permission that effectively included Reader-level access.
• The reporter received a US$7,500 bounty award for the VPN PSK issue.

Context

Azure RBAC is the permissions layer that decides what a principal can do at a given scope. In this case, the governance gap is not just over-assignment by customers, but misleading built-in role definitions that expose more than their names imply, plus an API issue that can surface VPN pre-shared keys.

For identity teams, the risk is structural. A low-trust Azure role can become a discovery mechanism for secrets, topology, and network paths, which means IAM and network access are no longer separable governance domains. The attack path starts with overbroad read authority and ends with access to internal systems that should have remained outside the original role boundary.

This is typical of cloud environments where generic built-in roles are used for convenience and later assumed to be harmless because they appear read-only. The article shows that assumption is unsafe when the read path includes sensitive metadata, keys, and network configuration.

Key questions

Q: What breaks when Azure built-in roles grant more read access than their descriptions imply?

A: Least privilege breaks because administrators assign roles based on the label instead of the permission set. A role that looks narrow can still expose resource metadata, secrets, diagnostics, and network paths, which turns a supposedly low-risk identity into a discovery foothold for later compromise.

Q: Why do broad Azure read permissions increase the risk of network compromise?

A: Because read access can reveal the information an attacker needs to pivot, including role assignments, deployment artifacts, VPN settings, and connected-resource details. Once that information is exposed, the identity no longer just observes the environment. It helps map and unlock the next access path.

Q: How should teams decide whether to use a built-in role or a custom Azure role?

A: Use a built-in role only when its full permission set matches the task and its scope can be tightly constrained. If the role grants wildcard read access, reaches unrelated services, or exposes keys and configuration data, a custom role is the safer governance choice.

Q: What should IAM teams do when cloud roles can expose VPN credentials?

A: They should treat VPN credential retrieval as a privileged function, separate it from ordinary read access, and review who can reach it through any API or role path. The key control question is not who can see the gateway, but who can obtain the secret that opens it.

Technical breakdown

How Azure RBAC scope can overstate real access

Azure RBAC assigns permissions through role definition, principal, and scope. On paper, a role such as Reader looks limited because it is read-only, but the actual effect depends on whether the permissions are generic, service-specific, or both. When a role includes wildcard read access, the effective blast radius can extend far beyond the service named in the role description. That matters because operators tend to reason from the role label, while attackers reason from the permission list. The mismatch between intent and effective access is where misuse begins.

Practical implication: review role definitions, not just role names, before assigning broad Azure access.

Why a read-only role can still expose secrets and network paths

Read permissions are not all equal. In Azure, a principal with broad resource read access can enumerate metadata, role assignments, diagnostics, and resource relationships, which helps an attacker map where sensitive systems live and how they connect. If the same permission surface reaches deployment artifacts, scripts, or service settings, it can also expose credentials and environment variables. The security problem is not write access alone. Discovery of secrets and infrastructure layout can be enough to set up later privilege escalation or network access.

Practical implication: treat broad read access as a discovery and secrets-exposure risk, not merely an information-only permission.

How VPN pre-shared key exposure turns identity misuse into network access

The VPN weakness in the article matters because a pre-shared key is effectively a shared network credential. If an attacker can obtain it through an Azure API path, a low-value identity can pivot from cloud visibility into site-to-site VPN access and reach internal networks connected to the gateway. That collapse matters because it breaks the assumption that identity controls stop at the cloud control plane. Once a VPN secret is exposed, the trust boundary moves from Azure RBAC into downstream network access.

Practical implication: protect VPN secrets as high-value credentials and remove any API path that can reveal them to broad readers.

Threat narrative

Attacker objective: The attacker wants to move from a low-trust Azure identity into broader infrastructure access, including connected internal networks and cloud assets.

1. Entry occurs when an attacker gains a weak Azure identity with read-level access or one of the over-privileged built-in roles.
2. Credential access follows when broad read permissions reveal VPN gateway material or other sensitive configuration data that should not be visible to that principal.
3. Escalation happens when the attacker uses the leaked VPN pre-shared key to authenticate to the site-to-site connection and reach connected environments.
4. Impact is achieved when the attacker gains access to internal cloud assets, on-premises networks, and other resources behind the same VPN boundary.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Role descriptions are not governance evidence: This article shows that Azure built-in role labels can understate real permission surfaces, which means administrators are making access decisions from intent language rather than from effective authorisation. That is not a cosmetic problem. It is a governance failure because identity teams often certify roles by name and assume service-specific framing means service-specific scope. The practitioner lesson is to validate the actual action set before any role is treated as safe.

Cloud read access is a discovery privilege: Broad read permissions in a cloud control plane are often treated as low risk because they do not directly change resources. In practice, they can expose secrets, role relationships, diagnostics, and network topology, which makes them a precondition for follow-on compromise. The article demonstrates that discovery itself is a security outcome. Teams should stop classifying read-only roles as benign when they can surface the map that later attacks use.

Identity blast radius now includes network credentials: The most important feature of this case is not the role misconfiguration alone, but the way it reaches a VPN pre-shared key. That creates an identity blast radius where a cloud authorisation issue becomes a network access issue. The implication is that role governance and network credential governance cannot live in separate operational silos.

Custom roles are a control boundary, not a convenience feature: The article makes clear that generic built-in roles are attractive because they reduce administrative effort, but convenience is not a control objective. Where the built-ins are overly broad, custom roles and narrower scopes become the only defensible way to preserve least privilege. Practitioners should treat built-in role drift as a standing governance risk, not as a one-off exception.

Over-privileged read paths create silent trust debt: This research exposes a recurring pattern where documentation, defaults, and actual permission behaviour diverge. That divergence creates trust debt because every assignment based on the description rather than the definition carries hidden exposure. The field should recognise this as a broader identity governance issue, not just an Azure-specific bug report. The practical conclusion is to audit trust assumptions wherever platform defaults define access too loosely.

What this signals

Azure role roulette is a governance pattern, not a single misconfiguration: When platform-provided roles blur the line between descriptive intent and actual permission set, IAM teams inherit hidden exposure. The practical response is to stop assuming that a built-in role is least privilege just because its label sounds narrow.

Network credentials now need identity governance. If a cloud API can surface a VPN pre-shared key, then the control problem spans IAM, secrets governance, and remote access, not just one Azure permission edge.

Role review programmes should check for trust debt in the permission model itself. Where wildcard read access is present, the question is not whether the role can make changes, but what sensitive state it can enumerate and hand to an attacker.

For practitioners

• Audit built-in role definitions before assignment Compare the documented description with the actual Azure permissions list, especially for roles that include wildcard read access or service-specific extras that expand visibility unexpectedly.
• Constrain role scope to the smallest viable resource boundary Prefer resource group or single-resource assignment over subscription-wide or management-group-wide scope when the principal only needs limited visibility.
• Replace risky built-ins with custom roles Create custom roles that include only the specific actions required for the task, and remove any unnecessary */read permissions from identities that do not need broad discovery.
• Treat VPN secrets as high-value credentials Review who can retrieve VPN gateway shared keys, then restrict that path to narrowly controlled administrative roles and verify it is not reachable from broad reader-type access.

Key takeaways

• Azure built-in roles can be broader than their descriptions suggest, which makes the label itself an unreliable signal of least privilege.
• The article shows that read-level access can still expose secrets, topology, and VPN credentials, creating a path from discovery to network compromise.
• The practical fix is tighter role scope, custom roles where needed, and separate governance for credentials that bridge cloud and on-premises access.

Key terms

• Azure Role Definition: An Azure role definition is the permission template that determines what actions a role can perform. In practice, the definition matters more than the marketing name of the role, because wildcard actions or service overlaps can expand access far beyond what the description implies.
• Role Assignment: Role assignment is the process of linking a user account to one or more predefined roles. Once assigned, the user inherits the permissions carried by those roles. In identity governance, this is a core control for keeping access consistent, auditable, and easier to provision or revoke.
• Wildcard Read Access: Wildcard read access is a permission pattern that allows a principal to read many resource types or endpoints with one broad rule. It is often treated as harmless, but it can expose configuration data, secrets, and dependency maps that attackers use for later compromise.
• VPN Pre-Shared Key: A VPN pre-shared key is a shared secret used to authenticate site-to-site VPN connections. If exposed through a control plane or overbroad role, it can become a direct path from identity misuse into internal network access, making it a high-value credential rather than a routine setting.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.