Uncovering Hidden Threats: The Risks of Dangling Issuers in Federated Credentials

Uncovering Hidden Threats: The Risks of Dangling Issuers in Federated Credentials

Speakers: Gautam Peri, Senior Security Engineer, Microsoft

Conference: Cloud Village

YouTube: https://www.youtube.com/watch?v=lBlqhp1xv90

Overview

Gautam Peri, a Senior Security Engineer at Microsoft, delivered a highly technical talk at Cloud Village titled "Uncovering Hidden Threats: The Risks of Dangling Issuers in Federated Credentials." This presentation sheds light on a critical, yet often overlooked, vulnerability within modern cloud identity systems, specifically focusing on Microsoft Entra ID (formerly Azure Active Directory). The core of the research revolves around dangling issuers, which are unregistered or deleted domains and subdomains that are mistakenly configured as trusted OpenID Connect (OIDC) issuers within federated identity credentials.

The talk meticulously details how an attacker can exploit these dangling issuers to impersonate legitimate identities, forge access tokens, and gain unauthorized access to cloud resources. This vulnerability represents a significant hidden backdoor, allowing for stealthy privilege escalation and lateral movement across cloud environments. Peri’s work highlights that while Workload Identity Federation (WIF) aims to eliminate the risks associated with managing traditional secrets like API keys and certificates, it introduces a new attack surface rooted in the trust relationships defined by OIDC issuers.

The implications of this research are profound for organizations heavily relying on cloud services and federated identity. The ability for an attacker to take over a forgotten or deleted domain and then use it to masquerade as a trusted identity provider poses a direct threat to the integrity and security of cloud deployments. Peri not only dissects the technical mechanisms of this attack but also provides actionable strategies for discovery, prevention, and mitigation, making this talk essential viewing for security professionals, cloud architects, and developers working with federated identity in any cloud environment.

Background

▶ Watch: Speaker introduction and conference experience (0:00)

The evolution of identity management in the cloud has been a journey away from static, shared secrets towards more dynamic and secure methods. Initially, cloud applications relied on traditional credentials like API keys, shared secrets, and certificates. However, these methods presented significant operational overhead due to rotation requirements and inherent security risks from potential leaks. The advent of OAuth and OpenID Connect (OIDC) brought about a paradigm shift, enabling token-based authentication and authorization flows that improved security and manageability. Cloud providers subsequently integrated these concepts into their Identity and Access Management (IAM) services, introducing features like managed identities and IMDS (Instance Metadata Service) to provide identities to cloud resources based on Role-Based Access Control (RBAC).

The rise of cloud-native environments, particularly Kubernetes, introduced a new "identity crisis." Workloads running in Kubernetes clusters often need to access cloud resources (e.g., Azure Storage, Key Vaults). Reverting to shared secrets for these workloads would negate the progress made in identity security. To address this, cloud providers developed Workload Identity Federation (WIF), which leverages OIDC to allow external workloads to use their existing identities to access cloud resources without needing to manage secrets. Google was an early adopter, with AWS and Azure (Entra ID) subsequently implementing their versions.

In Entra ID, WIF is implemented through Federated Identity Credentials (FICs). These are a new type of credential that establishes a trust relationship between an external identity provider (IdP) and Entra ID. For example, an Azure DevOps pipeline or a Kubernetes pod can obtain a federated token from its own OIDC issuer, which Entra ID then exchanges for an Azure access token after validating the federated token's signature and claims. This process eliminates the need to store client secrets or certificates within the workload itself, streamlining credential management and reducing the attack surface related to secret leakage.

Gautam Peri's research was inspired by prior work on dangling reply URLs in Entra ID and techniques for controlling Security Token Services (STS). He connected the dots, realizing that if a domain associated with a trusted OIDC issuer could become "dangling" (unregistered or deleted), an attacker could take control of that domain. By then hosting a malicious OIDC configuration and public keys, the attacker could effectively impersonate the original issuer, tricking Entra ID into issuing access tokens for the associated identity. This insight formed the basis of his investigation into the risks of dangling issuers, extending the concept of domain takeover to the critical realm of federated identity credentials.

Key Findings

▶ Watch: Overview of talk topics and technical prerequisites (4:00)

