Cloud-Wide Contamination: Chaining SSRFs for Tenant Compromise in Azure (CVE-2025-29972)

Cloud-Wide Contamination: Chaining SSRFs for Tenant Compromise in Azure (CVE-2025-29972)

Speakers: Vladimir Tokarev, Senior Vulnerability Researcher, Cyera

Conference: CODE BLUE

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

Overview

In a compelling presentation at CODE BLUE, Vladimir Tokarev, a Senior Vulnerability Researcher at Cyera (formerly with Microsoft's Azure Network Security Research team), unveiled a critical vulnerability chain designated as CVE-2025-29972. This research, conducted during his tenure at Microsoft, exposed a method to achieve cloud-wide contamination in Azure by chaining Server-Side Request Forgery (SSRF) vulnerabilities. The talk detailed how an attacker could leverage an SSRF in the Azure Storage Resource Provider (SRP) to leak Azure AD tokens, bypass critical network and service trust boundaries, and ultimately compromise other tenants' SFTP accounts, leading to a CVSS score of 9.8.

The core of the attack lies in manipulating how Azure's identity and storage services interact, specifically within the encryption scope functionality. By carefully orchestrating DNS rebinding and a novel "spray and pray for bind" cache evasion technique, Tokarev demonstrated how an attacker could redirect internal Azure service requests to their own infrastructure to steal tokens, and then redirect subsequent requests to internal Azure targets in other tenants. This sophisticated chain of exploits highlights the persistent threat of foundational web vulnerabilities like SSRF, even in highly secured cloud environments.

This talk is crucial for cloud security professionals, Azure administrators, and developers, as it dissects a real-world, high-impact vulnerability that breached fundamental Azure trust boundaries: the network trust boundary, service trust boundary, control-data plane, and critically, the tenant trust boundary. The findings underscore the importance of stringent input validation, secure logging practices, and the continuous threat of established attack vectors adapting to new cloud paradigms.

Background

▶ Watch: Critical SSRF (CVE-2025-29972) breaking Azure boundaries (2:06)

The research was conducted by Microsoft's Azure Network Security Research (ANSR) team, which typically employs a robust methodology involving static code analysis, dynamic analysis with tools like Burp Suite, and debugging to identify vulnerabilities. Once a flaw, such as an SSRF, is discovered, it is reported to MSRC (Microsoft Security Response Center), which then forwards it to the relevant Azure resource provider—in this case, the Azure Storage Resource Provider (SRP).

Azure's architecture relies heavily on the Azure Resource Manager (ARM), which acts as the frontend control plane for managing Azure resources. User requests from the Azure portal first hit ARM, which performs preliminary checks before routing them to specific resource providers like SRP. The SRP is responsible for managing various storage functionalities, including blob, queue, table, and file storage. A key concept within SRP is Encryption Scope, designed to encrypt different users' data within a single storage account using distinct keys. To retrieve the necessary metadata for these user-specific encryption keys, SRP communicates with the Microsoft Identity Resource Provider (MIRP).

Azure implements multiple layers of trust boundaries to ensure isolation and security:

1. Tenant Trust Boundary: Prevents one tenant from accessing another tenant's logic or data.
2. Control/Data Plane Boundary: Separates management operations from direct data access.
3. Service Trust Boundary: Ensures that one Azure service (e.g., SRP) cannot access data or logic of another service (e.g., Network Resource Provider) without explicit authorization.
4. Network Trust Boundary: Restricts network access within Azure, ensuring not all services can communicate freely.

The critical nature of CVE-2025-29972 stemmed from its ability to bypass these crucial boundaries, particularly the network, service, and tenant trust boundaries, by leveraging an SSRF to hit the control data plane. This made the vulnerability exceptionally severe, earning its 9.8 CVSS rating.

Key Findings

▶ Watch: Leveraging SSRF for Azure AD token leakage (10:50)

The research uncovered several key findings that collectively enabled the cross-tenant compromise:

1. SSRF in Azure Storage Resource Provider (SRP): The primary vulnerability was an SSRF within the processEncryptionScope method and related functions in SRP. This method, triggered by actions like creating or updating an encryption scope, would attempt to retrieve identity metadata from a user-controlled URL specified in the identityURL or delegatedIdentityClientSecretURL fields.
2. Azure AD Token Leakage Mechanism: The getIdentityMetadataAsync function, called by processEncryptionScope, exhibited a critical behavior:

• It first performs a GET request to the provided URL.
• If the response is a 401 Unauthorized status code and includes a WWW-Authenticate header containing authorization and resource values, SRP extracts these.
• It then generates an Azure AD token based on these extracted values.
• Finally, it sends a second request (GET or POST) to the same URL, this time including the newly generated Azure AD token in the Authorization header. This allowed an attacker to capture a legitimate Azure AD token by controlling the endpoint.

1. DNS Rebinding for Internal Target Redirection: With the ability to leak an Azure AD token, the challenge became redirecting the second request (containing the token) to an internal Azure endpoint. This was achieved using DNS rebinding. An attacker's DNS server would first resolve the malicious domain to the attacker's HTTP server (to capture the token), and then on the second lookup for the same domain, resolve it to an internal Azure IP address.
2. "Spray and Pray for Bind" DNS Cache Bypass: Azure's DNS caching mechanism, with a typical 5-minute TTL, posed a challenge to DNS rebinding. The attacker's initial GET request would cache the attacker's IP, preventing the second request from hitting the internal target. To overcome this, the "spray and pray for bind" technique was developed: continuously triggering SSRF requests at 15-second intervals. This strategy aimed to hit the precise moment when the DNS cache for the domain expired and refreshed, allowing the second request to be redirected to an internal Azure IP.
3. Cross-Tenant SFTP Password Regeneration: The complete exploit chain allowed an attacker to target another tenant's SRP instance. By supplying the target tenant's account name, resource group name, subscription ID, and username (information often publicly exposed or less securely stored than secrets), the attacker could invoke the regeneratePassword endpoint for an SFTP account. The response from this internal SRP call would contain the newly generated SSH password.
4. Plaintext Logging of SSH Passwords: A critical oversight revealed that the logIdentityMetadata function in SRP, which stores the identity metadata after processing, did not redact the SSH password from the response. This meant the plaintext SSH password was written directly into Azure's internal logs, providing a clear path for attackers to gain persistent access if they could access these logs (though this was noted as difficult due to Microsoft's strict internal controls like UBI hardware).

