Need to avoid a honeypot? Here’s how

We like honeypots on your internal network – they’re an awesome, cheap way of picking up rogue activity. Why would anyone legitimately be port scanning or attempting to exploit your internal network without your knowledge?

They’re also a great way of tripping up your pen testers!

So, when we’re testing, we need to be a bit more stealthy. You suspect there are honeypots on your target network. How do you avoid setting off the alarms, whilst still finding and exploiting useful hosts?

No ports scans, no ping sweeps, no vulnerability scanners. Don’t go looking for open services, go passive and LISTEN instead.

Maybe run an ARP scan to find out about the local subnet. Get all the hosts to confirm which IP address they’re on, so you have a list of potential targets, but you still don’t know which are the honeypots.

Then, fire up Wireshark, look out for NetBIOS name server requests. You can work out which hosts on the network are workstations, servers, DCs, etc.

More importantly, it’s highly unlikely that honeypots are going to be in any of the NetBIOS name server requests.

Why would a workstation make a NetBIOS name server request from a honeypot? It wouldn’t, as the honeypot isn’t offering the client a service that it would be interested in.

Hence, servers that don’t have NetBIOS name server made of them are potentially honeypots. There will be plenty of other reasons why a server wouldn’t have a request made of it, but it’s a big red flag for the attacker.

So, you now have a set of candidate servers on the network that are much more likely to be honeypots. Don’t scan them if you don’t want to set off alerts!

What can you do to stop this?

Good question! How about setting up a client workstation (a honeyclient?) to make valid NetBIOS name server requests of the honeypot? It would generate a lot of alerts from your honeypot, but at least you can suppress these, as you know the IP addresses of your ‘fake’ clients.

Alternatively, install the honeypot software on a real server, and just suppress the alerts on the particular service port. For example, if you were running a UNIX webserver, you could still alert on traffic to standard Windows file sharing ports.

This does underline that a honeypot is just part of your intrusion detection and prevention strategy though. There are no magic bullets!