Honeypot: Efficient and Cheap Way to Detect LAN Attacks

There is a lot happening in our company lately. In the last two months, two great new colleagues, Petr and Jarda, have come to us and the third one is on its way. Thanks to the higher work capacity, my hands have been relaxed and I can focus more on developing our technologies.

In the last article, “Security Life Cycle“, I wrote that everyone does restrictive security measures. However, security will never be 100% just because there is an imbalance between the attacker and the defender. A single system fault is enough for an attacker to break in. While we, the defenders, must not have a single system error in the entire system! That’s a pretty unrealistic idea.

For this reason, there is a need for some networking technology (ideally more) to detect that an attack is occurring and to alert us. Try to think about it, would you be able to detect an attack? How? And now I don’t mean botnet attempts to break internet facing services. 🙂 Probably it is not just for nothing that the time of intrusion detection is in months (see FireEeye report).

We have some methods and systems to detect an attack (see the article above). But the technology I am writing about now and which we will be deploying to our customers within a few weeks will be our champion in price-performance ratio.

But enough wandering around, let’s do it.

What does an ideal attack detection system look like?

In my opinion, the ideal attack detection system should have the following parameters:

• Minimum of false detections – Detecting each attack and no false detections. False detections, when normal activity is misidentified as an attack, are annoying. Moreover, when something really happens, you will ignore it. As if someone would call “fire” every day. Firefighters would arrive twice, but no one will appear again on the third day, even if it is truly on fire.
• The lowest possible costs – if the security system is more costly than what it is supposed to protect, it is not good.
• The shortest possible maintenance time – there is a shortage of good people, we cannot waste their time on maintaining another system.

I think that honeypot in the form I describe it in the article has these qualities.

How and when to detect an attack

The best way to detect an attack is when it is happening – it is when the attackers are the “noisiest”. They scan the network, test passwords, exploit and use various administrator/hacking utilities. At this stage, you can still defend, for example, to cut off an attacker from the network, cancel compromised accounts. However, once the attack is complete (the attacker has what he came for – the data, a hidden backdoor to the network), the detection is hard to do. And thanks to a hidden backdoor, the next attack can be blitz – network/server/IS unavailable in minutes.

In general, you need to detect activity on a network that ordinary users never do, but attackers always do. What I have learned and always do in penetration tests is the “exploration” phase. When an attacker enters the LAN (eg, via wifi, spear phishing, plugging the probe into the network), he finds himself in an unfamiliar environment (your network) and must, therefore orientate himself. He will seek to locate the facilities and services through which he will get closer (“lateral movement/privilege escalation”) to achieve his goal (data theft, paralyzing the company, influencing the business).

Our goal is to detect an attacker during the exploitation phase. We will do this by connecting a “bait” (honeypot) to the network. Honeypot will wait for someone to try to contact it. Since it is a device that no one knows exists, ordinary users will not be able to connect with it. I assume that users do not entertain themselves with IP scans, port scans and logging on to foreign services during business hours.

Conversely, an attacker is not in the network to perform data entry into your IS as employees do. But to find a vulnerability through which he gets closer to meeting his goal in the network. And finding the device itself (or scanning its ports) or attempting to log in to some services will trigger a notification to the network administrator. Therefore, I expect the honeypot solution to be reliable and to have a minimum of false detections (the attacker always scans the network, including the user not at all).

Failed plans to present

I have thought we could use honeypots in our customer networks a few years ago already. Many customers use virtualization. I thought we could deploy Linux virtuals with some open source honeypot (list of interesting honeypots). This would mean saving for HW and SW.

Unfortunately, I didn´t manage to find suitable software for honeypot back then. What I found was created for use on the Internet for statistics (from where attacks are performed), or to capture malware samples. Honeypots were made for “noisy environments” (where attacks happen in just a matter of a few seconds). But I needed something that was done for “sterile/silent” corporate networks where no attack should occur. I have eventually put the thing down.

I have recently come across the lecture “Haroon Meer/keynote – Time to play‘ D‘” (see video below). She was great – she talks to my soul. I have tried to find more of her lectures and came across “Bring Back the Honeypots” (see video below). Bingo, Haroon did exactly what I needed. Honeypot for internal network: sensitively tuned to serve as an attack detector. They have released the SW as open source (OpenCanary) and also have a commercial version of Canary.tools  ($10,000 for 5 devices).

What honeypot OpenCanary can do

OpenCanary is an open source low interaction honeypot written in Python. It can “simulate” the following services: FTP, HTTP, HTTP proxy, MS SQL, MySQL, RDP, SMB, SIP, SNMP, SSH, telnet, TFTP, VNC, portscan. Any attempt to interact with these services will then be emailed to the administrator.

