43

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.

16
  • 12
    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.
    – user143703
    Aug 15, 2017 at 2:37
  • 7
    Can you unplug everything and put things back on the network one at a time?
    – R. S.
    Aug 15, 2017 at 2:45
  • 1
    1) You can likely see the MAC of the rogue server (if the trojan didn't change it), and - if you don't have a list from the MACs of your clients - then you can grep for it in your earlier (yet clean) DHCP logs. 2) If nothing other works: plug out half of the machines from the net, check if he still is here. So you will know, in which half is the bad guy. Then so the same in found half, and so on.
    – peterh
    Aug 15, 2017 at 4:16
  • 4
    What router? It could be that the router itself is infected.
    – J...
    Aug 15, 2017 at 10:22
  • 1
    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. Aug 15, 2017 at 16:49

4 Answers 4

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.

6
  • 1
    How can I view the MAC address and ARP tables of an unmanaged switch?
    – Dai
    Aug 15, 2017 at 9: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, 2017 at 10:15
  • 1
    @Dai What make and model is the switch? Aug 15, 2017 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. Aug 15, 2017 at 13:01
  • 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, 2017 at 10:53
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.

  1. 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.
  2. I then did a ipconfig /all to populate the ARP table.
  3. 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!
  4. 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.
  5. 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.
  6. 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.

7
  • 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, 2017 at 19:00
  • 3
    Why in the world would a network camera have a DHCP server???
    – RonJohn
    Aug 16, 2017 at 0: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, 2017 at 2: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, 2017 at 16:14
  • 3
    The S in IoT stands for security.
    – Patrick M
    Aug 17, 2017 at 16:59
18

Do a binary search.

  1. Disconnect half the cables
  2. Using '/ipconfig release' test if it's still there
  3. If so, disconnect another half of the remaining and goto 2
  4. 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.

3
  • 3
    A better way to do the unmanaged switch unplug search. +1 Aug 15, 2017 at 17:27
  • I'd go after the switches themselves rather than the machines. That will narrow it to one switch pretty easily. Aug 17, 2017 at 4: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, 2017 at 4:08
17

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.

1
  • 4
    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, 2017 at 11:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .