Diversion Tactics: Using Vulnerable Windows Servers to Fool Hackers

Even in the modern technology startup where the majority of infrastructure is hosted on cloud platforms, it is not uncommon to see a stray Windows server on the office network. There are plenty of logical reasons that a single Windows box may be on an office network, even if there is little other infrastructure. The server could be a local Domain Controller, file or print server, or even a host used to run the proxy card software that governs access to the office.

For pentesters, finding these boxes always brings a smile. There is no shortage of tools and techniques available for attacking Windows servers. And the complexity of attacking these servers has been reduced to a level that even novice attackers can pull off.

Due to this fact, Windows Servers are practically irresistible to hackers everywhere. This makes the lone Windows Server a perfect candidate for a honeypot. How better to divert a hacker’s attention from what matters than by giving them what they think is an easy win?

Getting in the mind of your opponent.

As mentioned above, a lone Windows Server sitting on the network will nearly always be a top target for hackers, ethical and not-so-ethical alike.  Especially if you place a legacy Windows 2003 Server on the network, within a separate subnet to make it appear that IT has tried to quarantine this legacy system but done a poor job of it.

A Windows 2003 server can be easily popped with multiple pre-built exploits pre-loaded in the free platform Metasploit.  These exploits are used to deliver a number of popular payloads such as reverse TCP shells or Meterpreter sessions. Within minutes, the credential theft tool Mimikatz can be used to dump all the passwords on the box in cleartext. This is hacking 101 and pulling it off never gets old.

The experienced hacker might take pause before attacking such a juicy piece of prey and consider that this could very easily be a trap. In my experience, this is rarely considered to be the case for two reasons:

  1. Many hackers tend to be a bit jaded and assume most of their victims are unskilled, lazy, or too stupid to set up such a trap.
  2. Many well-meaning organizations still have Windows 2003 servers sitting around in their networks for a variety of reasons. These reasons may indeed be due to laziness or lack of training but could also to a need to support legacy systems, or underfunding.

Ideas and Caveats for Setting Up a Windows Server 2003 Honeypot

There are a few things to consider when deploying vulnerable Windows 2003 server as a honeypot on the network. Remember, the primary reason for this server is to draw attack and tip off your security ops and incident handling team.

Segregate the Box but Make it Discoverable

If possible, consider locating the Windows 2003 honeypot server among a cluster of updated servers in the same IP network but within a different layer 2 network to minimize damage from ARP poisoning and other network-based attacks.

Make the server easy to scan and identify on the network but block other systems on your network from talking to this machine. An endpoint firewall rule implemented via your configuration management application would work. You could also roll out a rule via your enterprise endpoint protection solution.

Set Up Monitoring and Be Alert

Place monitoring on this system that creates a high-risk alert as soon as anyone authenticates to that system. This tactic works because it is more common than you think to find legacy Windows servers in environments. Most attackers will not be able to resist going for the easy kill.

Manage Access to the Box Appropriately

Configure a set of special credentials developed just for that server that are not used elsewhere. As mentioned above, the attacker will be able to dump the passwords in cleartext quickly on a Windows 2003 machine with Mimikatz. Do not join the server to the domain in order to limit exposure to other Windows servers in the domain.

Have the Correct Control and Infrastructure in Place to Respond

Test your logging and monitoring capabilities and be confident in your incident response procedures. Once the machine is compromised, the attacker will be able to use it to their advantage. Implementing a honeypot is an intriguing idea, but without the right controls in place, it will do more harm than good.

Expand Use of Honeypots with Caution

Be wary of putting honeypots on the public internet. An attacker who has access to one of your servers on the public internet could use that system to attack other companies or pivot into your network.

Please share any critique, ideas, and experiences below. We are always learning and looking for ways to improve.

Leave a Reply