Cyber Terms - Honeypot
Honeypot is another useful cyber term to be aware of. It’s got a fun name and it doesn’t sound at all like a trick to draw in bears. It is though - but only bad bears, bears that want to do bad things to our network and the devices on it.
Cybersecurity defenders are continually looking to gain more knowledge on attackers’ tactics, techniques, and procedures, or TTPs (which is another good cyber term to know). We do that with a wide array of tools and resources - like tools for endpoint detection and response tools, threat alert feeds, security information and event management (SIEM) tools, threat hunting, and more.
Honeypots are a good tool to have in our toolbox to help improve these capabilities. Here’s how they are intended to work:
Honeypots are designed and setup to look like an attractive target for an attacker or and adversary group.
They’re meant to draw adversaries’ attention and efforts- and can be setup to mimic just about any of our devices/digital assets - from applications to network servers and network infrastructure devices.
They’re made to be enticing to adversaries, appear to be a high value target; a target that appears to allow the adversary access to a critical system or systems in our IT or even our OT (Operational Technology) environment, where they can gain access to sensitive data and look to cause damage and disruption to the those environments.
Honeypots are a great data source for cyber defenders - because we know that all activity on them is malicious. Our InfoSec and IT and OT teams are aware of them (or should be), so all the activity seen will be by external, or even malicious insider, bad actors.
They are effective decoy and reconnaissance tools, but there are a few things to be aware of so that we don’t shoot ourselves in the foot when deploying honeypots, including:
Honeypots need to be properly, securely configured. If they end up having a real vulnerability they can become a risk / threat to our organization. The diagram at the top of this post is a very basic example of this; and we could easily add further layers of segmentation to this, for example.
Another bear analogy (sort of) fits here. The honeypot needs to be designed so that it is not obvious in its purpose. It can’t be that Goldilocks perfect fit, it needs to create a good amount of a “this chair is not right and that chair is not right” feelings . CrowdStrike concisely outlines why making things too obvious is a risk:
Cyber criminals can also use honeypots just like organizations. If bad actors recognize that the honeypot is a decoy, they can flood the honeypot with intrusion attempts in an effort to draw attention away from real attacks on the legitimate system.
I was inspired to write on this by a Bleeping Computer report a couple years back titled RDP honeypot targeted 3.5 million times in brute-force attacks - which offers a great look at how successful honeypots can be. A couple of excerpts from it:
Over three months, the researchers at GoSecure, a threat hunting and response company with headquarters in the U.S. and Canada, recorded close to 3.5 million login attempts to their RDP honeypot system.
The honeypot has been functioning on and off for more than three years and running steadily for over a year but the data collected for the presentation represents only three months, between July 1 and September 30, 2022.
During this time, the honeypot was hit 3,427,611 times from more than 1,500 IP addresses. However, the attack count for the entire year reached 13 million login attempts.
That’s an awful lot of sniffing around by attackers, just what defenders want to see.