Introduction
Recently, I have taken upon learning malware reversing and how to properly analyze malware in the wild. I find nothing more interesting than taking things apart and seeing how they work. I am also fascinated my the sophistication of modern-day malware. In order to pursue my goal of becoming a malware reverse engineer, I have began manually reversing live samples of malware found in the wild.
Getting Started
To begin, I first had to obtain a method for getting samples of wild-malware. I contacted the nice guys at VirusTotal and outlined my research goals to them. In a short amount of time the gave me an API key with nearly unlimtted access to their Intelligence service. For those of you who are unaware, this is a service that allows one access to fresh samples submitted to VirusTotal.com. This service even allows one to filter samples based on YARA rules. I spent a fair amount of time playing with YARA rules to generate a few rule sets that fit my needs. With my YARA rulesets created and actively filtering live samples coming into VirusTotal, it was time to play the waiting game and begin my hunt for malware.
It Didn't Take Long...
Almost immediately after enabling the YARA rules I was being bombarded with live samples of malware showing up in my notifications. I am not going to lie, I got pretty excited and my adrenaline was going. These weren't old samples that have been hacked apart by universities and research teams; these were wild samples of malware with live C2 servers. I couldn't wait to get started, so I fired up my sandbox environment that would soon become my second home and got to work...
My Malware Sandbox
I should make a brief note of what my malware sandbox consists of. My sandbox is extremley limited and basic as I set it up it a short time, but it gets the job done. What I did was simply create a VM, load windows 7 home premium onto it, loaded some tools that I would think useful for malware analysis, and snapshot it.
Some tools I started with:
Ollydbg w/ various plugins
PEiD
Resource Hacker
Wireshark
FastScanner V3.0 Final
ILSpy
dis#
Delphi Disassembler (DeDe)
HxD
LADS
TCPView
Process Explorer
*after learning to manually unpack PE's using ollydbg, I obtained some common unpackers to speed up the process
AsPackDie
UPX_unpacker
*note, I am fully aware that modern malware analysis is almost entirely automated. However, I refrained from setting up an automated sandbox such as Cuckoo for the sole purpose of learning. For me, hands-on is the best way to learn and automating the process surly would not help my goal.
njRAT Reversal
njRAT is a variant of a common class of trojans know as Remote Administration Tools (RATs). The goal of this reversal is to demonstrate and practice my ability to reversal a live sample of wild malware, identify its command and control server (C2), and to write a SNORT rule for the sample's callback (or phone home), in order to detect the presence of this sample on a network.
Obtaining the sample
To obtain this particular sample, I used the following YARA rule written by Kevin Breen:
rule njRat : RAT
{
meta:
author = " Kevin Breen <kevin@techanarchy.net>"
date = "2014/04"
ref = "http://malwareconfig.com/stats/njRat"
maltype = "Remote Access Trojan"
filetype = "exe"
strings:
$s1 = {7C 00 27 00 7C 00 27 00 7C} // |'|'|
$s2 = "netsh firewall add allowedprogram" wide
$s3 = "Software\\Microsoft\\Windows\\CurrentVersion\\Run" wide
$s4 = "yyyy-MM-dd" wide
$v1 = "cmd.exe /k ping 0 & del" wide
$v2 = "cmd.exe /c ping 127.0.0.1 & del" wide
$v3 = "cmd.exe /c ping 0 -n 2 & del" wide
condition:
all of ($s*) and any of ($v*)
}
VirusTotal's Intelligence service did the rest, supplying me with live samples that match the above YARA rule.
This particular sample is identified by its SHA-256 Hash of "baead7962c62083ecb2d77dcbdc65ba348addd128f03825e1b9d9e1cd3a047a6"
Identifying the Packing Used
I always start by checking which packing is used on the portable executable. This determines which direction I am going to go in when beginning the reversal. I used PEiD v0.95 and cross reference it with Fast Scanner v3.0 Final to determine what I am working with. I chose this piece of malware as my first reversal based on the fact that it was written in C#, a .NET language.
Below are screenshots of this process:
A Closer Look...
My next step was to take a closer look at the sample in question. Since this sample was written in C#, I can use any common .NET reflector tool to convert the assembly code to readable functions. For this I generally use ILSpy.
I begin my doing a quick skim through of the entire code, trying to get a feel for the malware's behavior and keeping an eye out for keywords in variables and function names such as HOST, CONNECT, PORT, KEY, PASSWORD, NICK, MSG, as well as strings or integers that fit the format for an IP address or port number. The purpose of this is to catch any valuable information such as a unique callback method and the address of the command and control server.
In this particular sample I lucked out and found the following variables:
public static string H = "86.21.42.108";
public static string P = "1234";
Below is a screenshot of the code in ILSpy:
Now I have a suspect IP for the command and control server, as well as a port number. Knowing what destination and source address to keep an eye out for, I popped open Wireshark to begin some network analysis of this sample in action.
Fire In The Hole!
This is one of my favorite parts of my process, getting to knowingly execute a live sample of malware. There's just something about double clicking that executable that gets my blood flowing. It's like knowingly pressing the switch on a detonator: despite it being a controlled environment your are still getting to blow something up, and that's pretty cool, right?
When I run a sample I like to have process explorer open, "netstat -naob" ready to run in an elevated CMD window, and Wireshark listening. This let's me see any immediate changes in my system upon execution of the sample. Process Explorer will alert me to any new processes being spawned, as well as give me a ton of information on each one. *Later I use Process Explorer to do a live memory dump of a sample to further analyze it* "Netstat -naob" will tell me what processes are activley listening out to the internet on my system. I have found that this often will be a dead giveaway to the callback behavior of a sample. Finally, Wireshark which allows me carefully inspect each packet going across my interface.
Wireshark allows me to see the process in which a sample interacts with its C2 as well as any data it is sending or receiving. This is crucial in developing a unique signature to identify this malware's activity by. I can use this information to write a custom SNORT rule to detect activity of this malware on a network.
Below is a screenshot of this sample's TCP packet stream in Wireshark, as well as a screenshot of the data stream it is sending to the C2:
Identifying The CallBack
In order to create a useful signature of this sample that can be later turned into a SNORT rule, I must identify the callback method used by the malware.
Analysing the ILSpy dump, I find a function that catch my eye:
Which when further inspected, reveals a TCP connection being made to the previously discovered host and port, as well as sending the data from the function "OK.inf()":
Clearly, we should check out "OK.inf()", here is a snipped of the function:
Essentially what this function is doing is gathering some data on our system and calling other functions to compress and obfuscate it using base64 encoding. We could further dissect this to determine exactly what information from our system is being grabbed, however for our purpose of finding a unique network signature, we will skip this step.
OK.Connect() takes the information gathered of OK.inf() and sends it to the C2. This is the first time an outbound connection is being made, and is our initial callback of this sample. Analyzing the first packet sent by this sample confirms this theory and can be seen below:
Crafting The SNORT RULE
With all of the information we have obtained above, we can now craft a snort rule for this piece of malware's callback to its C2. As shown in the above packet, as well as in the code of the sample, the inital callback begins with:
lv |'|'|
This is shown in the code via the next two screenshots:
Knowing that this string is hard-coded into this malware, we can write a SNORT rule that parses network packets for this string, and alerts when it it is found:
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"njRAT C2 Callback"; flow:from_client,established; content:"|00|lv|7C 27 7C 27 7C|"; fast_pattern;reference:url,www.virustotal.com/en/file/baead7962c62083ecb2d77dcbdc65ba348addd128f03825e1b9d9e1cd3a047a6/analysis/; classtype:trojan-activity;)
Findings
Command and Control Server: 86.21.42.108
SNORT Rule For C2 Callback:
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"njRAT C2 Callback"; flow:from_client,established; content:"|00|lv|7C 27 7C 27 7C|"; fast_pattern;reference:url,www.virustotal.com/en/file/baead7962c62083ecb2d77dcbdc65ba348addd128f03825e1b9d9e1cd3a047a6/analysis/; classtype:trojan-activity;)
Conclusion
This is the first part of my Malware Reversing series, which will document my findings of my research on live samples of malware in the wild. I apologize for its length, as later segments will skip right to the analysis of the malware. My goal of this research is to better hone my skills of malware reversal with a hands-on approach, while also being able to contribute to the security community by offering up C2 server addresses and SNORT rules to detect malware activity.
