Azure Role Misconfigurations: How Over-Privileged Access and API Flaws Put Enterprises at Risk

Read full article here: https://www.token.security/blog/azures-role-roulette-how-over-privileged-roles-and-api-vulnerabilities-expose-enterprise-networks/?utm_source=nhimg

Token Security researchers discovered two complementary problems in Azure that, together, create a powerful identity-driven attack chain:

1. Multiple built-in Azure roles include a generic */read permission that unintentionally grants broad visibility across subscriptions and resources. Several service-specific built-in roles therefore behave like the generic Reader role—enabling discovery of code, environment metadata, and other artifacts that often contain secrets.

2. A separate Azure API implementation issue allowed retrieval of VPN pre-shared keys (PSKs) via an endpoint that was improperly exposed to GET semantics, enabling principals with read access to obtain values that should have required more restrictive permissions.

Combined, these issues allow a low-privilege principal (user, service principal, or managed identity) assigned one of the mislabeled built-in roles to discover sensitive configuration and then, in some configurations, obtain VPN PSKs. An attacker who obtains a VPN PSK can create a Site-to-Site connection or otherwise access networks that rely on that PSK, bridging cloud workloads into on-prem resources and dramatically expanding blast radius.

This report summarizes the findings, the attacker logic at a conceptual level, Microsoft’s response, and prioritized mitigations organizations should apply now.

Key findings

• Misleading role definitions: At least 10 Azure built-in roles include */read in their actions (effectively broad read access), despite names/descriptions implying scoped, service-specific permissions. Examples: Managed Applications Reader, Log Analytics Reader, Monitoring Reader, Resource Policy Contributor, and others.
• High-value discovery via read permissions: Generic read access enables discovery of automation artifacts, resource metadata, diagnostics, application code and environment variables, and pointers to sensitive backups and data stores. Those artifacts frequently contain secrets or operational context useful for escalation.
• API implementation weakness (VPN PSK): An Azure VPN Gateway API exposed a secret (Site-to-Site pre-shared key) via an endpoint that could be accessed under read semantics — enabling an escalation vector from read access to network access. Microsoft has patched this specific API and clarified required permissions.
• Attack chain risk: The combination yields a credible path from low-privilege role → discovery → secret retrieval → lateral network access. This is particularly dangerous in hybrid environments where VPNs bridge cloud and on-premises networks.

Attack chain

1. Obtain a principal (user, service principal, or managed identity) with a built-in role that contains */read.
2. Enumerate resources and artifacts to find high-value items: automation accounts, deployment scripts, storage metadata, backup locations, diagnostics, and clues to secret locations.
3. Identify exposed secrets/keys referenced in discovered resources or accessible via permissive APIs (the researched VPN PSK case was an example).
4. Use compromised credential(s) to expand access or connect to bridged networks (e.g., VPN S2S), increasing lateral movement options and access to internal systems.
5. Cover tracks by deleting logs/adjusting diagnostic settings where possible.

Note: This description is intentionally high level to inform defenders; it does not provide exploit steps.

Why this is serious

• Privilege illusions: Administrators and app owners assign service-specific roles expecting limited scope; */read undermines that expectation and increases attack surface without obvious audit signals.
• Discovery is powerful: Read-only access can still reveal secrets and configuration artifacts that enable escalation.
• Hybrid impact: VPN PSK exposure connects cloud and on-prem networks — an attacker can jump from a cloud principal to internal infrastructure.
• Scale: Built-in roles are widely used; many organizations may have inadvertently assigned one of the problematic roles across subscriptions or to third-party integrations.

Vendor response & status

• VPN PSK leak: Microsoft acknowledged the API issue and deployed a fix. Permissions were clarified so retrieving shared keys requires a dedicated action (Microsoft.Network/connections/sharedKey/action) rather than generic read privileges. Researcher received a bounty.
• Over-privileged built-in roles: Microsoft classified the misleading built-in roles as lower priority and updated documentation to clarify scope. The role definitions themselves remain unchanged at this time; customers must act defensively.

Prioritized mitigation checklist (immediate → medium → long term)

Immediate (hours → days)

