Why Use Honeypots?

For an organization that has a reasonably complete security posture, including a mature threat intelligence capability, the implementation of a so-called “honeypot” should be considered. A honeypot is like a digital trap that is set for potential attackers. It lures the attackers inside by mimicking it to be a target they were looking for, sometimes with deliberate built in vulnerabilities, apparently waiting to be exploited.

Once the attackers use the honeypot system, thinking they have reached the intended target, all actions are recorded and all modified and newly-dropped files are captured. In this way, a great deal can be learned about potential adversaries, their Tools, Techniques and Procedures (TTP’s) and how they would circumvent the organizations actual production security controls. It allows for truly proactive security intelligence gathering, although there are some caveats.

The Issue With Honeypots

A honeypot is a great weapon in the arsenal of defensive security teams. Its use does, however, come with some challenges.

The obvious one is the risk that an attacker successfully exploits a honeypot and then manages to move laterally into the actual production network. It is critical to isolate a honeypot from any other network! This seems like a simple task, but it only takes a single forgotten system or a single firewall rule change to create a very dangerous situation. Networks are inherently complex.

Another challenge is the amount of time and with that, are the costs that come with the management of a honeypot. The system will need to be configured and maintained, of course. But that is not all: The captured activity needs to be used within the organization’s security teams for it to be of any value. This will take a lot of time to structure and to fit within operational processes. The information will need lead to actionable intelligence, such as by blocking the adversary’s infrastructure, the creation of Intrusion Prevention System rules or the creation or tuning of malware signatures.

Using the Cloud

Some of the mentioned challenges can be overcome by using a public cloud system to host a honeypot.

The public cloud provides complete isolation from any production network. There is also no need for specific hardware or dedicated Internet connections. Once a machine has been compromised and the data is collected, a snapshot can be used to revert the system back to its captured state before the attack took place.

Another great advantage of using a public cloud infrastructure for a honeypot deployment is that it can be distributed anywhere in the world by selecting the desired geographical locations within the cloud system configuration. A sensor can be placed in East Asia one day and can be moved to Germany the next with just a few mouse clicks. Considering the fact that observable attacks and attackers can differ a lot depending on the location of the exposed system, this is great for research and intelligence gathering purposes. A honeypot located within Russia will see quite a different range of attacks and scanning activity compared to the same system in Brazil. A distributed honeypot network consisting of a manager and several sensors such as the Modern Honey Network (MHN) benefits even more from this flexibility.

Some honeypot products have been developed around a private cloud instance as well, such as the Thinkst (Cloud) Canary. Canary honeypot devices are deployed at strategic locations within the customer’s network. These sensors all report back to a central, cloud-based system allowing the customer to detect perimeter activity and lateral movement inside the production network when a real attacker unexpectedly interacts with one of these sensors. This system does not come cheap, but it will still provide critical visibility when all other detections have failed to keep the attacker out. In this case, the cloud connectivity assists in the preservation of logs, improved customer accessibility and the very quick and easy deployment of what can be a complex honeypot infrastructure.

Limitations

There is a direct correlation between placement and relevance when it comes to honeypots.

For a honeypot to provide the most relevant (and actionable) output, it needs to be somehow linked to the organization a potential attacker is interested in. This could potentially be via a fake company website or a registered domain name. Only then will the organization be able to observe attacks that are highly targeted, instead of simple scans from attackers looking for any low-hanging fruit. Of course, if possible, placing a honeypot within the organization’s existing cloud perimeter can also help in the identification of targeted attacks, but its isolation needs to be well-designed.

There is also a legal and policy aspect to the use of honeypots. Some cloud providers do not particularly like the idea of directing hackers into their networks and collecting malware within their infrastructure. After all, once the host is compromised, there is a chance it can be used to attack other targets on the Internet. When this is the case, it could damage the reputation of the cloud provider (hosting the compromised system) and could even lead to the blocking of that provider’s IP ranges and domains, impacting its other paying customers.

When in doubt, always look through the online usage policies or contact the provider for permission before setting up a cloud-based honeypot system.

Want to read more? Check out some of our other articles, such as:

Attacking the Cloud

What is a Honey Pot?

Using Cloud Infrastructure to Gain Privacy and Anonymity

Conclusion

As described, honeypots require a lot of maintenance in order to reach their full potential. They also come with some risks. By using a cloud platform, at least the risk of cross-contamination between a honeypot and a production system can be reduced to almost zero. Adding the benefit of the significant flexibility of deployment locations to that, it makes the cloud a great environment for any organization ready to take the first steps into the realm of honeypot deployments.