TryHackMe TakeOver Walkthrough Easy Subdomain Takeover Room

🎯 Room Info

📖 What This Room Is About

TakeOver is built around a different kind of vulnerability than most of the rooms in this series — it's not about breaking into an app's code, it's about DNS hygiene. Specifically, it covers subdomain takeover: what happens when a DNS record still points to a third-party service (like a cloud hosting platform) that the organization has stopped using or never claimed.

The room covers:

1. 🔍 Enumerating subdomains for a target domain
2. 🌐 Identifying a subdomain pointing to an unclaimed external service
3. 🏴 Claiming that service yourself to take control of the subdomain
4. 🚩 Proving the takeover by serving your own content

This is a real, still-actively-exploited bug class — subdomain takeovers regularly show up in bug bounty payouts because they're easy to miss and easy to automate discovery for.

🧠 Skills You'll Practice

• DNS reconnaissance (dig, nslookup)
• Subdomain enumeration tooling
• Recognizing "dangling" CNAME records
• Understanding how third-party service claiming works (the takeover step)

🛠️ Step-by-Step Walkthrough

1️⃣ Start with basic DNS recon

dig <target-domain>
nslookup <target-domain>

Get a feel for the domain's existing records before enumerating subdomains.

2️⃣ Enumerate subdomains

Use a subdomain brute-forcing tool against a wordlist:

gobuster dns -d <target-domain> -w /usr/share/wordlists/subdomains-top1million-5000.txt

Or, if the room provides a specific subdomain list to check (common in TryHackMe's guided version of this room), work through it directly with dig:

dig CNAME <subdomain>.<target-domain>

3️⃣ Look for a "dangling" CNAME

The core of subdomain takeover: find a subdomain whose CNAME record points to an external service (like a cloud storage bucket, a PaaS app URL, or a GitHub Pages site) that doesn't actually exist anymore or was never claimed.

dig CNAME status.<target-domain>

Example of what a vulnerable record looks like:

status.<target-domain>.  CNAME  some-unclaimed-app.exampleplatform.io.

If visiting that subdomain in a browser shows a "not found," "no such app," or "this domain is not configured" style error from the third-party platform — that's your signal. The DNS record is still live, but nothing is actually claiming that name on the platform's side.

💡 Why this matters: when a company stops using a third-party service but forgets to delete the DNS record pointing to it, anyone who can register that same name on the third-party platform effectively takes control of the subdomain — visitors' browsers will still resolve it and load whatever the attacker hosts there.

4️⃣ Claim the service

The exact steps depend on which platform the dangling CNAME points to (this varies room to room — could be a static site host, a PaaS platform, or a cloud storage bucket). The general pattern:

1. Sign up for a free account on the platform the CNAME points to
2. Create a new app/site/bucket using the exact same name referenced in the CNAME
3. Deploy simple content (even just an index.html with a message) to prove control

curl -I http://status.<target-domain>

Check that the response now comes from your deployed content instead of the platform's default error page.

5️⃣ Confirm the takeover and find the flag

Once your content is live at the subdomain, the room typically confirms success either through:

• A flag displayed directly on the platform's admin panel for the claimed service
• A flag that appears when you successfully load the subdomain in a browser
• A verification check built into the room itself

🚩 Click to reveal: flag

Redacted — swap in your own captured flag if you want to keep a private record.

📋 Every Command, In Order

dig <target-domain>
nslookup <target-domain>
gobuster dns -d <target-domain> -w /usr/share/wordlists/subdomains-top1million-5000.txt
dig CNAME <subdomain>.<target-domain>
curl -I http://<subdomain>.<target-domain>

🎓 Key Takeaways

• Subdomain takeover is a DNS hygiene problem, not a code vulnerability. It happens when infrastructure gets decommissioned but the DNS pointing to it doesn't get cleaned up.
• Dangling CNAMEs are the classic signature. Any CNAME pointing to a third-party platform is worth checking — does that resource still actually exist and belong to the organization?
• This is a real, actively-paid bug bounty category. Tools like subjack, nuclei, and dnsx automate large-scale scanning for exactly this pattern across bug bounty scopes.
• Fixing it is simple but often forgotten: delete the DNS record the moment the underlying service is decommissioned. It costs nothing and closes the door entirely.