Azure RBAC over-privilege and VPN key leakage: what changes?

TL;DR: Azure built-in roles can grant broader read access than their descriptions suggest, and an Azure API flaw can leak VPN keys, creating a chain from a weak identity to cloud and on-premises access, according to Token Security researchers. The trust boundary here is the role definition itself, not just the attacker’s foothold.

Editorial analysis by NHI Mgmt Group, based on content published by Token Security: “Azure's Role Roulette: How Over-Privileged Roles and API Vulnerabilities Expose Enterprise Networks”.

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.

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.

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.

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.

Practitioner guidance

• 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.

Bottom line: Azure built-in roles can be broader than their descriptions suggest, which makes the label itself an unreliable signal of least privilege.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →