Back to BlogProduct Update: Automating Honeypot Security Detections
It’s the time of year when I let our audience know about our honeypot and all of the new amazing features we have to offer!
Just to recap: a honeypot is a network device that either appears to contain, or does actually contain, vulnerable data intended to lure an attacker into accessing it. Whether a threat actor tries to log in to the interface, scans the device using a scanning tool, or attempts to access anything on the device, the alerting component will instantly inform your security team that something threatening is happening.
All honeypots are built differently, generally. Some have visibly exploitable vulnerabilities, others look like a hardened system – meanwhile, they are just waiting to be scanned or logged into by an attacker.
New Responder Detection Capabilities
Our first version of the honeypot was shaped to look like a vulnerable fileshare server. Although the first iteration of our honeypot was a powerful detection mechanism for our customers, there is always room for improvement. Our security team, working with our backend developers, came up with a more robust honeypot which includes capabilities the cybersecurity industry is still attempting to adopt.
One of the most notable upgrades we’ve made is our addition of “WhereIsMallory” – the new cross-architecture Responder detector. If you’re familiar with Responder, it is one of the most powerful red team/hacking tools you can use. It is also one of the toughest to detect, due to its stealthiness. If you’re not familiar with the tool, the overview taken from Kali.org states:
“This tool is first an LLMNR and NBT-NS responder, it will answer to *specific* NBT-NS (NetBIOS Name Service) queries based on their name suffix (see: http://support.microsoft.com/kb/163409). By default, the tool will only answer a File Server Service request, which is for SMB. The concept behind this is to target our answers and be stealthier on the network. This also helps to ensure that we don’t break legitimate NBT-NS behavior.”
Responder detection has classically required manual investigation and a keen eye from the blue team. We, as the blue teamers, have been fighting a losing battle against Responder… until now! Our team has worked hard to integrate a Responder detection mechanism into the new honeypot module. When Responder is automatically detected by our service, a Priority 1 Threat Finding is generated. From there, we have drawn up a step-by-step guide on how to remediate a Responder attack on your network.
How Does It Work?
WhereIsMallory sends out LLMNR (Link-Local Multicast Name Resolution) traffic to the multicast addresses of the interfaces and probes the broadcast, which results in an attacking Responder responding to the LLMNR lookup request at the broadcast. This way, we’re able to identify that the response is indeed from Responder and ship that result via syslog for our customers to digest in a Finding.
To put all of this into simpler terms, we pretend to be a Windows host every few seconds and request LLMNR traffic across the broadcast to see if Responder is attempting to respond to us. This is a capability that even next-generation antivirus software has not been able to pull off.
We’ve also made a few minor changes to the honeypot, to make it seem more believable to the naked eye, such as opening specific ports and services that mirror a legitimate server on the network. Attackers keep an eye out for obvious honeypots; these changes will make it much harder for the attacker to decipher which is a legitimate server, and which is not.
These changes will be in effect this quarter! If you’re a Blumira customer, you shouldn’t need to take any additional action to take advantage of the new honeypot features and detections. If you’re not a Blumira customer, we’d love to help you protect your network with our ever-evolving technologies.
Please reach out to us if you have any questions about our services, or sign up for a free trial of Blumira’s detection and response platform.