My buddy Aamir Lakhani and I spoke last week at RSA about our botnet research. Our aim was to answer one question. That question is this.
We all know botnets have been around for a while, many have been taken down and, in most cases, many infected hosts are not remediated. Is it possible to identify hosts that are infected by dead botnet software and use that botnet software to launch a completely new attack?
The answer we found is yes, but the real value in our research is more about the HOW. How can you do this, how is it likely happening in the real world and what is the risk?
Step 1: Create and Test a Hypothesis
Let’s walk through our research in this post. What we are attempting to do is similar to proactive threat hunting since we first need to develop and test a hypothesis. We found the following items as big influences on what we call our “goldilocks zone” for identifying and resurrecting botnets.
- Modern Botnets: We pointed out that modern botnets leverage modern encryption, 3rd party authentication, sophisticated defenses and so on making it a bad target. We are not saying that it’s impossible to resurrect modern botnets however we are saying that it is much easier to target older botnets.
- Popular Takedowns: We decided to stay away from popular takedowns since it’s very possible the leftovers are still being monitored. For example, if we found the FBI or large security firm owned the domain that was taken over, we stayed away to avoid being put on a list regarding potential illegal activity.
- Very old botnets: There is a cutoff point when the botnet software is too old to provide value.
This led us to target botnets between 2001-2009, that were not part of a huge popular takedown. What is interesting is that one RSA attendee pointed out that we could consider this a floating window of time meaning 5 years from now, 2006-2014 would likely be a similar experience based on the length between the botnet takedown date and modern tech. We pointed out that many security tools don’t detect very old signatures hence systems that haven’t been reimaged in a while found in manufacturing and supply chains had botnet software installed and periodically beaconing to nothing … unless somebody like us comes along to resurrect that old breach.
Step 2: Locating Domains
The first part to resurrecting botnets is obtaining a domain. This is by far the hardest part and can become pricy based on how you invest in domains. There is also a lot of challenges including predicting DNS traffic, generators, fake websites, honeypots, etc. We went into gory detail about all of the hurdles, but the key was researching not so popular botnets that have been taken down and obtain the domain. I’ll post our talk notes for more details in this area along with the talk once available.
Step 3: Create Listener
The next step is creating a listener and wait for communication using a cloud VSP. Our goal is to obtain a list of infected systems. It is not to establish communication. We need to obtain the botnet software to understand how communication works before we can step in. At this point, we are just identifying potential systems.
Things of interest were seeing odd destination ports, source ports not increasing, duplicate and used ACK all leading to the PCAP telling us this is not normal traffic we would see when monitoring domain traffic. The data itself was garbage but our goal at this point was to determine if the sender was indeed a system that was infected with the botnet software.
Step 4: Learn Botnet Communication
As stated in Step 3, we need to understand how the botnet and C&C communicate in order to resurrect the software hence we have three options.
- Exploit one of the systems communicating back to the domain, find the botnet software, download it into a sandbox, reverse engineer it. (The hard way to do this, which we did not do)
- Attempt to break encryption so we can learn about the communication (hard and nope, we didn’t do this)
- Identify a website that provides samples of the botnet since its known and was taken down. Reverse engineer it (a LOT easier and sorta what we did)
- Identify a website that has the botnet AND the results of reverse engineering it so the work is done for you (pretty much what we tried to do when available)
Anytime we planned to purchase a domain, we had already identified binaries associated with the botnet related to the takedown. This way we had what we needed to establish communication. I’ll post examples of research used in an upcoming post.
Step 4: Lazy Exploitation – Metasploit Listener
What we found interesting is how easy exploiting botnet software is once you understand the C&C authentication. We could have created our own C&C but instead, we just set a reverse shell to pop the box. We knew going in the bot binary had features we could exploit with Metasploit based on research performed before obtaining the associated domain. Sure enough, it worked like a charm for some of our domains.
If you are thinking “this isn’t anything special” … well that is exactly the point! By simply knowing how the botnet works, one could use plain old metasploit to ride the botnet into the system. What this means is we CAN obtain the following:
- Basic access to infected endpoints
- Access to C&C domains
- Sometimes we can obtain a remote shell depending on the botnet we are exploiting
- Ability to sometimes install additional software (examples remote access tools (RATs), Ransomware, etc.
What we COULD NOT do using this approach is the following:
- Gain full control of the original botnet features … but so what
- Learn the identity of the botnet developers … again who cares
We received a handful of questions about what we did once on the endpoints but once again, that’s beside the point for answering our question. We were not performing a full pen test or looking into what you can do with a full compromised system. Our focus was on obtaining a foothold into a network leveraging an existing botnet infection, which we found we could do. That was the flag we were capturing. We were also asked about targets, but we felt it was not appropriate to disclose that information.
Wrap up:
Why care about this? We believe this is a real problem that is being abused today. There are adversaries using a similar approach and owning systems that are likely lingering in manufacturing or supply chain environments that have antivirus lacking the signatures to detect the botnet software. There probably aren’t network telemetry tools being used to look for very periodic beaconing hence these systems are just hanging out waiting for somebody to step in a own them. Exploitation is super easy, and many botnets have binaries published for anybody to grab and analyze. As one person pointed out, we believe the sweet spot for this attack will continue to move up in time as technology improves meaning new botnets today will become somewhat old botnets in the future leading to falling within the strike space for this research. As botnet creation and takedowns increase, the number of possible targets increases meaning this problem is just going to get worse.
Regarding fixing the problem, we really don’t have a specific focus for this issue. General security best practice such as defense in depth, enforcing baselines, installing endpoint detection and response, leveraging network telemetry are just some examples of how problems like this can be resolved. We believe updated systems won’t have botnet software that is easy to exploit like we targeted such as user laptops. We do believe (and saw) systems that are not often used and never updated are a high risk of containing older botnet software, which can lead to a direct breach of network bypassing many popular security tools.
We hope you enjoy our research and for those that attended our talk, thank you. We hope to see you at a future security event. —- Aamir and Joey
