Keypoints
- Vulnerability: Azure multi-tenant apps can list redirect URIs that reference subdomains the organization no longer controls, enabling takeover.
- Impact: An attacker controlling the redirect URI can intercept OAuth 2.0 authorization codes and obtain access/refresh tokens to act as users.
- Attack vector: Threat actors register the orphaned subdomain in their tenant (e.g., Azure App Service or Traffic Manager) and deploy code to capture codes.
- Typical lure: The attacker sends a Microsoft OAuth link with the compromised redirect_uri/replyUrl to a target (spearphishing link) to harvest the code.
- Detection steps: Enumerate multi-tenant apps, extract reply/redirect URLs, strip schemes/ports to get FQDNs, and perform DNS A lookups to find unregistered FQDNs.
- Provided tooling: CTU published a bash script leveraging Azure CLI, jq, and host to automate discovery of unregistered redirect URIs.
- Mitigation: Claim or reconfigure orphaned subdomains in the appropriate Azure resources (e.g., Azure App Service, Traffic Manager) to prevent abuse.
MITRE Techniques
- [T1566.001] Spearphishing Link – Used to lure victims: “The attacker sends a phishing link to an employee of the organization. The link is a Microsoft URL where the redirect_uri or replyUrl parameter contains the compromised redirect URI.”
- [T1078] Valid Accounts – Using stolen authorization codes/tokens to impersonate users: “The threat actors can then use the stolen authorization code to obtain access tokens on behalf of the victim, providing access to the multi-tenant application and the backend Azure APIs while impersonating the victim’s account.”
- [T1190] Exploit Public-Facing Application – Abuse of orphaned cloud subdomains and resources to host malicious interceptors: “the threat actor could register the compromised organization’s multi-tenant application in the attacker’s tenant and register the compromised organization’s unregistered redirect URI in the appropriate Azure resource. They could deploy code to that Azure resource that intercepts the victim’s authorization code…”
Indicators of Compromise
- [Domain] Redirect URI root domains referenced as common takeover targets – azurewebsites.com, trafficmanager.com
- [URL] Research and reference links – https://www.secureworks.com/research/azure-redirect-uri-takeover-vulnerability
- [Redirect examples] Common redirect URI values in apps – http://localhost (development example) and organization subdomains of azurewebsites.com (potentially orphaned)
Technical summary and detection procedure
Azure multi-tenant applications can include redirect (reply) URIs that reference subdomains hosted under Microsoft-owned domains (for example, *.azurewebsites.com or *.trafficmanager.com). If an organization deletes or loses the Azure resource that originally hosted such a subdomain, the DNS or hosting for that FQDN can become unclaimed. An attacker who registers the orphaned subdomain in their own Azure tenant (for example by creating an App Service or Traffic Manager profile) can host code that receives OAuth 2.0 authorization codes sent to the redirect URI and then exchange those codes for access and refresh tokens, effectively impersonating users for that application and accessing backend APIs.
To detect these unregistered redirect URIs, enumerate all multi-tenant applications owned by your tenant, dump each application’s reply/redirect URLs, and normalize them to FQDNs by stripping URL schemes and ports. For each FQDN, perform a DNS A record lookup (or equivalent) to determine whether the domain has an active DNS record; absent records indicate prime takeover targets. CTU provided a bash approach that uses the Azure CLI to list apps, jq to parse replyUrls, a small function to remove schemes/ports, and the host command (or DNS lookup) to check for A records; unresolvable FQDNs are flagged for remediation.
Remediation entails claiming or re-provisioning the orphaned subdomains in the correct Azure resources (e.g., deploy the FQDN to an Azure App Service or Traffic Manager profile) or removing the stale redirect URIs from the application registration. Prioritize checking root domains commonly used by Azure services (azurewebsites.com, trafficmanager.com, and other Azure-hosted domains) and automate periodic checks to prevent future redirect URI takeover risks.
Read more: https://www.secureworks.com/research/azure-redirect-uri-takeover-vulnerability