Before starting this lesson, complete **networking-dns-tls(Web & Networking Foundations) andpassive-recon-osint** (OSINT, Metadata & Hidden Data). This lesson builds directly on the DNS record types covered in the first and the certificate-transparency enumeration covered in the second. If you arrived here straight from Lesson 3 (Content Discovery), pause and work through those two lessons first.
Organisations point dozens — sometimes hundreds — of subdomains at third-party services: a blog on GitHub Pages, assets in an S3 bucket, a demo on Heroku, a status page on a SaaS provider. Each is wired up with a DNS record, almost always a CNAME, that says "for blog.victim.example, go ask GitHub Pages." It works perfectly — until someone tears down the backing resource but forgets the DNS record.
A dangling DNS record points at a third-party resource that no longer exists. The provider treats the name as unclaimed — and lets anyone re-register it.
That is a subdomain takeover: the alias survives, the resource behind it does not, and an attacker re-claims the resource to serve their own content from a subdomain users and browsers already trust.
DNS in one breath
- An A record maps a name straight to an IP address.
- A CNAME record is an alias — "this name is really an alias for that other name; go resolve that instead."
assets.victim.example -> victim-assets.s3.amazonaws.com. - A dangling record is one whose target no longer exists or is no longer claimed — the classic case being a CNAME aliasing a deprovisioned third-party resource.
Why it matters
A taken-over subdomain lives under a trusted parent domain, so it enables:
- Phishing on a trusted domain — a login form on
account-portal.victim.examplebeats any look-alike domain. - Parent-domain cookie theft — cookies scoped to
.victim.exampleare sent to every subdomain, including the attacker's. - Allow-list abuse — security controls that trust
*.victim.examplenow extend that trust to attacker content, enabling token theft and script injection. (The specific mechanisms — OAuth, CORS, and CSP — are covered in later lessons.) - Valid HTTPS — providers auto-issue certificates for custom domains, so the takeover often shows the padlock with no warning.
In this lesson you will
- Understand how dangling DNS arises from a teardown-ordering mistake.
- Learn to recognise per-provider takeover fingerprints and the detection tooling.
- Enumerate subdomains of an authorised domain and inspect their CNAME targets.
- Learn the durable fix — remove dangling records and decommission resources in the right order.
Prerequisites
networking-dns-tls— this lesson builds on DNS record types (A, CNAME) and the resolution chain; complete it first if you have not already.passive-recon-osint— subdomain enumeration via certificate-transparency logs is covered there and applied directly in the hands-on step.content-discovery-enumeration— the forced-browsing habits from that lesson apply here at the subdomain level.
Authorisation, up front. The practical is read-only. Enumerate and inspect only a domain you own or are explicitly authorised to test. Detecting a dangling record is reconnaissance; claiming a third-party resource you do not own is unauthorised access — never do it, even to prove the finding. See [hacking-ethics-and-authorization](hacking-ethics-and-authorization).
Target: an authorised domain's enumerated subdomains, with read-only third-party sources. Estimated time: ten to fifteen minutes.
When you are ready, send the Continue signal.