Please note that some of the links below may be affiliate links. As an Amazon Associate I earn from qualifying purchases.

For the last several years, I’ve been working on a honeypot system to detect “east to west” internal traffic that doesn’t go “north to south” to the internet. The reason is to detect potential threat actors moving laterally in the network. While this doesn’t catch all internal to internal traffic, it does alert on internal traffic to the device. The need for such a device came from a job several years ago.

At a place where I worked, the managers would comment that we could see North-South traffic to and from the internet. But we couldn’t detect potentially malicious East-West traffic internally between systems. We could see East-West between Zones, but not systems in the same zone.

Which lead to the suggestion of Honeypots. Both Management and Legal said we can’t have a honeypot because they believe them to be entrapment devices. Management also didn’t want to give threat actors a beachhead device to take over and use to attack other devices.

What was needed was a device that could act like an alarmed/monitored door, that would alert when used. Something that had next to zero interaction. It took a couple of years but I found a workable solution with Chris Sanders’ Intrusion Detection Honeypots (affiliate link).

Background:

I first came across the concept of a honeypot working on the networking side in the late nineties and early aughties. I remember in the early aughties hearing about the LaBrea Tarpit honeypot made by Tom Liston. I think I heard of some other ones at the time, but I never looked into the topic of honeypots too deep, because it didn’t fit the space I was working in at the time.

In the mid to later aughties I read a few books. Cliff Stoll’s The Cuckoo’s Egg (affiliate link), and Bill Cheswicks Firewall and Internet Security book (affiliate link). The book can be found in PDF form on Mr. Cheswick’s website, too.

In Cliff Stoll’s case, while not using the term honeypot, he created a honeypot designed to delay the threat actor by providing fake military information in the late eighties. *Spoiler warning* The delay action was meant to keep the threat actor connected to the phone system in Germany so the German Phone company could trace the call. *End Spoiler Warning*

Sometime shortly after The Cuckoo’s Egg, I read Bill Cheswick’s book. One of the things that stuck out, was Chapter 16 “An Evening with Berferd” where Mr. Cheswick, in 1991, simulated a honeypot by hand to track an attacker. If I remember right, his team created a slow jailed system to keep the threat actor busy. This honeypot was built on a series of decisions that Bill Cheswick made along the way.

Known Honeypot projects and types:

While there are multiple honeypots out there like Glutton, Cowire, Conpot, Dionaea, and others found at The Honeynet Project, none of them fit my needs. Remember, we want almost no interaction, not low.

Honeypots come in interaction types: Low Interaction, Medium Interaction, or High Interaction. This means providing an amount of service or operating system to use. Low-interaction honeypots don’t give much to the threat actor but does emulate a small amount of the protocol or service being used. High interactive systems will provide simulations of complete operating systems for the attacker to use. Medium is between the two spaces.

Again, I was looking for something that could act as an alarmed/monitored door. It didn’t have to respond to the threat actor accessing it, nor an environment to run commands.

Honeypot Types:

While I disagree, most sources I referenced online claim there are two categories of Honeypots. Research and Productions.

Research honeypots tend to fall under academic areas for monitoring threat actor actions and the spread of the types of attacks being used. People use these honeypots to detect different types of mass scanning, credential stuffing, and track internet worms and other malware. SANS DShield is an example of a research honeypot.

Production honeypots are used to monitor threat actors on the network to see the types of threat actor actions being used in the company. These could be attacks that generate SIEM alerts or not. But the honeypots focus on the attacks in their environment not all the attacks on the internet.

But I didn’t need something to monitor the keystrokes or scripts the attacker used to attack the device. My need isn’t about seeing the attacks being used, and it’s not about seeing how the malware is spreading. That information is secondary if it is collected (sometimes it is). What I needed was a type of Intrusion Detection system. While Intrusion Detection Honeypots would probably be considered Low Interaction of Honeypots, I would consider the ones I’m using as Zero Interaction devices. There is no service or portion of the operating system environment to work with. It’s a port that doesn’t reply to the traffic to it beyond the handshake, if there is one.

Back to the original need:

I had already introduced a few honeytoken concepts into the business, using Thinkst’s Canarytokens and others using web images embedded in documents on our servers (future post). Those were great, but they relied on the threat actor accessing those files. What we needed was a way to know if someone was trying to find systems that no one should be accessing.

I had already read John Strand, Paul Assadorian, Ben Donnelly, Bryce Galbraith, and Ethan Robish’s Offensive Countermeasures: The Art of Active Defense (affiliate link) but couldn’t get buy-in to implement the honeypot tools. However, Chris Sanders’ book showed how Netcat was used on a device to monitor a port for Intrusion Detection. He set up his to reply with traffic, but that would make it more interactive than I was looking for. But it was a starting point.

Because there was no real process running behind the listened port, and thus no response to traffic to it, I got management and legal to buy off on it, or at least a POC.

I now had the concept for a tool that “should never be interacted with, and any interaction should be assumed to be malicious.” (Strand, p.28, 2017).  Now I just needed to make some decisions and build it.

My decisions for the device:

I wanted something Linux-based that could be left behind to run without taking up much space (think easy to deploy under a desk or the back of a monitor) and would need most of the dev time done on the weekends at home. Which lead to my decision for the honeypot:

1. I wanted something small, and portable that could be quickly deployed to detect potential traffic.
2. Have two network ports. One for listening and one for log shipping and administration.
3. Something I could modify to mirror different parts of the network: user vlan, server vlan, etc.
4. Be able to log inbound connections.
5. Be able to monitor directly.
6. Provide zero services to the threat actor to use.

If you’ve read my blog, you know I’m a fan of the Raspberry Pi. I think it’s a good development/test platform, which makes it good for Proof of Concepts.

For the most recent version of this project, I used a Pi 4, 4 GB Cana Kit (affiliate link) with an extra Amazon Basics USB to Ethernet adaptor (affiliate link).

This meets my need for something small and portable. The secondary network card lets me have a network port for administration and log transfer and a second to listen for incoming traffic. The installed packages on the Raspberry Pi OS without the desktop let me change the listening ports based on need. Because it’s a listener only, it gives zero services to the threat actor to use.

Since it’s not publicly known in the company the only access to it is going to be automated tools or threat actors. Both need to be looked at. Again, to reference John Strand, something is triggering the monitoring system, the question is why and what needs to be tuned to fix it? Tuning in this case doesn’t always mean tuning out the alert, it could be fixing a tool.

In the next post, I’ll walk through setting up the device.