May 9, 2021
Practical Malware Analysis, Part 1: Basic Static Techniques
Before going through the labs, we’ll skim the chapter and download any of the tools it mentions. I’d forgotten just how many there were in this book — going through this process reminded me of populating fresh virtual machines with these tools in college. This is just the first chapter, though, so most of the tools are pretty basic, focusing on determining packing methods and searching executables for strings or linked libraries.
With that out of the way, we can get started on the lab questions. There’s a fair amount of repetition here, so for brevity’s sake I’ll just complete Lab 1–1 and 1–4.
Part 1–1: Lab01–01.exe, Lab01–01.dll
1. Upload the lab files to VirusTotal. Do they match existing signatures?
Oh, yes they do. I’m sure these have been uploaded to VirusTotal hundreds of thousands of times, if not millions. Interestingly, Kaspersky failed to determine that either file was malicious.
2. When were these files compiled?
The creation time for these files is December 19th, 2010, at 4:16 PM.
3. What signs, if any, are there of packing/obfuscation of these files?
PEiD doesn’t give any indication of packing for either of the two files.
4. What do the imports say about the function of the malware?
The file lab01–01.exe only imports a few .dll files. Kernel32.dll is a pretty standard Windows .dll, used for memory management and critical to the functionality of the Windows operating system and a many programs that run on it.
This malware seems to be importing functions mainly pertinent to locating, copying, and creating files.
The second import, msvcrt.dll, contains a number of functions for programs written in C++, including string and math functions.
We don’t really see any imports out of the ordinary here.
The second file, Lab01–01.dll, has three main imports. The first of these is also Kernel32.dll.
Some google-fu later, I’ve learned that these functions (aside from sleep) seem to relate to creating and managing some sort of shared (but “mutually exclusive”, hence “mutex”) resource. I’m not sure what it is, but I’d hazard a guess, just from these imports, that the malware might be designed to have the malicious .dll file imported by a legitimate process, then have the .dll start the corresponding .exe file.
This library is also used to export an enormous number of other functions, too many to usefully sift through.
The other two imports are ws2_32.dll, the windows socket API, and msvcrt.dll, which functions as discussed above. Neither of these import any immediately interesting functions, with the exception of msvcrt.dll, which imports strncmp, which is the string comparison function.
So, in summation:
- This file searches the file system of the system it has infected.
- It appears to create processes and remain inactive for periods of time.
- It may search for specific file names.
- It copies files, and may create new ones.
- It is active over the network.
From this, my guess regarding the purpose of this malware is data exfiltration, possibly of specific files/directories, which would make sense — it’s unlikely that malware would attempt to send the entire contents of a computer file system over the network. It may be persistent or wait for certain conditions prior to operation.
5. Are there any other files you’d use as indicators of compromise on infected systems?
The malware does import a function for creating files, so let’s see if there are any obvious strings in either file.
Nothing interesting here. Let’s try the second one:
Not much here either. What am I missing?
A quick review shows a rather obvious trick that nevertheless worked perfectly on me. I’ll chalk it up as a lesson to look more carefully next time.
The “l” in “kernel32” has been replaced with a “1” in these strings. A subversion of the Windows library for memory management would, of course, be catastrophic to continued operation of the compromised system.
6. What network-based indicators of compromise are there?
Strings output from analysis of the .dll file includes an IP address. Traffic to and from this IP address can therefore be interpreted as an indicator of compromise.
7. What is the purpose of these files?
Without conducting static analysis, my best guess is that the malware is designed to exfiltrate data. It may also damage the operating system and require a fresh installation, depending on whether or not it damages kernel32.dll or merely hides as it. It’s not entirely obvious which of the two files is designed to be run first; however, the .exe file contains a string referring to its counterpart, while the reverse is not true. If I had to guess, I’d say the .exe is required to activate the .dll file, which then conducts the remainder of malicious activity.
Out of curiosity, I cloned my VM and ran the malware. It had no obvious effect, and, to my disappointment, did not drop a “kerne132.dll” file in the directory indicated in the output of the Strings tool. I restarted the computer, and it booted up fine. Uploading the kernel32.dll file to VirusTotal indicated no change from baseline.
So much for “WARNING_THIS_WILL_DESTROY_YOUR_MACHINE”.
Part 1–4:
1. Upload the lab file to VirusTotal. Does it match existing signatures?
Yep. As with the previous lab, many others have uploaded this file before me.
2. What signs, if any, are there of packing/obfuscation of this file?
None. Looks like a normal executable file, according to PEiD.
3. When was this file compiled?
According to VirusTotal, the file says it was created August 2019, but since it first appeared in 2011, we know that the header has been either corrupted or faked.
4. What do the imports say about the function of the malware?
This piece of malware imports three main .dll files. The first of these, kernel32.dll, we’ve seen before. Interesting imported functions include GetProcAddress, CreateFileA, WriteFile, MoveFileA, and other functions that appear to revolve around file and process manipulation.
The second, advapi32.dll, is a library of advanced API functions for windows (hence “advapi”), including functions for registry and security operations.
These three functions appear to center around accessing and altering the privileges associated with a process, probably to increase the privilege level of a malicious process.
The third .dll, msvcrt.dll, is a .dll required for Microsoft Visual C++ files to run properly.
Most of these functions seem pretty run-of-the-mill, although it’s unclear to me why a running piece of malware would care about its own input arguments. Two that caught my eye were __p__commode and __p__fmode, which are involved in file I/O and generally not supposed to be called by user-created programs.
5. What host-based or network-based indicators of compromise exist for this malware?
Running Strings on this program mentions two specific files, as well as a URL pointing to a specific executable. The first file, \system32\wupdmgr.exe, is the Windows Update Manager, and is a legitimate program. The second, however, is the slightly different \system32\wupdmgrd.exe. Its presence can be used as an indicator of compromise. Further, references to the URL can be used as a network-based IOC.
6. Use Resource Hacker to extract the resource from this malware. What is it for?
Extracting the resource from the base file was pretty straightforward. I saved the resource as a separate file and pulled up PEiD to confirm that it was, in fact, an executable.
I uploaded the file to VirusTotal. Most of the detection programs flagged it as dangerous, with various references to being a downloader and/or a Trojan.
I opened up Dependency Walker to see what functions it called. If this doesn’t scream “dropper”, I don’t know what does.
Well, that concludes the Basic Static Techniques chapter exercises of PMA! Next up is Chapter 3: Basic Dynamic Analysis. (Lab 2 is about analysis in a virtual machine, which we’ve already been doing, and it doesn’t have any associated lab exercises.)