Since it is a “low interaction” honeypot, the service simulation is usually limited to the login phase (including the service banner). But it does not matter, because the fact that someone is trying to log into (in the e-mail notification from honeypot the administrator gets the source IP and login credentials) an FTP server that no one in the company knows exists is a sign of “problem” in the network.

You can choose what services will honeypot simulate for yourself. It would be ideal to try a real one (to make the attacker believe it) and interesting (to be interested in trying some interaction) combination. For example, create one honeypot called “Server-backup” with FTP, SSH, and SMB services and put it in a VLAN with servers. Then create a second named “PC-Admin” with VNC, RDP, and MS SQL and put it in VLAN with PC. I think both of them will sound interesting enough for an attacker to “try” the service a little and reveal himself to you.

Because it is open source, you can code missing services/modules. For example, we are working on a new reporting plugin that will send data to our IS instead of an email (we will have better reporting and log correlation).

The best part is that you can run OpenCanary on a virtual Linux server (256MB RAM, 1 CPU, 4GB HDD is enough to run it) on existing infrastructure. This will cost you 0 CZK for purchase. Which meets my next requirement for the lowest possible cost. And no one can complain about missing investments from the management. 😉

Why it should not work – arguments

As Haroon’s lecture says, we can sometimes be overwhelmed by the mood to maintain the status quo and the idea of why it should not work.

• The attacker detects honeypot and avoids it. Yes, the attacker sooner or later finds out that he is communicating with the honeypot. OpenCanary is just the “low interaction” honeypot anyway. That means it just mimics the services. However, in order for the attacker to find out that it is a honeypot, he must first contact it (eg port scan and practice connection/login to a service) and that is what we want. Our goal is for the attacker to join the honeypot and reveal himself.

• It’s a nice technology, but first I need to deploy AppLocker/UTM/2FA. I think the use of honeypot (or other detection technology) is more important than restrictive measures. In my opinion, restrictive measures will never be complete. There will always be something to deploy/improve and the SW is full of undiscovered errors. Remember, all an attacker needs is a single error to get into the system while you as an admin need to secure everything (these are no fair conditions). All the more you need the technology to let you know if restrictive measures were overcome.

• Honeypot will be just another vulnerable device on the network. Yes, the device may be hacked. But it doesn’t help much. There is nothing confidential on the device, nor does it have access to anywhere that the attacker would not have (otherwise he would not get to the honeypot). Plus, honeypot still fulfills its mission – sending a message of the attack before falling into the attacker’s hands. 🙂

• It will fight the network scanning technology we use. There are a number of solutions, ranging from setting some IP exceptions, time rules, or completely shutting down the port scan detection module.

How do we aim to deploy it?

I want our honeypot to be a cheap box that just needs to be physically plugged in and to not to worry about it but to get notified only once it detects unwanted activity in the network. (ie, minimum maintenance time).

That’s why I have built our honeypot using Raspberry Pi 3 Model B+ (priced at 1 300 CZK incl. VAT with a box and SD card). It runs OS Raspbian (Debian port) with automatic updates, OpenCanary, and agent for our monitoring system. The honeypot can look like a vulnerable Linux and Windows server and only interaction is once it detects unwanted activity or has other problems (eg HW fails).

Few notes:

• Installation: The box just plugs into the network. It loads IP from DHCP itself and connects to the monitoring system. It can be transferred and plugged into another network or VLAN at any time without having to change anything.
• Problem detection: If the honeypot stops reporting (eg, HW dies, or service fails), the monitoring system sends an email and the event is also displayed in the monitoring system dashboard.
• Attack detection: When honeypot detects an attack attempt, it sends an e-mail notification with the logs and also displays the event in the monitoring system dashboard.
• Remote administration: Honeypot VPN tunnels to our company in case of configuration modification (it also runs Teamviewer, but VPN tunnel allows us to better connect to our RDM password manager, which will be much more comfortable).

I already have a functional prototype of honeypot at the time of writing of this article. I’d like to deploy it in the upcoming weeks at a few of our customers. If everything works well, the rest of the customers who have a segmented network will get one as well. Wish us luck!

Conclusion

I hope I have managed to convince you of the need for some detection technology. Maybe you can try it with OpenCanary too. The same service as OpenCanary is offered by CanaryTokens. I will try to write more about it next time (but if you saw the lecture I have mentioned, the benefits of the service are clear to you). Again, as always, I’ll be happy for your feedback.

PS: If you are interested in OpenCanary but don’t have time to play with it yourself, please contact me (martin.haller@patron-it.cz). We could send you our prototype, including access to the monitoring system and debug it together.