“TrstdXploitz” by “L33terman6000”

I’ve been wanting to perform an experiment for some time now and finally got around to it. I present to you what I think is a unique spin on an old idea, a new type of honeypot. Follow along as I explain the adventure that unfolded, including personal threats, Distributed Denial of Service attacks, the Dark Web, and some shocking statistics! Warning: Some egos were likely harmed during the making of this blog.

As a Security Consultant, I’m always advising my clients during web application security assessments to review third party code before merging it in with their code. I’ve written another blog about not trusting appliances or software on your network just because they claim to help with security. As a penetration tester I often rely on third party scripts and tools to help me do my day-to-day job, as do our blue team counterparts. It seems everyone in the Cyber Security industry does, thanks to the vast number of open-source contributions available to the community. When we forensically analyze malware we take precautions in order to avoid infection for ourselves and our clients. Why then, do we feel so comfortable running our infosec tools without checking the source? Is it because they’re open source and we assume something would have been caught? Is it due to the widespread use or the fact that someone well known in the industry shared it? Is it because of where we got it from? Just to be clear, I’m not above any of you that may be guilty of this. I’m just as much at risk as anyone else.. which got me thinking.

As many pentesters do, I often come across new vulnerabilities in customers’ environments which do not yet have weaponized exploit code available in our favorite exploitation frameworks. I turn to Proof of Concepts (PoC’s) in places such as Exploit-DB and GitHub to see if I can snag something I can use or re-author for my purposes. I know Exploit-DB and GitHub both do some work to validate and filter out malware, and with stars and watchers you can get a sense of how popular the code is. Most exploit code looks pretty similar, with a string of hex characters used as shellcode as part of the payload, and is often written in Python, Ruby, Go, Bash, etc.

I’ve always been a little skeptical of running these Proof of Concepts/Exploits because these “researchers” are also “hackers”, by definition. It’s a little of a grey area for some who research during the day and moonlight as black hats. I try to take the time to look over the code, at least at a high level, to try and understand what it is that’s taking place. If there’s hex or another encoding method used I do my best to deobfuscate and study it. I’ll admit, my effort isn’t always 100% but enough to make me feel comfortable with running it, at least locally. There’s always this fear in the back of my mind that by getting access to a remote machine, am I unintentionally handing a back door over to a black hat somewhere? Am I infecting my machine, with client data, or worse.. my client’s environment? This is a BIG responsibility for the security professional that often goes unchecked.

Our clients trust us to keep their environments safe. I’ve had clients in the past who insisted we provide a list of all tools up front that had to be approved and deployed for us beforehand. This seemed overkill to me at the time and a major obstacle when in the moment you just need to run ad hoc based on what you encounter at the time. Now, I’m not so sure. Do you feel confident your actions won’t do the opposite? Do you thoroughly review all code before you run it? Do you assume it’s okay because that security professional you follow on Twitter, having seven thousand followers, says you should try it out? (Hint for later on, the answer is no) Security customers reading this and even some security folks are probably thinking this is a no-brainier, that the answers to these questions is a resounding “YES”! I’m here to say you might just be surprised.

The Idea

Of all the open-source security tools I execute on a daily basis, PoC exploit code gives me the most hesitation. If I’m being honest, I don’t always fully understand exactly what’s going on behind the scenes in order for an exploit, especially Remote Code Execution (RCE), to work. In most cases there is raw shellcode passed along as part of the payload to establish the reverse bind shell with the client-side script, which can be a little intimidating to look at. The exploit script itself may be written in a language you aren’t as familiar with. (For me that would be Ruby) I was curious how many different types of people use third-party exploit code and how many also don’t inspect the code. Also, would anyone willingly promote it without having to advertise it? I’ve noticed malware and vulnerability researchers are often the first to point out whenever there’s a working PoC for a high profile vulnerability, such as BlueKeep, in recent history. I had always assumed black hats, who make their money on exploitation, must be keeping an proactive eye on these somehow. I wanted to know more and see if there was a teachable moment here for all of us, so I came up with an experiment.

This article by TechTarget contains my favorite definition of a traditional Honeypot:

“A honeypot is a network-attached system set up as a decoy to lure cyberattackers and to detect, deflect or study hacking attempts in order to gain unauthorized access to information systems. The function of a honeypot is to represent itself on the internet as a potential target for attackers — usually a server or other high-value target — and to gather information and notify defenders of any attempts to access the honeypot by unauthorized users.”

