Honeypots, Honeytokens and Some Things to Consider Before Deployment

Looking to lure cybercriminals to your doorstep? Enter honeypots and honeytokens. They are a safe environment to lure bad actors and see how they work. Specifically, honeypots are systems or servers that are meant to be attacked and honeytokens are tokens or objects that when interacted with would indicate an attack. 

What are honeypots and how are they used?

There are various use cases for honeypots. One of the use cases is research. For example, one of the popular honeypots we’ve seen and used are SSH honeypots. SSH honeypots were put on the internet to observe what credentials the attackers or bots are attempting to use brute force or login to a system. One of our findings is that the attackers were using default credentials for some popular IoT devices. Additionally, we discovered that the attackers were deploying cryptocurrency miners or DDoS bots.

Researchers also set up new honeypots for a new attack or threat. For example, if I’m aware that someone is compromising Exchange Servers, I could set up a vulnerable Exchange Server and see what the attackers do after compromising it.

Another use case for honeypots is to detect an attacker inside of a network. From various reports and forensics incidents, we know that after initial compromise, some of the attackers like to scan the network and look for RDP and file shares. Implementing a honeypot for detecting signs of scanning would help us detect this behavior earlier in the attacker life cycle. 

There are various types of honeypots when it comes to interactivity. There are low and high interaction honeypots. Low interaction honeypots just provide basic functionality of a system they’re pretending to be. High interaction honeypots are very close to a real system that they’re pretending to be and provide a lot of functionality.

The nature of having honeypot systems does increase your attack surface. A honeypot system is just another system and just another application that could also suffer from vulnerabilities or bugs. When considering deployment, attack surface and risk of deployment should be considered as well.

What is a honeytoken?

Honeytokens are objects such as API keys, files, etc. that when opened or used indicate that someone was able to access them. For example, a honeytoken could be an API key that is saved in a database somewhere and use of that key would indicate compromise of that database. Files can also be tokens as mentioned before. Certain file types will make a network connection when opened. This functionality can be used to detect a file being stolen and opened by an attacker.

Things to consider before deploying honeypots

There are some things you should consider before deploying a honeypot. 

What needs to get detected?

Placement of the honeypot and the type of honeypot would depend on what your organization is hoping to detect. For example, are you attempting to detect insider threat, lateral movement, or credential compromise?

Do the attacks you’re hoping to detect match what the real threat actors do?

Knowing what specific attacks you’re trying to detect based on your threat model combined with intelligence about actions from real threat actors can be useful. Actions conducted by real threat actors may also differ from what a pentester may do (sometimes). Think about what specifically needs to be detected. We recommend reviewing your internal security testing reports, public incident response for forensics reports, and reports on threat actors to understand what the real attacks look like.

Honeypot location

Honeypot placement matters, especially for detecting certain threats or actions. A honeypot that’s exposed to the internet may be very noisy and may not spot threats specifically targeted at you. Honeypots placed internally can help look for post-compromise actions, depending on various other factors. 

Another thing to consider is making honeypots believable when it comes to placement. It would be beneficial if the honeypot and it’s properties (hostname, services, etc.) matched the environment it’s placed in.

Honeypot discovery

Think about how an attacker may discover the honeypot and what they have to compromise or what other work they have to do before they discover the honeypot. If discovery of the honeypot is too hard or too late in the attack lifecycle, its placement may need to be changed.

Detection / Logging

Logs from the honeypot should have enough information for an action to be taken, depending on how the honeypot is set up and how a threat actor interacts with it. Having fields such as username or IP could be useful.

Depending on the honeypot or token, detection may differ based on the location of the hunt. Detection alerts could be generated from a SIEM or from a service that tells you that something used a token.

Some ideas for cybersecurity honeypots and honeytokens

Set up an internal RDP server

Setting up an internal RDP server could be interesting. You could try to see who accesses it, if nobody is supposed to be accessing it. We’ve often seen threat actors bring in tools such as Advanced IP Scanner to look for internal RDP servers to access.

Set up an internal file share

Having an internal SMB share or an FTP server for someone to discover could be a good way to catch people that are doing internal scanning and then attempting to access files. Both SMB servers and FTP servers can have their logs sent to a SIEM for alerting.

Place honey files or canary files

Putting various types of canary files in various locations could be useful if you’re trying to detect someone accessing and opening them. Canarytokens.org (by Thinkst) generates files and tokens that can be used as honey files.

Watch out for vulnerabilities

One of the biggest things to watch out for when using a honeypot is to make sure that you do not accidentally allow attackers more access to a system than they should. You ensure that the attacker can’t use the honeypot system to attack other things (unless that’s what you want) or gain additional information such as valid credentials to different systems and services. You should understand the risks that come with creating and managing your own honeypot systems if you plan to do that.

Interested in learning more about threat hunting? Through our Managed Detection and Response (MDR) engagements, our clients have 24/7 access to our Security Operations Center and can communicate with the team through the SCOPE portal. Learn more about our MDR services.