1. Inventory and audit role assignments
   • Query all role assignments across management groups, subscriptions, and resource groups. Flag any principals (users, service principals, managed identities, groups) assigned the ten identified roles (and any roles that include */read).
   • Use automation to produce a prioritized list by exposure (subscription scope > resource group > single resource).
2. Restrict use of problematic built-in roles
   • Stop assigning the identified built-in roles at broad scopes. Where possible, remove them and suspend existing assignments until scopes and owners are validated.
3. Rotate and re-vault high-risk secrets
   • Treat exposed artifacts and credentials as compromised until proven otherwise. Rotate API keys, certificates, and vault secrets that could be reached from broad read access or automation artifacts.
4. Apply least-privilege scope
   • Replace broad assignments with scope-limited role assignments (resource or resource-group level) and tighten the principle of least privilege immediately.

Short term (days → weeks)

1. Create and roll out custom roles
   • Define custom roles that grant only the required actions (avoid */read). Replace risky built-in role assignments with custom roles that explicitly enumerate necessary actions.
2. Harden network boundary controls
   • For VPN gateways: ensure PSKs and S2S connections use additional controls (IP restrictions, certificate-based auth when possible), monitor for new site configurations, and require multi-party change approvals.
3. Add detection rules & monitoring
   • Implement ITDR/behavioral rules to detect unusual enumeration patterns, bulk resource listing, and atypical diagnostic/backup reads. Alert on principals performing large reads across subscriptions or multiple disparate services.
   • Monitor resource types where secrets commonly surface (automation accounts, deployment artifacts, function app settings, storage account metadata, backup vaults).
4. Audit logging and retention
   • Ensure diagnostic settings and activity logs are centrally collected and immutable (append-only), and set retention long enough for forensic investigation.

Medium/long term (weeks → months)

1. Adopt identity-centric posture management (ISPM/ITDR)
   • Deploy tools that continuously map identity graphs, highlight privilege accumulation, and correlate identity behavior across cloud/SaaS. Invest in Identity Threat Detection & Response to detect NHI misuse early.
2. Automate role-sanity checks in CI/CD
   • Integrate policy as code to gate role assignments. Prevent granting problematic built-in roles at subscription/management group scope via IaC policy checks and pre-commit hooks.
3. Periodic role & permission reviews
   • Establish quarterly reviews for role assignments and implement approval workflows for elevated role usage (JIT elevation patterns for administrative tasks).
4. Secure secret lifecycle & vaulting
   • Move keys and connection strings to managed secret stores (Key Vault, managed secret managers) with fine-grained access policies, and eliminate storing secrets in code or deployment outputs.

Detection playbook (sample rules to implement)

• Anomalous enumeration: Alert on principals issuing resource list/read operations across > N different resource types or subscriptions in short windows.
• High-value artifact access: Alert when principals read automation account runbooks, app settings, function app environment variables, or deployment source code.
• VPN config access: Alert on any access to VPN configuration endpoints or connection metadata by non-network operators.
• Role assignment drift: Alert when built-in roles known to contain */read are assigned at management group or subscription scope.
• Mass export behavior: Alert on repeated read actions that correlate with data export patterns (e.g., repeated storage container listing + downloads).

Operational guidance for cloud & security teams

• Treat read privileges as sensitive. Visibility equals power; plan accordingly.
• Use custom roles to codify what “read” means in your environment — be explicit, not generic.
• Assume secrets leak via metadata and index deployment artifacts for secret leakage.
• Harden VPN configurations and prefer certificate/radius-based authentication for S2S where possible.
• Invest in identity-first tooling that maps who an identity is, what it can do, and where it’s used—across both cloud and hybrid networks.

Final thoughts

This research exposes a crucial lesson: not all “read” rights are risk-free. Cloud providers’ built-in convenience can mask powerful capabilities. In hybrid environments, implementation quirks (such as API method semantics) can convert visibility into access. Defenders must assume that read privileges can be weaponized and treat role assignments, API access, and secret management with the same rigor as credential administration.

If you’d like help operationalizing these mitigations, Token Security provides continuous NHI discovery, identity risk graphing, ITDR detection, and automated remediation workflows that reduce the attack surface created by role sprawl and API misconfigurations. Book a demo to see how we can help secure your Azure environment and strengthen identity controls across cloud and hybrid networks.