«
◀
OP-25 // DOMAIN DANGLE
CAMPAIGN 3 // SUBDOMAIN TAKEOVER
0
XP
T1
RANK
0%
DETECT
↻
RESET
CAMPAIGN 3 — THE GHOST PROTOCOL
SUBDOMAIN TAKEOVER // OWASP A05 // DNS MISCONFIGURATION
OP-25
SECURITY MISCONFIGURATION // DNS
DOMAIN DANGLE
DNS READER · SUBDOMAIN SCANNER · TRAFFIC LOG ANALYST · DECOMMISSION BUILDER
OPERATION DOMAIN DANGLE — CAMPAIGN 3
🔌
SITUATION
41H 20M REMAINING
Op 24 found it in the dashboard: ops-archive.vantage-sys.net — a loose thread hanging off the Syndicate’s own front. Shadow ran a DNS lookup. The subdomain has a CNAME record pointing to a cloud storage bucket that no longer exists.
Vantage decommissioned the cloud archive account eight months ago. They did not update the DNS record. The subdomain still resolves. Automated systems across Vantage’s infrastructure still send requests to it. Those requests currently return errors.
If Shadow registers the defunct bucket, those requests start arriving at a system Shadow controls. The subdomain still carries Vantage’s name — and inside the Syndicate, Vantage’s name is Kane’s name. Every system that trusts it will trust Shadow.
Vantage decommissioned the cloud archive account eight months ago. They did not update the DNS record. The subdomain still resolves. Automated systems across Vantage’s infrastructure still send requests to it. Those requests currently return errors.
If Shadow registers the defunct bucket, those requests start arriving at a system Shadow controls. The subdomain still carries Vantage’s name — and inside the Syndicate, Vantage’s name is Kane’s name. Every system that trusts it will trust Shadow.
WHAT IS SUBDOMAIN TAKEOVER?
FEYNMAN PRIMER
Imagine a company leaves an old office but forgets to cancel its forwarding address. Someone else takes over that office. Now messages meant for the original company go to the new occupant.
🔌 The DNS record is the forwarding address. The cloud bucket is the building. Vantage moved out. Shadow is moving in.
VANTAGE SYSTEMS // INFRASTRUCTURE DECOMMISSION NOTE // 2023-05-14 // HOLT, M.
“Cloud archive account decommissioned as of today. DNS records to be updated in the next infrastructure cycle. Low priority — the subdomain receives no client-facing traffic.”
◈ MENDAX: “Next infrastructure cycle. Eight months ago. Still waiting.”
MENDAX — DARK CHANNEL // OP-25 BRIEF
08:22
MENDAX
“Claim it. Op 25.”
Op 24 — Session hijacking: using the stolen token to access Wilkins' dashboard and extract mission-critical data.
TARGET
nexus-dev.nexus-global.int
IP ADDRESS
DNS → unclaimed cloud resource
OS / SERVER
AWS S3 · Dangling CNAME · No origin claim
KEY SERVICES
CNAME → decommissioned S3 bucket · Bucket claimable
ATTACK SCOPE
Subdomain takeover — claim unclaimed resource + host payload
ATTACKER NODE
shadow@sigma9 · 10.99.0.1
📋 ROOM TASKS
01
✓
Understand how dangling DNS records enable subdomain takeover
02
▶
Claim the unclaimed cloud resource and verify control
03
○
Classify DNS record types by subdomain takeover risk
04
○
Identify the fix (delete dangling records before decommission)
05
○
Submit the capture-the-flag token
CAPTURE THE FLAG
Complete the exploit lab. The flag appears below once Phase 2 is done. Copy and submit it here for +50 XP.
PHASE 01
DNS RECORD READER
ANALYSE
SIGMA-9 CAPTURE LOG — HOW WE FOUND IT
02:47 UTC
> enumerated vantage-ops.net subdomains — ops-archive.vantage-sys.net still in DNS
> it resolves, but the destination returns an error page, not their site
> FOUND: the CNAME points at an S3 bucket nobody owns anymore — NoSuchBucket
MENDAX: "They tore down the building but left the address on the map. We can move in."
MENDAX — HOW THIS IS ACTUALLY DONE
LIVE
MENDAX
First you trace where the subdomain actually points. A dangling CNAME still resolves — it just forwards to a service that's been decommissioned. The error message tells you which provider, and that's your way in.
$ dig CNAME ops-archive.vantage-sys.net +short
# where does this subdomain forward to?
vantage-archive-2019.s3.amazonaws.com.
$ curl -s https://ops-archive.vantage-sys.net/
<Error><Code>NoSuchBucket</Code></Error>
MENDAX
NoSuchBucket means the name is free to claim. You register a bucket with the exact same name — now their subdomain points at content we control, on their domain, with their trust.
$ aws s3 mb s3://vantage-archive-2019
make_bucket: vantage-archive-2019 → ops-archive.vantage-sys.net now serves OUR content
MENDAX
We own a piece of their domain now — every cookie scoped to vantage-ops.net flows to us. Your call, Shadow — phishing page or cookie trap?
💡 A dangling CNAME is not a broken link — it is an unclaimed address. The subdomain still resolves. It still receives traffic. Anyone who registers the destination controls what that traffic receives.
MENDAX
ENCRYPTED
The full DNS zone for vantage-sys.net. Every record tells you something about the infrastructure. Tap each record to query it — the terminal shows what it resolves to and whether the destination exists.
One record is the vulnerability. The others give you context. Find the dangling CNAME.
One record is the vulnerability. The others give you context. Find the dangling CNAME.
► ZONE FILE // vantage-sys.net // dig axfr
✓
DANGLING CNAME IDENTIFIED
ops-archive.vantage-sys.net points to a cloud storage bucket that no longer exists. Every other record resolves correctly. This is the only unclaimed destination in the zone.
The CNAME itself is not wrong — it is a perfectly valid DNS record. What is wrong is that nobody deleted it when the bucket was decommissioned. The record points at a building that has been empty for eight months.
The CNAME itself is not wrong — it is a perfectly valid DNS record. What is wrong is that nobody deleted it when the bucket was decommissioned. The record points at a building that has been empty for eight months.
Why the subdomain still receives traffic: Vantage’s internal systems, monitoring agents, and automated backup processes were all configured to send data to ops-archive.vantage-sys.net. When the archive was decommissioned, nobody updated those systems either. They still send. The subdomain receives. Shadow will be the new recipient.
🔧 UNDER THE HOOD▼
THE ATTACK — STEP BY STEP
Subdomain takeover — a DNS CNAME points to a service that no longer exists. Anyone who claims that service gains control of the subdomain:
# Step 1: find dangling CNAMEs in DNS records
dig CNAME staging.victim.com
# Returns: staging.victim.com CNAME victim-staging.herokuapp.com
# Step 2: verify the target is unclaimed
curl -I http://victim-staging.herokuapp.com
# Returns: 404 "No such app" — Heroku app was deleted but CNAME remains
# Step 3: claim the target service:
# Create a new Heroku app named "victim-staging"
heroku create victim-staging
# Now staging.victim.com resolves to YOUR Heroku app
# Step 4: serve content from victim's subdomain
# Can host phishing pages, steal cookies scoped to *.victim.com,
# pass TLS certificate issuance (Let's Encrypt validates via HTTP)
COMMON VARIATIONS
1. S3 bucket takeover — a CNAME points to an S3 bucket that was deleted. Create a bucket with the same name in any AWS account:
3. NS-level takeover — if an NS record points to a nameserver that can be registered (e.g., on a shared DNS provider), control of the nameserver gives control of all DNS for that zone. More severe than CNAME takeover.
dig CNAME assets.victim.com
# → victim-assets.s3.amazonaws.com
# Check: curl -I http://victim-assets.s3.amazonaws.com
# "NoSuchBucket" → create the bucket, serve content from victim's domain
2. GitHub Pages takeover — a CNAME points to victim.github.io which was deleted or renamed. Create a GitHub Pages site under victim.github.io.3. NS-level takeover — if an NS record points to a nameserver that can be registered (e.g., on a shared DNS provider), control of the nameserver gives control of all DNS for that zone. More severe than CNAME takeover.
HOW TO DEFEND
Regular DNS audits and a decommission checklist that removes DNS records BEFORE retiring services:
# Audit all CNAMEs with automated scanning:
# subjack — checks for common vulnerable providers:
subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c fingerprints.json
# can-i-take-over-xyz — maintained list of vulnerable services:
# github.com/EdOverflow/can-i-take-over-xyz
# Internal DNS audit script (bash):
while read sub; do
target=$(dig CNAME +short "$sub")
if [ -n "$target" ]; then
status=$(curl -s -o /dev/null -w "%{http_code}" "http://$target")
if [ "$status" = "404" ] || [ "$status" = "000" ]; then
echo "POTENTIAL TAKEOVER: $sub -> $target (HTTP $status)"
fi
fi
done < subdomains.txt
Decommission workflow: (1) remove CNAME from DNS, (2) wait for TTL to expire, (3) then retire the target service. Never in the opposite order.PHASE 02
SUBDOMAIN SCANNER
DISCOVER
DNS records mapped. Now identify which dangling endpoint is actually worth claiming — not all abandoned addresses carry traffic worth intercepting.
💡 Not all dangling subdomains are worth claiming. Five are dangling. Only one receives traffic significant enough to be operationally useful. Scan them all. Classify each. Then claim the right one.
MENDAX
ENCRYPTED
Shadow has the full subdomain list from the DNS zone. Tap each subdomain to run a resolution check. The scanner returns nslookup-style output. Classify each result: active (resolves correctly), dangling (CNAME to nowhere), or protected (resolves but requires authentication).
When you have classified all six, you will know which one to claim.
When you have classified all six, you will know which one to claim.
Classified: 0 / 6
✓
ALL SUBDOMAINS SCANNED — ops-archive CLAIMED
Five dangling subdomains. Four receive minimal or zero traffic — forgotten endpoints from decommissioned projects. ops-archive.vantage-sys.net is different: it receives continuous automated traffic from Vantage’s internal monitoring agents.
Shadow registers the defunct storage bucket. Within four minutes, the first automated request arrives. The building has a new tenant. The mail is being read.
Shadow registers the defunct storage bucket. Within four minutes, the first automated request arrives. The building has a new tenant. The mail is being read.
Why ops-archive is the target: The other dangling subdomains are digital ghost towns — decommissioned and forgotten, but nobody sends traffic there anymore. ops-archive is an active mail forwarding address. Vantage’s infrastructure trusts it. That trust is now Shadow’s.
PHASE 03
TRAFFIC LOG ANALYST
CLASSIFY
The bucket is claimed and traffic is arriving. Someone else has noticed — read the logs before they do anything with what they found.
💡 Three types of traffic arrive at the claimed subdomain: automated (Vantage internal systems), operator (Vantage staff still using the old archive URL), and anomalous (someone who noticed the subdomain change and is probing deliberately).
MENDAX
ENCRYPTED
24-hour access log from the claimed subdomain. nginx format. Tap each entry to classify it. Automated traffic is safe to ignore. Operator requests are intelligence. One entry is neither — it is a message sent deliberately by someone who noticed the subdomain anomaly and decided to probe it.
Find the message.
Find the message.
0 / 10 classified
► ACCESS LOG // ops-archive.vantage-sys.net // 24h
10 entries
✓
LOG ANALYSIS COMPLETE — MESSAGE FOUND
Eight automated requests from Vantage monitoring agents. One operator request for archived data. One message — a deliberately crafted HTTP POST from an IP in Paris, France, with a custom user agent string that contains a name: C. Rousseau / ICIJ-affiliated.
She has been watching Vantage-connected domains for months. She noticed the CNAME anomaly. She sent a message to what she thought was still a Vantage archive server.
She has been watching Vantage-connected domains for months. She noticed the CNAME anomaly. She sent a message to what she thought was still a Vantage archive server.
Instead it reached Shadow.
PHASE 04
DECOMMISSION BUILDER
DEFEND
Rousseau's message received — Shadow broke protocol and responded. Now understand the eight steps that would have locked this door eight months ago.
💡 DNS cleanup must happen before resource deletion — not after. Delete the bucket first and the CNAME dangles immediately. The correct sequence is not obvious — which is why Holt’s team got it wrong.
MENDAX
ENCRYPTED
This is what Vantage should have done eight months ago. Eight steps in the correct order. One wrong step and the subdomain becomes claimable — which is exactly what happened.
Tap each step in sequence. Wrong placement shows you the specific failure it creates.
Tap each step in sequence. Wrong placement shows you the specific failure it creates.
BUILD THE CORRECT SEQUENCE
TAP TO PLACE
💡 HINT (−20 XP)
DNS TTL is the key: remove the CNAME record first and wait for TTL to expire before deleting the resource. This way no client ever tries to reach the old address after the bucket is gone.
✓
CORRECT DECOMMISSION SEQUENCE
This is the exact sequence that would have prevented the takeover. DNS cleanup before resource deletion. Waiting for TTL expiry before proceeding. Auditing traffic before removing systems to confirm nothing is still actively using them.
Holt’s memo said “DNS records to be updated in the next infrastructure cycle.” The cycle never came. The resource was deleted. The DNS record was not. Shadow moved in.
Holt’s memo said “DNS records to be updated in the next infrastructure cycle.” The cycle never came. The resource was deleted. The DNS record was not. Shadow moved in.
The rule that matters: A DNS record pointing to an external resource must be deleted before that resource is decommissioned. Never after. The moment the resource disappears, the record becomes claimable by anyone.
🔌
OPERATION 25 — COMPLETE
DOMAIN DANGLE — SUCCESS
SUBDOMAIN CLAIMED // MESSAGE RECEIVED
+0
XP EARNED THIS OPERATION
Shadow has controlled ops-archive.vantage-sys.net for nineteen minutes. Forty-seven automated requests from Vantage monitoring agents — health checks, backup confirmations, status pings routed to Shadow's bucket — plus a Vantage operator browsing for archived reports and one message from Camille Rousseau.
In a real organisation, a forgotten DNS record pointing to a decommissioned cloud resource can be claimed by any attacker willing to register the bucket name. Every internal system still trusting that address — monitoring agents, automated scripts, staff browsers — will send its traffic straight to the claimant. No exploit required: just a credit card and four minutes of setup.
The defensive fix is procedural, not technical: delete the DNS record before decommissioning the resource, then wait for TTL to expire before the resource goes away. Holt's team reversed the order. MENDAX said do not respond. Shadow responded.
In a real organisation, a forgotten DNS record pointing to a decommissioned cloud resource can be claimed by any attacker willing to register the bucket name. Every internal system still trusting that address — monitoring agents, automated scripts, staff browsers — will send its traffic straight to the claimant. No exploit required: just a credit card and four minutes of setup.
The defensive fix is procedural, not technical: delete the DNS record before decommissioning the resource, then wait for TTL to expire before the resource goes away. Holt's team reversed the order. MENDAX said do not respond. Shadow responded.
ROUSSEAU, C. — ICIJ-AFFILIATED
ops-archive.vantage-sys.net // POST // 08:31
“I know what Vantage is. I have been trying to publish for eight months. Three editors have killed the story. I think one of them is a client. If you are who I think you are — I have something you need. And you have something I need.”
MENDAX — DARK CHANNEL // AFTER SHADOW RESPONDS
08:34
■
[ 90 seconds of silence ]
MENDAX
“What did she say?”
08:34 — DARK CHANNEL // SHADOW + MENDAX + ROUSSEAU
ROUSSEAU
The URL of the auction platform. I found it through Companies House and a shell company trace in Luxembourg. Whoever you are — this is where the sale happens.
SHADOW
Forwarding to MENDAX.
MENDAX
She found it through Companies House and a shell company trace. Useful.
MENDAX
The auction platform has a race condition in the bidding mechanism. We do not need to win the auction. We need to prevent it from completing. Op 26.
DEBRIEF — REFLECTION QUESTION
The subdomain pointed to a decommissioned service, and you claimed it. What should be removed from DNS before any service is retired — and why is a dangling pointer dangerous?
SIGMA-9 ACADEMY
OPERATION 25 // SUBDOMAIN TAKEOVER // DNS HYGIENE // COMPLETE REFERENCE
◈ HOW DNS WORKS — RECORDS YOU NEED TO KNOW
A record: Maps a hostname directly to an IPv4 address. The most fundamental DNS record. example.com → 93.184.216.34.
CNAME record (Canonical Name): Maps a hostname to another hostname rather than to an IP address. ops-archive → some-bucket.s3.amazonaws.com. The final IP is resolved by looking up the target hostname. This is where subdomain takeover lives — if the target hostname disappears, the CNAME is left pointing at nothing.
MX record: Specifies mail servers for a domain. A dangling MX record can enable email spoofing under the target domain.
TXT record: Free-form text. Used for domain ownership verification, SPF records, DMARC policies. Not typically a takeover vector but can leak information.
NS record: Specifies authoritative nameservers for a domain. A dangling NS record pointing to an expired domain is one of the most severe takeover scenarios — the entire subdomain's DNS becomes controllable.
◈ WHY DANGLING CNAME ⁄ BROKEN LINK
A broken link is an inconvenience. A dangling CNAME is a security vulnerability. The difference is that the subdomain still resolves and still receives traffic.
What a broken link does: The subdomain stops working. Users see an error. Automated systems log failures. Nothing malicious happens.
What a dangling CNAME does: The subdomain still resolves — DNS returns the CNAME target. If the target is an unclaimed resource (a cloud storage bucket, a GitHub Pages site, a Heroku app), anyone can register it. Once registered, any traffic sent to the subdomain — by users who trust the parent domain, by automated systems, by monitoring agents — reaches the attacker instead. The subdomain’s inherited trust is the weapon.
◈ THE CORRECT DECOMMISSION ORDER
The sequence matters because of DNS TTL (Time To Live) — the duration DNS resolvers cache a record. If you delete the resource before removing the CNAME record, any resolver that cached the CNAME will keep trying to reach the now-deleted resource for up to the TTL duration. That window is claimable.
Correct: Remove CNAME → wait for TTL → delete resource. During the TTL wait, the subdomain stops resolving for new clients. Once TTL expires, all caches clear. Then delete the resource. No window exists for takeover.
Wrong (Vantage): Delete resource → plan to update DNS later → never update DNS. The CNAME points at a dead address that is now free to register. Takeover window: infinite.
❓
FIELD QUESTIONS — DOMAIN DANGLE
Why does Holt’s memo describe the subdomain as “low priority” — and why was he wrong?
Holt’s reasoning was that the subdomain received no client-facing traffic — only internal automated requests. He concluded that since no clients used it, its takeover would have no user-facing impact. This reasoning confuses impact on users with impact on security. The internal automated traffic was more valuable than client-facing traffic: it revealed the shape of Vantage’s internal monitoring architecture, confirmed which systems were still active, and gave Shadow a trusted position inside Vantage’s DNS namespace. Rousseau’s message arriving through this channel was an unforeseeable bonus. “No client traffic” does not mean “no valuable traffic.”
What is DNS TTL and why does it matter for decommissioning?
TTL (Time to Live) is a value attached to every DNS record that tells resolvers how long to cache it before re-querying. A TTL of 3600 means DNS resolvers cache the record for one hour. During that hour, they do not re-query — they return the cached value. When decommissioning a resource: if you delete the resource before removing the DNS record, any resolver that cached the record will keep returning the old value for up to the TTL. During that window, anyone who registers the deleted resource at the same address will receive all that traffic.
How could Vantage have detected this vulnerability before Shadow exploited it?
Automated DNS monitoring tools can detect dangling CNAME records by periodically resolving every CNAME in a DNS zone and checking whether the target resolves successfully. If a CNAME target returns NXDOMAIN (no such domain) or a cloud provider’s “bucket not found” response, the record is flagged for immediate attention. Tools like can-i-take-over-xyz, SubFinder, or enterprise DNS monitoring services perform this check continuously. The entire Op 25 vulnerability would have been caught and resolved in a scheduled DNS audit. Vantage had no such audit process.
Why did Rousseau message ops-archive.vantage-sys.net specifically?
Rousseau had been probing Vantage-connected domains for months as part of her investigation. She noticed the CNAME anomaly — the subdomain’s resolution changed. A dangling CNAME eventually starts returning different responses (cloud provider error pages) before a takeover, and after a takeover the responses change again. A careful observer monitoring the domain over time would notice these transitions. Rousseau sent a message to what she believed was still a Vantage archive server — hoping it might reach an insider. She did not know Shadow had claimed the subdomain. She was hoping the building still had staff. Shadow had just moved in.
REAL-WORLD TOOLS — DNS & SUBDOMAINS
WHAT PROFESSIONALS USE
🌐
dig
FREE / OPEN SOURCE
Resolve CNAME/NS records to spot dangling pointers aimed at decommissioned services.
dig CNAME +short promo.example.com
🔎
Subjack
FREE / OPEN SOURCE
Scans subdomain lists against a fingerprint database of takeover-prone providers — used by defenders to find gaps first.
subjack -w subs.txt -ssl -c fingerprints.json
✅
can-i-take-over-xyz
FREE
A maintained reference of which services are vulnerable to takeover, guiding safe decommission order.
github.com/EdOverflow/can-i-take-over-xyz
LEAVE MISSION?
Progress is saved. You can resume from the mission select screen at any time.
RESET MISSION?
This wipes all progress for this operation only. XP in other operations is unaffected.
ARE YOU SURE?
Final confirmation -- all progress for this operation will be permanently erased.