SimulatorUnit 3 · Topic 3.1
DNS poisoning: plant a fake record
Plant a fake DNS record and see where users end up.
New to this? Read the topic first: 3.1 Network Vulnerabilities and Attacks.
Simulation · DNS poisoning [3.1.A.3, 3.5.E.5]
Simulator: poison a DNS server's records
A student looks up bank.example. Watch what changes when an adversary plants a fake record, then switch sides and find it.
| Name | Type | Time to live (s) | Data |
|---|---|---|---|
| bank.example | A | 3600 | 198.51.100.20 |
Learned from: the authoritative name server for bank.example
C:\> nslookup bank.example Server: dns1.school.example Address: 10.0.1.53 Non-authoritative answer: Name: bank.example Address: 198.51.100.20
Example Bank
Sign in
Username: student01 Password: •••••••• Sign inBehind the scenes: connected to 198.51.100.20, the real bank.
bank.example · Visits per hour Web analytics
Read the steps without the simulator
- Normal lookup. The DNS server's record says bank.example is at 198.51.100.20, the real bank. nslookup on the student's laptop shows that address, and the browser connects there.
- The attack. The adversary pretends to be the authoritative name server and plants a fake record on the DNS server: bank.example is at 203.0.113.66, with a long time to live (TTL) so it stays cached.
- Credential harvesting. Every user of that DNS server now reaches the adversary's copy of the sign-in page. The address bar shows the same name. (In real networks, an HTTPS site would also need a valid certificate for that name, so the browser would usually warn; the attack works when users click past the warning.) The real site is untouched, but the usernames and passwords typed into the copy go to the adversary.
- Detection. Users see nothing unusual, so DNS poisoning is hard to detect. The sign is an abrupt, unexplained drop in visits to the real website. Defenders then examine the DNS records and find the fake one [3.5.E.5].
Go to the topic: 3.1 Network Vulnerabilities and Attacks