If we want to study the behaviors of both white hat researchers and black hat hackers, it sounds like we could use a honeypot. However, this wouldn’t be a honeypot in the traditional sense since the server isn’t sitting somewhere in an environment waiting to be attacked. Instead, the exploit code itself could be booby-trapped to make it appear the target the attacker has in mind is itself vulnerable and being actively exploited. In the beginning of this thought experiment I realized I could obtain useful information about the attack, such as the vulnerable target. We don’t have to deploy this anywhere, people are willingly giving us useful information and thinking they’re connecting to these targets successfully. (I can only imagine the roller coaster of emotions. So sorry!) If we could monitor these targets in real time we could potentially keep an eye out for victims to warn or to proactively monitor against our own client’s networks. Also, if I provided a fake argument with my script to specify a “local host” for the reverse bind shell to connect back to, I could build a list of Command and Control servers that may otherwise not be known to the world. Lastly, if I collect the WAN IP address of every request in addition to the “lhost” IP address, I may even know the real IP address of the attacker or researcher, assuming they’re not hiding behind a VPN. This might be helpful one day to authorities in stopping attacks or, for my research, could help to identify any organizations which are consulting firms or potential clients of security professionals.

My initial idea was to craft a fake PoC Python script for a sought after CVE and model it after a legitimate one. For anyone looking through the code at a high level, it needed to appear that it was making a request to the targets in the supplied input, but it needed to secretly make another call to a back-end HTTP server which I control in order to collect metadata. To do this, I figured I would obfuscate that portion of the code using a combination of hex and Base64 encoding and make it look like shell code for the payload. The string would be concatenated and use custom delimiter characters to slow down reversing efforts a little.

Python Fake PoC Code

I would research current critical Windows RCE CVE’s, host the PoC out on GitHub, and wait to see if someone would eventually search for it, without actively advertising anything. What I didn’t anticipate, was how much this metadata project would evolve into a fully-fledged honeypot/terminal emulator of its own in an attempt to get more data and Indicators of Compromise (IOC’s). I also ran into issues with supporting legacy code versions due to a lack of foresight in regards to not being in control of my own repositories.

Recent RCE CVE “Exploit PoCs”

The Setup

For those that don’t care about this section, I understand, you may skip along to the statistics and outcomes of the experiment below. However, I want to talk briefly about the setup, as I originally planned to release the source for the front-end and back-end code but have since decided not to. I made this choice out of consideration for research teams who track legitimate exploits and to not contribute to more malicious attacks, like back doors being added. This experiment apparently shook things up for research teams and unexpectedly made things difficult for them, which to me just shows how fragile this current system of exploit validating and reporting is.

The client-side code, as pictured above, simply requests input from the user and sends an HTTP request to a PHP web server. The PHP then does a number of things dynamically, but the first thing it does is validate the input and source (python), then throws the entire raw command line argument into a MySQL database. The back-end records the IP address which made the requests and inserts a timestamp as well. Initially, this is all that would happen, followed by a “Sleep(10)” and a “Connection Terminated: Timeout” message on the client. This allowed me to collect the information previously discussed and appeared to be a faulty PoC to the user.

As I thought more about this, the web request was already being made to the server and if I made it respond to that request, instead of just accepting input, I could print that back to the client. Since the PHP could be dynamic based on the argument supplied, I could create a series of “If” statements that respond differently to simulate a Windows terminal, making it look like a connection had actually been established. This could all be done on the back-end as to not increase the payload size in the PoC script, potentially tipping someone off. The python script would loop through responses from the web server until no output was returned, so I could terminate the session with a “timeout” still. This was key because my intent was to make the session seem unstable, encouraging the user to establish their own remote shell for better availability and functionality. I even dropped hints that the server had been used that way already, previously compromised with empire launchers (empire_lnchr.bat) and Covenant grunts (grunt.exe). What I eventually had was a shell emulator for both Windows (based on CVE) and Linux, which was entirely done via a web requests. I considered taking this a step further and use it as an HTTP proxy against a real windows VM in an isolated environment, but decided I didn’t need to make it that involved. The goal now was to see if I could get the black hats to provide payloads for their malware, which I could then analyze in a VM. I also got a lot of great input into what commands were run in the wild and could create support for the most common ones as I went along, without changing any of the front-end code. This was key, because I learned that my repositories were being forked at an alarming rate with old code and I no longer had control over those, forcing me to keep copies of back-end code available and separate instances of my database.