Subdomain Takeover: The Silent Killer of Web Security — Tryhackme Lab Walkthrough

the TryHackMe The Ultimate Subdomain Takeover Guide: Cracking Lab

What is a Subdomain Takeover? (The Viral Vulnerability)

Before we jump into the terminal, let's talk strategy. A Subdomain Takeover happens when a subdomain (like support.futurevera.thm) points to an external service (like Amazon S3, GitHub Pages, or Zendesk) that has been deleted or unclaimed.

If the DNS record still exists, an attacker can claim that service and host their own malicious content on your official domain. It's a win for attackers and a nightmare for security teams.

The first rule of Offensive Security: You can't hack what you can't find. Our target is futurevera.thm.

I started with high-speed Subdomain Enumeration to map out the attack surface. Using tools like or Gobuster (in vhost mode) combined with the legendary DNS wordlists, I filtered through the noise.

The Discovery:

2. Certificate Transparency — The Pro OSINT Move

Most beginners look at the source code; pros look at the SSL Certificate.

By inspecting the certificate (Lock Icon → View Certificate), I performed a Certificate Transparency (CT) Inspection. Certificates often leak backend information, internal staging URLs, or cloud storage identifiers. In this lab, the certificate details hidden within the Subject Alternative Name (SAN) or issuer notes often hint at the backend architecture

3. Protocol Analysis (HTTP vs. HTTPS)

A common mistake in Vulnerability Assessment is only testing the secure (HTTPS) version of a site. I decided to compare the behavior of both:

1. HTTPS: Often returns a "Common Name Mismatch" or a blank page. This usually indicates a broken SSL binding.
2. HTTP: This is where the magic happened. The server responded with a raw string ending in .

4. Identifying the Misconfiguration (Amazon S3)

The presence of .s3 is a " smoking gun" in cloud security. It confirms that support.futurevera.thm is configured as a CNAME pointing to an Amazon S3 Bucket.

The Technical Breakdown:

• The Dangling DNS: The organization deleted the S3 bucket but forgot to remove the DNS record.
• The Leak: Because the bucket is gone, the routing layer is exposing the " Bucket Not Found" or a raw reference in the HTTP response.
• The Takeover: In a real-world scenario, an attacker could now register an S3 bucket with that exact name in that AWS region and effectively " own" the content of the support site.

5: Capturing the Flag (Proof of Concept)

By specifically targeting the misconfigured HTTP endpoint, I successfully extracted the lab's proof of concept:

This confirms that the subdomain is fully vulnerable and ready for a takeover.

Summary: The Attack Chain

To recap, here is how we breached the Takeover lab:

1. Enumeration: Used Gobuster/FFUF to find support.futurevera.thm.
2. OSINT: Inspected SSL certificates for hidden service data.
3. Behavioral Testing: Identified a critical mismatch between HTTP and HTTPS.
4. Root Cause Analysis: Diagnosed a "Dangling DNS" pointing to a deleted S3 bucket.
5. Exfiltration: Accessed the flag via the misconfigured routing layer.

Hello! I'm Meheraz Hossen Siyam, a dedicated Cybersecurity Researcher and Ethical Hacker with a deep passion for uncovering vulnerabilities before the bad actors do. My journey into the world of Linux and offensive security began on March 24, 2023, and since then, I have been obsessively documenting my path through complex labs and real-world scenarios.

Originally published at https://meherazhosensiam.blogspot.com.