I love to use analogies, so when I was asked to put together an article comparing honeypots vs. honeynets, I immediately thought of the word “fish.” Fish is an interesting word, in that it can denote a single fish: “I caught a fish this morning,” or multiple ones: “I caught almost a dozen fish yesterday.” While the number of fish that the word references may change, in the end we are still talking about the same sea creature.
That’s kind of how honeypots and honeynets compare to one another. A honeypot is a single device, usually a server, that subtlety conveys to an attacker that it may host something of value. Its purpose is to lure wannabe attackers into targeting the enticing decoy so that their actions can be monitored and studied.
The honeypot typically hosts some type of HR web-based application or a database server that holds the personal information of customers or employees. The honeypot’s security configurations are purposely just lax enough so as not to discourage an intruder from breaching it. By learning more about the attack methodologies of the attacker, the cybersecurity team can have a leg up in how to stop them before they can infiltrate production targets.
(Note that honeypots typically employ honey files (sometimes spelled as one word, i.e., “honeyfiles”), which are files that an attacker might look for that appears to contain juicy information on passwords or personally identifiable information (PII). These honey files draw them in, just like honeypots).
In short, a honeynet is a bunch of honeypots. The most common scenario is a group of virtual servers hosted on a single host, each one serving as an individual honeypot. Collectively, they mimic the server farm of a live network, with each honeypot offering something that an attacker may want to further investigate.
Honeynets can include other assets such as routers, firewalls, and other types of network appliances. These types of devices are usually set up with their default configurations, to make them vulnerable to common exploits and attack methodologies.
All the devices are monitored by some type of passive security controller that silently keeps a watchful eye. Because none of these honeypot devices serve any authorized users or processes, any connection attempt usually denotes an illicit activity. Once identified, the security team can observe the actions of the attacker to learn about their behavior and what attack vectors, malware, or exploits they utilize.
Well-constructed ransomware attacks don’t occur overnight. Honeypots and honeynets would in fact be of little value if attacks were implemented immediately after infiltration. The idea that an unsuspecting user clicks on a phishing link and encrypts all available servers within hours is a rarity—successful hackers and ransomware gangs come to reside in your network like an unwanted guest that makes themselves at home.
During that time, they browse your network, identifying data repositories and data driven applications, assessing your security tools, and attacking your backup systems to take them out prior to the main attack.
Often, they install a trojan to pump in multiple attack tools and malware strains to aid them in other types of attacks. All of this takes time, and the more time the attackers spend interacting with the honeypots is time wasted for them, thus buying you time in the process.
In the end, honeypots and honeynets serve the same purpose. The only real difference is in their deployed numbers and the fact that honeynets may use other devices besides servers. Whether you are talking the singularity of a honeypot or the plurality of a honeynet, what matters in the end is that they both serve a purpose in the fight against ransomware.