Tuesday, June 18, 2013

Writing Rootkits 101: Lessons Learned (plus files)

The Background!
I'll start with an apology for the delayed third portion of this series. There were a number of personal life reasons for the delay, one of which was the purchase of a new home. Anyone that has purchased a home can understand the time drain and will hopefully forgive the delay.

So in this article I promised to release the source code for the UmitKit rootkit. The code can be found on my Google Drive here.

The Setup!
The files are sorted into two directories (services and scripts). The services directory contains the startup script for the Magic$hell and the Magic$hell itself. The scripts directory contains all the replaced command scripts. As you can see, most of the scripts are small and quite simple.

The Big 3 Failures:

One: The biggest failure of the rootkit is the ease of detection. Any file integrity check on normal system administration binaries will fail and lead to an investigation. If that wasn't easy enough, the rootkit sets up a new service on a special port. Any kind of monitoring and/or regular scanning would detect the new service.

Two: Once detected, the rootkit does nothing to hide its intentions. All the scripts are plain text rather than binaries. This makes for an easy understanding of the goals of the infection as well as where to look for the next big failure.

Three: Finally, the lackluster persistence ability of the rootkit. The rootkit leaves all system binaries intact for the system administrator to easily remove the rootkit once detected. A simple look at one of the scripts will point to the hidden but intact system binaries. This makes it very simple for a system administrator to replace the damage done.


The Attack!

The Big 3 Successes:

One: The first success came from the rootkit's ability to hide the malicious user's activity. Multiple scripts are designed to hide the connection of the user from a lazy system administrator. Attempts to determine who is online will not show our malicious user. Simple as it may be, the evasion works!

Two: The rootkit attempts to gain lateral access. In addition to preventing removal and/or password lockout, several scripts will record administration activity to world readable file. This would allow you to view password changes as well as attempts to remove the malicious user.

Three: Lastly, the rootkit establishes multiple channels of persistence. Remember that third failure? I lied a little. Although the removal of the malicious scripts is quite simple, removal of the malicious user is not quite so easy. There are three major methods of persistence. First, common commands are replaced with scripts to readd the malicious user. So if an administrator switches to the root user to do pretty much anything, they will unwittingly readd our user. Second, the root user crontab is modified to silently readd the our malicious user every minute of every day. Lastly, the Magic$hell has the ability to remove/add our malicious user.


The Payload!

It's not the world's best rootkit and you can probably find better with a simple Google search. However, the UmitKit should give you an idea of the goals of a rootkit and how easily a simple rootkit can be created. The UmitKit can be used as good learning tool for someone wanting to get an idea of an attacker mindset.

I strongly encourage those interested in trojan/rootkit development to take the time to create your own simple package. The act of creating all these scripts gives you a better understanding of how to think like an attacker. If you have a friend, have the friend attempt to remove the infection. After some time, I forgot which files I had manipulated and gave up trying to remove my own infection. If you can frustrate your friend, you're doing it right!


-Suspicious.Low

Wednesday, June 12, 2013

Malware Analysis In Situ

Preface: I am by no means a "professional" malware analyst, and I'm sure there are easier ways  to analyze samples (including just throwing the following sample at a sandbox). This was more of a live-fire exercise.


Besides drive-by downloads, typically in the form of Exploit Kits, one of the most common vectors for delivery of malware is email. Last week I received a typical message promising to contain deposit slips in a .rar file. Instead of trashing it or uploading it to a public sandbox, I decided to take a peak into the sample's functionality using a variety of techniques. Some of these have been covered in previous articles (Malware Analysis 101 Part 1, Malware Analysis 101 Part 2, Malware Analysis 101 Part 3) while others will be somewhat more advanced. First we'll start with static analysis in dependencywalker and Ida Free. Then we'll move onto OllyDbg. Next up will be behavioral analysis within the analysis VM using Brian Baskins' Noriben.py (and fakenet to emulate a "real" internet connection). Finally, I'll share the final report from malwr.com to see what indicators we may have missed throughout the above process.

Friday, March 15, 2013

Memory Games - Volatility


I had a brief introduction to memory forensics, or rather I was pushed into exploring the topic after an interesting conversation with Micrmsoft's own Allison Nixon.

Allison had come across a malware sample that was thwarting VM runtime execution and static code analysis. It was evident after IDA began to loop on a large block of code that this particular sample was packed. This was confirmed with a quick strings search. Besides the Visual Basic ASCII strings, there was no means by which to analyze this sample without patching out the encryption function. Unfortunately, neither of us is at a point where we can handle that just yet so we threw some ideas around. Prior to roping me in, while closely observing the sample (Redacted), she discovered the means by which the VM detection was functioning. After removing the registry entry that was observed (more info to come in a blog from Allison) the sample successfully executed and the VM was infected!