The central discovery of Gautam Peri's talk is the critical vulnerability posed by dangling issuers within federated identity credentials in Microsoft Entra ID. This vulnerability arises when a domain or subdomain configured as a trusted OpenID Connect (OIDC) issuer for Federated Identity Credentials (FICs) becomes available for takeover by an attacker. This can happen if the domain is unregistered, expires, or if a cloud service subdomain is deleted and subsequently becomes reclaimable.

Peri identified two primary scenarios where dangling issuers manifest:

1. Custom Domain Takeover: Organizations often configure custom domains as trusted OIDC issuers for their applications or services. If such a custom domain (e.g., cloud.secure-sts.com) is allowed to expire or is intentionally deregistered without updating the federated credential configuration in Entra ID, an attacker can register that domain. Once registered, the attacker can host a malicious OIDC discovery document (.well-known/openid-configuration) and a JSON Web Key Set (JWKS) containing their own public keys on the newly acquired domain.

1. Cloud Service Subdomain Takeover: Cloud services often provide subdomains for hosting static content or applications (e.g., Azure Storage static websites, Azure App Service). Developers might configure these subdomains as trusted OIDC issuers. If the underlying cloud resource (e.g., the Azure Storage account hosting the static website) is deleted, its subdomain might become available for re-provisioning by any user. An attacker can then claim this subdomain, enable static website hosting, and upload their own OIDC metadata and JWKS files to impersonate the original issuer. Peri specifically highlighted his discovery of certain Azure Storage static website suffixes, such as .z13.web.core.windows.net, and their mapping to Azure regions, which were not publicly documented, demonstrating how an attacker could identify and target such subdomains.

The attack flow is remarkably stealthy and effective:

1. An attacker identifies a dangling issuer configured in an Entra ID federated credential.
2. The attacker registers/claims the dangling domain or re-provisions the cloud service subdomain.
3. On the controlled domain/subdomain, the attacker hosts a malicious OIDC configuration, including their own JWKS URI pointing to public keys they control.
4. The attacker then crafts a JSON Web Token (JWT), acting as a client assertion, signed with their corresponding private key, and sends it to Entra ID's token endpoint as part of a client credential flow request. The JWT's iss (issuer) claim matches the dangling issuer's URL.
5. Entra ID, trusting the configured issuer, attempts to validate the incoming JWT. It fetches the OIDC metadata from the attacker-controlled URL, retrieves the attacker's public keys from the JWKS URI, and successfully validates the JWT's signature.
6. Believing the assertion to be from a legitimate issuer, Entra ID issues an access token to the attacker, granting them the permissions associated with the compromised federated identity.

The impact of this vulnerability is severe:

• Identity Impersonation: Attackers can fully impersonate the identity associated with the federated credential.
• Privilege Escalation and Lateral Movement: Depending on the permissions granted to the compromised identity, attackers can escalate privileges, access sensitive Azure resources (e.g., Key Vaults, storage accounts, Kubernetes clusters), and move laterally within the Azure environment.
• Cross-Cloud Access: In scenarios where federated credentials are used for cross-cloud configurations, this attack could potentially enable movement between different cloud providers.
• Stealthy Attack: The attack occurs at the identity validation layer, making it difficult for traditional security monitoring (e.g., network logs, endpoint detection) to detect, as it appears as a legitimate token exchange.

This research underscores that while WIF enhances security by eliminating static secrets, it introduces a new class of identity-based vulnerabilities that require diligent attention to domain ownership, configuration hygiene, and continuous auditing.

Technical Deep Dive

▶ Watch: Tracing the evolution of identity in cloud environments (4:50)

The technical foundation of the dangling issuer vulnerability lies deeply within the Workload Identity Federation (WIF) mechanism and the OpenID Connect (OIDC) protocol, as implemented in Microsoft Entra ID. WIF aims to provide identities for workloads (such as CI/CD pipelines, containerized applications, or serverless functions) to access Azure resources without the need for traditional secrets like client secrets or certificates. This is achieved through Federated Identity Credentials (FICs).

A FIC establishes a trust relationship between an external identity provider (IdP) and Entra ID. When a workload needs to access an Azure resource, it first obtains a federated token from its own external IdP (e.g., a Kubernetes OIDC issuer, GitHub Actions OIDC). This federated token is typically a JSON Web Token (JWT). The workload then presents this federated token to Entra ID's token endpoint to exchange it for an Azure access token.