Technical Deep Dive

▶ Watch: "Spray and Pray for Bind" to bypass DNS cache (24:00)

The technical foundation of this attack began with the Azure Storage Resource Provider (SRP), specifically the encryption scope functionality. When a user creates or updates an encryption scope, the processEncryptionScope method is invoked. This method, as shown in pseudo-code, extracts either an identityURL or delegatedIdentityClientSecretURL from the encryption scope configuration. If these URLs are present, the method proceeds to call getIdentityMetadataAsync to retrieve identity-related information.

The getIdentityMetadataAsync function is where the Azure AD token leakage mechanism resides. Its execution flow is crucial:

1. Initial GET Request: SRP initiates an HTTP GET request to the URL specified in the encryption scope (e.g., identityURL).
2. Attacker Elicits 401: An attacker controls this URL and hosts an HTTP server that listens for incoming requests. Upon receiving the GET request, the attacker's server responds with an HTTP 401 Unauthorized status code. Crucially, this response includes a WWW-Authenticate header, formatted with Bearer authorization="<auth_value>", resource="<resource_value>". The authorization and resource values are controlled by the attacker.
3. Azure AD Token Generation: Upon receiving this specific 401 Unauthorized response, SRP, following its internal logic, extracts the authorization and resource values from the WWW-Authenticate header. It then uses these values to generate a legitimate Azure AD token. This token is scoped to the SRP service itself and based on the provided resource.
4. Second Request with Token: After generating the token, SRP makes a second request (either GET or POST) to the exact same URL as the first request. This time, the request includes the newly generated Azure AD token in its Authorization header. The attacker's server, still listening at the URL, captures this second request, thereby obtaining a valid Azure AD token.

The challenge at this point was to redirect this token-bearing request to an internal Azure endpoint, rather than back to the attacker's server. This is where DNS rebinding came into play. The attacker needed a domain (e.g., gandalf.in.lead) under their control, with an associated DNS server. The DNS server was configured to respond differently to successive queries for the same domain:

• First DNS Resolution: For the initial GET request, the DNS server would return the IP address of the attacker's HTTP server.
• Second DNS Resolution (Rebind): For the subsequent request (which would carry the Azure AD token), the DNS server would return the IP address of an internal Azure target. The speaker demonstrated a simple DNS server logic: if the query count is odd, return the attacker's IP; if even, return the target IP.

However, Azure's internal DNS infrastructure employs caching. A typical DNS cache TTL (Time To Live) of 5 minutes meant that the first resolution (to the attacker's IP) would be cached. Any subsequent requests within that 5-minute window would resolve to the attacker's IP, preventing the rebind to the internal target. To overcome this, the "spray and pray for bind" technique was devised. This involved continuously triggering the SSRF vulnerability at short intervals, specifically every 15 seconds. The rationale was that by repeatedly initiating the SSRF, one of these attempts would eventually coincide with the expiration of the DNS cache, allowing the DNS rebind to successfully redirect the token-bearing second request to the intended internal Azure target. The "winning" attempt would be the one closest to the 5-minute cache refresh mark.

