Rogue DHCP Server Can't be found

Question

Over the last 3-4 weeks I have been trying to find a rogue DHCP server on my network but have been stumped! It is offering IP Addresses that do not work with my network, so any device that needs a Dynamic Address is getting one from the Rogue DHCP and then that device stops working. I need help to find and destroy this thing! I think it might be a Trojan of some sort.

My Main Router is the only valid DHCP Server and is 192.168.0.1 which offers a range of 192.160.0.150-199, and I have this configured in my AD as Authorized. This ROGUE DHCP claims to be coming from 192.168.0.20 and offering an IP Address in the range of 10.255.255.* which is messing up EVERYTHING on my network unless I assign a static IP Address to it. 192.168.0.20 does not exist on my network.

My network is a single AD Server on Windows 2008R2, 3 other physical servers (1-2008R2 and 2 2012R2) about 4 Hypervisor VM's, 3 laptops and a Windows 7 box.

I can't ping the rogue 192.160.0.20 IP, and I can't see it in the ARP -A output, so I can't get its MAC address. I'm hoping that someone reading this post has come across this before.

I'm no help on the windows side but if I was on Linux, I'd simply take a packet capture with tcpdump on a client as it obtained a bad dhcp lease. The packet capture should have the mac address of the system that sent the offer. Trace that. — , Aug 15 '17 at 02:37
Can you unplug everything and put things back on the network one at a time? — R. S., Aug 15 '17 at 02:45
Isn't there a way on the switch to disable dhcp on ports? I thought there was. — curious_cat, Aug 15 '17 at 07:34
@curious_cat - the only way to disable rogue DHCP servers at the switch level is to employ a switch that has DHCP snooping (that's the Cisco terminology). A single port can be configured to be a "trusted" DHCP port (which your trusted DHCP server should be connected to) and it will be the only port to allow DHCP requests through. All other ports can then block the requests - thus eliminating rogue DHCP server situations. Managed switches with this functionality are a must-have for networks with untrusted users/devices. — Kinnectus, Aug 15 '17 at 09:22
Exactly. That's what I meant. It seems like a robust solution to this problem. — curious_cat, Aug 15 '17 at 09:24
What router? It could be that the router itself is infected. — J..., Aug 15 '17 at 10:22
What type of switch do you have? managed or unmanaged? Brand? Model? Depending on the capabilities of the switch you might have some more possibilities how to solve the problem. — Raffael Luthiger, Aug 15 '17 at 16:49
Are you running a VPN server somewhere? Usually VPN's put connections on a different subnet and then build routes to allow them to talk... maybe it's misconfigured and offering it's DHCP onto your regular subnet instead of only to VPN users. — SnakeDoc, Aug 15 '17 at 21:14
@yoonix You can do that with Wireshark or similar on Windows (or your own program using WinPCAP, if you prefer.) — reirab, Aug 15 '17 at 22:26
@peterh Even if the MAC address had been changed by a trojan, it must still be one that works on the network, otherwise the DHCP handshake would fail. — reirab, Aug 15 '17 at 22:28
@reirab ...and so will be known, that the rogue is in the switched off half... — peterh, Aug 15 '17 at 23:02
DHCP by design shouldn't work cross-subnets - unless a relay agent is specifically configured. So the request for a DHCP lease should not make it across the VPN unless an agent pushes it across. DHCP snooping (or equivalent) is definitely the best option to stop this long term. — Shane, Aug 16 '17 at 07:44
@MatthewWetmore I don't think it is a duplicate. That question is about how to detect the presence of a rogue DHCP server. This question is about how to find out where it is once its presence on the network is already known. — kasperd, Aug 16 '17 at 23:06
@kasperd, yeah, I'll go with you on that. There was some indirect stuff that overlapped with wireshark and finding the MAC - which is one of the issues in this question. But this does go a bit further/better on getting it down to the port on the switch. Good catch, thanks. I'm not sure how to unflag - possibly just deleting the auto-generated comment by flagging? — Matthew Wetmore, Aug 17 '17 at 05:39
@Shane My comment was more along the lines of a VPN Endpoint/Router combo that had a wrong configuration and decided to offer 2 DHCP server's on the same subnet, but for different DHCP address pools... not some VPN user pushing DHCP into the network. — SnakeDoc, Aug 17 '17 at 15:44

score 52 · Answer 1 · answered Aug 15 '17 at 02:51

52

On one of the affected Windows clients start a packet capture (Wireshark, Microsoft Network Monitor, Microsoft Message Analyzer, etc.), then from an elevated command prompt run ipconfig /release. The DHCP client will send a DHCPRELEASE message to the DHCP server that it obtained it's ip address from. This should allow you to obtain the MAC address of the rogue DHCP server, which you can then track down in your switch MAC address table to find out which switch port it's connected to, then trace that switch port to the network jack and the device plugged into it.

answered Aug 15 '17 at 02:51

joeqwerty

110,860

1

How can I view the MAC address and ARP tables of an unmanaged switch? – Dai Aug 15 '17 at 09:04
26

@Dai Step 0: Buy managed switches. I know that's not always an option but usually your network is either big enough to make them worth it or small enough that it wouldn't be a hard job to walk around to every machine and interrogate it. – Oli Aug 15 '17 at 10:15
1

@Dai What make and model is the switch? – Hagen von Eitzen Aug 15 '17 at 12:52
19

If you have an unmanaged switch, the mac address still gives you something to work with - you can look up the vendor so you have an idea what brand of hardware to look for, AND you can use a tool like arping to ping the rouge while you unplug switch ports to work out which port it's connected to. – Michael Kohne Aug 15 '17 at 13:01
1

This is wrong. The DHCP client believes the IP of the DHCP server to be 192.168.0.20. It will send a release to this address. Nothing about a message being sent to this incorrect address will reveal either the correct IP or the correct MAC of the server. – jwg Aug 17 '17 at 10:28
2

What @Oli said. If you don't, in this day and age, have a fully-manageable switch infrastructure, your problem isn't that you can't find a rogue DHCP server. It's that you can't find anything. – MadHatter Aug 17 '17 at 10:53

score 38 · Answer 2 · answered Aug 15 '17 at 17:54

38

Found it!! It was my DCS-5030L D-Link Network Camera! I have NO idea why this happened. This is how I found it.

I changed my laptop IP Address to 10.255.255.150/255.255.255.0/10.255.255.1 and the DNS Server 8.8.8.8 so that it would be in the range of what the rogue dhcp was dishing out.
I then did a ipconfig /all to populate the ARP table.
Did a arp -a to get a list of the IP's in the table and there was the MAC Address for 10.255.255.1 which is the gateway of the rogue DHCP Server!
I then used Wireless Network Watcher from Nirsoft.net so I could find the REAL IP Address of the device from the MAC Address I found. The actual IP of the Rogue DHCP was 192.168.0.153, which was dynamically picked up by the Camera.
I then logged onto the Camera web page and saw that the it was previously set to 192.168.0.20 which was the IP Address of the rouge DHCP Server.
Then I switched it to a static IP and kept it as 192.160.0.20.

Now I can get on with my life!! Thanks to everyone for support.

answered Aug 15 '17 at 17:54

Dave Stuart

760
7
12

26

If your network camera was running a DHCP server I suspect it has been compromised with malware. No camera would run DHCP on purpose. I looked it up on D-Link documentation and it does have that ability to run a server but I'd be very surprised if it was configured that way on purpose. Check it for malware, many cameras have been hijacked that way. – Zan Lynx Aug 15 '17 at 19:00
3

Why in the world would a network camera have a DHCP server??? – RonJohn Aug 16 '17 at 00:36
14

@RonJohn so you can access its configuration webpage on a standalone network that doesn't have a DHCP server of its own. I agree that it's stupid for a device like that to have a DHCP server, but that's the reason they do it. – Moshe Katz Aug 16 '17 at 02:31
7

@ZanLynx No camera would run DHCP on purpose ... you haven't met a lot of software engineering managers have you ;) – txtechhelp Aug 16 '17 at 16:14
1

I just took a look at the user manual at ftp://ftp2.dlink.com/PRODUCTS/DCS-5030L/REVA/DCS-5030L_REVA_MANUAL_1.00_EN_US.PDF and it has the 192.168.0.20 set up as default even though it "looks" like it can't act as a DHCP Server. All I can say is that it was and boy did it make a mess of my entire network for devices looking for a Dynamic IP Address. Maybe one of my Routers was somehow using the Camera as a DHCP Server. Once I pulled the plug on the camera the rogue DHCP disappeared. – Dave Stuart Aug 16 '17 at 20:28
1

But then I gave it a static IP and used a gateway that pointed at a router that I was using Mail for (Port 25, 110 etc... all of them for mail) as well as websites on Port 80. Then my mail (SmarterMail) and web sites (IIS) broke! I had to change the gateway on the camera again to point at my WiFi Router's gateway and reboot the Mail router in order to get things back to normal, well at least until something else goes south. – Dave Stuart Aug 16 '17 at 20:29
3

The S in IoT stands for security. – Patrick M Aug 17 '17 at 16:59

score 18 · Answer 3 · answered Aug 15 '17 at 16:33

18

Do a binary search.

Disconnect half the cables
Using '/ipconfig release' test if it's still there
If so, disconnect another half of the remaining and goto 2
If not, reconnect the half of the previously disconnected first half, disconnect the second half and goto 2

This will divide the network into two each successive test, so if you have 1,000 machines it may take you up to 10 tests to find the individual port the DHCP server is running on.

You'll spend a lot of time plugging and unplugging devices, but it will narrow it down to the dhcp server without a lot of additional tools and techniques, so it'll work in any environment.

answered Aug 15 '17 at 16:33

Adam Davis

5,456

3

A better way to do the unmanaged switch unplug search. +1 – Todd Wilcox Aug 15 '17 at 17:27
I'd go after the switches themselves rather than the machines. That will narrow it to one switch pretty easily. – Loren Pechtel Aug 17 '17 at 04:05
@LorenPechtel yes, if you have multiple switches then the binary algorithm might only require disconnecting one or two cables to disconnect half the network. – Adam Davis Aug 17 '17 at 04:08

Aaron Tate · Answer 4 · 2017-08-15T04:10:58.143

You could just:

Open the network and sharing center (either from start or right click the network tray icon), click the blue connection link -> details.
find the ipv4 dhcp address (in this example it's 10.10.10.10)
Open Command Prompt from the start menu.
ping that ip eg ping 10.10.10.10, this forces the computer look up the dhcp server's MAC address and add it to the ARP table, be aware that the ping might fail if there is a firewall blocking it, this is ok and will not cause issues.
do arp -a| findstr 10.10.10.10. This queries the arp table for the MAC address.

You'll see something like:

10.10.10.10       00-07-32-21-c7-5f     dynamic

The middle entry is the MAC address.

Then look it up in the switches MAC/Port table as per joeqwerty's answer, post back if you need assistance with that.

No need to install wireshark.

The OP said he wasn't able to ping the DHCP server ip address and wasn't able to find the MAC address in his ARP table, which is why I posted my answer. He may or may not have any success with your suggestion, but yours is by far a simpler, more straightforward approach. — joeqwerty, Aug 15 '17 at 11:18

Rogue DHCP Server Can't be found

4 Answers4

Related