With the sample active in a controlled environment, I suggested that a memory snapshot of the VM environment could be used to carve a copy of the unencrypted sample for local static analysis. This would allow us to bypass the encryption function of the original sample! The awesome thing about VM environments, and VMware Workstation (http://www.vmware.com/products/workstation/) in particular, is the ability to create snapshots which include a ".vmem" file. This file format is very similar to using dd (http://www.forensicswiki.org/wiki/Tools:Memory_Imaging) to dump RAM from a live system, and thus, the open source Volatility Framework (https://www.volatilesystems.com/default/volatility). After creating taking a snapshot of the infected VM to generate the .vmem file I needed, I fired up SIFT (Freely provided by SANS here) to begin my search for the nastiness.

Sunday, February 24, 2013

Monday, February 18, 2013

Writing Rootkits 101: What now?

The Background!

Where was I? Oh yes, pwning my fellow classmates. So I had root access via a new user "kernel" on my classmate's computer. The next question was, "What now?" The answer came to me faster than I expected. Do NOT let him figure out I am on his system!

Sidenote: This is an ok article I found that SANS released regarding rootkit detection/removal that's worth reading. Rootkits For Beginners (Prevention/Removal)

The Setup!

So the initial goal my rootkit was evading detection. However, a rootkit can have multiple goals:
  1. Gain Privileged Access
  2. Establish Persistence
  3. Evade Detection
  4. Steal Sensitive Information
  5. Other Maliciousness
Shockingly (/sarcasm), these are the same kinds of things that most modern malware attempt to do.

The Attack!

Rootkits can use any number of techniques to approach the goals listed above.

1. Gain Privileged Access:
Some rootkits come packaged with common exploits/techniques to escalate privileges on the host in which they are installed. My rootkit did a little of this, but a more detailed explanation is needed to explain (which I'll give in the next article).

2. Establish Persistence
Rootkits will typically open backdoors and/or phone home to command and control servers in an effort to establish persistence. The backdoor can be done in obvious ways (running a new service on the host) or in less obvious ways (hiding in an existing service). My rootkit used a custom "Magic$hell" service that ran as root and gave me persistence on the host.

3. Evade Detection:
My rootkit used a type of command filtering at the application level to attempt to evade detection. That is a fancy way of saying: I moved actual command binaries to a hidden location (the same directory with "." in front of them) and put my custom scripts in their place. There are much better and harder to detect methods of accomplishing this same functionality (rebuilding binaries, hooking into the kernel, etc.), but my method was quick and worked well enough for my purposes.


The Payload!

So this is probably the section you've been waiting for...

Introducing the UmitKit!!!!


It should be noted that the UmitKit was designed to infect an Ubuntu Linux host.

The UmitKit has two overall sections: Overwriting Commands and Service Addition/Manipulation.

Overwritten Commands:

Persistence:
"cat"   =   New command would silently try to readd the malicious user.
"nano"  =  Same as above.
"sudo"  =  Same as above.
"vi"  =  Same as above.
"ed"  =  Same as above.
"ls"  =  Same as above.
"mv"  =  Same as above.
"rm"  =  Same as above.

Evasion:
"who"  =  New command would filter output by removing entries for the malicious user.
"lastlog"  =  Same as above.
"users"  =  Same as above.
"w"  =  Same as above.
"last"  =  Same as above.

Information Disclosure/Persistence
"passwd"  =  On first attempt, the command would log the new password (and username) to a publicly viewable hidden file and display a normal mismatch error. Second attempt would succeed unless the change was for our malicious user (in that case it would only "appear" to work).
"deluser"  =  If the command was run for our user, it would mimic a successful removal. In all cases, it would then attempt to readd the user to the system.
"userdel"  = Same as "deluser".


Service Addition/Manipulation:

Service Manipulation:
Root User Cron Job - The UmitKit would replace the root user's crontab with a new file that attempts to silently readd the malicious user every minute of every day.

Service Addition:
Backdoor (Magic$hell) - The UmitKit installed a new service on the system that attempted to disguise itself as a type of shell on the host (like bash, sh, ksh, etc.). The service was named "mshd" and the executable was named "msh" in the same directory as other common system shells. The backdoor was hardcoded for the IP address of the attacker and would not open for any other source IP address. A simple telnet session to the correct port from the hardcoded IP would give full access to the system as well as some custom commands to easily see what is happening on the host.



In the next addition, I will release the source files for the UmitKit, discuss failures/successes for the rootkit, and discuss future changes that would make the rootkit more useful.

-Suspicious.Low

Sunday, February 17, 2013

An unexpected weekend project that went very well.

We all have these unexpected projects. This week I was given a surveillance DVR that had seen better days. The primary hard disk had spun a bearing (hehe). It was a system I built a number of years ago for my family. Previously I used the software that came with the capture card, a generic 4 channel bt878 card. The software ran on Windows XP so from the start I never really expected anything long lasting although it did last about 5 years.

Anyways, enough about what it was. I dug up a 4Gb USB flash drive, installed a very basic CenOS 6 install, got x264, FFmpeg, ZoneMinder, MySQL, PHP and Apache and made it a reliable surveillance server now. It does have a 1Tb drive for the video.

I have to say the ZoneMinder software is not anything fancy by first appearance but supports all the features that most expensive commercial solutions offer. I like that it did not require me to install any GUI environment on the device itself. No resources wasted on this build.


[root@cam ~]# uptime
 11:09:56 up 1 day, 23:04,  2 users,  load average: 0.00, 0.18, 0.22
[root@cam ~]# ps ax | grep zm[ac]
12795 ?        S      0:04 /usr/bin/perl -wT /usr/local/bin/zmaudit.pl -c
12931 ?        S     46:47 /usr/local/bin/zmc -d /dev/video0
16011 ?        S    131:08 /usr/local/bin/zma -m 5
16192 ?        S     35:39 /usr/local/bin/zmc -d /dev/video1
16204 ?        S    126:37 /usr/local/bin/zma -m 6
16231 ?        S     35:32 /usr/local/bin/zmc -d /dev/video2
16243 ?        S    120:07 /usr/local/bin/zma -m 7
16309 ?        S     34:22 /usr/local/bin/zmc -d /dev/video3
16321 ?        S    128:12 /usr/local/bin/zma -m 8


 Not bad for an old Pentium E5200 with 2Gb.

-Mathew

Saturday, February 16, 2013

Writing Rootkits 101: The pre-story

The Background!
So a long time ago, I was at school in an introduction to cyber-security class. No one in the class really wanted to learn anything about security, we just knew we would get to setup servers and attempt to attack each other at some point during the semester.

The Setup!
Each person in the class was given a really cheap laptop to setup as a Linux based server. You could choose your own flavor, but only Ubuntu would be supported by the Instructors. Each server had to have a couple services running (SSH and Finger). I have no idea why we had to have Finger running. I assume it was to annoy the students as it's a depreciated service. In addition, there had to be three user accounts on the host (one admin for the professor, one admin for the TA, one guest user with username=guest and password=password). All of the users had to be able to use the ping command once logged in.

The Attack!
So at the time of this class, I knew little to no security. As such, my attack attempts were dismal. The best I could do was fork bomb a few of my classmates. Since most of the servers were up to date with limited services available, me and a friend of mine (Let's call him Davis) decided to team up for some social engineering. A few of our classmates were horrible with their technical knowledge when it comes to Linux. They had only ever done programming and never with Linux. So we decided to "help" them setup/fix their servers. Davis was a better script writer than me and I am a better "talker". As such, Davis started setting up a couple scripts to give us admin access while I went to help out our classmates. Most of the people I talked to knew better than to have me help them, but one person was more than happy to have me help. It was around this time that Davis texted me that he had our "payload" ready and I let him know which classmate we were "helping". As I was helping our classmate (yes, I did actually help him too), I executed the payload and we were off to the races!

The Payload!
So the initial payload was dumb and any good admin would have known something was wrong. There was now a "kernel" user on the machine with root privileges. At first both Davis and I used the account and were just happy to be on the system. However, I really wanted to play around and see what fun I could have. I started writing scripts and putting them on the system to hide our user from being discovered. Mostly I stuck with hiding from commands being taught in class like "who","lastlog", etc. I didn't really want to be "malicious" to the point where you couldn't find our user. I just wanted to hide enough that a complete n00b wouldn't see us. That was sufficient for my time in the class, but it was an amateur attempt at being persistent on the host. Later, I would develop a more advanced version of the "rootkit" (I use the term very loosely) that is fairly easy to detect, but difficult to remove.

This seems like a good place to stop for the pre-story. In the next segment, I'll talk more about attack vectors, the goals of a rootkit, and hopefully get into the details of the rootkit I created.

-Suspicious.Low