While the leaked AD token was powerful, attacking arbitrary Azure services proved difficult due to scope mismatch and Azure's layered security. Azure AD tokens are scope-bound, meaning a token generated for SRP might not be valid for, say, the Network Resource Provider (NRP). Furthermore, stringent network isolation, extra validations per service/endpoint, identity constraints, and logic isolations within Azure prevented broad lateral movement. Consequently, the most viable path was an SRP-to-SRP attack, leveraging the leaked token to target another instance of SRP, potentially belonging to a different tenant.

The specific target chosen was the regeneratePassword endpoint within SRP for SFTP accounts. To exploit this, an attacker needed to know the target's account name, resource group name, subscription ID, and username. While private, these pieces of information are not considered "secrets" and might be found in less secure locations, such as public GitHub repositories or misconfigured environments. If successful, this endpoint would return an HTTP 200 OK response containing a plain JSON object with the new SSH password string.

A final critical detail emerged regarding logging. The logIdentityMetadata function, responsible for logging the metadata received from the getIdentityMetadataAsync call, used a "permissive" identityMetadata struct. This meant that new fields not explicitly defined in the original struct would still be stored. Crucially, the SSH password was not on the list of values to be redacted (which included client secret, password, token, key). As a result, the regenerated SSH password was logged in plaintext within Azure's internal systems, posing an additional risk of compromise if an attacker could gain access to these logs.

Demo / Proof of Concept

▶ Watch: Chaining SSRF to regenerate other tenant's password (28:00)

Vladimir Tokarev meticulously demonstrated the various stages of the exploit chain through a series of Proof of Concepts (PoCs), illustrating each component's functionality and the ultimate impact.

1. Basic SSRF Trigger: The initial demonstration showed the successful triggering of an SSRF from Azure. By creating an encryption scope with a malicious URL, the update operation triggered the SSRF. A webhook callback was received, originating from a Microsoft Corporation IP address, confirming the SSRF was active within the Azure environment.

1. Azure AD Token Leakage: This PoC highlighted the token leakage mechanism. The setup involved a Burp Suite proxy to initiate the request, an attacker-controlled DNS server, and an attacker-controlled HTTP server.

• The get request from SRP was directed to the attacker's HTTP server (via DNS resolution).
• The attacker's HTTP server responded with a 401 Unauthorized containing the crafted WWW-Authenticate header.
• SRP then generated an Azure AD token.
• A subsequent post request, now containing the leaked Azure AD token, was sent back to the attacker's HTTP server and successfully captured, proving the token leakage.

1. DNS Rebinding Demonstration (Initial Attempt): This PoC aimed to show DNS rebinding in action. The attacker's DNS server was configured to return the attacker's HTTP server IP for the first query and then a target IP for subsequent queries. However, the demo clearly showed that the second request never reached the intended internal target. The HTTP server only received the initial GET, because the Azure DNS cache retained the attacker's IP for the domain for approximately 5 minutes, preventing the rebind from succeeding.

1. "Spray and Pray for Bind" Success: To overcome the DNS cache, the "spray and pray for bind" technique was demonstrated. The attacker repeatedly triggered SSRF attempts at 15-second intervals. The PoC showed a series of GET and POST requests reaching the attacker's HTTP server (indicating the cache was active). After approximately 5 minutes, a specific attempt resulted in only a GET request hitting the attacker's HTTP server, with no corresponding POST. This signified success: the POST request, carrying the Azure AD token, was successfully redirected to the internal Azure target due to the DNS cache expiring and the rebind taking effect.

1. Cross-Tenant SFTP Account Takeover: The final and most impactful demonstration showcased the full exploit chain leading to cross-tenant SFTP account compromise.

• A victim user was shown uploading a GIF (of Gandalf, humorously) to their SFTP account.
• The attacker initiated the "spray and pray for bind" attack, targeting the victim's SFTP account's SRP instance with the regeneratePassword endpoint.
• Similar to the previous PoC, the attacker's HTTP server eventually received only a GET request, confirming that the POST with the AD token was successfully sent to the victim's SRP instance to regenerate the password.
• Following the attack, the victim attempted to connect to their SFTP account again but failed, demonstrating that their password had been changed without their knowledge. This confirmed the successful compromise and takeover of the SFTP account.

Defensive Implications

▶ Watch: Q&A: How users can detect or protect against such attacks (40:00)

The findings from this research provide critical insights for both Azure operators and Microsoft alike, leading to significant defensive implications.

Microsoft, upon receiving the report, implemented several key mitigations within the Azure Storage Resource Provider (SRP):

