In the first post, we created our own malware lab with some basic tools. Now we’re going to use someone else’s sandbox. The automated analysis provided by Malwr.com has been tremendously useful in the short time that I have been using it. It’s a great tool for getting things done quickly. Keep in mind that even though a lot of the essentials are automated here, we’ll stick to a more manual approach in future posts.
Word Doc Sandbox
The first stage of the malware is the malicious resume that we received. Now, many sandboxes are built specifically for executables, but there are exceptions. One such exception is Xec-Scan which handles Word documents. Submitting our sample to Xec-Scan gives us something we had already discovered: the domain to which the malware calls.
Xec-Scan also labels it as “APT-Malicious!” That may be a bit of a leap given the target and method of delivery, but the document certainly is malicious. One thing that I really like about this sandbox is the automated Yara and Snort rules it can create.
The sandbox kindly gives us the information that we need to at least begin the containment process. It can also fingerprint some of the basic behavior of a given piece of malware, although as we will see later, there are other tools that yield additional (and more accurate) information on that front.
Analyzing Our Sample
Here is a link to the malware sample that I have already run: https://malwr.com/analysis/NWM0NGNkZTc3ODQ1NDExY2JiYTk5ODJjMDIwNTNhZjk/.
The first page that we see gives us a quick overview of the file. There are a bunch of interesting things right off the bat. First, the file type section states that it’s a PE32 executable (not surprising). What I found more interesting is that it is a Nullsoft Installer self-extracting archive. What does that mean? A common practice with malware is to use a “packer.” For a normal program, a packer can be used to compress code. This decreases the storage space necessary for the application. It can then fit specific types of media within smaller space. It also takes less time to transfer and can increase the difficulty of reverse engineering.
Luckily for us, the Nullsoft packer is easy to extract, in fact all we need is 7zip.
Lower down we have some signatures that were found by Malwr.com.
Some antivirus programs are labeling this as malicious, and that’s good. We also can see that it executed a process and injected it (a wild relevant blog series appears!). Conveniently, we can see that one of the compressed files was a DLL. It’s likely that is what’s being loaded. We will examine that further in the future. For now, Malwr has a lot of other useful information to give us.
One point of note is that no hosts or domains are contacted. What value does malware have if it doesn’t connect back to anything? More questions unanswered. Head on over to the Static Analysis page and let’s see what we can learn there.
Static Analysis
We’ll first take a closer look at the version information. Remember how the original macro renamed the downloaded file to putty.exe? The version information displayed adds another layer of masking. Further down, there are methods that it imports. Here are a couple that I find interesting (but don’t overlook other things):
- LoadLibraryA/LoadLibraryExA
- LoadLibrary is how a process can load modules into it. This is the first step for several methods of DLL injection. Since Malwr is warning us that it injects into a process, this is something we will want to look at.
- WriteFile
- Used to write a file, simple as that. What could it be writing?
- CreateFileA
- Creates a file that could then be written to.
- Registry Commands
- These could be indicative of other actions that the malware is performing. Maybe it’s using the registry for persistence
On the antivirus tab, we get the results of the VirusTotal scan; there were a lot of hits there. This can sometimes give you a good feel about the specific malware family you might be observing. General consensus says that our piece of malware is some form of trojan.
Behavioral Analysis
The behavioral analysis page is where we can get an idea of what it does when it runs. The timeline graph I find particularly useful.
Using these results, it’s easier to narrow down “what happens when” and focus on points of interest. For example, maybe we are worried about a keylogger. The “hooking” part of the timeline could give us an idea of when or if the malware is hooking our keyboard to gather keystrokes. Registry persistence is another worry. Just take a look at the registry calls to see if there is anything that we might be interested in.
The last thing I found interesting was the dropped files tab. We can see our lamprey dll there, as well as a tmp file. What do these do, how are they used?
Our Own Automated Sandbox
Sometimes for whatever reason, we may not want to share these files with others. This could be proprietary research, it could be that you have created your own malware, or perhaps you have something that you don’t want to be out in the public. Luckily, there are tools available to build your own. If you liked Malwr.com, Cuckoo Sandbox is probably the tool for you. Malwr.com is built on top of Cuckoo. You could also take the environment from the original post and expand that to fit your needs.
Where Do We Fit In?
With all this information that we gained from this automated tool, what’s the point in learning about malware analysis? One thing malware can do is detect and avoid analysis, so for all we know it was designed to do nothing in this kind of environment. So maybe we aren’t getting the full picture from these tools. We also know it didn’t call out when this was run, so what did it do? There are a lot of questions that I got from looking at the results, so taking a deeper look could prove useful. I also have found a lot of value in learning some of these tools as there is definite carry-over knowledge in other Infosec areas. Being able to use IDA proficiently will hopefully help me in vulnerability research. Setting up this environment has made me more cautious about handling malware. I am learning about Windows internals, which has been useful in some tool writing I have done. Even if the automated tools are all you need, I hope that you can find some value in learning to reverse engineer malware. I know I have.
Comments
If you have been enjoying my series, want me to write about something specific, or just want to comment: shoot me an email at wr.malark3y@gmail.com. Keep hacking!
References
https://malwr.com/analysis/NWM0NGNkZTc3ODQ1NDExY2JiYTk5ODJjMDIwNTNhZjk/
http://www.7-zip.org/download.html
http://www.cuckoosandbox.org/
https://www.virustotal.com/
http://scan.xecure-lab.com/