The process of token exchange in Entra ID, specifically using the client credential flow with FICs, involves several critical steps:

1. Workload Client Assertion: The external workload constructs a JWT, known as a client assertion. This JWT contains claims such as iss (issuer, identifying the external IdP), aud (audience, typically Entra ID's token endpoint), and other relevant information. Crucially, this JWT is signed by the private key of the external IdP.
2. Request to Entra ID: The workload sends a POST request to Entra ID's token endpoint, including the client_id of the registered application or managed identity and the client_assertion (the signed JWT).
3. Entra ID Validation - OIDC Discovery: Upon receiving this request, Entra ID identifies the issuer URL specified in the federated credential configuration for the given client_id. To validate the incoming client_assertion, Entra ID needs the public keys of the external IdP. It obtains these by first fetching the OIDC discovery document from the issuer URL at the standard endpoint: [issuer_URL]/.well-known/openid-configuration.
4. JWKS Retrieval: The OIDC discovery document is a JSON file that contains various metadata about the IdP, including the jwks_uri field. This jwks_uri points to another endpoint where the IdP's public keys (in JWKS format) are hosted. Entra ID then fetches these public keys from the specified jwks_uri.
5. Signature Verification: With the public keys in hand, Entra ID verifies the digital signature of the client_assertion JWT. It also checks other claims within the JWT, such as the iss and aud claims, to ensure they match the expected values configured for the federated credential.
6. Access Token Issuance: If all validations pass, Entra ID trusts that the request originated from the legitimate external IdP and issues an Azure access token to the workload. This access token can then be used to access Azure resources according to the permissions assigned to the associated application registration or managed identity.

The dangling issuer vulnerability exploits steps 3 and 4 of this flow. If the issuer URL configured in Entra ID's federated credential points to a domain or subdomain that an attacker can control, the attacker can manipulate this validation process.

• App Registrations: For applications registered in Entra ID, developers can configure FICs directly, specifying a custom issuer URL. If this custom domain becomes unregistered or expires, an attacker can purchase and register it.
• User-Assigned Managed Identities: Managed identities, particularly user-assigned ones, can also have FICs configured. These might be linked to cloud service subdomains, such as those provided by Azure Storage for static website hosting (e.g., *.web.core.windows.net). If the underlying storage account is deleted, its unique subdomain becomes available for recreation.

In either scenario, once the attacker controls the issuer URL, they can:

1. Host Malicious OIDC Metadata: Set up a web server (or re-provision the cloud service) at the controlled issuer URL.
2. Create .well-known/openid-configuration: Host a JSON document at /.well-known/openid-configuration that specifies the attacker's own jwks_uri.
3. Generate JWKS: Create a JWKS file containing the public key corresponding to an attacker-controlled private key.
4. Craft Signed Assertion: Generate a JWT (client assertion) with an iss claim matching the now-controlled dangling issuer, and sign it with their private key.
5. Initiate Token Exchange: Send this signed client assertion to Entra ID.

When Entra ID attempts validation, it will fetch the OIDC metadata and JWKS from the attacker's controlled domain. Since the attacker controls the private key used to sign the assertion and provides the corresponding public key via the JWKS, Entra ID will successfully validate the signature. This leads to Entra ID mistakenly issuing an access token to the attacker, effectively granting them the identity's permissions.

Peri's additional finding regarding Azure Storage static website suffixes (e.g., z13, z12, z14 in *.z13.web.core.windows.net) highlights a specific vector for cloud service subdomain takeovers. By systematically creating storage accounts across different regions and enabling static website hosting, he mapped these suffixes to their respective regions. This knowledge can aid attackers in identifying potential dangling storage account subdomains if they know the region where a deleted resource was located, further demonstrating the practical exploitability of this vulnerability.

Demo / Proof of Concept

▶ Watch: Introduction and common scenario for Workload Identity Federation (6:30)

Gautam Peri presented two compelling proofs of concept (PoCs) to illustrate the dangling issuer attack, demonstrating its feasibility and impact in real-world scenarios. Both demos followed the core attack pattern: taking over a dangling issuer, hosting malicious OIDC metadata, and then using a custom tool to obtain access tokens from Entra ID.

The first demonstration focused on a custom domain takeover.

1. Scenario Setup: A federated credential was configured in an Entra ID app registration with a custom domain, cloud.secure-sts.com, as the trusted issuer. This domain was then allowed to become available for registration.
2. Attacker Control: Peri, acting as an attacker, registered cloud.secure-sts.com. He then utilized Sleddorf, a Microsoft open-source tool for capturing out-of-band interactions (similar to Burp Collaborator), to host the necessary OIDC discovery document (.well-known/openid-configuration) and the JWKS URI containing the attacker's public keys. Sleddorf's advanced features, such as returning specific responses based on reject patterns, were instrumental in this setup.
3. Token Exchange: A custom token exchange tool, developed by Peri specifically for the conference, was used to craft and sign a client assertion JWT with the attacker's private key. This tool then sent a client credential flow request to Entra ID, presenting the forged assertion.
4. Validation and Access: The demo video clearly showed Entra ID making out-of-band requests to cloud.secure-sts.com (captured by Sleddorf) to fetch the OIDC metadata and JWKS. Since the public keys provided by the attacker's Sleddorf instance matched the private key used to sign the assertion, Entra ID successfully validated the token and issued an access token.
5. Post-Exploitation: With the acquired access token, Peri demonstrated using the Azure CLI (az account get-access-token --resource https://management.azure.com/.default) to list all resources within the associated Azure subscription, confirming full impersonation of the federated identity. Screenshots further depicted the decoded signed assertion (with iss: cloud.secure-sts.com) and the successful resource listing.

The second demonstration illustrated a cloud service subdomain takeover, specifically using an Azure Storage static website.

1. Scenario Setup: A user-assigned managed identity was configured with a federated credential, and its issuer URL pointed to an Azure Storage static website subdomain (e.g., cloudsecurity.z13ecocode.windows.net). This storage account was then deleted, making its subdomain available.
2. Attacker Control: The attacker (Peri) re-provisioned an Azure Storage account and claimed the previously used subdomain. He then enabled static website hosting on this new storage account and uploaded the malicious OIDC discovery document (.well-known/openid-configuration) and JWKS files to the blob storage, making them publicly accessible via the static website endpoint.
3. Token Exchange: Similar to the first demo, the custom token exchange tool was configured with the new issuer URL. It generated a signed client assertion using the attacker's private key and sent the request to Entra ID.
4. Validation and Access: In this case, Entra ID fetched the OIDC metadata and JWKS directly from the attacker-controlled Azure Storage static website. Upon successful validation, an access token was issued.
5. Post-Exploitation: Peri showcased how this access token was then used to dump the contents of an Azure Key Vault that the compromised managed identity had access to. A quick snippet of the Key Vault dump was presented, unequivocally proving the successful compromise and access to sensitive data.

These live demonstrations provided concrete evidence of the dangling issuer vulnerability, highlighting its effectiveness across different types of issuer configurations and its potential for significant impact, ranging from listing resources to exfiltrating sensitive secrets from services like Key Vault. The use of custom tools and specific cloud services like Sleddorf and Azure Storage made the PoCs highly relevant and actionable for the audience.

Defensive Implications

▶ Watch: Highlighting the problems with traditional secrets and certificates (7:45)

The discovery of dangling issuers in federated credentials presents significant challenges for cloud security, but also offers clear avenues for defense. Organizations must adopt a proactive and continuous approach to mitigate this stealthy threat.

Discovery Strategies

The first step in defense is identifying existing dangling issuers within an Entra ID tenant:

• API-Based Scanning: Entra ID provides APIs to list federated credentials.
• For App Registrations: The applications API can be queried to list all federated credentials. This requires specific permissions such as Application.Read.All or Application.ReadWrite.All.
• For User-Assigned Managed Identities: A separate API exists to enumerate federated credentials linked to managed identities.
• Automated Scripting: Security teams can leverage scripting languages (e.g., PowerShell, Python) with the Azure SDK or Azure CLI to programmatically fetch all federated credential configurations. Peri suggested that even an LLM could assist in generating such scripts.
• Domain Ownership Verification: Once all configured issuer URLs are extracted, each one must be rigorously checked for active ownership. This involves:
• WHOIS lookups for custom domains to ensure they are registered to the organization and not expired.
• Cloud resource checks for cloud service subdomains (e.g., Azure Storage static websites) to confirm the underlying resource still exists and is owned by the organization. Tools that identify available subdomains or perform subdomain takeovers can be adapted to identify potentially dangling ones.
• Continuous Auditing: Establishing a routine audit process for federated credentials is crucial. This ensures that new configurations are reviewed and that existing ones remain valid over time.

Prevention Strategies

Preventing the creation of dangling issuers is the most effective defense:

• Azure Policy Enforcement: For User-Assigned Managed Identities, Azure Policy can be used to enforce restrictions on the issuer URLs that can be configured. Policies can define an allow list of approved issuer domains, preventing developers from adding arbitrary or unverified URLs. Peri demonstrated a policy preventing the addition of a non-allowlisted issuer URL. It's important to note that this specific policy capability is currently limited to managed identities and might not directly apply to app registrations.
• Conditional Access Policies: For App Registrations, while direct policy enforcement on issuer URLs might be less granular, Conditional Access Policies can be explored to add additional layers of security. These policies could, for example, restrict token issuance based on network location or device compliance for identities associated with federated credentials, adding friction to an attacker's attempt even if they obtain a token.
• Strict Configuration Review: Implement mandatory security reviews for all new or modified federated credential configurations, especially those involving custom domains or external IdPs.

Mitigation Strategies

Should a dangling issuer be discovered, immediate mitigation is required:

• Limit Issuers to Trusted Ones: The most fundamental mitigation is to ensure that federated credentials only trust explicitly verified and actively owned issuer URLs. Arbitrary or temporary URLs should never be used in production configurations.
• Verify Domain Ownership Continuously: Integrate domain ownership verification into regular security and operational workflows. If a domain is configured as an issuer, its ownership status must be continuously monitored. If a domain is no longer needed, the federated credential configuration referencing it must be immediately removed or updated before the domain is allowed to expire or be deleted.
• Continuous Auditing and Cleanup: Regularly audit all federated credentials. Any configurations referencing expired domains, deleted cloud resources, or unverified external IdPs must be promptly removed or updated. This "cleanup" prevents an attacker from taking over a stale configuration.
• Enforce Allow Lists and Policies: As mentioned in prevention, enforce allow lists for issuer URLs where possible. This provides a strong control mechanism.

By combining robust discovery, proactive prevention through policy, and diligent mitigation strategies, organizations can significantly reduce their exposure to the critical threat posed by dangling issuers in their federated identity landscape. The stealthy nature of these attacks necessitates a shift towards identity-centric security monitoring and validation.

Key Takeaways

• Workload Identity Federation (WIF) introduces a new attack surface: While WIF effectively eliminates the need for managing static secrets by leveraging OpenID Connect (OIDC), it shifts the security focus to the integrity of trusted issuer configurations.
• Dangling issuers are a critical, stealthy vulnerability: Unregistered, expired, or deleted domains/subdomains configured as trusted OIDC issuers in Federated Identity Credentials (FICs) can be taken over by attackers. This creates a hidden backdoor that is hard to detect with traditional security tools.
• Attackers can impersonate identities and gain full access: By controlling a dangling issuer, attackers can host malicious OIDC metadata, forge JSON Web Tokens (JWTs), and trick Entra ID into issuing valid access tokens, leading to impersonation, privilege escalation, and lateral movement within cloud environments.
• Two primary exploit vectors: The vulnerability applies to both custom domains configured in App Registrations and cloud service subdomains (like Azure Storage static websites) configured in User-Assigned Managed Identities.
• Proactive discovery and continuous auditing are essential: Organizations must actively scan for and identify all configured federated issuers, continuously verify their ownership, and regularly audit and clean up any stale or unowned configurations.
• Prevention and mitigation strategies are available but require diligence: Implementing Azure Policies to allow-list trusted issuers (for Managed Identities), enforcing strict configuration reviews, and maintaining continuous domain ownership verification are crucial to prevent and mitigate these attacks.

About the Speaker(s)

Gautam Peri is a Senior Security Engineer at Microsoft, where he works on the "Serpent" team, focusing on pentesting. His talk at Cloud Village marked his debut as a speaker at Defcon, although he previously contributed to the conference by giving a workshop on Snyk last year and working on authoring security rules. Peri has also shared his expertise at other events, including the OASP Boston application security conference. He is active on social media, using the alias "Hawkeye dev" on Twitter and can be reached on LinkedIn, demonstrating his engagement with the broader security community. His research into federated credentials highlights his dedication to uncovering and addressing complex security challenges in cloud environments.