Honeypot is another useful cybersecurity term to be aware of and understand. It’s got such a sweet and gentle name too - it couldn’t possibly be a trick or a trap to draw in innocent bears. Well actually it could and it is - but only the bad bears, the bears who want to do bad things to our honeypot and to more of our things.
One of the essential practices to develop and mature in our cybersecurity programs is the collection, analysis, and understanding of the tactics, techniques, and procedures (TTPs) used by attackers. TTPs is another great cyber term to understand, and I gave an overview of it a couple of weeks back. Honeypots are a good tool to have in our toolbox to help improve these capabilities. Here’s how:
A honeypot is designed and setup to look like an attractive target for an attacker or and adversary group.
It’s 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.
It will me 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 yesterday 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.
Next week I’ll be back on the non-cyber topic routine for my midweek post, hope you’ll forgive the curve ball on this one.
I am is enlightening to see how threat actors use the honeypot to their own advantage too. It is eye opening