A honeypot is a computer configured to be vulnerable in an attempt to log and study unauthorized interactions. Because Internet-facing systems are subject to constant automated attacks, it is important to be aware that any port open to the internet provides a bridge for outside parties to interact with your system. When we leave our honeypots out, we are mimicking signs of vulnerable systems hoping attackers come in and try to execute on their attacks. Think about that next time you’re looking at vulnerability reports. 🙇
Honeypots are used to collect data on attacking behaviors. The attack source, techniques used, their success or failure rates, and malware samples can all be extracted from honeypot logs. Security teams may take action based on intelligence sourced from the analyzed data. Patterns seen in the attacker’s behavior are identified within security logs to alert on security events that matched the behaviors observed in honeypot logs. Security teams are benefited because it give them a unique opportunity to proactively blocklist suspicious behaviors before systems are infected.
Research by individuals within the security community often target specific industries, products, protocols, or challenge widely accepted security standards against emerging technologies. Security researchers consider the kinds of questions they are looking to have their data answer. When applied to an organization, consider how honeypot data can be leveraged to mature your internal security posture. The questions here being, “What does the attack landscape look like?” and “How does that affect my existing resources?”
We can also use honeypots within an organization to capture modern malware and threat techniques at different points within your environments. The question here being “What types of threats is my organization actively facing and what do they look like?” These points may be located just outside your external firewall, within a demilitarized zone (DMZ), in environments frequently used by third parties, and/or within internal networks. When placed within internal networks honeypots monitor signs of trespassing not identified by security information event management software(SIEMs).
Note that while honeypots are a nice thing to add to a mature and well-documented security programs, they are unnecessary for basic security detection and protection processes. Honeypots should not be installed in the same networks as critical assets unless the security administrator can guarantee the asset will not pose a risk to surrounding assets. It is a good idea to reasonably segment honeypot systems from critical production systems in an attempt to prevent unforeseeable damage. For instance, upon brute force detection connections from an unusual IP could be forwarded to a quarantined asset for further data collection and analysis.
Honeypots share 3 common characteristics regardless of type or service:
- Honeypots are intentionally configured to be vulnerable;
- Honeypots are intended to be interacted with by unauthorized parties;
- Honeypots log unauthorized behavior.
Similar to honeypots exist honeytokens, which are used within enterprise resources to identify if an asset has been accessed and modified without authorization. As a safer alternative to honeypots, people will purposely seed false credentials, or honey tokens, for research purposes. This practice is like phishing for cyber criminals because the only way to validate stolen tokens is to log in.
Security Researchers from Atlassian, who developed Project Spacecrab, an AWS honeytoken open source tool set, reported that when credentials are posted to Github publicly they are used 83% of the time and within an average of 30 minutes. When the credentials are posted to Pastebin, however, only 9% were shown to be exploited. If you would like to learn more, check out Project Spacecrab and other free and open source software (FOSS) for honeytokens including honeybits, honeylambda, dcept, and honeyku.
There likely already exist honeypot solutions that apply to your specific industry and services used within your organization or even in your home network. I found FOSS Honeypots varied on two major dimensions: interaction level and service offered.
Honeypot interaction levels are broken down into low, medium, and high interaction honeypots.
Low interaction honeypots extend few behaviors to an attacker. Often, just enough to allow a connection. Data collected from low interaction honeypots are often limited to attacking IP and the username and password combination attempted accompanied by event timestamps. Examples include: ADBHoney, Honeyd, mysql-honeypotd, HoneyPy.
Medium interaction honeypots extend some interaction to the attacker (i.e. bash shell). The distinction here being that a piece of a real system is emulated, attackers are not an not given a real environment, shell, or operating system — or at least not the one it appears to be. Examples include: Kippo, Cowrie, sticky_elephant, hornet.
High interaction honeypots are more intensive both computationally and in risk consideration as full behavior is extended to the attacker and nothing is emulated. Examples include: Capture-HPC, Pwnypot, SMB Honeypot, HIHAT.
Beyond interaction level, honeypots are categorized by the service they emulate. These services are varied and attempt the same core mission — to emulate real systems in use in real industries. Examples of common honeypots service categories include database, web, industrial control system (ICS), supervisory control and data acquisition (SCADA), and secure shell (SSH). If you’d like to learn about other honeypots check out this awesome-honeypots list by paralax. 😎
If you’re interested in standing up your own honeypot I’d encourage you to check out this SSH honeypot how-to article. This will give you a feel for what a honeypot is, how it’s used, and introduce you to some common problems associated with big data analysis and gathering security intelligence.