ContradictionC2: A Takedown-Resistant Botnet Based On Dead Drops
March 18, 2016
This blog entry is a little different than previous blog entries. While in college, some friends and I theorized and implemented a botnet architecture that was designed to be difficult to take down, anonymous, and stealthy. We spoke about our project at a couple conferences, and it was ultimately an awesome learning endeavor. I’m writing this more as a memoir of the entire experience, rather than my normal technical content. If you are mainly interested in the technical side of the project, I suggest skipping to the Design and Implementation or Project Materials sections.
Backstory
Design and Implementation
Conference Debuts
Project Materials
Backstory
During the spring semester of 2014, I was enrolled in my college’s Information Assurance capstone course. The course revolved around a capstone project, which was functionally a group project incarnation of a senior thesis. Luckily for me, I had some close talented friends from my college’s computer security research group, NULLify, in the course with me. This gave us the perfect opportunity to attempt something grand.
We ultimately came up with the idea of a new breed of botnet architecture. Botnet architecture is also commonly referred to as command and control, or C2 for short. We wanted to make something that addressed the issues with the current status-quo of botnets. Something that would be difficult to take down, anonymous, and stealthy. This idea was contradictory to both our professor’s and college’s conception of a capstone project, given its offensive nature. Even though building something like this appears malicious, our intentions were to expand our thinking so that both we and our audience can better defend our systems against emerging threats such as this. After some discussions on the ultimate-good that could come of this seemingly malicious idea, we received approval.
Contradiction C2 was born.
Design and Implementation
Brief History of Botnets
As stated in the overview, we wanted to design an architecture that would be difficult to take down, anonymous, and stealthy. To achieve this, we decided to research and see what botnet architectures looked like at that time (early 2014). At that point in time, there were two major schemes: centralized and peer-to-peer.
Centralized architectures are appealing due to their ease of use and simplicity. This simplicity comes at a cost, the centralized architecture had problems with both anonymity and ease of takedown. Centralized communications means that the “head” of the botnet could be removed, therefore destroying the botnets capabilities. Additionally, a centralized server gave researchers and authorities a single spot to focus attribution efforts, therefore hurting the bot master’s anonymity (This assumes the centralized server was not living on bulletproof hosting. However, hosting choice is outside the scope of the topic of architecture design). Lastly, a centralized architecture’s stealthiness is only as good as its masquerade. There is nothing inherent to the design to add stealth.
The natural progression of botnets led to the second design, peer-to-peer. These architectures addressed the issues of centralized architectures, but also introduced their own problems. The Achilles’ heel of any peer-to-peer system is the issue of trust, how can you trust the peers? If researchers or the authorities gain access to a compromised client on the peer-to-peer network, they could potentially reverse the botnet’s communication and inject their own commands into the network, thus have control to take down the botnet. This is known as peer-poisoning. However, because the bot master is on the same organizational tier as its peers, there is no good way to achieve attribution. In the end, the peer-to-peer architecture attempts to address the issues of anonymity and takedown resistance, but can ultimately only solve anonymity. Similar to the centralized architecture, peer-to-peer has no built-in stealth mechanisms. However, a centralized design is less inconspicuous to researchers and authorities because a victim would be communicating to a single server. Whereas in a peer-to-peer design, victims could be communicating to a variety of systems, which is more alarming.
This brings us to our design.
Design
Our design revolves around a fundamental security problem, input sanitization. Few websites perform input sanitization on user uploaded images, and in some cases allow this with no authentication and display them publicly. These types of websites are what our architecture exploits. Examples of this are comment sections on blogs, news articles, various forms of social media, and etc. The idea was based upon dead drops used in the physical world. We designed a json based datagram that could be steganographically hidden into an image, which then could be uploaded 
to a vulnerable site. The victims in our design, also know as botnet clients, are configured with a list of vulnerable websites. When it’s time to fetch an instruction, the botnet client would recursively attempt to recover our datagram out of all images available on the vulnerable website. Once a datagram is found, the botnet client can then verify its authenticity via a rolling asymmetric encryption key schema that functions both as authentication and concealment. The asymmetric encryption makes sure that even if researchers or the authorities reverse the communication, they will only be able to recover the public key. The public key would allow them to decrypt datagrams, but they would not be able to forge or spoof new datagrams. After verification, the botnet client can perform the task presented in the datagram, such as: execute command, update vulnerable website list, change fetch time interval, and etc. In theory, the communication channel is bidirectional, just as datagrams can be placed on vulnerable websites, a botnet client can send a response in a similar fashion.
This architecture is very difficult to take down. The datagrams do not live on a singular site or a singular URL of a site, which not only makes things difficult to remediate, but also adds a layer of redundancy. Both of these factors lead to difficult takedown. Additionally, the architecture adds a layer of anonymity. Depending on the vulnerable website, the datagrams could potentially be dropped with no authentication, therefore only leaving behind a IP address. This could easily be thwarted with various anonymizing proxies. Even if an attacker left their actual IP address, some serious coordination would be required amongst website owners, hosters, operators, and the authorities to piece together some form of attribution. This would be difficult. Because the datagrams live on public, functioning, and potentially trusted websites, the architecture is stealthy. The botnet’s communication would look similar to that of user browsing the vulnerable website, therefore walking past any IDS/IPS. The only option defenders would have, aside from cleaning the malware off infected computers, would be to block entire domains that are found to be vulnerable. But even this task is difficult when major websites like Wikipedia are (at least at the time) vulnerable. I double dog dare you to block Wikipedia.
Implementation
To prove our concept, we built a simple implementation. The botnet client was written entirely in Python, while the bot master command interface was written in PHP with a Python and MySQL backend. The bot master command interface was an application a bot master could use to create and manage both datagrams and botnet clients. Some screenshots of this application can be seen on the right. (Frozen happened to be big at the time… who am I kidding, I still love it!) By no means was our implementation production quality, it was merely a proof of concept. We focused on making the botnet operate on WordPress blogs with open, unauthenticated picture uploads. 
We built a barrage of virtual machines running WordPress installations to mock vulnerable websites. Next, we created a series of datagrams and embedded them in images using the automation in our bot master command interface. The command interface automation then posted the images to the different WordPress sites. We then configured our botnet client to check the various WordPress sites for datagrams and watched them crawl and execute our commands!
That was a quick and basic overview of our design and implementation, full details can be found in the project materials section.
Conference Debuts
Peter Kiewit Institute Capstone Conference
Each year the Peter Kiewit Institute hosts a conference for students from various colleges to present their capstone projects to industry professionals and compete for cash prizes. The tracks are broken up into undergraduate and graduate projects, thus our project would be competing against capstone projects of the various information technology colleges. This was challenging for us because security is often intangible to most people, especially when stacked against more tangible, consumer-focused projects from the other information technology colleges. We tailored our presentation for a more general audience and made sure to really hit home the importance of offensive security and why our malicious idea is actually a good thing. The talk went great and we were excited to hear we took second place!
A fellow NULLify member took first place with a security project as well. This was especially exciting because this was the first time a Information Assurance project had placed, let alone sweeped 1st and 2nd place.
DefCon 22 SkyTalk
At this point, we had a paper, a slide deck, and some confidence. We already had plans to attend DefCon and decided to submit our project to DefCon’s call for papers. When working on this project, our course’s deadline was our priority. The course’s deadline was very late in terms of DefCon’s call for papers deadline, which lead to the denial of our talk. However, the organizers mentioned if they would have had it sooner, we would have made the cut. This was a double edged sword, it felt great that they liked our paper, but at the same time, it was sad that we were too late. But to our excitement, they also mentioned that the SkyTalk track was a separate submittal and still had some openings. We quickly submitted for SkyTalks and got in! This was going to be my first trip to DefCon, which was ultimately a good thing, because if I would have know what I was in for, I probably would have never agreed to submit and speak. However, after a mild panic attack and some pacing, we got on stage. It was difficult at first, but after getting into the “groove” of our presentation, everything went smooth. It was exciting to finally have an audience that understood the importance of offensive security and we could skip the lecture and focus on the juicy inter-workings of our project.
Project Materials
At the end of the day, it was quite the journey! I learned immensely both technically and professionally. I hope you found the memoir to be of interest and thanks for reading!