Introduction
Honeypots have the potential to level the cyber security playing field. They were out of style, but research regained momentum. Setting them up can take minutes, and having them in place creates a minefield for adversaries.
Production honeypots should be considered by every company to increase cyber defense performance, but research honeypots should be handled with care. I'll demonstrate a vulnerable setup with one of the most used research honeypots. Then, I'll explain why utilizing honeypots is an excellent defensive strategy.
Honeypot terminology
Research honeypots differ from production honeypots. Research honeypots are generally utilized for threat intelligence, such as monitoring the behavior of attackers and malware. Production honeypots tend to be less sophisticated and act as sensors (or 'tripwires').
The terms low-interaction and high-interaction refer to the ability for attackers to interact with the fake system. High-interaction research honeypots may allow simulated commands such as curl or wget to convince attackers to download their malware in order for researchers to analyze it. Low-interaction production honeypots are more focused on catching and discouraging attackers.
Honey assets are bait resources that aid in making a honeypot-like setup work, like a user account or a document that's put in place to trigger an alert or monitor behavior.
Research on research honeypots
Most honeypots used in research are - not surprisingly - research honeypots. They benefit from interfacing with malicious entities for as long as possible, to gather intelligence on attack vectors and ways of working.
Research on ICS honeypots flourished after Stuxnet (2010), DuQu, Night Dragon and Flame (2012) attacked critical infrastructure. 2019 saw a noticeable increase in the development of self-adaptive IoT honeypots for similar reasons. Many are closed source and have discontinued development after the initial research. [10]
Attackers can quite easily figure out that certain older generation honeypots are being used. Some can even be identified by nmap. [3] Later generations of honeypots do a better job at mimicking live systems, and they are a huge asset for global threat intelligence. For example, in a recent thesis from C. Scholten, taint analysis in emulated IoT device firmware is used to catch zero-day vulnerabilities. [11]
TrendMicro (2020) created a hybrid honeypot to simulate a complete factory by combining real ICS hardware with simulated components. Digital visitors were quite rude: they installed ransomware, changed settings and one just stopped the factory and left. As the researcher amusingly concluded: "Attackers will be mean and hurt your feelings". [8] In another research project, an attacker managed to perform a fork bomb in a honeypot to crash the EC2 instance it was running on. [5]
The complexity of research honeypots makes data control a challenge, as the systems must not allow actual production systems to get breached. [0] [10] This brings us to the original research question of this article: Can a honeypot increase my attack surface in such as way that I can get hacked? The answer is yes, it totally can.
An example vulnerability in the Cowrie honeypot
Cowrie is widely used in both research and production projects as a medium-interaction honeypot. [5][10] I've looked at the source code and found an easy vulnerability that allows an attacker to make web requests to internal addresses.
Do not set up a research honeypot unless you know the ins and outs of the software you're installing (this goes for all software, but sadly, it's hard to keep track these days). I think Kippo, the precursor of Cowrie, explains this best in their manual [1]:
Running a server that's available to the Internet - especially a honeypot such as Kippo - is not to be taken lightly. Even though Kippo is very easy to set up, if you don't understand 100% what is going on, honeypots are NOT for you.
By running kippo, you're virtually mooning the attackers. Just like in real life, doing something like that, you better know really well how to defend yourself!
Cowrie simulates commands such as curl and wget. The curl command works, but the code checks if you're not pointing to an internal IP address. If you do, it simulates that it can't resolve the host.
Three months ago, a developer created a TODO note with a clear description of a vulnerability, which made my search a whole lot easier.
No changes have been made to the source code since then. The note means that an attacker can make HTTP requests to internal services (essentially an SSRF vulnerability), so you better have none available in the same network as your honeypot.
In the example below I use AWS's EC2, since AWS's metadata endpoint is a common target for exploiting SSRF. I spun up a default EC2 instance, installed the latest version of Cowrie, and pointed the domain awsmeta.graa.nl to the internal metadata IP address.
The screenshot demonstrates me retrieving temporary AWS credentials from the AWS metadata endpoint via the Cowrie honeypot.
So if you deploy Cowrie, you better make sure it can't connect to internal network services that your adversary isn't supposed to play with. A honeypot that's allowed to interact with real systems inherently introduces risk. Do not deploy it without understanding what it does.
Production honeypots and honey assets
High-interaction honeypots are required to be believable, which comes with a risk. Production honeypots don't have this requirement and can take minimal resources to set up and maintain.
C. Moore's paper from 2016 uses Windows FSRM (File Server Resource Manager) to classify certain files. Events for those files are monitored via the Windows event logs, causing these files to act as tripwires. EventSentry is used as a monitoring tool to respond to file access. The paper suggests a hierarchy of responses (tiered response) to certain events, from alerting admins to shutting down a server. [4] Note that EvenSentry can be any software that responds to changes in logs, and that the tripwire files were created using only Windows tooling, requiring negligible changes to the infrastructure.
Work from J. Onaolapo's (2019) thesis on decoy accounts coins honey assets, which are bait resources such as tokens (honey tokens), documents (honey docs) and honey accounts. It gained media coverage and even funding. He also proposes a Honeypot Development Lifecycle, from system design to data analysis. [7] Again, the interesting insight is the effortless implementation of some honey assets, like creating a dummy user account to trigger alerts on usage.
The Black Hat talk Bring Back the Honeypots (2015) from Thinkst really brings the point home. A nice insight is that honeypots can change the playing field from the common saying "an attacker only has to be right once, defenders have to defend against everything" to a field where attackers have to make quite an effort not to step on a tripwire when performing lateral movement. They also introduce OpenCanary, which is an open source tool for installing canaries (sensors) in minutes. [2]
You can get creative with honeypots and honey assets, since fake services, canaries and decoys can be build into practically anything. There are even "fake honeypots", in which production systems are made to look like honeypots to add to the confusion. [6] The malleability of these resources allow defenders to manipulate the playing field to heighten their advantage.
On decoy systems
Some papers differentiate between the terms honeypot and decoy system. A decoy system is described as an advanced honeypot that generates believable responses in real-time, mimicking live systems. These are not for the faint of heart to implement.
The Tularosa and Moonraker studies (2019, 2020) found decoy systems to slow down and confuse attackers. In the Moonraker study, the control group was twice as successful at completing malicious tasks, and were about twice as fast. Feelings of surprise and confusion were profoundly lower. In the Tularosa study, 132 professional red teamers were observed. Just like the Moonraker study, participants who were presented with decoy systems were more confused and surprised. [6][9]
Recommendations
Sensors created with honeypots or honey assets are not that different from the monitoring sensors your SOC or sysadmin should already be using. However, honeypots come with less false positives and the added benefit of misleading attackers.
Think of places in your infrastructure where you can drop honeypots or canaries. You can create alerts when fake shares are browsed or when files are opened. Which steps, in terms of reconnaissance, would an attacker need to take before being able to launch a ransomware attack?
OpenCanary is a great tool for creating fake services. I've looked at the source code and it looks very secure. It offers low-interaction services, made for logging, to get secure tripwires without exposing real services on your network.
I've just spent 5 minutes to enable fake services on my VPS using OpenCanary. In the following screenshot of an nmap scan, one service is real. Can you figure out which one? And what would you do if you were trying to hack the server?
Fun facts
References
[0] Jiang, Xuxian & Wang, Xinyuan. (2007).
"Out-of-the-Box" Monitoring of VM-Based High-Interaction Honeypots.
4637. 198-218. 10.1007/978-3-540-74320-0_11.
[1] Tamminen, U. (2014, May 27).
Kippo: Frequently Asked Questions.
Github.
https://github.com/desaster/kippo/wiki/FAQ
[2] Marco & Meer, Black Hat. (2015, August 28).
Bring Back the Honeypots [Video].
YouTube.
https://www.youtube.com/watch?v=W7U2u-qLAB8
[3] Sher et al., media.ccc.de. (2015, December 30).
Breaking Honeypots for Fun and Profit [Video].
YouTube.
https://www.youtube.com/watch?v=HSoVvFT1NUo
[4] C. Moore, "Detecting Ransomware with Honeypot Techniques," 2016 Cybersecurity and Cyberforensics Conference (CCC), 2016, pp. 77-81, doi: 10.1109/CCC.2016.14.
[5] Higgins, A. (2018).
Adaptive Containerised Honeypots for Cyber-Incident Monitoring.
University of Dublin.
[6] Ferguson-Walter, Kimberly & Shade, Temmie & Rogers, Andrew & Niedbala, Elizabeth & Trumbo, Michael & Nauer, Kevin & Divis, Kristin & Jones, Aaron & Touva, Angela & Abbott, Robert. (2019).
The Tularosa Study: An Experimental Design and Implementation to Quantify the Effectiveness of Cyber Deception.
[7] Onaolapo, Jeremiah. (2019).
Honeypot boulevard: understanding malicious activity via decoy accounts.
[8] Charles Perine. (2020, October 1).
Faking a Factory: Creating and Operating a Realistic Honeypot [Video].
YouTube.
https://www.youtube.com/watch?v=4y7JJoZd0ic
[9] Shade, Temmie & Rogers, Andrew & Ferguson-Walter, Kimberly & Elson, Sara & Fayette, Daniel & Heckman, Kristin. (2020).
The Moonraker Study: An Experimental Evaluation of Host-Based Deception.
10.24251/HICSS.2020.231.
[10] Franco, Javier & Arış, Ahmet & Canberk, Berk & Uluagac, Selcuk. (2021).
A Survey of Honeypots and Honeynets for Internet of Things, Industrial Internet of Things, and Cyber-Physical Systems.
[11] Scholten, Christian. (2021).
Automatic Detection of Zero-Day Attacks in High-Interaction IoT Honeypots using Static Analysis Techniques.
The article was originally published on my LinkedIn, but I migrated all posts here.