MiTM - DNS Zone Poisoning Attacks Using DNS
Prerequisites¶
- VirtualBox or VMware Workstation Pro Installed.
- Virtual Machine
[project-x-corp-svr]is configured with Docker. - Docker Container
[project-x-corp-svr-dns-svr]setup and configured. - Docker Container
[project-x-corp-svr-web-svr]setup and configured. - Virtual Machine
[project-x-attacker]is turned on.
Network Topology¶
Likeliness Meter¶
Moderate: Zone poisoning would be considered a "Unlikely". We rate this as an overall "Moderate" for DNS-based attack. However, DNS as a protocol and medium for attack has a moderate chance. There is a lot that can go wrong with misconfigured DNS zones, caches, records, or servers. A compromise of any of these will lead to severe security implications.
MiTM Overview¶
Man-in-the-Middle (MiTM) attacks occur when a threat actor secretly intercepts, relays, or alters communication between two parties without their knowledge. In the context of DNS, MiTM attacks aim to manipulate name resolution to redirect victims to malicious systems.
DNS is a prime example of how Man-in-the-Middle attacks can be highly effective. Because DNS serves as the backbone for translating domain names into IP addresses, compromising DNS can give attackers significant control over network traffic and user trust.
This central role makes DNS servers a frequent and valuable target for attackers to deploy MiTM and DoS attacks.
DNS Zone Poisoning¶
DNS Zone Poisoning involves injecting false records directly into a zone file (typically via compromised DNS servers), redirecting domains to attacker-controlled IPs.
Impact¶
MiTM and DNS MiTM attacks can lead to a loss of integrity, credential theft, data interception, and network traffic redirection.
DNS Zone Poisoning¶
The goal of this attack is to redirect www.projectxcorp.com to an attacker controlled web server. The attacker could copy the real web page, modify it to gather a username or password for a "sign-up" event.
When our employees, Jane or John, navigate to www.projectxcorp.com the attacker web page would be served.
[project-x-attacker]¶
Let's assume the attacker has got access to the internal network, similar to what we have already been doing.
Performing an nmap scan on all ports, we notice a few services running, notably 22 and 2222.
If we were to attempt to login, and let's say we brute force the password, we find that its admin.
We know the IP address already.
Performing a netstat -tuln as some initial recon, we notice port 53, which is DNS is running on this servers IP, which 10.0.0.8. Interesting...
Let's search around...
One command we can use is view recently installed software:
grep " install " /var/log/dpkg.log
Searching around for some time, we find that BIND9 service is running.
We can use ChatGPT or Google to see where BIND9 configuration files are installed by default, which is /etc/bind.
Looking at the BIND9 configuration files, we notice a DNS record being served for www.projectxcorp.com. Looks like it's going to an internal web server, in this case it's just another docker container [web-svr] (we wouldn't know this until doing more recon).
We can edit this file to redirect to system we control.
In the real-world, the attacker would stand up their own server in the cloud or VPS service. For our lab, we will just use the attacker machine.
Let's edit this zone file from 10.0.0.8 to 10.0.0.15, which is the attacker's IP address.
nano /etc/bind/zones/db.projectxcorp.com
Searching around Google, we find that we can flush our dns cache with rndc flush and restart BIND9 with service named restart.
Back on the attacker machine, we can serve whatever web page we want.
Navigate to /var/www/html.
Based on our previous exercises from Enterprise 101, you may have some files. That's okay.
- You can delete or change the
index.html.
You can clone the exercise files: INSERT LINK
Start the web service: service apache2 start.
In this case, the attacker copied the real www.corpprojectx.com web page and made some edits to align with our objective.
Now to simulate a victim running through the scenario.
Let's use johnd's, [project-x-win-client].
First make sure [...-win-client] is using the DNS service of 10.0.0.8.
Next, we can go to the browser, and type www.corpprojectx.com.
And we can register to this corporate event.
Going back to the attacker machine, we see some new credentials come in. We got 'em.
This is a very simple example of how DNS zone files can be "poisoned" into redirecting to an attacker controlled environment.
Looking at the likeliness meter at the beginning, this specific attack is not real-world in most cases. Most Internet DNS servers are managed by large technology companies, they often do a very good job of hardening them down.
However, for internal DNS servers, something you might see in a business LAN environment, you may be able to hijack and poison a zone or cache.
This attack serves as an example of how dangerous MiTM attacks can be and why they are often fixed very quickly when discovered.