Table of Contents
I’ve been scanning dark web sites for a long time and the greater internet for even longer, mainly looking for command-and-control (C2) servers in use today by attackers. I like to think of this as threat hunting in the attacker’s space, rather than how we traditionally think of threat-hunting within the defender’s space (inside our organizations systems).
Something I’ve seen more and more recently is the use of deception (or anti-deception?) in an attempt to mitigate these defensive operations in the attacker’s space.
These differ from traditional honeypots and deception ops. With a device configured for traditional deception, you would try to emulate a real system, configuring it to be as close to the real thing as possible. Sometimes even just using a real, vulnerable system with the goal of getting an attacker to exploit it. This is so you can monitor their techniques and add these to your defensive capabilities or use them as early warning signs that you’re being monitored/looked at / already popped. (Sticking some false entries in your robots.txt file and monitoring those sites is a good starting point).
But what I’ve seen is different.
My first thought was that these are just poorly designed honeypots. However, I found something interesting, which leads me to believe this is incorrect. These tools are designed to pollute results with false information.
Don’t believe me? Well, take a look at this file in one directory that makes it pretty obvious what its intended goals are.
As my Chinese speaking ability is what some would describe as “terrible”, it’s important to double-check that this wasn’t a translation error. The same string was passed into different translation tools, including ChatGPT; all of which returned the same results:
Taking a closer look into the code directly, it was evident that this is exactly what the intended purpose was. Several files contain multiple keywords that trigger various types of scanners, ranging from weak passwords and /etc/passwd being open, to false service names in the response received. This is likely to fire on both attackers knocking and search engines like Shodan and Censys. Based on the translated text from earlier it seems like this is part of the design.
Finding these types of systems is not overly difficult. They always contain some unique marker that you can hunt for. In this specific instance I was hunting for a unique csrf-token in the headers. You can find a lot of interesting indicators from analyzing malware and looking at its certificates. Extra points if you set everything up in a lab and analyze the self-signed certs, this will help you achieve production scale quickly.
What is even more interesting though is what they are doing. Take a look at one such host I found on Shodan:
Many of these are hosting MiniUPnPd for port redirection, most likely to redirect to the second frequent item; a huge number of false services:
For scanners this is annoying at best, as it messes with results that often need to be adjusted to accommodate. For search engines, it can wrongfully show vulnerability metrics if the honeypot isn’t identified and excluded from search results.
Having done some more digging I found this article from Censys published last September that goes into great detail on this specific threat: https://censys.com/red-herrings-and-honeypots/, they also linked the files I came across to a repo on Github.
Many of these devices have an unusual marker in the server header. If you want to take a look yourself at many of these types of devices, here’s a simple Shodan query to reveal the hosts using that specific project: https://www.shodan.io/search?query=Rm9yIGludGVnZXJzLCB0aGVyZSBpcyB1bmlmb3JtIHNlbGVjdGlvbiBmcm9tIGEgcmFuZ2UuIEZvciBzZXF1ZQ%3D%3D.
If you have an enterprise account add -tag:honeypot to filter out the known honeypots and see the ones that slipped through. The purpose of poisoning search results is interesting. It clearly shows a greater operation in mind, and likely is intended not to be annoying for an analyst to fix, but rather to create a smokescreen that an attacker can then operate from. Using projects like this at scale, and having a true C2 hidden within the noise is an excellent use of deception to hide in plain sight, and have their infrastructure misclassified by scanners – allowing a threat actor to operate from the same infrastructure for longer, bringing down their operational costs.
Or it could just be a poorly designed honeypot.
Links:
• Repo: https://github.com/fuckhoneypot/fuckhoneypot/tree/main
• Shodan search: https://www.shodan.io/search?query=Rm9yIGludGVnZXJzLCB0aGVyZSBpcyB1bmlmb3JtIHNlbGVjdGlvbiBmcm9tIGEgcmFuZ2UuIEZvciBzZXF1ZQ%3D%3D.
• Censys report: https://censys.com/red-herrings-and-honeypots/
