Practical Malware Analysis - Chapter 12 Lab Write-up
Chapter 12. Covert Malware Launching
Lab 12-1
Analyze the malware found in the file Lab12-01.exe and Lab12-01.dll. Make sure that these files are in the same directory when performing the analysis.
Question 1
What happens when you run the malware executable?
Answer 1
Before running the malware we can take a quick look at the imports it has to give us some more context.
From the imports of Lab12-01.exe we can begin to assume it may perform some type of process injection due to the API calls involving multiple of the below which are commonly used for process injection.
- CreateRemoteThread
- WriteProcessMemory
- VirtualAllocEx
- LoadLibraryA
- VirtualFree
Looking at the import from USER32.dll of Lab12-01.dll we can begin do get some context on what this may perform.
Based on this we are under the assumption that this may inject into a process and cause a message box to pop-up. By running the executable we can confirm our findings with a pop-up occurring.
Question 2
What process is being injected?
Answer 2
To get clues on what process is being injected into without reverse engineering the binary, we take a look at the strings of Lab12-01.exe.
Based on the strings and the order they occur, we can begin to infer that explorer.exe may be what is being injected into. Further analysis of the binary in IDA reveals that the main method contains a number of checks and operations, before calling sub_401000 with a relevant processID.
This is part of a looped function which looks to be checking through all processes based on their processID, and is comparing the output of ‘GetModuleBaseNameA’ (translating processID to process name from dword_40870C), to the string ‘explorer.exe’.
If this comparison matches, the process function will return ‘1’ (true), open a handle to the process, and then as the next loop occurs begin to allocate memory that will be used by LoadLibrary to load the DLL specified earlier in this method into memory.
From this we can tell that an existing instance of explorer.exe is being injected into. We can confirm this by simply using process explorer to look for any process that has loaded Lab12-01.dll.
Question 3
How can you make the malware stop the pop-ups?
Answer 3
The easiest way to make the malware stop the pop-ups is to use PowerShell to stop explorer.exe. By using this explorer.exe will stop, killing the thread which has been injected into. It will then startup again automatically and only seem like Windows has briefly refreshed.
Stop-Process -ProcessName explorer
If you’d prefer to not stop explorer, process explorer can also be used to kill individual threads, so by killing the malicious thread you don’t need to kill the entire process.
Question 4
How does this malware operate?
Answer 4
Given we now understand how the injection works from analysis in previous questions, we need to now take a look at ‘sub_10001030’ of Lab12-01.dll which is the code that will be running as a thread within the explorer.exe process.
Analysing this is pretty straight forward. In this instance we can see that a looping function occurs. Within this var_18 is used as a variable that will be incremented by 1 every time it loops, and prior to executing there is a 60,000 millisecond timeout.
Based on this we can see that every 60 seconds a new thread will be created to display a message box from within the explorer.exe process. This will contain the message “Practical Malware Analysis %d” where %d is replaced by the variable var_18, and so this is used to tell you how many minutes have passed since this was injected into explorer.exe.
Lab 12-2
Analyze the malware found in the file Lab12-02.exe.
Question 1
What is the purpose of this program?
Answer 1
Taking a look at the imports of this program leads us to believe it is performing memory manipulation on a ran process or some form of injection. Of interest is that this is creating a process, manipulating threads, looking for a file within its own resources, and getting a handle on a file based on the Windows APIs imported.
From this we can begin to assume that this may be used to run code embedded within one of its resources. Examining the resources of this executable reveals an unusual resource of interest called ‘name_0’ using PE-bear. If we examine using Resource Hacker, we can see this is instead called ‘LOCALIZATION’.
By saving this resource, taking the hash of both the resource, and the sample, and checking them against a public malware repository such as VirusTotal, we can see that this is being flagged as a KeyLogger, and more so that this is the same sample we looked at in Lab 3-3.
Given this is the same as we analysed in Lab 3-3, we know that this uses some form of process hollowing / process replacement, and this backs up what we’ve inferred in these API calls. Based on this we can make the determination the purpose of this program is likely to launch another process, which will be hollowed into / replaced with malicious code stored within its resource section called ‘LOCALIZATION’.
Question 2
How does the launcher program hide execution?
Answer 2
Although we know this hides execution by hollowing into svchost, we can look at this program in IDA to get more context on how this occurs. Based on the main method we can see a few API and subroutine calls which we can elaborate on. Simplified descriptions of each function is shown below.
The application subroutines can be viewed and expanded on to understand how they work.
- sub_40149D
This routine is fairly straight forward, it’s calling ‘GetSystemDirectoryA’ and using the passed in buffer containing the string svchost.exe to concatenate them to make C:\Windows\System32\svchost.exe in this case.
- sub_40132C
This routine is responsible for extracting our malicious resource.
It also goes a step further to copy the elements of it into a buffer in memory for use and calls another routine at ‘sub_401000’. This is a decoding routine that’s elaborated further in Question 4.
- sub_4010EA
This routine performs a lot of the heavy lifting when it comes to replacing the code within svchost.exe to our malicious code. Shown below is where this routine creates the svchost process with creation flags of ‘4’ which indicate it’ll be created in a suspended state.
Looking further we can see the API calls that show us the necessary process headers are being written into this process.
Shortly after we see a loop occurring to write the malicious resource code into the memory of this thread before using ‘SetThreadContext’ to get the start of the thread, and resuming it, starting the malicious code in the context of this process.
Question 3
Where is the malicious payload stored?
Answer 3
Based on our analysis above and in question 1, we know this is stored in the program’s resource section under the resource ‘LOCALIZATION’ which is stored as ‘UNICODE’.
Question 4
How is the malicious payload protected?
Answer 4
As discovered in question 2, there’s a decoding routine which resides at ‘sub_401000’. If we examine this we can see evidence that this uses the 3rd passed argument as a key for XOR decoding.
By stepping back to what is calling this we can see that 41h (or 0x41 in hex) is being pushed to the stack first, so will be the third argument popped off the stack, and in this case indicates our key for decoding.
Question 5
How are strings protected?
Answer 5
As discovered in the question above, strings within the program’s resource section ‘LOCALIZATION’ is XOR encoded using the hex key ‘0x41’.
By using a hex editor capable of XOR operations such as 010 Editor, or using a tool such as CyberChef, you can easily make the necessary modifications to this resource to reveal a familiar ‘MZ’ executable file format indicating your decoding was successful.
By hashing this file and checking it against a public malware repository such as VirusTotal we see it has almost double the rate of detections now that it is decoded.
Lab 12-3
Analyze the malware extracted during the analysis of Lab 12-2, or use the file Lab12-03.exe.
Question 1
What is the purpose of this malicious payload?
Answer 1
Given we already have a good idea that this functions as a keylogger, we can still use some other tools to help back this theory up. For example by looking at this binary using pestudio we can immediately see this picks up on some imports and strings that help lead us to believe it acts as a keylogger.
Exactly how it does this can be determined by using IDA to examine how the malicious payload injects itself into applications.
Question 2
How does the malicious payload inject itself?
Answer 2
By examining the main method of this binary we can see that it installs an application-defined hook procedure using .
In this instance the idHook argument of ‘0D’ in hex translates to 13, and this defines the type of hook to be installed. Referring to Microsoft documentation we find that this relates to a ‘WH_KEYBOARD_LL’ hook.
By examining ‘fn’ which is a pointer to a defined hook procedure, we can see that this is called with a ‘dwThreadId’ of 0 indicating that the hook procedure is associated with all existing threads running in the same desktop as the calling thread, which in this case allows all of this user’s applications to be hooked. We can also see it calls a subroutine at ‘sub_4010C7’ which defines the actions to be taken by this hook. Initially the program will check if a keylog file is present, and if it isn’t it’ll look to first create it.
Of note is that the graph view of this is quite long, and almost looks like a keyboard. Examining this is hooked function is fairly straight forward, first of all we can see that this attempts to pass in and log the window title of whatever application is in focus.
After this further checks and calculations occur to determine what special key is being pushed, and in the event one is a specific value is outputted to the keylog file.
Based on this we know the malicious payload injects itself by using an application-defined hook procedure using SetWindowsHookExA.
Question 3
What filesystem residue does this program create?
Answer 3
As shown in the above analysis this program creates a keylog file called ‘practicalmalwareanalysis.log’ to store stolen key presses.
Lab 12-4
Analyze the malware found in the file Lab12-04.exe.
Question 1
What does the code at 0x401000 accomplish?
Answer 1
Looking at the code at 0x401000 we can see pointers that reference to a number of unknown values indicated by dword, byte, and word values.
By examining these values and converting them to an ascii string using the letter ‘a’, we can better see what’s going on here.
In the above the string ‘winlogon.exe’ is being assigned to the variable at var_14, and “
Naturally if the values that were previously assigned didn’t change this will always fail, so we need to take a closer look at ‘dword_40312C’ and ‘dword_403128’ to see what they’re doing. If we examine them we can see that they don’t have any values assigned. This leads us to believe that they’re being dynamically resolved from somewhere else, likely through the use of a Windows API call to ‘LoadLibraryA’ to load a previously unspecified DLL. To get an idea of what is resolving this, we use ‘x’ to get cross references to ‘dword_40312C’, and look for any references where a value is being moved into this global variable.
If we examine the main function we can see that 3 pointers are being assigned to 3 different global variables, all of which call a different export of the dynamically loaded dll ‘psapi.dll’.
Now that we have some idea of what is occurring we can rename these variables and move back to our code at 0x401000.
At this stage it’s clear that the code at 0x401000 is designed to open a process, search the process modules, for each module get the associated base name (remembering that an executable has its own name as one of its modules), and then where the name is equivalent to ‘winlogon.exe’ return ‘true’ (1).
Question 2
Which process has code injected?
Answer 2
Based on our above analysis we assume that this will be injecting into winlogon.exe, but at this stage we haven’t seen any evidence of injection. If we examine cross references to 0x401000 we can see it is run in the main function of this executable which is confined to a loop. This loop looks to be enumerating processes as it calls our previously renamed ‘EnumProcs’.
From the above we can see that when our subroutine at 0x401000 successfully finds winlogon.exe, it will call another at ‘sub_401174’. Looking into this we see a familiar call that confirms that winlogon.exe is what is being injected into.
Of interest is that there’s no calls to ‘WriteProcessMemory’ or ‘VirtualAllocEx’, so we should examine exactly what this is trying to do.
Question 3
What DLL is loaded using LoadLibraryA?
Answer 3
By examining ‘sub_401174’ more in depth, we can easily piece together what DLL is loaded using LoadLibraryA, and what this code is attempting to accomplish.
- Grant self Debug Privileges
- Load system file checker DLL (sfc_os.dll)
- Locate module at ordinal 2
- Open winlogon.exe process with full rights
- Create a remote thread in winlogon.exe with code from ordinal 2 of system file checker DLL
The question still remains on what code is contained within ordinal 2 of the system file checker DLL. A quick search reveals this is an export known as ‘SfcTerminateWatcherThread’ that is used to disable windows file protection allowing modification of files which are otherwise protected by the system file checker.
Question 4
What is the fourth argument passed to the CreateRemoteThread call?
Answer 4
From the above analysis we can determine that the fourth argument passed to the CreateRemoteThread call is the exported module with ordinal number ‘2’ from ‘sfc_os.dll’ which is ‘SfcTerminateWatcherThread’ exposed by the System File Checker DLL used for Windows File Protection on older operating systems such as Windows 2000 and XP. This allows modification of otherwise protected windows files.
Question 5
What malware is dropped by the main executable?
Answer 5
Moving back to our main function we find 4 actions are taken with the access gained from the above injection.
These actions are as follows:
- Locate the windows update manager binary (wupdmgr.exe)
- Assign this to a local variable called ExistingFileName
- Assign a local variable called NewFileName to the
\winup.exe - Move ExistingFileName to NewFileName and call the subroutine ‘sub_4011FC’.
From here we can examine ‘sub_4011FC’ to get an idea of how malware is dropped by the main executable.
This performs 4 distinct actions as follows:
- Locate the location of the original windows update manager binary (wupdmgr.exe)
- Get a handle on the running and search its ‘BIN’ resources for ‘#101’
- Load the specified resource from this resource section
- Write this resource to the original windows update manager binary location
After this the binary calls winexec on this binary with an argument of ‘0’ (SW_HIDE) to ensure it is hidden.
Question 6
What is the purpose of this and the dropped malware?
Answer 6
To understand the dropped malware, we can examine this resource in Resource Hacker, and like in previous analysis conducted, we can save it to a file for opening in IDA.
The main purpose of this is as follows:
- Locate the legitimate backed up windows update binary and run
- Locate a file location at C:\Windows\system32\wupdmgrd (notice the trailing ‘d’)
- Download ‘http://www.practicalmalwareanalysis.com/updater.exe’ to the above file location and execute
Based on all of this we can conclude that the overall purpose of this malware is to disable Windows File Protection, trojanize the legitimate wupdmgr.exe with a malicious executable which is designed to run the legitimate wupdmgr.exe executable. This acts as a dropper for another unknown executable which is downloaded and run from http://www.practicalmalwareanalysis.com/updater.exe.
This concludes chapter 12, proceed to the next chapter.
