Spread honeypots over your defense plan

I love honeypots. I’ve even written a book about them. Any time you set up a fake system that nothing and no one should try to connect to, you cull invaluable information that any security defender will find useful.

I’m still surprised that honeypots aren’t part of every organization’s security strategy. My guess is that’s because you don’t have a lot to choose from in honeypot emulation software. My personal favorite is KFSensor, which has a host of excellent features and is continually updated over time.

Why bother with honeypots? Well, when fine-tuned, a honeypot is incredibly low noise and high value. That’s exactly the opposite of every other computer’s security defense tool. For example, firewall logs fill up with of tens of thousands of dropped packet events every day, most of which have nothing to do with maliciousness. And the malicious actors? Good luck finding them in the logs.

The sweet benefits of honeypots

The work you invest in a honeypot takes place up front: You spend a little time filtering out the normal broadcast traffic and legitimate connection attempts (from your antivirus updating programs, patch management tools, and so on). But once that’s done — which usually takes two hours to two days — any other connection attempt is, by definition, malicious.

A honeypot is absolutely the best way to catch an intruder who has bypassed all other defenses. If you assume that your defenses are either currently breached or could easily be breached, then you need the early-warning system offered by a honeypot.

Your honeypots sit there waiting for any unexpected connection attempt. I’ve tracked a lot of hackers, and one fact almost always stands out: They search and move around a network once they gain access. Few hackers know which systems are or aren’t honeypots, so they move around, and when they simply “touch” the honeypot, you got ‘em.

Case in point: One of the most common attack methods is the pass-the-hash (PtH) attack, where the attacker gains hold of elevated logon credentials and uses them to access other systems across the network. They move laterally and horizontally with ease, usually without detection. But establish one or more honeypots as fake Web servers, database servers, or application servers, and you’ll even be able to detect an advanced persistent threat (APT).

Honeypots are also great at detecting insider threats, where someone who has legitimate logon credentials attempts unauthorized actions. In this scenario, it’s important that as few people as possible know about your honeypots. Give the project a code name that the project team uses whenever discussing the topic. You don’t want the word “honeypot” floating around in email or commonly known by your staff and other co-workers. Even other members of the computer security defense and the incident response teams should simply be told that you have “intrusion sensors.”

Honeypots are also great at detecting previously undetected malware. Today, some malware starts looking on the network once it breaches your defenses. Often it will try a multitude of common passwords against every network file share it can find. Make sure your honeypot contains NETBIOS or regular file shares to detect connection attempts.

The best place for a honeypot

In the early days, people often placed honeypots on the Internet or in the DMZ, but today, you’d get a swarm of unauthorized connections that would be impossible to sort through. If you can’t investigate every honeypot hit, then you’ve designed your honeypot wrong.

That’s why you should set up your honeypots internally, as a last warning. Look at how and where past attacks succeeded. Create threat models from past attacks and try to estimate future attacks. Determine where you have gaps in your current detection methodology and install honeypots to cover those gaps.

In general, I always recommend that honeypots mimic one or more Web servers, database servers, file servers, or application servers. I like low-interaction honeypots, which have a minimum of advertised services because they are extremely easy to set up and monitor.

For example, you could set up Microsoft Internet Information Server (IIS), using only the built-in website/page. When attackers connect to it, they will probably blow it off as a website that was never set up and move on. But now you have an unauthorized connection attempt (it’s a fake system, no one should be trying to connect) and you can add an originating IP address to your incident response analysis.

A lot of defenders want to set up high-interaction honeypots, which contain real-looking content, to see if they can ascertain the intent and primary target of the hacker. These honeypots take 20 to 50 times the effort to set up and maintain, and they come with all sorts of risks not present in a system that has almost nothing beyond a default advertising port/service.

Install a honeypot

As I already mentioned, I use KFSensor for emulated honeypots. There are a multitude of open source honeypot projects, many of which are more flexible than KFSensor and can emulate more actions. However, they are often hard to configure and maintain, and many people end up abandoning the honeypot initiative.

I’m a big fan of using real operating systems and devices as honeypots. When working with a real operating system, here are my basic steps (I don’t care if you use physical or virtual machine software):

1. Install a brand-new OS or use image that you already use for production systems
2. Install, configure, and patch the system as you would a normal production system
3. Install all the normal software as you would on a production system
4. Enable pervasive event logging, capturing every event possible
5. Enable packet capturing using port mirroring, for out-of-band capture and analysis
6. Looking at the logs, fine-tune out all legitimate connection attempts
7. Test attack scenarios you identified in your threat modeling
8. Send alerts when high risk events are noted
9. Respond to every alert
10. Modify as needed

How do I attract hackers?

Build it, and they will come.

If you’ve registered the honeypot systems in DNS, correctly configured the threat modeling, made them look as ordinary as possible, and placed them around your high-value assets, you’ve done a lot to encourage malicious intruders to connect to honeypot systems. In my career, I’ve never set up a honeypot that did not detect malicious activity within days of implementation.

If you’ve done everything correctly and still get no detection attempts, great! It means you have a high-value, low-noise, detection tool in your computer security arsenal. You’ll also have peace of mind that if badness gets in your network, your early-warning system will be ready.