Organizations with mature information security programs could deploy a honeynet utilizing honeypots to lure adversaries and document their tactics, techniques, and procedures (TTPs).
Control Type: Technical
Control Function: Detective
One of the riskiest yet most rewarding proactive information security projects is implementing a honeynet. A honeynet is a collection of purposely insecure systems and services called honeypots that sit in an isolated, publicly accessible network segment. The goal of a honeynet is to entice adversaries to explore and compromise the insecure services so that the information security team can observe, log, and analyze the adversary’s activity. This is especially useful for organizations that find themselves the victims of targeted, well calculated cyberattacks from APTs, nation state actors, and organized crime groups. By diverting the adversary’s attention from actual, sensitive network segments towards a purposely insecure segment, the organization can delay the compromise of critical assets and extract Indicators of Compromise (IoCs) to use for remining detection rules and blocklists.
The actual substance of a honeynet is entirely up to the discretion of the organization. Most honeynets comprise a few honeypots such as basic insecure servers, endpoints with EOS/EOL operating systems, and vulnerable web applications. Typically, these honeypots contain honeytokens, which are fake data objects meant to convince adversaries. Organizations can decide how far they want to go in creating a lie with honeytokens. They could place a few authentic looking documents in an exposed file share and leave it at that. Or they could place fake password files, API keys, network diagrams, financial statements, and other data that looks especially enticing to adversaries.
A honeynet is largely pointless without mechanisms to monitor and document the activity going on in it. Honeynet traffic can be passively monitored with an IDS like Snort that logs activity in .PCAP files which can be analyzed by security administrators with tools like Wireshark and TShark. Activity on honeypots can be ingested into a SIEM like Wazuh or Splunk so administrators can create timelines, extract IoCs, and create granular detection rules. The adversary data from the honeynet can then be documented and added to enterprise security services; blocking malicious IP addresses in ACLs, blacklisting malicious domains on DNS Sinkholes, and adding malware hashes to EDR/XDR detection databases.
It would be wrong of me to recommend configuring a honeynet for all organizations, since it is a very risky endeavor if you don’t know what you’re doing. Improperly configured honeynets can result in adversaries finding a door into your internal LAN. Honeynets should be granted allow all outbound access and allow only specified services to be accessed inbound by the Internet. The honeynet should also be allowed to send logs to specific IPs on a management VLAN for administrators to monitor. Under no circumstances should the honeynet be allowed to contact internal network segments, or vice versa. For added security, it is recommended that the device used to manage the honeynet be a jumpbox that administrators remotely access from their own workstations.
Further risks are added based on what kind of services and privileges the organization makes available to adversaries. Typical honeynets expose classic, commonly targeted services such as Telnet, RDP, SSH, HTTP, FTP, SMB, and MySQL. Organizations need to carefully weigh what services their honeypots will mimic, and how much functionality will be exposed to adversaries. Things can get out of hand quickly if the organization lacks knowledge on what exactly they are giving to adversaries. Serious issues could arise if adversaries are allowed write access to services like FTP. Extremely insidious adversaries could try and utilize exposed file systems as part of launching point or transmission ring for illegal material such as malware and CSAM material. While I would like to say this isn’t extremely likely, it is still not a “mess around and find out” scenario, and the organization could find itself in a legal hurdle. The most responsible course of action when deploying a honeynet is to only expose when the organization and information security staff understands, and to have proper justification and documentation for doing so.
Honeynets are not recommended for most independent small to medium sized businesses. Honeynets are most useful for large enterprises and public agencies that are frequent targets of APTs, nation states, hacktivists, and organized crime actors. The insights gained from a well-designed and enticing honeynet can help all sectors, as the threat intelligence extracted can inform the public and help with crafting detection rules. If a smaller organization wants to utilize a honeynet, it is their prerogative to do so. It can be a great part of a mature and informative information security program and help the organization stay up to date with the latest tactics, techniques, and procedures used by adversaries. However, the organization must know what they are doing and have seasoned information security staff to supervise the honeynet.