TryHackMe · Subdomain Takeover

TakeOver

Identify a dangling subdomain, inspect TLS certificate metadata, and recognize an AWS S3 static-site takeover condition.

Room

TakeOver

Target Hostname

futurevera.thm

Target IP

10.66.147.141

Objective #

The company site itself is not the end goal. The real objective is to identify a forgotten or dangling subdomain that still points to a third-party service that is no longer properly claimed — and recover the flag hidden there.

Key Finding

A hidden support subdomain secrethelpdesk934752.support.futurevera.thm is associated with an AWS S3 static website endpoint whose bucket is no longer claimed — a classic subdomain takeover condition.

Skills Tested #

Web Reconnaissance DNS / VHost Awareness TLS Certificate Inspection Subdomain Enumeration Cloud Infrastructure Patterns Subdomain Takeover

This room is less about exploiting a live application bug and more about understanding infrastructure hygiene failures. When an organisation rebuilds or migrates support infrastructure, stale DNS records and forgotten cloud endpoints often linger — and attackers love them.

Attack Flow #

  Add futurevera.thm to /etc/hosts
              │
              ▼
  Browse https://futurevera.thm
  (company site, note "support rebuild" clue)
              │
              ▼
  Enumerate subdomains / vhosts
  → support.futurevera.thm discovered
              │
              ▼
  Inspect TLS certificate SAN entries
              │
              ▼
  Hidden subdomain revealed:
  secrethelpdesk934752.support.futurevera.thm
              │
              ▼
  Browse hidden host → redirects to
  AWS S3 static website endpoint
              │
              ▼
  Dangling cloud asset confirmed
  (bucket deleted, DNS remains)
              │
              ▼
  Recover flag ✓

Methodology #

1 · Add the Hosts Entry

The room hints that the target uses hostname-based routing. Without the correct Host header, the server may return nothing useful.

echo "10.66.147.141 futurevera.thm" | sudo tee -a /etc/hosts

Or edit /etc/hosts manually and add:

10.66.147.141 futurevera.thm

2 · Browse the Site First

Before running any scanner, browse the target manually at https://futurevera.thm. The page presents a legitimate-looking company website. Pay attention to the task narrative — the mention of a support system being rebuilt is not flavor text; it is a deliberate clue.

Why this matters

When an organisation migrates support infrastructure, old DNS records, helpdesk aliases, and cloud endpoints are frequently abandoned. The narrative narrows the search space significantly.

3 · Form a Hypothesis

Working hypothesis at this stage:

There may be a stale support-related subdomain that still points to an unclaimed third-party resource.

This is driven by three converging signals:

Room title: TakeOver
Narrative: support system rebuild
Common real-world pattern: forgotten helpdesk / static hosting subdomains

4 · Enumerate Subdomains

Use virtual host fuzzing to discover hidden hostnames:

ffuf -u https://futurevera.thm/ \
  -H "Host: FUZZ.futurevera.thm" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -fs 0

This reveals support.futurevera.thm — aligning perfectly with the room story and warranting deeper inspection.

5 · Inspect the TLS Certificate

One of the most valuable passive-recon techniques is checking Subject Alternative Name (SAN) entries in the TLS certificate. Organisations often request a cert covering the main domain and several subdomains — including forgotten internal or support names.

openssl s_client -connect futurevera.thm:443 \
  -servername support.futurevera.thm 2>/dev/null \
  | openssl x509 -noout -text | grep DNS

The certificate reveals a hidden subdomain:

secrethelpdesk934752.support.futurevera.thm

Why this is the pivot point

This hostname is obscure, nested under support, has a random-looking suffix, and is not linked anywhere publicly — exactly the kind of hostname defenders forget and attackers find.

6 · Browse the Hidden Hostname

Add the hidden hostname to /etc/hosts and browse https://secrethelpdesk934752.support.futurevera.thm. The goal is not just to see whether the page loads but to observe infrastructure behaviour: redirects, error messages, backend hostnames, cloud service references.

The response reveals a reference to an AWS S3 static website endpoint — the critical clue.

7 · Recognise the S3 Takeover Pattern

Whenever an S3 website endpoint appears behind a forgotten-looking subdomain, ask:

Does DNS still point to a bucket or website endpoint that is no longer claimed?

Typical failure pattern

