'Lab01-01.exe', 'Lab01-01.dll'
Road to #100: Malware Report #1
It’s been a little bit of a while since the introductory newsletter, admittedly. So to you nerds who couldn’t wait for the next issue, I apologize. It’s here now. Welcome back to Crux of The Matter and of course, our first malware samples.
A bunch of prerequisites.
I’ve compiled some essential tools - as mentioned in our source book - we’d need for analysis below:
Windows Operating System
Hopefully, you can infer what these tools are all about as we work with them over time. You’d need them all at some point in your budding analyst career so get used to working with them. They’re all light-weight, don’t worry.
For those of you who love Linux, I’m with you, but we’ll be focusing on malware written for Windows computers since there’s a lot more of it out there. If you’re a Linux user, no problem, just grab a VM and follow along. My lips are sealed.
Oh, and one more thing: here's a link to the labs/samples we’d be using. I’d suggest you download the samples and work along with me.
Phew, had to trudge through that! Now, the crux of the matter; malware report 1 of 100. Get comfortable, this might take a while.
Identification.
For our first lab, we have two files; ‘Lab01-01.exe’, which is an executable and ‘Lab01-01.dll’, a dynamic link library. You’re probably familiar with executables, the latter not so much. To keep things rather simple, an executable runs a program while a dynamic link library (DLL) is a Windows feature that provides the necessary modules and functions a program might require during it’s execution/runtime - hence the term “dynamic”. Think of an execuatable as the engine of a car and a DLL as its fuel. Just as a car’s engine powers and propels the vehicle, an executable provides the code and instructions needed to run a program. And just as a car requires fuel to power its engine, a program might require one or more DLLs to provide additional code and functionality needed to run the program. As for the file names of our samples, don’t sweat it. In most cases, malware samples have generic or misleading names.
We upload both files to VirusTotal - a free online service that performs a scan on uploaded files/URLs against known antivirus signatures - to obtain vital information on the files. Granted, the information returned can be quite verbose - especially in our case of well researched samples - so I’d keep things as minimal as possible.
VirusTotal summary tab on Lab01-01.dll;
VirusTotal summary tab on Lab01-01.exe;
Clearly, both files have been in the wild for a considerable amount of time prior to this analysis. As a result, their file signatures and hashes can be readily obtained - as shown above, which is generally good news for you, the researcher. Perhaps, our hypothetical threat actor has been sloppy and reused well documented malware. That would definitely make your job as an analyst a whole lot easier.
When we navigate to the ‘details’ tab for each sample, we get a ton of supplementary information, like the file type, aliases, size, hashes, and more. For this specific lab exercise, however, we need to determine the compile time for each sample, as an older compile time can be a crucial factor along the way. But here’s the catch - clever malware authors can forge these timestamps, making them appear older or newer than they actually are. Pretty cool, right? It's a rather intriguing technique, but it underscores the need for caution and thorough analysis when examining potential malware samples.
Here’s the compile time for Lab01-01.dll;
And for Lab01-01.exe;
Quite a bit of information so far. Before we get into functionality and behaviour though, there’s packing and obfuscation.
In simpler terms, packing is shrinking or compressing the total size of an executable file, and obfuscation is hiding the execution of an executable file. For the astute reader, you can probably guess how this can affect our analysis on the behaviour of these samples. Two main clues hint of packing or obfuscation.
The first is how much space the sample’s code sections take in memory. We can check for that in the ‘details’ tab of each sample’s VirusTotal output. Remember .text, .rdata, .data etc? If you don’t here’s a quick primer. Pay attention to the .text section in particular because, as you might already know, that’s where executable code is stored. If the executable code takes up a lot more space in memory than on disk, the file is probably packed. Unpacking the executable code in memory increases it’s size significantly hence the change from the initial size stored on disk. Here’s an extremely simple illustration of the concept.
Heh, I drew that.
Going by this indicator, both files have no odd section sizes and therefore could be determined to be unpacked code.
Our second indicator is the number of imports a sample makes. Remember libraries and how including certain ones in your code exposes you to functionality that they posess?
Yeah?
That’s the same idea with “imports”. A sample having too few imports is a sign of packing or obfuscation and as we’d soon see, it’s not so hard to check for imports on files.
Characteristics and behaviour.
Back at the ‘details’ tab on VirusTotal for each sample, you’ll find information on the sample’s imports; key indicators of it’s features, functionality and behaviour.
Imports for the DLL;
And imports for the exe;
KERNEL32.dll is found as an import in most Windows programs and contains code that handles core functionality such as memory and file manipulation. MSVCRT.dll provides access to standard C library functions within the Windows program like malloc(), printf() etc. WS2_32.dll is a networking DLL handling network-related functions.
These DLLs imported by our samples in turn export certain functions back to our samples. Inputting the samples to Dependency Walker, we recover these functions from each import.
For Lab01-01.dll;
KERNEL32.dll exports: CloseHandle(), CreateMutexA(), CreateProcessA(), OpenMutexA(), Sleep().
MSVCRT.dll exports: free(), malloc(), strncmp() and more.
WS2_32.dll doesn’t show any imports under Dependency Walker. However, importing the DLL strongly suggests networking activity which could be corroborated with an IP address amongst readable strings.
For Lab01-01.exe;
KERNEL32.dll exports; CopyFileA(), CreateFileA(), CreateFileMappingA(), FindClose(), FindFirstFileA(), FindNextFileA(), MapViewOfFile(), UnmapViewOfFile() and more.
MSVCRT.dll exports: __getmainargs(), __p__fmode(), _stricmp(), exit().
That’s a lot of functions and funtionality to look through, I know. But if you did look through their hyper-linked documentation you’d have a fair idea of what these samples are coded to do. If you didn’t, no worries, here’s a brief breakdown of key and particularly interesting functions and how they contribute to the sample’s behaviour:
Lab01-01.exe imports KERNEL32.dll, which exports CopyFileA(), CreateFileA(). This suggests that the program can modify or create files. The exports FindNextFile() and FindFirstFile() suggest further file manipulation functionality. Meanwhile, MSVCRT.dll exports __p__fmode(), which is used to alter the read, write, execute, or access permisions of system files.
On the other hand, Lab01-01.dll imports the sleep function from KERNEL32.dll. This function basically puts the current process to sleep for a specific amount of time. So, in a sense, it’s “sleeping” the executable in memory. When you combine this with the process manipulation function imports like CreateProcessA(), it could be a way to start processes that check for sandboxing environments and evade them.
With the reasonable number of imports on both the executable and DLL, certainly neither file is packed.
Host-based indicators and network-based indicators.
Congratulations researcher if you’ve read this far. Even more congratulations if you’ve been working alongside me throughout this analysis. We’re nearing the end and I want to make sure we cover all our bases.
So far, we’ve learnt general information on our executable and dynamic link library; examining compile times, hashes, nature of executable (packed or obfuscated), and then a brief overview on the potential behaviour and functionality of these files once they’re in memory. All static analysis so far.
That’s not enough. And no, I’m not referring to further dynamic analysis. We’ll get there soon enough.
Rather, how do we identify the presence of this malware on an infected computer system? In other words, what signs could you look out for that suggests we’re dealing with Lab01-01.exe and Lab01-01.dll as our infecting malware? This is where “host-based indicators” and “network-based indicators” come into play.
Basically, host-based indicators refer to evidence that can be found on the affected computer system itself. These could include things like unusual registry keys, new files or directories, or unexpected changes to system settings. Network-based indicators, by contrast, involve monitoring network traffic to and from the infected system for unusual patterns of network connections.
Identifying these indicators requires a keen eye and a deep understanding of how malware operates. But by keeping an eye out for these signs, we can get a better sense of the source of the infection - a crucial first step in mitigating damage and preventing future attacks.
For this purpose, we’d use Strings; a command-line application that “searches for ANSI and Unicode strings in binary images”. Using this tool, we can find hardcoded references to certain could-be useful host or network-based indicators.
Running Lab01-01.exe on Strings, some of the output strings stand out;
[Sidebar to those following along, do not run these files. That’s no bluff, it will destroy your machine]
In the image, the strings ‘C:\Windows\system32\kerne132.dll’ and ‘kerne132.dll‘with the number ‘1’ replacing the letter ‘l’ is highlighted amongst the Strings output. The presence of a kerne132.dll file meant to look like the system file kernel32.dll could be used as a host-based indicator. Remember the file creation functions? That’s right!
Similarly, running Lab01-01.dll on the Strings tool outputs a vast amount of strings - mostly false positives - with one obvious flag to pay attention to; a hard-coded IP address.
This is a possible network-based indicator. Perhaps, the executable might be connecting to the IP address 127.26.152.13 at some point during execution. Remember the WS2_32.dll import being used for network functionality? Well, that’s probably what’s happening here.
Conclusion.
And there you have it - the end of our first analytical writing. While ‘Lab01-01.exe’ and ‘Lab01-01.dll’ certainly have a lot more functionality than shown so far, as stated in our source material, we’ll be revisiting these complex files in the near future.
Our aim with this first issue was to provide you with the fundamental concepts that will be necessary for the upcoming issues. As we progress, issues will be more direct, covering more advanced topics and a little less introductory. In the meantime, take care, review the concepts we’ve covered thus far, and perhaps have a go at the next lab sample from our source material.
I’m wldfngrs, and this is Crux of The Matter.
I have to read it one at a time, my brain is lagging a bit
haha
It's a solid analysis, nice