Practical Malware Analysis, Lab 1 - 1.

(I'm doing this within a VMware safe environment, as should you, since these are malicious binaries.)

A) First make sure you have WinZip installed on your system.

B) Go to this website: Lab01-01.exe and Lab01-01.dll. Save the download to your desktop, then right click the saved file, select "open with 7-zip", then type in the password malware. Then once unlocked, you should see a single binary .exe, double click that file, click run, then accept, change the destination folder to your desktop, then click extract. A folder should have appeared on your desktop. In that folder, should be the samples that exist throughout the entire book for each lab in PMA.


































C) Visit www.virustotal.com, click on choose a file, select the location of Lab01-01.exe and Lab01-01.dll. These two:














Scan them both. After you hit the scan button for one of them, select "view last analysis", and you'll be given a new SHA256 for each. Here are the results for both: 

Lab01-01.dll

Lab01-01.exe

Lab Questions

1) Does either file match any existing antivirus signatures? To answer this question, i'm only going to use the Lab01-01.dll as an example, since this image will be taking up too much space.

As you can see in the left column, these are all the antivirus that have listed their results when queried with this signature, in their databases to see if any of their signatures match this one. Then in the second volume from the left, you have the "results" place. Here, when you see a green check mark in line with an anti virus on the left, this is an indication that the "file was not detected", meaning that antivirus companies software has not found or archived a match to this sample. Then in red text above the green check marks, you see a whole bunch of different names that are paired with different AVs. The reason why they have different names, but have matching signatures is because malware developers will incorporate, or add as a variant to their designs, many different pieces of malware to their toolkits. If a malware package only had one type of malicious dll associated with it, then malware analysis would be an easy job. How AV's are capable of keeping track of all these variants, is a discussion worth having all by itself. But this particular dll, has 19 matching signatures found, and 56 AVs that didn't detect a match to your signature. This information is listed at the top under "Detection Ratio".

2) When were these files compiled? A scanned file has a "file detail" section that displays when a file was compiled. 

Lab01-01.exe

Lab01-01.dll

You can also view when an .exe (not a dll) was compiled with the PEview tool. Here is Lab01-01.exe:





















You can see the time stamp represented in Hex as 4D0E2FD3, followed by its readable string value. I'm assuming pFile 00F0 is its location. 


3) Are there any indications that either of these files are packed or obfuscated? A common program used to pack malware is the Ultimate Packer for Executables UPX program, that is identifiable by a program called PEid. Here are both the .exe and the dll files in PEid:
















Under info, it shows they are both developed in Microsoft Visual C++. If a packer like UPX was present, it would be listed under info in place of MSVC. 

(Tip: Packed and obfuscated code will often include at least the functions LoadLibrary and GetProcAddress. These allow a program to access any function in any library on the system, which means that when these functions are used, you can’t tell statically which functions are being linked to by the suspect program.)

(Tip: if an executable is showing a long list of imports, that can tell us that the persons who created the malware have not used a packer to hide evidence. This is found under IMAGE_SECTION_HEADER.txt.)

(Tip: When using PEview to analyze a file, if the Virtual Size is much larger than the Size of Raw Data (data on disk), you know that the section takes up more space in memory than it does on disk.)

