Since the start of the Internet, honeypots have been a very valuable defensive strategy. No matter how simple or complex they are, they definitely add a lot of value to your security posture. Clifford Stoll and his marvelous book The Cuckoo’s Egg is always referenced as one of the first deception use cases in cybersecurity, but since then, many organizations have used deception in order to level up their defenses.
When we talk about deception, we should start by describing the different use cases, which can vary depending on maturity:
- Deception for pure and rapid detection: Honeypots can give you real-time alerts that something malicious is happening. By definition, no one should ever interact with the honeypots you have deployed, so any alert is worth having a look. This means a great signal-to-noise ratio and something that can ease your security team’s alert fatigue.
- Deception as another valuable source of threat intelligence: The TTPs and IOCs that you can collect from your deception environments are unique intel that you are gathering from attackers attacking your organization.
- Deception for testing your threat hunting hypotheses: Once you have created threat hunting hypotheses, you can easily use honeypots for testing whether they are valid or not.
- Deception for engaging with threat actors: This is the most mature use case. Once you already know the TTPs from the threat actors that are likely to target your organization, you can deploy customized deception environments that will be very attractive to them.
At the same time that deception techniques were actively being adopted by many organizations, many methods for fingerprinting them were also developed. But there is a huge difference between fingerprinting emulations versus fingerprinting real applications, operating systems or even cloud services.
Evading honeypots
The bottom line is that only when it comes to detection (the first use case) can emulations be used effectively. This is because we are interested merely in someone interacting with our asset. On the other hand, in the other three use cases, the use of emulation or low-interaction honeypots is completely ineffective— attackers will quickly identify that they are not real environments and will ignore them.
In these use cases, credibility of the environment is key to success. That is the main reason for always using real assets, and also to generate credible content in those assets.
Let’s have a look at some of the honeypot detection approaches that are now publicly available, and we will see how they can be successful only when honeypots are abusing emulations or misconfigurations.
In 2004 there was a CVE affecting honeyd (CVE-2004-2095), a famous low-interaction honeypot where it was possible to easily fingerprint a honeyd installation just by sending a specific TCP packet. It meant that sending a single TCP packet, with both SYN and RST, to an open port could solicit a reply from Honeyd. No other machine on the Internet would reply to such a packet. Apart from this bug, just by measuring the latency of the network packets, an attacker could identify a honeyd installation, as discussed in this article.
In 2006, Jon Oberheide created a tool called ‘Winnie’ that could also fingerprint a honeyd installation due to a bug in the “IP fragment reassembly code which does not follow RFC 791. Honeyd incorrectly omitted the IP protocol number when searching for corresponding fragments for reassembly. By constructing a fragmented TCP SYN packet with a different IP protocol number in each packet, it is possible to elicit a SYN/ACK response from addresses monitored by Honeyd, thereby exposing the honeypot deployment.”
At that time there was another famous low-interaction honeypot called Nepenthes, that was a “low interaction honeypot like honeyd or mwcollect. Low Interaction Honeypots emulate known vulnerabilities to collect information about potential attacks. Nepenthes is designed to emulate vulnerabilities worms use to spread, and to capture these worms.” In this case, fingerprinting Nepenthes could be really easy as it was exposing many services, like a Christmas tree.
PORT STATE SERVICE VERSION
21/tcp open ftp
22/tcp open ssh OpenSSH 4.3 (protocol 2.0)
25/tcp open smtp?
42/tcp open nameserver?
80/tcp open http?
110/tcp open pop3?
135/tcp open msrpc?
139/tcp open netbios-ssn?
143/tcp open imap?
220/tcp open imap3?
443/tcp open https?
445/tcp open microsoft-ds?
465/tcp open smtps?
993/tcp open imaps?
995/tcp open pop3s?
1023/tcp open netvenuechat?
1025/tcp open NFS-or-IIS?
2105/tcp open eklogin?
3372/tcp open msdtc?
5000/tcp open UPnP?
10000/tcp open snet-sensor-mgmt?
17300/tcp open kuang2?
As we can see, any low-interaction honeypot could easily be fingerprinted. However, they would be a very valuable source of detection as they would at least identify that someone is trying to fingerprint them. Let’s take a look at how honeypots are currently being fingerprinted.
One of the first Internet mass-scanning services that started to fingerprint honeypots was Shodan. Shodan includes a honeyscore if they are able to identify a honeypot. Again, the majority of these detections are low-interaction honeypots that can be easily fingerprinted.
One of the most common examples is the use of Conpot, an OT low-interaction honeypot. As you can see in the following images, Shodan tags those findings as ‘honeypot’ as they always respond with the same data:
Another fingerprinting technique for honeypots is the use of JA3 hash. The JA3 hash is a fingerprinting technique used in network security to identify and classify the cryptographic properties of a TLS (Transport Layer Security) handshake. It has been a staple for incident response teams and threat intelligence platforms since its fingerprinting technique was published by Salesforce in 2017. The hash allows for quick identification of hacking tools like Cobalt Strike, Sliver beacons, and SQLmap, and is reliable over time because threat actors often reuse such tools without modification.
When a client and server establish a secure connection over TLS, they exchange a series of messages called the handshake. The JA3 hash is generated by analyzing the specific characteristics of this handshake, such as the TLS version, supported cipher suites, and extensions used. The combination of these attributes is unique to the cryptographic configuration of each TLS client or server.
There is a good series of articles describing how you can use JA3 hashes in order to fingerprint honeypots in the Ghost website:
Evading fake accounts
As we have seen, there are a number of methods to fingerprint low-interaction honeypots, as well as some misconfigured high-interaction honeypots (that are not randomly generated or that they don’t include any credible content). But can fake accounts created within the honeypot environment to attract and observe potential attackers also be detected? How can you be sure whether an account is real or not?
Again, it depends on the context and the credibility of the user account. If we just create a user account but that account never logged in, or it does not have anything in their home directory, definitely is a suspicious account. Re-using the Honeynet Project naming convention, we could differentiate the following accounts:
- Low-interaction accounts: those that are just created but don’t include any history or content (emails, files, authentications, password changes, etc.)
- High-interaction accounts: those that include a context and history and they are actively used.
Just like with with the honeypots, detecting low-interaction user accounts is often easier than detecting high-interaction user accounts. An example is the HoneypotBuster tool, that can identify fake accounts in Active Directory:
- Kerberoasting Service Accounts Honey Tokens
- Fake Computer Accounts Honey Pots
- Fake Credentials Manager Credentials Breadcrumbs
- Fake Domain Admins Accounts Honey Tokens
- Fake Mapped Drives Breadcrumbs
- DNS Records Manipulation HoneyPots
One of the main methods used by HoneypotBuster is counting the number of logins and checking the date of the last login of any user in order to fingerprint any fake account.
What is the recommended approach?
If rapid detection (the first use case) is the only goal, then we shouldn’t care if an attacker is fingerprinting any of our deception deployments, as we will detect that first interaction and trigger an alert. However, this approach is limited in how effective it can be, especially for more sophisticated threats.
If we are more interested in the other use cases, emulated honeypots are rendered useless. We should definitely only use real assets (high-interaction honeypots) in our environments, as well as being able to continuously update those assets and any user accounts that we are using almost in real time. Otherwise, the use of honeypots is futile. Credibility a key goal of the entire defense strategy.
At CounterCraft, we have a deep expertise in those three advanced use cases, as well as the most advanced credibility technology in the industry, so please contact us if you are interested in learning more.
Find out more about how credible honeypots and deception environments can take your security beyond detection.
David Barroso is a founder and CTO of CounterCraft. You can find him on LinkedIn.
See it for yourself.
Spend 20 minutes with us to see why the world’s most sophisticated organizations, including the U.S. government, are using our deception technology platform for active cyber defense, freeing up resources and staying ahead of threat actors.
