Menu
Well-established network security defense practice involves combining a range of preventative measures such as a secure network topology incorporating DMZ’s and firewalls, along with effective detective controls such as logging, monitoring, SIEMs, vulnerability scanning, and hybrid preventative/detective measures such as IDS/IPS systems. However, one tool that is often overlooked despite a history of deployment stretching back over thirty years is the honeypot, a deployed resource that is used to monitor and analyse attacks against a network, as well as reveal information about the attackers behind them. In this blog post we examine exactly what honeypots are and how they work, and whether they could benefit your organisation.
A number of flies were attracted to a jar of honey which had been overturned in a housekeeper’s room, and placing their feet in it, ate greedily. Their feet however became so smeared with the honey that they could not use their wings, not release themselves, and were suffocated. Just as they were expiring, they exclaimed “O foolish creatures that we are, for the sake of a little pleasure we have destroyed ourselves”
A honeypot in cybersecurity refers to a computer or computer system that is deployed by an organisation to serve no production purpose other than to detect inbound cyberattacks. It can be used to protect other more critical production systems by offering an apparently less secure and hence more attractive target for any attackers, deflecting attention away from key production services. It can also be used to gain information about how cybercriminals operate, and to uncover some information about their network identity that can be used to potentially inform and update rules on IDS/IPS systems and other perimeter defenses, as we will explain below. Like those flies around the honey jar, cybercriminals are attracted to honeypots, believing them to be tempting and less-protected but legitimate production systems, something worthy of their time. That’s because the honeypots are “baited” typically with a combination of apparent security flaws, combined with running applications and data that simulate a real computer system, yet is not real data that the organisation is looking to protect.
A honeypot system is typically a virtual machine that looks like any other real computer system, with running applications and network services and data stored on it – if implemented properly it is not obvious to attackers that the data is not in fact real production data – a honeypot could for example mimic a company’s customer billing system – a frequent target of attack for criminals who want to find credit card numbers – and would therefore need to contain apparently-valid credit card numbers in a sufficiently production-like format, as well as have typical (though apparently flawed) defenses that may be expected of such a system.
Honeypots are made attractive to attackers by exposing an apparent security vulnerability on initial scan or reconnaissance of the network that marks it as an attractive target but does not importantly allow immediate and full compromise and takes time to exploit – since it is important that an attacker does not immediately realise that a system is a honeypot (and therefore move on to attacking a real production system) the honeypot defenses should be at least realistically robust (though less so than the real production system) and the data not trivial to access.
Once an attacker has begun probing and attempting to access the system, their activities can be (passively) monitored and recorded.
The goal of honeypots is to attract and engage attackers for a sufficiently long period to obtain high-level Indicators of Compromise (IoC). IoCs are “patterns” or “fingerprints” of the attacker that can allow partial identification of an attacker or some further information about their offensive methods or capabilities. Typical IoCs may include virus signatures and source IP addresses, MD5 hashes of malware files, or URLs or domain names of botnet command and control servers. After IoCs have been identified via a process of incident response and computer forensics, they can be used for early detection of future attack attempts using intrusion detection systems and antivirus software – for example an identified botnet can then be proactively blocked on an IDS/IPS device from attacking real, production systems.
Because there is no reason for legitimate users to access a honeypot (given that it hosts no legitimate production services), any attempts to communicate with the honeypot are highly likely to be malicious in intent, meaning that it is relatively “low-noise” and all activity into the system is highly likely to indicate potential aggression and be worth investigating.
Viewing and logging activity in the honeypot therefore simultaneously provides both insight into the level and types of threats a network infrastructure faces, while also distracting attackers from assets of real value. They can also be used to test incident response procedures, or potentially in internal “blue/red team” exercises within the organisation, in a safe manner (in that the systems can be shut down or disconnected from the network if the incident response plan calls for it, without disrupting production activity and systems.
Honeypots take significant skill to deploy correctly, so rather than “baking your own”, organisations will typically select an off the shelf solution (either open source or commercial), as they would any other network defense. Just as with any other network defense, honeypots are not completely “free” in that they require careful planning, analysis, deployment, and maintenance.
Honeypots are often placed in a demilitarized zone (DMZ) on the network. This approach keeps the honeypot isolated from the main production network segment, while still being within the organisation’s network perimeter and hence a plausible production system from the attacker’s point of view. In the DMZ, a honeypot can be safely monitored by the organisation, while permitting attackers external to the network to access it, minimizing the risk of the main network being breached.
A variety of honeypot types exist (one curated list of honeypots is maintained on GitHub at https://github.com/paralax/awesome-honeypots). Most honeypots mimic application servers, database servers, web servers, and credential databases such as domain controllers, as well as network devices, such as routers, wireless hubs, or security equipment. Which variant or variants of honeypot you choose to deploy is typically determined by the type of system that best mimics your key production services – this is so that the honeypot both looks plausible to attackers that may know a little about your organisation and to help the honeypot “blend in” and look like one system among many), as well as ensuring that lessons learned from running the honeypot are directly applicable to protecting real production services.
As with any system, honeypots have distinguishing characteristics no matter how carefully honeypot designers attempt to make them mimic other system types, i.e., to a sufficiently knowledgeable attacker they can be distinguishable from production systems in terms of their network service footprint or other clues. Since honeypots can be distinguishable from legitimate production systems, experienced hackers may be able to differentiate a production system from a honeypot system using system fingerprinting techniques.
To minimise this trait of being distinguishable, most honeypots should be placed near the assets they are attempting to mimic, albeit safely screened or segmented from them. This is a tricky balance but ensures that the honeypot doesn’t stand out as an obviously different and implausible target (i.e., that it doesn’t look like a honeypot). It is important that no matter how plausible the honeypot is, it absolutely must not represent a threat to your production systems – you must assume that the system will be compromised and ensure that any attempts to then “jump off” the compromised honeypot and use it to pivot attacks onto other systems are not possible.
As we have seen above, the placement of the honeypot is incredibly important, and the risk of the honeypot being compromised and used to attack other systems be considered.
It is also worth considering that if the honeypot is compromised, the system could potentially be recruited into a botnet or otherwise turned into a malicious or offensive tool that resides on your network so it is incredibly important to decide in advance how you will handle this potential issue from a technical and legal perspective. This may include defence strategies such as so-called unavoidable actions in which a system employs measures that cannot be prevented or neutralised by an attacker, such as initiating a hard shutdown of the honeypot or triggering a security switch to disconnect its network access if it is seen to be compromised.
It is also worth noting that a honeypot must remain strictly a detective, passive, and defensive system – it is not permitted to use a honeypot to perform or inform offensive activities by your organisation – you cannot “attack the attacker”.
The main benefit of a honeypot is the ability to harvest information about attackers in a relatively low noise manner – i.e. with relatively few false positives. Many cybersecurity detection technologies such as IDS/IPS systems can generate alerts that include a significant volume of false positives, since they are attempting to determine (using heuristics, or behavioral analysis) which actors or actions are malicious from amongst a high-volume continuous stream of mixed benign and malign traffic. A honeypot on the other hand can minimise the number of false positives because there is no reason for legitimate users to access the honeypot and so all or almost all traffic is immediately more likely to be malicious in nature. This makes it much easier to spot patterns, such as IP addresses from within a particular range or registered Autonomous System (AS) number being used to carry out a network scan.
Honeypots, like any other network defense, are not “free” and can be time consuming to manage properly, as a long-term commitment. Honeypots are not set-and-forget it solutions – quite the opposite in that as with any other system it is important to appropriately plan, install, configure, update, and monitor the honeypot. A honeypot isn’t of any value unless there is a human operator analysing the recorded malicious activity and responding to it via some defined playbook – whether that be updating firewall or IDS/IPS rules or setting up alerts when threat events from highly suspected threat actors (those with activity against the honeypot) occur against production systems. As with IDS and IPS systems, much of the time burden will lie in tweaking and customizing behaviour and rulesets on an ongoing basis to minimise false positives and gain maximum value from the system’s performance.
Operating a honeypot can also by its very nature represent a risk to the organisation and should be subject to suitable risk analysis prior to deployment. If a honeypot is not configured or deployed safely, it could potentially be used to gain access to real production systems or as a launchpad for attacks against other target systems.
A compromised honeypot may also lead to “abuse” concerns in which the system is itself turned into an offensive system by the attacker, such as being recruited into a botnet and used to attack other organisations. To the organisation thus targeted, it will appear (correctly) that the attack is originating from your organisation’s network. This may have serious reputational and potentially legal consequences and should be seriously considered.
The final potential drawback is that, as with police “sting” operations, honeypots are fraught with potential ethical concerns over whether they constitute entrapment. If a data breach or similar event occurs that necessarily involves law enforcement, it may be challenged whether an organisation has provoked the commission of a crime by someone who would not otherwise have done so.
In addition to the standalone honeypot system security teams often refer to several additional variants, outlined below:
Honeynet – Two or more honeypots on a network are often described as forming a honeynet. Typically, a honeynet or “honey net” is used for monitoring a larger and/or more diverse network in which one honeypot may not be sufficient. Honey nets and honeypots may also jointly be implemented as parts of larger network intrusion detection systems within larger enterprise organisations.
Honey farm -similar to a honeynet, the term honeyfarm is sometimes used to describe a centralized collection of honeypots and analysis tools.
Deception Technology – Recently, a new market segment called deception technology has emerged that combines basic honeypot technology with the addition of advanced automation at scale for larger enterprise organisations. Deception technology addresses the automated deployment of honeypot resources over a large commercial enterprise or government institution.
Honeytokens. The concept of a canary trap has existed for decades, as a method for exposing an information leak by giving different versions of a sensitive document to each of several suspects and seeing which version gets leaked Honeytokens are a similar concept within cybersecurity, being fictitious records that are added to legitimate databases. The idea is that a different honeytoken is accessible or returned under different access conditions or privileges – and if data is stolen, honey tokens therefore allow administrators to identify who it was stolen from, by whom, or how it was leaked.
Honeyclients – Client Honeypots or honeyclients flip the honeypot concept on its head. Rather than being passive server systems, they are active client systems in search of malicious servers that attack connecting clients. The client honeypot poses as a client and interacts with the server to examine whether an attack has occurred. Often the focus of client honeypots is on web browsers that for example crawl the World Wide Web searching for websites that use browser exploits to install malware, but any client protocol that interacts with servers can be part of a client honeypot (for example ftp, ssh, email, etc.).
Network telescope – Internet background noise (IBN), also known as Internet Background Radiation consists of data packets on the Internet which are addressed to IP addresses or ports where there is no network device set up to receive them. These packets often contain unsolicited commercial or network control messages or are the result of port scans and worm activities. A network telescope is simply a passive receiving system or set of systems that listen for such traffic. The Conficker worm was one early example of malware seen in 2008 and originating in Ukraine that was responsible for a large amount of background noise generated by viruses looking for new victims and a network telescope can be used to passively record the “fingerprint” sent out by the worm as it scanned for targets.
Tarpit – finally, a tarpit is a service that runs on a server for the purpose of actively stalling and delaying incoming connections. The technique was developed as a defense against computer worms, but the idea is that network abuses such as spamming or broad scanning are less effective, and therefore less attractive, if they take too long, so the resources of an attacker can be wasted. The concept is analogous with a tar pit or swamp, in which animals can get bogged down and slowly sink under the surface.
As we have seen, honeypots represent an intriguing possibility in expanding network defense beyond more traditional preventative measures. But as we have also examined, they are not a “free” solution and require careful analysis, planning, operating and ongoing maintenance in order to be effectively leveraged, and may not be suitable for smaller organisations or security teams at this point in time.
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA)
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@appcheck-ng.com
No software to download or install.
Contact us or call us 0113 887 8380