Team creates a static site or helpdesk on S3
DNS is pointed to the S3 website endpoint
Project is retired or migrated
Bucket is deleted
DNS record remains — orphaned
Attacker re-creates the bucket and claims the subdomain

Why it is dangerous

Phishing under a trusted company subdomain
Credential harvesting via spoofed support portal
Brand impersonation at low cost and noise
No application vulnerability required

8 · Recover the Flag

With the takeover condition confirmed, the room delivers the flag.

Flag

flag{beea0d6edfcee06a59b83fb50ae81b2f}

Deep Dives #

Why TLS SAN Enumeration Matters

Directory brute-forcing misses a large amount of passive recon data. Certificates can reveal admin portals, staging hosts, retired vanity domains, and migration aliases. In takeover hunting this is especially valuable: the most dangerous subdomains are often obscure, not linked publicly, still covered by old certificates, and attached to outsourced or cloud infrastructure.

Why AWS S3 Is Common in Takeover Scenarios

S3 static website hosting is cheap and simple. That convenience creates operational risk. Defenders miss stale DNS because:

Ownership changes across teams over time
DNS is managed separately from cloud assets
Support or marketing sites are perceived as low-risk
Decommission checklists are incomplete or skipped

Why Start with Web Recon Rather Than Port Scanning?

The room provides the hostname and signals a web-centric challenge. The highest-value first actions are resolving the host, browsing content, inspecting metadata, and enumerating related hostnames. Port scanning remains useful but is secondary here.

Defensive Lessons #

Remove stale DNS records. Any record pointing to third-party infrastructure must be reviewed when the service is retired.
Track cloud resource ownership. If a subdomain points to S3, Azure, GitHub Pages, or similar, the DNS record lifecycle must match the resource lifecycle.
Audit certificates regularly. SAN entries reveal the full subdomain inventory — forgotten names should be investigated and cleaned up.
Treat support systems as security-relevant. Attackers do not care whether the asset is "just a helpdesk." If users trust the hostname, it has value to an attacker.

Common Mistakes to Avoid

Ignoring the /etc/hosts hint · spending too long on content discovery on the main site · missing TLS SAN inspection · overlooking the support-rebuild narrative clue · seeing an S3 reference and not recognising takeover potential.

Full Reproduction Path #

Add hosts entry
echo "10.66.147.141 futurevera.thm" | sudo tee -a /etc/hosts
Browse main site
Open https://futurevera.thm and note the support-rebuild clue in the task text.
Enumerate subdomains / vhosts
Use ffuf, wfuzz, or gobuster vhost against futurevera.thm. Identify support.futurevera.thm.
Inspect the TLS certificate
Use browser cert viewer or openssl s_client on futurevera.thm:443. Look for SAN values covering hidden subdomains.
Discover the hidden hostname
secrethelpdesk934752.support.futurevera.thm
Investigate redirects and backend clues
Open the hidden host. Observe the link to an AWS S3 static website endpoint.
Conclude subdomain takeover condition
The subdomain references a cloud web service consistent with an abandoned bucket — the takeover is confirmed.
Submit the flag
flag{beea0d6edfcee06a59b83fb50ae81b2f}

Commands Reference #

Hosts Configuration

echo "10.66.147.141 futurevera.thm" | sudo tee -a /etc/hosts

Quick HTTP Checks

curl -I https://futurevera.thm
curl -vk https://futurevera.thm

Virtual Host Fuzzing

ffuf -u https://futurevera.thm/ \
  -H "Host: FUZZ.futurevera.thm" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -fs 0

Certificate Inspection

openssl s_client -connect futurevera.thm:443 -servername futurevera.thm
openssl s_client -connect futurevera.thm:443 -servername support.futurevera.thm

DNS Lookups

dig futurevera.thm
dig support.futurevera.thm
dig secrethelpdesk934752.support.futurevera.thm

Inspect Headers on Hidden Host

curl -I https://secrethelpdesk934752.support.futurevera.thm
curl -vk https://secrethelpdesk934752.support.futurevera.thm

Quick Reference #

Vulnerable Subdomain

secrethelpdesk934752.
support.futurevera.thm

Underlying Service

AWS S3 Static Website

Issue Type

Subdomain Takeover

Flag

flag{beea0d6edf...}