• MIRP-based URL Validations with Regex: Enhanced validation for URLs passed to the identity resolution mechanisms, likely using stricter regular expressions to prevent arbitrary external URLs.
• DNS Rebinding Mitigations: Specific measures were put in place to detect and prevent DNS rebinding attacks, although the exact technical details were not fully disclosed for security reasons.
• Caching Random Details: To hinder attacker reconnaissance and make it harder to confirm successful rebinding, SRP now caches random details rather than predictable responses, making it difficult for an attacker to determine if their "spray and pray" attempt was successful.
• Enhanced Data Redaction: Crucially, the SSH password (and likely other sensitive data) is now explicitly included in the reduction list for logging, preventing its plaintext storage in internal logs.
• Internal Monitor Enhancements: Existing internal monitoring systems on SRP were further enhanced to detect and alert on suspicious activity related to these attack vectors.

For Azure users and defenders, several key takeaways and recommendations emerge:

• Multi-Factor Authentication (MFA) is Paramount: Even if an attacker manages to leak credentials like an SSH password, MFA can significantly reduce the risk of actual account takeover. The speaker specifically noted that SFTP accounts can support MFA, and users should enable it wherever possible.
• Trust No External Input in Identity Resolution: This vulnerability chain fundamentally exploited a lack of sufficient validation on external URLs used for identity metadata resolution. Developers and architects must implement rigorous validation and sanitization for any external input, especially when it dictates network requests or identity-related operations.
• Strict Secret Redaction in Logs: The plaintext logging of SSH passwords highlighted a common but critical security oversight. All sensitive data, including passwords, client secrets, API keys, and tokens, must be meticulously redacted or encrypted before being written to any log system, internal or external. A permissive data structure that accepts new fields without explicit redaction rules is a significant risk.
• Awareness of "Old Tricks, New Targets": The talk emphasized that the underlying techniques—SSRF, DNS rebinding, and cache poisoning—are not new. However, their application in a complex, highly distributed cloud environment like Azure demonstrates their continued potency. Defenders must remain vigilant against these foundational attack vectors, understanding how they can be adapted to modern infrastructures.
• Leverage Cloud Provider's Security Features: While this vulnerability was significant, the speaker acknowledged Azure's extensive layered security, including network isolation, software-defined networks (SDNs), strict firewall rules, pervasive HTTPS/TLS, telemetry and log access controls (e.g., UBI hardware for log access), and compute isolation (Hyper-V). These layers make a "total win" or widespread compromise extremely difficult, highlighting the value of these inherent cloud security controls.
• Stay Informed on Cloud Provider Actions: Microsoft actively scans for and mitigates such attack behaviors on its network. Users should trust that the cloud provider is working to secure the underlying infrastructure, but also understand their shared responsibility in securing their own configurations and applications.

Key Takeaways

• SSRF in Cloud Environments Breaks Boundaries: A seemingly common Server-Side Request Forgery (SSRF) vulnerability, when strategically exploited, can shatter fundamental cloud trust boundaries (network, service, control-data plane, and tenant isolation), leading to critical cross-tenant compromise.
• Chaining Simple Flaws Leads to High Impact: The full attack vector was a sophisticated chain of relatively simple vulnerabilities: an SSRF, Azure AD token leakage, DNS rebinding, and a DNS cache bypass technique. This demonstrates that attackers can combine known methods to achieve high-impact results in complex cloud architectures.
• Sensitive Data Must Be Redacted from Logs: The plaintext logging of generated SSH passwords was a critical vulnerability. All sensitive information, regardless of its perceived "secrecy" or source, must be rigorously redacted, encrypted, or otherwise protected before being written to any log system.
• DNS Rebinding Remains a Potent Threat: Despite being an "old trick," DNS rebinding proved highly effective in redirecting internal service-to-service communication within Azure, showcasing its continued relevance as an attack vector against modern cloud infrastructure.
• Multi-Factor Authentication (MFA) is Non-Negotiable: Even when core credentials are compromised (e.g., an SSH password leaked), MFA provides a crucial additional layer of defense, significantly hindering an attacker's ability to gain access.
• Cloud Provider's Layered Security is Crucial but Not Absolute: Azure's extensive security controls (network isolation, HTTPS, host security, access controls) make widespread compromise challenging. However, this research proves that targeted, chained attacks against specific services can still bypass these layers and achieve significant impact.

About the Speaker(s)

Vladimir Tokarev is a Senior Vulnerability Researcher at Cyera. Prior to joining Cyera, he conducted the research presented in this talk during his tenure at Microsoft, where he was a member of the Azure Network Security Research (ANSR) team. His expertise lies in vulnerability research across a broad spectrum of platforms, including Windows, Linux, IoT (Internet of Things), and Azure cloud environments. His work focuses on discovering and analyzing security flaws that can impact critical systems and services.