Detecting Rogue DHCP Server
What is a rogue DHCP server #
A rogue DHCP server is an unauthorized DHCP server that distributes knowingly or unknowingly wrong or malicious information to clients that send DHCP discover packets within a network. The following section lists some examples of rogue DHCP servers.
- Devices with integrated DHCP server:
- most commonly routers that are newly connected to the network. Especially some mobile WLAN routers for hotspots can cause problems if they are connected to a network for a longer time. Non-tech people are often not aware of the consequences.
- Threat actors:
- threat actors could spin up a DHCP server in your network to reroute traffic, distribute malicious information, e.x. an IP to a malicious DNS server, and cause a lot of damage after a short time.
- there are many scenarios in which a misconfiguration could cause a rouge DHCP server to cause trouble. An easy example would be to accidentally activate the DHCP server on a firewall.
Side note: Every network should have measures to prevent a rogue DHCP server from causing trouble. I'll list some methods at the end of this post.
Signs of a Rogue DHCP server #
Some signs of having a rogue DHCP server on your network are listed below:
- a client receives an IP from another subnet
- a client receives a duplicate IP within the network
- IP reservations do not work
- a client receives different network information (DNS, NTP, PXE, etc.)
- more than usual DHCP traffic
- DHCP traffic from new/unknown IPs
What is DHCP #
I won't go into too much detail on how DHCP is. In a nutshell, DHCP stands for Dynamic Host Configuration Protocol and allows automatic assigning of IP addresses to devices and provides more information about the network, like the default gateway, subnet mask, DNS server, NTP server, and more.
The 'DORA' process is essential and should be basic knowledge when a DHCP troubleshooting session starts.
The following screenshots show a rough overview of the DORA process. Since this is not the main topic of this post, we don't need to go into detail.
So, enough theory; let us detect the rouge DHCP server.
Detecting a rogue DHCP server #
There are various ways to detect a rogue DHCP server. Some work on the client or network level, or both.
In the following sections, we assume that we only have one legitimate DHCP server on an IPv4 network. Larger environments can have multiple of course, but this is not relevant, and the following detection methods work even if you have multiple servers.
Side note: You can release the old and request a new IP on Windows via command line
ipconfig /release and
ipconfig /renew and on Linux with
sudo dhclient -v -r and
sudo dhclient -v. Don't forget to specify the interface if you use multiple.
Packet capture #
It is important that the packet capture is taken on a client or intermediate device on the same network as the suspected rogue DHCP server. Wireshark and tcpdump are common tools to do so, and intermediate devices have their own tools.
You should look for UDP traffic on ports 67 and 68. It makes it easier to detect rogue DHCP servers if you are familiar with the above-mentioned 'DORA' process. Having multiple 'Offer' packets for a single 'Discover' packet from 1 or more IPs is an indicator for a rogue DHCP server. We have to keep IP spoofing in mind. Another option is to check on the server side: does the authorized DHCP server sends more than usual 'Offers' without receiving a 'Request'? - This is somewhat vague, but it could help to find a rogue DHCP server.
You can find more DHCP display filters for Wireshark in this post.
Using nmap #
- Scan for IPs that listen on the UDP port 67 in your network:
sudo nmap -sU -p 67 -d 10.10.20.0/24
-sU- limits scan to UDP ports
-p 67- destination port
-d- optional: increase debug level.
-ddfor even more information
10.10.20.0/24- your network
[...] Completed UDP Scan at 23:22, 0.24s elapsed (2 total ports) Overall sending rates: 16.82 packets / s, 470.93 bytes / s. Nmap scan report for _gateway (10.10.20.1) Host is up, received arp-response (0.00041s latency). Scanned at 2023-02-06 23:21:58 CET for 2s PORT STATE SERVICE REASON 67/udp open|filtered dhcps no-response MAC Address: 90:6C:AC:78:80:FB (Fortinet) Final times for host: srtt: 406 rttvar: 3765 to: 100000 [...]
This gives you a quick overview of your network.
nmap Scripts #
The required NSE script
broadcast-dhcp-discover should be installed by default together with nmap. More information to the script can be found in the official documentation.
Side note: If you are using Linux, you can find the interface's name with
ip -br a or
ip -br l.
- The default command looks like this:
sudo nmap --script broadcast-dhcp-discover -e eth0
- by default, this script will ask for an IP for the MAC address
de:ad:c0:de:ca:fe. Decent threat actors will sort those requests out to stay undetected. It is recommended to change the MAC address like in the following commands.
- Nmap command to use a fixed or random MAC address:
sudo nmap --script broadcast-dhcp-discover --script-args broadcast-dhcp-discover.mac=aa:bb:cc:dd:ee:ff -e enp0s31f6
sudo nmap --script broadcast-dhcp-discover --script-args broadcast-dhcp-discover.mac=random -e enp0s31f6
user@pleasejustwork:~$ sudo nmap --script broadcast-dhcp-discover --script-args broadcast-dhcp-discover.mac=aa:bb:cc:dd:ee:ff -e enp0s31f6 [sudo] password for kuser: Starting Nmap 7.80 ( https://nmap.org ) at 2023-02-06 17:22 CET Pre-scan script results: | broadcast-dhcp-discover: | Response 1 of 2: | IP Offered: 10.10.20.57 | DHCP Message Type: DHCPOFFER | Server Identifier: 10.10.20.1 | IP Address Lease Time: 7d00h00m00s | Subnet Mask: 255.255.255.0 | Router: 10.10.20.1 | Domain Name Server: 220.127.116.11, 18.104.22.168 | Renewal Time Value: 3d12h00m00s |_ Rebinding Time Value: 6d03h00m00s | Response 2 of 2: | IP Offered: 192.168.178.242 | DHCP Message Type: DHCPOFFER | Server Identifier: 192.168.178.51 | IP Address Lease Time: 2m00s | Renewal Time Value: 1m00s | Rebinding Time Value: 1m45s | Subnet Mask: 255.255.255.0 | Broadcast Address: 192.168.178.255 | Domain Name Server: 192.168.178.51 |_ Router: 192.168.178.1 WARNING: No targets were specified, so 0 hosts scanned. Nmap done: 0 IP addresses (0 hosts up) scanned in 1.23 seconds
For more information about
nmap visit the nmap guide or other
Windows DHCP server event logs #
The following event logs on the authorized Windows DHCP server can indicate a rogue DHCP server on a network.
|1042||Microsoft-Windows-DHCP-Server||The DHCP/BINL service running on this computer has detected a server on the network. If the server does not belong to any domain, the domain is listed as empty. The IP address of the server is listed in parentheses.|
|1105||Microsoft-Windows-DHCP-Server||Server found in our domain|
|1109||Microsoft-Windows-DHCP-Server||Server found that belongs to DS domain|
|1110||Microsoft-Windows-DHCP-Server||Another server was found|
|1111||Microsoft-Windows-DHCP-Server||Restarting rogue detection|
The source can be found on microsoft.com.
You can check the logs regularly or add those events to your monitoring solution.
Microsoft Rogue DHCP Checker #
Microsoft provided a tool to detect rogue DHCP servers, but this blog post from 2009 is no longer available. But thanks to archive.org we can find the blog post and download the 'RogueChecker' there.
Installed it on Windows 10 and it seems to work.
Turn off your own DHCP server #
Especially in larger networks, this often enough is not a solution, but I thought it would still be noteworthy. Disable the legitimate DHCP server in some way, release the IP on the client and ask for another IP. You shouldn't get a new legitimate IP address! - In case you receive a new IP address, the chances are high that there is a rogue DHCP server.
You can now check the DHCP server on the client and use other methods to find the rogue DHCP server on your network.
Intrusion Detection Systems #
There are many solutions that cover the detection of rogue DHCP servers, but not all companies have the capacities to maintain such a system. Therefore, we do not need to go into detail, but it is still worth mentioning.
Preventing actions of a rogue DHCP server #
Detecting is one thing; preventing any damage from a rouge DHCP server is another. This post focuses on detection, but I thought it won't hurt to list some prevention measurements.
- DHCP snooping/guarding on intermediate devices
- firewall policies that allow communication via UDP 67 and 68 only with authorized DHCP servers
- client management solution to check the correct DHCP server; does not work for printers and so on
- authorize DHCP servers in Active Directory and other services
E-Mail hello @itta vern. com
- 05.01.2023 SSH - run script or command at login
- 20.12.2022 Online Security Guide
- 14.12.2022 SSH - How to use public key authentication on Linux
- 12.12.2022 Getting started with nmap
- 11.12.2022 nginx - simple and native authentication function
- 13.03.2023 My Offsite Backup - March 2023
- 10.03.2023 Getting started with iperf3 - Network Troubleshooting
- 05.03.2023 ICMP echo requests on Linux and Windows - Reference Guide
- 14.02.2023 Simulate an unreliable network connection with tc and netem on Linux
- 03.02.2023 Basics of the Linux Bash Command History with Examples