The Syndicate is on the back foot, so they are falling back to infrastructure they trust most — DNS. Every Vantage Systems node finds every other node by name, and the resolver that answers those names runs out of a hardened Reykjavik data-haven. Control the resolver and you control where the entire Syndicate thinks it is connecting.
DNS KESTREL built and guards that resolver. He is convinced it is unreachable. But a name lookup is just a question, and the resolver believes the first answer that arrives — not the true answer. We do not need to break in. We just need to answer before the real server does.
Get a forged record to stick, and Director Kane's people start walking straight into rooms we own — without ever noticing the address changed.
THE POISONED PHONE BOOK
CHILD-LEVEL EXPLANATION
Imagine a town that uses a shared directory to answer questions quickly. Instead of asking every time, people rely on stored answers.
Now imagine someone feeds the directory false answers. The directory accepts them. So everyone who asks later gets sent to the wrong place.
If the resolver trusts whichever reply lands first, not whichever one is real — what does an attacker need to win: strength, or speed?
INTERCEPTED — WATCHDOG COMMS
12:44 UTC
DNS KESTREL
"Tell the Director to stop worrying. The resolver is internal only — no external device can reach it. Cache poisoning needs network access to the resolver, which nobody outside the Syndicate has. Our DNS infrastructure is completely secure."
RAVEN
Shadow — the DNS Warden is correct that external devices cannot query the resolver directly. He forgot that query responses travel back through the same path — and UDP has no authentication. We do not need access to the resolver. We need to be faster than the authoritative server. MENDAX, positioned on the internal network during Op 12, runs the Kaminsky flood from inside the Syndicate perimeter at 10.80.0.5. Begin Kaminsky flood on my mark.
MISSION OBJECTIVES
01
TARGET: the DNS Warden's internal resolver — BIND 9.11 unpatched since 2019, fixed source port 53, predictable transaction IDs, no DNSSEC
02
EXPLOIT: Run the Kaminsky flood — race forged replies in ahead of the real server to plant pad.ghost.int in the cache
03
SWEEP: Classify which flood parameters make a forged reply win or lose the race against the authoritative answer
04
WIN: Verify the poisoned cache, then lock it down — the one protocol-level defence that makes cache poisoning impossible, not just harder
⚠ ETHICAL NOTICE: DNS cache poisoning and Kaminsky-style attacks are covered by CEH, OSCP, network security, and incident response training. All interactions are fully simulated. Real DNS testing requires explicit written authorisation.
🔧 UNDER THE HOOD▼
THE ATTACK — STEP BY STEP
HTTP response splitting / cache poisoning — inject a crafted header value that tricks a caching proxy into storing a malicious response and serving it to other users:
# Unkeyed header injection — the cache doesn't include X-Forwarded-Host
# in its cache key, so all users sharing a cache get the poisoned response:
GET / HTTP/1.1
Host: victim.com
X-Forwarded-Host: evil.com
# If the app reflects X-Forwarded-Host in responses (e.g. in a URL):
# <link href="//evil.com/style.css">
# This poisoned response is cached and served to ALL users
Web cache poisoning via unkeyed query parameter — the cache key uses only the path, but the app includes the parameter in the response:
GET /?utm_source=<script>alert(1)</script> HTTP/1.1
# If cached, delivers stored XSS to every subsequent visitor
COMMON VARIATIONS
1. DNS cache poisoning (Kaminsky attack) — flood a DNS resolver with forged responses for a target domain, racing to get a forged record cached before the legitimate response arrives:
# Attacker sends thousands of forged UDP responses with guessed transaction IDs:
# Forged: example.com A 1.2.3.4 (attacker's IP)
# Legitimate: example.com A 93.184.216.34
# If attacker wins the race, the resolver caches the forged record
2. HTTP request smuggling — exploits ambiguity in how a front-end and back-end parse Content-Length vs Transfer-Encoding to inject a request that gets attached to another user's cache-stored response.
3. Cache deception attack — trick the cache into storing a private response as a public resource by appending a cacheable suffix:
GET /account/settings/fake.css HTTP/1.1
# Cache stores the authenticated account page as "fake.css"
HOW TO DEFEND
Include all headers that vary the response in the cache key, and validate all inputs before reflecting them:
# Nginx — add X-Forwarded-Host to cache key:
proxy_cache_key "$scheme$request_method$host$request_uri$http_x_forwarded_host";
# Varnish VCL — normalize or strip untrusted headers before caching:
sub vcl_recv {
unset req.http.X-Forwarded-Host;
}
# Never reflect untrusted header values into responses without validation.
# Use allowlists for acceptable Host/X-Forwarded-Host values:
const ALLOWED_HOSTS = ['www.example.com', 'api.example.com'];
if (!ALLOWED_HOSTS.includes(req.headers['x-forwarded-host'])) {
delete req.headers['x-forwarded-host'];
}
For DNS: enable DNSSEC on your zones so resolvers can cryptographically verify responses. Use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) on clients.
⚡ CYBER RANGE — ACTIVE ENVIRONMENT
LIVE
TARGET
ghost-resolver.ghost-capital.int
IP ADDRESS
10.47.1.18
OS / SERVER
Ubuntu 22.04 · BIND 9.11.4-P2
KEY SERVICES
DNS resolver (UDP/53) · No DNSSEC · Sequential TXIDs
ATTACK SCOPE
DNS cache — Kaminsky attack on the resolver in scope
ATTACKER NODE
shadow@sigma9 · 10.99.0.1
📋 ROOM TASKS
01
✓
Understand how predictable transaction IDs enable cache poisoning
02
▶
Poison the DNS resolver cache to redirect target domain lookups
03
○
Classify configurations that help vs hinder the attack
04
○
Identify the DNSSEC + RFC 5452 source-port randomisation fix
05
○
Submit the capture-the-flag token
🚩
CAPTURE THE FLAG
Complete the exploit lab. The flag appears in the terminal output. Copy and submit it here for +50 XP.
PHASE 01
POISON THE CACHE
EXPLOIT
SIGMA-9 CAPTURE LOG — HOW WE FOUND IT
02:47 UTC
> fingerprinted the Ghost Protocol internal resolver with dig version.bind
> BIND 9.11, unpatched since 2019 — source port pinned at 53, TXIDs increment by one
> FOUND: no DNSSEC, no port randomisation — classic Kaminsky-vulnerable resolver
MENDAX: "Fixed port, predictable IDs, no signature checks. We don't have to be right — we just have to be first. One forged reply slips in and the cache lies for an hour."
MENDAX — HOW THIS IS ACTUALLY DONE
LIVE
MENDAX
First we confirm the resolver entropy. dig at version.bind tells us the build, and a burst of probes shows whether the source port ever moves.
$ dig +short chaos txt version.bind @10.10.0.53
# reveals the resolver build behind the cache
"9.11.4-P2" src-port: 53 (FIXED)
MENDAX
Now we trigger a lookup for the landing-pad domain, then flood forged answers spoofed from the authoritative server — one will match the transaction ID before the real reply lands.
The resolver now answers our address for the next hour. The helicopter will route to Landing Pad B. Say the word, Shadow.
RAVEN
ENCRYPTED
You just flooded the Ghost Protocol resolver with forged replies and one slipped in ahead of the real server — the cache now answers pad.ghost.int -> 10.66.0.7 for the next hour. Every lookup gets your address.
That matters because Director V boards a helicopter in 40 minutes, and its routing — which landing pad it flies to — comes from a DNS query to that exact resolver. It runs BIND 9.11, unpatched since 2019, source port fixed at 53, transaction IDs predictable. Textbook Kaminsky-vulnerable. With the cache poisoned, the helicopter lands at Landing Pad B, where your team is waiting.
You just poisoned the cache. Now make the call: what does DNS cache poisoning actually do under the hood?
TAP AN ANSWER — EXPLANATION APPEARS IMMEDIATELY
RAVEN — HINT (−20 XP)
The resolver trusts the first reply with a matching transaction ID. Attackers only need to guess 1 of 65,536 IDs — what reduces the search space and speeds up the attack?. Without logs the organisation does not know when the attacker arrived, what they accessed, how long they were inside, or which vulnerability was used. They cannot scope the damage, notify affected users, or fix the entry point. The attacker benefits from this invisibility during and after the breach.
✓
LOGGING FAILURE IMPACT UNDERSTOOD
Without logs, the attacker has unlimited dwell time. The average breach dwell time without good logging is over 200 days. With mature logging and alerting it drops below 24 hours. Longer dwell time means more lateral movement, more data exfiltration, and more persistence established.
Simple version: Without CCTV footage, the shop owner does not know when the thief entered, what was taken, or how they got in. The thief can come back every night — and the owner cannot even tell whether they are still in the building.
Logging failures also destroy forensic capability — without logs, there is no way to determine breach scope, notify affected parties, or close the vulnerability.
Real world: The 2020 SolarWinds breach had a dwell time of approximately 9 months before detection. Attackers inside that long can establish multiple persistence mechanisms, exfiltrate everything of value, and ensure that even after discovery, re-entry is possible. Good logging at the right points would have surfaced the anomalous behaviour within hours.
☢
HOW DNS ACTUALLY WORKS
DNS (Domain Name System) is the internet's phone book. When you type a domain name, your device asks a resolver: "what IP address is this?" The resolver checks its cache first. If not cached, it asks the authoritative server, stores the answer, and serves it to you.
Cache: temporary memory — answers stored until the TTL (Time To Live) expires. TTL: the expiry time set by the domain owner. Resolver: the server doing the lookup — often your ISP or corporate DNS server.
The vulnerability: resolvers use UDP, which is connectionless. UDP replies have no handshake — a resolver cannot tell if a reply came from the real server or an attacker. Matching is done by transaction ID (16 bits = 65,536 possibilities) and source port. Fix the source port and the attacker only needs to guess 1 of 65,536 IDs — and can send all 65,536 guesses in under a second.
PHASE 02
RESOLVER PROBE — FIND THE WEAKNESS
INTERACTIVE
One forged reply in the cache. Before we flood, we need to know exactly why this resolver is vulnerable — and which of its four weaknesses seal the helicopter's fate.
RAVEN
ENCRYPTED
RAVEN has mapped the DNS Warden's resolver. Before launching the Kaminsky flood, we need to identify exactly what makes this resolver vulnerable.
Four characteristics of the Ghost Protocol resolver. For each one, answer whether it enables the Kaminsky Attack or prevents it — and why. All four must be analysed before the flood begins.
MISSION OBJECTIVEFour resolver characteristics listed below. For each one, tap to expand and answer whether it helps or hurts the Kaminsky Attack. Correctly analyse all 4 to confirm the flood parameters and proceed.
CHARACTERISTICS PROBED
0 of 4 probed
RAVEN — HINT (−20 XP)
For each resolver characteristic: does it make the Kaminsky Attack easier (vulnerable) or harder (resistant)? The source port, transaction ID range, TTL, and DNSSEC status all determine whether our flood will succeed.
✓
ALL SCENARIOS ANALYSED — BLIND SPOTS MAPPED
All four vulnerability factors confirmed: fixed source port, predictable transaction IDs, long TTL, DNSSEC disabled. The DNS Warden has created the perfect conditions for a Kaminsky Attack. One flood. One poisoned cache entry. One redirected helicopter.
Simple version: The phone book has no security seal, the page numbers are predictable, the entry stays unchanged for an hour, and there is no way to verify entries are genuine. We just need to be faster than the real answer.
Real-world impact: The 2008 Kaminsky disclosure affected every major resolver globally. ISPs, corporate networks, and government DNS infrastructure all needed emergency patches simultaneously. Dan Kaminsky coordinated a secret 6-month patch effort before going public — because the vulnerability was so severe that public disclosure without a patch would have enabled immediate mass exploitation.
☢
THE KAMINSKY ATTACK — FULL MECHANICS
Step 1: Send a query for a domain to the vulnerable resolver — this triggers it to query the authoritative server. Step 2: While the resolver waits for the real reply, flood it with thousands of forged replies all claiming to be from the authoritative server. Step 3: One forged reply will match the transaction ID. The resolver stores it. Step 4: All future queries for that domain get the poisoned answer until TTL expires.
Key insight: The attacker does not need to intercept the real reply — just need one forged reply to arrive first with the matching ID.
Why the flood works: UDP is fire-and-forget with no authentication. The resolver cannot tell a legitimate reply from a forged one — it only checks source IP, source port, and transaction ID. Randomising source port and transaction ID (RFC 5452) makes the search space too large to brute-force. DNSSEC makes it impossible regardless.
PHASE 03
CLASSIFY THE FLOOD PARAMETERS
CLASSIFY
Vulnerability stack confirmed. Now configure the flood — ten parameters to sort. The helicopter lands at our pad in thirty-eight minutes. Every parameter we get wrong delays the launch.
RAVEN
ENCRYPTED
RAVEN is configuring the Kaminsky flood using dnschef. Each parameter either increases our chance of winning the race (HELPS ATTACK) or decreases it (HURTS ATTACK).
Tap a parameter, then classify it as HELPS or HURTS. All 10 must be correctly classified before the flood launches.
TAP A PRACTICE — THEN CLASSIFY IT
Select a parameter above
▲ HELPS ATTACK
▼ HURTS ATTACK
RAVEN — HINT (−20 XP)
HELPS: anything that makes it easier to send a matching forged reply before the real one arrives — fixed port, predictable ID, high send rate, long TTL, triggering query first. HURTS: anything that makes matching harder — DNSSEC (cryptographic), randomised port (too many combos), short TTL (too little time).
✓
ALL PRACTICES CORRECTLY CLASSIFIED
All 10 parameters classified. The Ghost Protocol resolver has a 4-vulnerability stack: fixed port, predictable IDs, long TTL, no DNSSEC. Our flood parameters are set: 10,000 forged replies per second, full authoritative section spoofed, query triggered. Launching now.
Simple version: We know the page number in the phone book (fixed port). We can predict which entry is being looked up (sequential ID). The poisoned entry lasts an hour (long TTL). And nobody checks if entries are genuine (no DNSSEC). Perfect conditions.
Real dnschef command: dnschef --fakeip=10.99.0.1 --fakedomains=landing-pad.ghost.internal --interface=10.80.1.5 --nameservers=10.80.0.1 — This sets up dnschef as a fake DNS server responding to all queries for our target domain with our landing pad IP.
☢
THE RACE CONDITION — WHY SPEED MATTERS
DNS cache poisoning is a race between the attacker and the authoritative server. The resolver sends one query and waits for a matching reply. First matching reply wins. The attacker must send enough forged replies fast enough that at least one arrives before the legitimate reply.
Typical authoritative server response time on an internal network: 1-5 milliseconds. At 10,000 forged replies/second, the attacker sends 10-50 replies before the real one arrives. With predictable IDs, far fewer are needed.
Real-world measurement: on a vulnerable resolver with fixed source port and sequential IDs, a successful Kaminsky poison takes an average of 1.3 seconds using freely available tools. On a patched resolver with random ports and IDs, the same attack would take statistically over 100 years.
PHASE 04
THE ONLY FIX THAT ACTUALLY WORKS
DEFENSE
Cache is poisoned. Director V is en route to Landing Pad B. Before this operation closes, one final call: what is the one control that makes DNS cache poisoning cryptographically impossible — not merely harder?
RAVEN — FINAL DEBRIEF
LAST PHASE
The cache is poisoned. Helicopter confirmed en route to Landing Pad B. Director V is in custody.
RAVEN: "Shadow — the DNS Warden believed an internal network was inherently safe. He disabled DNSSEC as unnecessary overhead, never randomised the source port, and left transaction IDs sequential. The Kaminsky Attack took 4 seconds. Which single change would have made this attack technically impossible — not just harder?"
MISSION OBJECTIVESelect the single defensive control that makes DNS cache poisoning impossible — not just harder to execute. One correct answer. The difference matters: harder means an attacker with more time still wins; impossible means the attack is dead regardless.
WHICH FIX MAKES CACHE POISONING IMPOSSIBLE?
RAVEN — HINT (−20 XP)
Think about the root cause: the resolver cannot tell a real reply from a forged one. The fix must make forged replies detectable or rejectable — not just harder to guess. Which option makes the forged reply technically invalid regardless of how perfectly the attacker guesses the transaction ID?
► INTEL — OP-18 // OPERATION TOXIC CACHE
TARGET: NEXUS Corporate DNS Infrastructure
Classification: TOP SECRET // Campaign 3 Ghost Protocol
MENDAX — CHANNEL BRIEFING
PRE-OP
MENDAX
DNS uses UDP with predictable transaction IDs and source ports. The Kaminsky attack floods the resolver with forged responses for a queried domain, poisoning the cache before the legitimate response arrives.
📓
OWASP CLASSIFICATION
INTEL
Network attack: DNS cache poisoning redirects all traffic for a domain to an attacker-controlled server. Impact: credential harvesting, malware distribution, session hijacking at scale.
⚖
GLOSSARY TERMS: DNS Cache Poisoning, Kaminsky Attack, DNS Hijacking, Transaction ID, DNSSEC, DNS over HTTPS, DNS Resolver. All terms auto-logged to your Field Manual as you encounter them.
ACADEMY — DNS CACHE POISONING
THE PHONE BOOK HAS BEEN CHANGED.
BEGINNERWhat Is DNS Cache Poisoning?›
DNS cache poisoning corrupts a resolver memory by injecting a fake DNS answer before the legitimate one arrives. Every device that asks the resolver for a domain name then gets the wrong IP address — silently, with no visible indication that anything is wrong.
The attack exploits UDP's lack of authentication. DNS uses UDP for speed — but UDP has no handshake, no session, no way to verify who sent a packet. A forged UDP packet from an attacker looks identical to a legitimate one.
The Kaminsky Attack (2008) showed that on resolvers with predictable transaction IDs and fixed source ports, poisoning any domain takes seconds.
Real world — 2010 China DNS Incident: A routing misconfiguration caused the Great Firewall's poisoned DNS responses to propagate globally. Millions of users in Chile and the USA were briefly redirected to wrong IPs for YouTube, Facebook, and Twitter. A single misconfigured DNS response, propagated through cache relationships, affected the entire internet for hours.
INTERMEDIATEAttack Mechanics — Kaminsky Deep Dive›
Step 1 — Trigger a query:
Send a query for the target domain to the vulnerable resolver. This causes the resolver to query the authoritative server — starting the race window.
Step 2 — Flood forged replies:
Simultaneously send thousands of UDP packets spoofed as replies from the authoritative server. Each reply contains: our fake IP, the matching domain, and a different transaction ID guess.
Step 3 — Win the race:
One forged reply matches the actual transaction ID. The resolver receives it before the real reply. It stores the forged answer in cache.
Step 4 — Persistence via TTL:
The poisoned entry stays in cache for the TTL duration. Every subsequent query gets redirected without any further attack needed.
Tools used:
dnschef — fake DNS server that responds to queries with arbitrary IPs
dnsspoof — sniff and forge DNS replies in real time
scapy — craft custom UDP packets with spoofed source IPs
EXPERTDefences and DNSSEC Explained›
DNSSEC — the only complete fix:
DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. The authoritative server signs every record with its private key. Resolvers verify the signature before caching any reply. An attacker without the private key cannot produce a valid signature — forged replies are automatically rejected.
Source Port Randomisation (RFC 5452):
Randomising the source port on outgoing queries expands the attacker search space from 65,536 to over 4 billion. Makes brute-force flooding statistically impossible — but not cryptographically guaranteed like DNSSEC.
0x20 Encoding:
Randomise the capitalisation of domain names in queries (e.g. GoOgLe.CoM). The reply must match the exact capitalisation — an attacker guessing replies also needs to guess this, adding another entropy layer.
Response Rate Limiting (RRL):
Limits how many responses the authoritative server sends per second to any single source — slows amplification attacks but does not stop Kaminsky-style poisoning.
Notable incidents:
2008 — Kaminsky disclosure, emergency global patch effort
2010 — China DNS leak, global propagation of poisoned records
2014 — Brazil ISP poisoning, users redirected to fake bank pages
2014 Brazil banking DNS attack: Attackers compromised a Brazilian ISP's DNS resolver and poisoned cache entries for major banks. Users typing their bank's URL were silently redirected to convincing fake sites. Credentials harvested. Losses in millions before detection. DNSSEC on the bank domains would have made the poisoned entries instantly detectable.
REAL-WORLD TOOLS — DNS SECURITY
WHAT PROFESSIONALS USE
☢
dnschef
FREE / OPEN SOURCE
A DNS proxy and fake DNS server. Creates a rogue DNS responder that replies to queries with arbitrary IP addresses. Used in penetration tests to redirect traffic, test DNSSEC validation, and simulate cache poisoning.
The standard DNS query tool. Queries any resolver for any record type and shows the full raw response including TTL, authoritative section, and caching status. Essential for verifying DNS responses and detecting poisoning.
dig @10.80.0.1 landing-pad.ghost.internal A +short +ttlid
🔒
DNSSEC-tools
FREE / OPEN SOURCE
Suite of tools for deploying, testing, and validating DNSSEC. Includes zone signing utilities, key management tools, and validation testers. Used by DNS administrators to implement and audit DNSSEC deployments.
Python packet crafting library. Allows creation of arbitrary network packets including spoofed UDP DNS replies. Used in DNS poisoning research and penetration testing to craft and send custom forged DNS responses.