Thursday, May 18, 2017

Linux botnet malware analysis: part 1

I came across my first Linux botnet malware when I setup a honeypot at work. I started analyzing it and it was really interesting. After that I started focusing on other work. I always wanted to see if I could track DDoS attacks but I never had the chance to further the project. This year, I was taking a NetSec class and decided that I should investigate botnet as my final project.
The analysis done here is a bit amateurish/half-assed. I was limited by time and skills. My goal was to determine what botnet infrastructure looks like, how it spreads, its capabilities, C2 protocol, and how to monitor it.
I worked with another person to do this. The data collection lasted about a month and we spent just a few weeks on analysis.
Background:
DDoS attacks are very commonly covered in the media/news now more than ever. Attacks are usually launched from botnets and that’s one reason to study botnets. Besides that, botnets are just interesting.
There are two basic components of a botnet. Command and control server and the victim/client. C2 is responsible for giving commands to the victim/client to launch attacks or do other things. Botnet can use different communication protocols, such as HTTP, IRC, and raw TCP socket connection.
Another thing required by the botnet malware is the ability to spread and infect more machines. Infection can rely on exploits or brute force. From what I’ve noticed from running honeypot is that the malware brute forces port 23/22 and runs a command, which downloads the sample malware and executes it.


I’ve seen download being done with curl, wget, ftp, and tftp.
In this research, we set up honeypots, acquired malware samples, and did analysis.


Honeypot Setup:
We utilized Modern Honey Network (MHN)  by ThreatStream for deploying and monitoring honeypots. MHN basically runs a central server that receives information from honeypot sensors. You can analyze what passwords were tried, where the attacks came from, and etc using it.
We were interested in anything that brute forces SSH so we deployed Kippo honeypots using MHN. Our original idea was to analyze bunch of samples/families so we deployed 7 honeypots but as soon as we started organizing the data, we realized that this would be too much so we decided to just focus on one family of malware and one group of samples.
Kippo saved logs of what commands were executed on the honeypots so we wrote a script to download those logs using sshpass (Kippo runs on port 22 and by default SSH was moved to port 2222 by MHN script):
sshpass -p ‘PASSWORD’ scp -r -P 2222 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@HP_IP_ADDRESS:/opt/kippo/log/* /root/logs/
After we obtained the logs we started looking through them. Since we were looking for command execution, we filtered the logs by looking for the word “executing command”. Now that we have list of commands executed, we noticed that some commands were irrelevant and we wanted lines in which download and execution occurred. We filtered again by looking for wget, curl, and ftp.
We can use the output from this and download the samples for analysis.
Various VPS providers were used to deploy these honeypots. Vultr was used to run MHN. Vultr is cheap, reliable, and user friendly.


Analysis Infrastructure setup:
Static and dynamic analysis will be covered in the next post.
For our research, we wanted to capture network some data to see who the victims of DDoS attacks are and information regarding the C2 protocol. We thought we would run the malware and then just filter for information using tshark.
Our goals when running the malware were that we wanted to capture the network traffic, avoid doing having a lot of impact when DDoS attacks were launched, and anonymize our IP address.
We utilized Proxmox, Tor router, Pfsense, and Linux containers.
In the picture above you can see the layout visualized. Proxmox allowed us to create containers and we created ubuntu containers. Traffic from the container is sent to pfsense, where we can do packet capture before the traffic goes to tor.
Proxmox containers have unique IP addresses assigned by pfsense so we can run multiple samples and filter by IP address to find out what sample is generating the specific traffic. Another benefit of proxmox is that it allows us to limit the network speed for the container. This allows us to avoid making a big impact in DDoS attacks but still monitor C2 commands.
Finally, the tor router we used was a physical one. Apparently, the latest version of pfsense does not have the tor package. This is okay. The router we used had a physical switch. When it’s switched to tor mode, nobody can access the configuration panel. To disable tor, you would literally have to be physically present and flip the switch.  
In the next post, I’ll cover binary analysis of the sample we decided to analyze.
Resources:
http://www.vultr.com/?ref=7127410 (FYI: this is an affiliate link, if you sign up using it, it puts credit in my Vultr account. You don’t have to sign up using it or even use Vultr if you find a better provider)

 The resources for this project were provided by the Living Lab at IUPUI.
Posted by at