4) Do any imports hint at what this malware does? If so, which imports are they? The PE file header stores information about every library that will be loaded and every function that will be used by the program. Importing libraries and calling functions can be done either statically (.lib), dynamically (.dll), or at runtime (.dll). So in order to know what a program does, you need to look at the list of functions they are importing, (Also, the PE file contains information about which functions a file exports, which isn't as helpful, since malware devs can simply change its name so easily). Dynamic linking is the most common, whereas runtime linking is most commonly used by malware, especially when it’s packed or obfuscated. We can use a tool called Dependency Walker, which is a tool the book suggested, to analyze the .dll ONLY. So if you were to scan a .exe with DW, you will only be able to see the.dll functions that are associated with that .exe. Here are the functions that are imported for both the Lab01-01.exe and Lab01-01.dll executables:

Lab01-01.exe

Lab01-01.dll

In both images, the red box represents the functions that are currently imported by each executable, whereas the blue box represents the "possible" list of importable functions. Since the KERNEL32.dll is a .dll with such an incredibly high value, (it's a .dll that controls I/O, memory management, interrupts, etc.. and is a crucial focal point for analysis), lets list what functions contain in each:

(You can find the descriptions of a function at MSDN's website.)

Lab01-01.exe

CloseHandle: Closes an open object handle.
CopyFileA: Copies an existing file to a new file's location.
CreateFileA: Creates or opens a file or I/O device.
CreateFileMappingA: Creates or opens a named or unnamed file mapping object for a specified file.
FindClose: closes the specified search handle. 
FindFirstFileA: searches a directory for a file whose name matches the specified filename.
FindNextFileA: continues a file search from a previous call to the FindFirstFile function.
IsBadReadPtr: Verifies that the calling process has read access to the specified range of memory.
MapViewOfFile: Maps a view of a file mapping into the address space of a calling process.
UnmapViewOfFile: Unmaps a mapped view of a file from the calling process's address space.

CreatFileA, CreateFileMapping, and MapViewOfFile work by creating a file that can be then completely mapped into memory. Once that's done, the program, (this program), can read and write to  a file without any additional function calls. 

Lab01-01.dll

CloseHandle: Closes a handle.
CreateMutexA: Creates or opens a named or unnamed mutex object.
CreateProcessA: Creates a new process and its primary thread.
OpenMutexA: Opens an existing named mutex object.
Sleep: Suspends the execution of the current thread until the time-out interval elapses.

The first thing that pops out is the important CreateProcessA function, which tells us that the program will probably create another process and suggests that when running the program, we should watch for the launch of additional programs. This function is most commonly used by malware to execute their malicious code.
CreateMutexA: mutexes are usually used by malware to control their infection vectors, make sure there is only one version of the malware running, and to keep the malware from exiting.  

5) Are there any other files or host-based indicators that you could look for on infected systems? 
From a static analysis perspective, and with the tools mentioned in chapter 1, we can use the Resource Hacker tool to get some additional information about the .rsrc section of a PE file. When doing a static analysis on a piece of malware, a vital form of data that allows us insight into the functionalities of the program, are the strings that exist inside of them. Commands that exist in shells like the string command, would list you names of functions, on top of all the ASCII based text that it comes across. Strings can offer up many missing pieces to your malware puzzle when trying to figure out where it goes and what it does. (ex: ip addresses, connecting URLs, usernames, dates, functions, file extensions, file names, etc...). Fortunately the Resource hacker tool scans and provides the strings that exist in our malware:
(Update: I was unable to get Resource Hacker to work any any of the three windows machines i have running, so instead, i'm going to be finding strings with the PEstudio tool):

Lab01-01.dll

There is the usual jumbled jargon that exists in a strings output, with a clearly visible and enticing IP address 127.26.152.13, (Could be a C&C it's reaching out to), plus in all caps, SADFHUHF, which is somewhat unusual. (While sadly sounding like a cheater, i checked and noticed online the few out there who have the luxurious IDA Pro at their disposable, were quickly able to identify that "SADFHUHF, is a mutex that the malware designer implements to make sure that its malicious instance is the only one running >:-). 

Lab01-01.exe

As you can see in the red box, one od the dlls is a lying fake who is deceivingly using a num 1 instead of the letter l, in the word kernel. Kernel32.dll is legitimate, whereas Kerne132.dll, is not.

6) What network-based indicators could be used to find this malware on infected machines? 
Well aside from the IP address 127.26.152.13 that we found in the malicious .dll, there is also another indicator of network connectivity. I forgot to mention, when analyzing the malicious .dll in Dependency Walker, it had a KERNEL32.DLL, a MSVCRT.DLL, and a WS2_32.DLL, which is a Windows socket used to handle network connections. A program that accesses this dll is most likely connecting to a network, or performs network related tasks :).















7) What would you guess is the purpose of these files?
Hmm where to begin. For starters, the .exe is probably being used to install and run the malicious .dll, which is disguised as the kerne132.dll. The .exe has functions we already discussed as having the functionalities to make copies of files, and then map them into memory. So this .exe must be trying to infect other files on the drive with this malicious .dll, and maintain its control with its mutex. Since i don't know anything about the IP we discovered, i don't know for sure if its a C&C that is being used as a bot for receiving commands from.