Hey folks, it’s been a hot minute since I’ve had time to throw something out on here. Been out of the country for a few months and that took up most of my time. Moving past that, I was looking at doing some posts on malware analysis. Malware is where I got my start and I’ve been following a lot of other analysts lately. So why not do a few posts on it?!
Let’s kick this off with the most basic of fundamentals; Static Analysis. You can tell all kinds of things about potential malicious software without even running the dang thing. Hashes, strings, headers, and other items can tell you a wealth of information about what you might be looking at. Starting with that, I’ll use this first post to cover how we can use publicly available tools to get started with basic static analysis of malicious software.
First things first, we need a basic lab environment in which to work. Personally I like to use VMware Workstation, but Virtual Box is a free alternative. For my examples I’ll be working within a Windows 7 Home 64-bit environment. Why Windows 7 and not Windows 10 you ask? I like to go with what I assume the lowest level of most users is. I realize there’s still a plethora of folks running XP, but I’ve seen the majority of organizations I’ve been around at least bumping that basement up to Windows 7, so that’s where I’ll operate as well.
After getting a Windows 7 instance up and running in VMware, I install a few static analysis tools and take a snapshot before loading any samples onto the box. This way if something wonky goes on with whatever I’m working with then I can just revert back to a clean state. I have the following tools loaded up already (although I may or may not use them all):
- IDA Free
- Process Explorer
- Process Monitor
- Dependancy Walker
- Resource Hacker
Additionally I’ll be using online tools such as VirusTotal and Hybird-Analysis.
I won’t walk through the entire setup for the lab, as that’s something thats covered extensively plenty of other places (google is your friend).
Getting To Work
In this scenario our network admins have passed us a file that they’ve received and think might be malicious; it’s our job to determine if it’s malicious, what it might do, and find indicators of compromise (IoC). The file for this scenario is called “Sample-01.exe“. We’re using static analysis only here, so we need to gather as much information as we can about this file without actually executing it.
The first thing I always do with suspicious files is run it through something like VirusTotal (VT). VT runs the file through dozens of different Anti-Virus systems as well as running it’s own analysis on the file. It’s also owned by Google, so it’s a pretty reliable and well up-kept system. Since we know nothing about this file right now, this might take a lot of the leg work out of it for us. Let’s throw our file in there and see what we come up with…
Bingo. Right away we see a crap ton of red flags going up with this file. 38 of 67 different AV systems tested have come back with positive results for malware. Based off the results we can assume this might be some kind of trojan. VirusTotal does much more than this though; let’s take a look at some of the details…
By moving over to the “Additional Information” tab, we can get all kinds of useful stuff. VT has hashed the file for us using a plethora of different algorithms, which can be useful in identifying this specific file. We also get an Import Hash, or imphash, as well. The Imphash is important because it’s a hash of the import table this binary uses. This can be very helpful in tracking malware campaigns as samples change over time (see my previous WANNACRY posts for an example).
Taking note of all this info, let’s move on over to the File Detail tab on VT…
Again we get some useful stuff right off the bat here. I was going to run PEiD against this thing anyway, but VT did it for me and identified a packer being used. With a file size of only 16k I feel pretty confident in saying that this might be packed/compressed code and that PEiD probably isn’t lying to me. Additionally we see a compilation time stamp; this can be forged however, which is why I tend to not give it a lot of importance. It’s good to note it, but I don’t read much more into it than that.
Since I now have a quick static analysis of this thing, I like to let something like Hybird-Anaylsis.com have a crack at it. Let’s browse on over, upload our file, and see what we find…
In this case, Hybrid Analysis doesn’t yield me a ton of interesting info. Something that did peak my interest however was some of the imports. Seeing CreateFileA tells me that this thing is probably dropping something onto the system. Additionally we see FindFirstFileA and FindNextFileA, which is functionality we typically see with malware that is looking to scan through the system. So yea, this has my attention. Let’s move past online tools and start digging into into it further.
Further Static Analysis
Since I’ve got a few of the basic things like hashing out of the way, I want to move into checking out all the different imports this thing is using. To do that I’ll throw it into Dependency Walker to take a further look…
We see Kernel32.dll and MSVCRT.dll listed. Kernel32.dll is a super common import, it controls basic functions like manipulating files and memory; so no big shocker there. We also see MSVCRT.dll, which holds standard C library functions. Looking at just this, I’m not seeing anything very useful. We need to dig further.
I fire up IDA and see what I can see. Having previously seen CreateFileA, I find that function and give it a look…
Winner! We have our first host-based artifact; the malware will drop a file in the System32 folder named “Kernel132.dll“. Further investigation within IDA of that DLL file reveals a hard-coded IP address of “127.26.152.13“.
So we’ve now identified both a host-based and network-based IoC. Coupling that with VT flagging this as malware, I would report this back as a probable trojan and look for the IoC’s indicated by our analysis as methods of detecting any infiltration of our network. Took me all of maybe 5 minutes of work.
In summary, we took a completely unknown file and were able to identify it as probably malicious just based on static analysis. Furthermore, we were able to identify both a host-based and network-based IoC to further check our network for any compromises.
We could go a LOT further with this by doing some real dynamic analysis on this thing, but that wasn’t the point for this exercise. We specifically wanted to use static analysis to see what we could learn and use.
I’ll probably follow up with additional malware analysis posts in the future. I’m not a professional reverse engineer though, so in the mean time I’d advise seeking out some real pros work and seeing how they do it. Two resources I’d recommend are MalwareTech Blog and Amanda Rousseau.
Until next time!