Dangling CNAME Takeover: Azure Cloud and GitHub Pages PoCs

Dangling CNAME Takeover: Azure Cloud and GitHub Pages PoCs

Generic “look for NXDOMAIN” guides stop too early. The money is in provider-specific claim steps: a CNAME still published at shop.example.com while the Azure site or GitHub Pages repo that used to answer is gone. You register (or reclaim) that edge resource and serve content on the victim hostname.

This writeup focuses on Azure and GitHub Pages claim paths — not another full recon taxonomy.

Fingerprint before you claim

Resolve the hostname. You want a CNAME (or chain) into a provider namespace, plus an error that means “unclaimed” rather than “blocked.”

GitHub Pages signals often look like a 404 page stating there is no site / site not found for that custom domain. CNAME targets commonly end in *.github.io.

Azure leftovers frequently point at *.azurewebsites.net, *.cloudapp.azure.com, *.trafficmanager.net, *.azure-api.net, or Front Door / CDN endpoints. HTTP bodies or certificates may still name the abandoned resource.

Confirm the parent program owns the DNS zone you are testing. Do not claim resources outside scope.

GitHub Pages practical PoC

1. Note shop.example.com → something.github.io (or apex instructions that expect a Pages org/user site).
2. Create a GitHub user/org and a repository with Pages enabled.
3. Add shop.example.com as a custom domain in the Pages settings.
4. If GitHub lets you verify/assign it without controlling the company’s GitHub org, you won — publish a harmless index.html with your hunter handle.
5. Fetch http(s)://shop.example.com/ and show your content. Screenshot DNS + Pages settings + response.

If the domain is still tied to another repo, you cannot claim it — not a takeover. Move on.

Azure practical PoC

For App Service style dangling CNAMEs:

1. Identify the target like name.azurewebsites.net from the CNAME chain.
2. In an Azure trial/subscription you control, create a Web App with that exact name if available.
3. Pointing is already done via the victim’s DNS; once the app name is yours, the victim hostname serves your app.
4. Deploy a static proof page. Avoid phishing kits — proof of control only.

Availability is the race. Common names may be taken by unrelated parties; that still demonstrates risk if you can show the DNS dangles and the claim path is real. Some programs want you to stop at “name available + dangling CNAME” without provisioning — read the policy.

Traffic Manager / API Management / Front Door have different claim UIs. The invariant: victim DNS points at a resource identifier you can recreate in your tenant.

What makes a strong report

• Exact DNS answers (dig / Resolve-DnsName output)
• Provider error page before claim
• Your proof page after claim on the victim hostname
• Clear blast radius: cookie scope, password reset links, OAuth redirect allowlists including the subdomain

Do not mass-claim dozens of hostnames. One solid PoC teaches triage; a scorched-earth grab creates legal and operational pain.

Cleanup

Delete the Pages domain binding or Azure app after the program acknowledges. Leave DNS alone — you do not control their zone. Mention cleanup in the ticket.

Provider docs change claim edge cases (domain verification files, TXT records). If a TXT challenge requires inserting records in the victim zone, you cannot complete the claim — report “dangling + blocked by verification” as a defensive note, not a full takeover.

When Azure or GitHub serves your HTML on their hostname, the subdomain is yours until they remove the CNAME. That is the whole finding.