Practical Malware Analysis - Chapter 11 Lab Write-up
Chapter 11. Malware Behavior
Types of malware behaviors:
- Downloaders and Launchers
- Backdoors
- Credential Stealers
- Persistence Mechanisms
- Privilege Escalation
- User-Mode Rootkits
- Keylogging
Lab 11-1
Analyze the malware found in Lab11-01.exe
Question 1
What does the malware drop to disk?
Answer 1
By examining the binary using PEview, we can see that it contains imports to do with reading from its resource sections, writing a file to disk, and also contains an unusual import which is tagged as a binary.
Based on this we can assume it will drop a file to disk. By examining strings of the binary, we can see reference to ‘MSGina.dll’ and a registry key location that leads us to believe this may drop a credential stealer designed for Windows 2000, XP, or Server 2003. This conclusion is drawn as ‘GINA” stands for ‘graphical identification and authentication’ which is a component of these older operating systems. GINA Interception is a known technique for harvesting credentials.
By using Procmon, we can see that this drops msgina32.dll to disk before setting up a registry key to specify the custom GINA DLL be used during logon.
Question 2
How does the malware achieve persistence?
Answer 2
As shown above persistence is achieved by registering msgina32.dll, which is pulled from its resource section, as a custom GINA DLL in the Windows Registry at the below location:
- HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL
By examining the documentation on GINA, we can see that this is loaded into winlogon, and can have credentials passed through it that can be captured.
One of the methods of doing this is to implement the WlxLoggedOutSAS which will be passed user credentials whenever someone tries to logon at the logon screen.
Question 3
How does the malware steal user credentials?
Answer 3
By using CFF Explorer VIII we can see that msgina32.dll exports a number of functions that correlate to known functions that need to be exported by a legitimate GINA DLL as it is prepended with Wlx.
By looking at the strings on this DLL we can see that it contains a couple of interesting strings that look to be formatting related, and reference to msutil32.sys which we haven’t seen used.
Opening this up in IDA, we can use msutil32.sys as a pivot point by looking for it in the code. Upon finding it we can use CTRL + X to find cross references to the function using this string which may give us more context into what it’s used for.
Immediately we can see that this calls _wfopen which indicates there’s a file by the name msutil32.sys which will be opened. Examining the reference to this function gives us the impression that the below formatted string will be written to the file msutil32.sys
- UN %s DM %s PW %s OLD %s
It should be noted that %s will be replaced with the appropriate dynamic strings pushed to the stack. Of interest is that this has come from the function ‘WlxLoggedOutSAS’. Looking at what arguments are passed to this function leads us to an interesting discovery.
Looking at documentation of this function, ‘pNprNotifyInfo’ which is passed to WlxLoggedOutSAS points to a structure that contains Domain, Username, and Password information for a user. This leads us to believe that this malware steals user credentials by using a custom GINA DLL which intercepts user passwords when no user is logged on.
Question 4
What does the malware do with stolen credentials?
Answer 4
Looking back at sub_10001570 it appears that this is getting the date, time, and another value which it is being place inside of msutil32.sys in addition to a new line character.
Based on what we see of this function the final value being written to this file is the contents passed by the calling function: UN %s DM %s PW %s OLD %s.
Placing all of this together we can make the informed decision that the malware will create a file called msutil32.sys which will contain the date, time, Domain, Username, and Password of a particular user every time a call is made to the exported function WlxLoggedOutSAS of msgina32.dll. Because this will be run by winlogon.exe we can expect this to fall within the directory C:\Windows\System32.
Question 5
How can you use this malware to get user credentials from your test environment?
Answer 5
Because GINA DLLs are ignored in Windows Vista and later, this will only work in Windows XP or prior. Once the GINA DLL has been installed the system needs to be restarted. This is to ensure the new GINA DLL will be loaded into Winlogon.
Upon restarting and logging in we can see a new file is created.
At this point we can confirm it has logged some relevant information as expected, and because no password was present it hasn’t logged an entry for ‘PWD’. If we log out and back in we can see a new entry has been added. By changing our password to ‘password’, logging out, and logging in we can see that the new credentials have been logged by this stealthy credential stealer.
At this point we know how the GINA DLL functions and where it stores credentials.
Lab 11-2
Analyze the malware found in Lab11-02.dll. Assume that a suspicious file named Lab11-02.ini was also found with this malware.
Question 1
What are the exports for this DLL malware?
Answer 1
Instead of using the same tools we’ve looked at, we examine another tool called PPEE (puppy) to get this information.
Based on the above we can see that this only has one export ‘installer’.
Question 2
What happens after you attempt to install this malware using rundll32.exe?
Answer 2
Given that this is a DLL which exports the function ‘installer’, we can use rundlle32.exe to run this exported function with the below.
rundll32.exe Lab11-02.dll,installer
By running procmon with a filter looking for only events from rundll32, we can then run this and see 311 events have been generated in our Windows 7 VM.
Naturally there’s a lot of requests that we won’t be interested in. One way to reduce the number of irrelevant entries is to add a filter that only shows operations that contain the words ‘set’ or ‘create’. Although this may seem like we miss out on interesting file reads, the ‘CreateFile’ API call is used both in file or I/O creation, or reading. This gives us coverage of these interesting events. By making this change we’re reduced to 99 entries.
From the above we can see 3 main entries of interest. The first is that it issues a CreateFile API call to the below:
- C:\Windows\System32\Lab11-02.ini
Because we know that the CreateFile can be used for either creating or reading a file, we can look a little bit deeper at the properties of this event. By doing this we see that it is only looking to open the file with read privileges, rather than write to it.
If you compare this to the event for CreateFile on the below, we can see that
- C:\Windows\System32\spoolvxx32.dll
In addition to this the malware attempts to add an entry to add the above DLL into ‘AppInit_DLLs’ within the registry. If we take a look into this and the security implementations added to Windows 7, we can gather that this is used to load the specified DLL into every user mode process on the system; however, because this is designed for Windows XP, there’s no modification to ‘RequireSignedAppInit_DLLs’ which is required to allow unsigned modules from being loaded in this manner.
Question 3
Where must Lab11-02.ini reside in order for the malware to install properly?
Answer 3
Based on the above analysis we can conclude that Lab11-02.ini must reside at C:\Windows\System32\Lab11-02.ini for the malware to install itself. Given this is on a Windows 7 system which introduces code signing requirements (without a registry modification) then this installation won’t be truly successful, even if you are running it as an administrator. From this we know that this was likely created with a target of Windows XP or older in mind.
Question 4
How is this malware installed for persistence?
Answer 4
Based on the analysis in question 2, the malware installs itself as an AppInit_DLL for persistence which then means it will be loaded into any user mode process (anything that loads a user interface e.g. using User32.dll) on a system making it difficult to fully remove if every user process is running the malware. This has publicly been reported as a tactic used (even in 2020) by nation state and cyber criminals. If we open this up in IDA and view the exported installer function we can see evidence that backs up what we’ve seen.
Question 5
What user-space rootkit technique does this malware employ?
Answer 5
To understand this we first need to take a look at this in IDA to get an idea of its functions. Using CTRL + F12 to view the call flow of this DLL is an excellent way to get an idea of its functions.
From this we can see that installer doesn’t seem to perform many more calls than what we’ve already identified. Of interest is that DllMain seems to have a number of extra calls, so we’ll look further into that. In particular the subroutine sub_100014B6 seems to make the most calls and is worth investigating.
If we examine this subroutine we can see that it contains a number of checks which appear to be looking for a specific process name.
Where the DLL is running inside of a process with any of the below names:
- MSIMN.exe
- THEBAT.exe
- OUTLOOK.exe
The DLL will proceed to call the below subroutines.
- sub_100013BD
- sub_100012A3
- sub_10001499
Of interest is that we can see reference to ‘send’ and ‘wsock32.dll’. Examining sub_100012A3 more closely, we can begin to see evidence that this gets a handle on wsock32.dll before GetProcAddress is used to get the send function of this DLL before passing them to sub_10001203.
Based on this it looks like the program is using inline hooking via this DLL as a form of user-space rootkit. The hooking code looks to primarily be installed from within ‘sub_10001203’.
Question 6
What does the hooking code do?
Answer 6
Examining ‘sub_10001203’ there’s a number of operations which occur due to the complexities of adding an inline hook.
Essentially this installation will calculate the correct jump address before modifying memory protections so that the ‘send’ function can be changed. This then creates a trampoline which will preserve the first 5 bytes of the send instruction, prior to overwriting these 5 bytes with the JMP instruction to what is now located in var_4. To understand what’s in var_4 we need to look back at what is being passed to this hook installation, as this is what is performing the hook function.
Based on this we can infer that ‘sub_1000113D’ and ‘dword_10003484’ are being sent as part of the hooking function and should be analysed. A quick look at sub_1000113D reveals similarities with the ‘send’ function. Because this needs to implement the same arguments as the send function it can be defined by setting the function type.
int __stdcall sub_1000113D(SOCKET s, char * buf, int len, int flags)
This makes it a little bit clearer. Looking at it we can see that it seems to be modifying in memory specified recipients by adding an entry involving ‘RCPT TO:’ and an unknown value specified by ‘byte_100034A0’.
To get more context on what this will contain we need to look for the operation which reads bytes into this offset.
Examining the main function which adds elements to this we can see that the data is pulled from Lab11-02.ini before calling the subroutine ‘sub_100010B3’.
Looking at the contents of Lab11-02.ini, we see that it looks to be ‘gibberish’ or more likely that some type of encoding is being used, which leads us to believe that ‘sub_100010B3’ may be a decoding routine.
We will examine this further in question 8.
Question 7
Which process(es) does this malware attack and why?
Answer 7
Based on our analysis in Question 5 and 6, this malware only attacks the below processes.
- MSIMN.exe
- THEBAT.exe
- OUTLOOK.exe
This is because they are specific email clients and this malware is designed to hook a specific API call only for the specified email clients.
Question 8
What is the significance of the .ini file?
Answer 8
Revisiting sub_100010B3 we’re under the impression it performs some decoding. Given this is quite challenging to work through manually in IDA, we move back to OllyDbg to perform some dynamic analysis of this subroutine. We’re able to do this by using the ‘loaddll’ binary.
By jumping to ‘0x100016CA’ which is what calls this suspected decoding routine and creating a breakpoint at the function, and directly after the function, we can then copy ‘Lab11-02.ini’ to C:\Windows\System32 where we know it is attempted to be loaded from. Running the program we hit our breakpoint.
By stepping over this routine ensuring that the second breakpoint has been added, we can now see the below value appear on the stack.
This leads us to believe that the .ini file is encoded and once decoded is used to specify an email which based on our analysis in question 6 will be added to any email sent as a secondary recipient based on the hooked send function.
Question 9
How can you dynamically capture this malware’s activity with Wireshark?
Answer 9
To do this we setup a host-only (networking) adapter in our VM, and then begin capturing packets on this adapter in Wireshark.
After this we run the installation function of the malware with the below.
rundll32.exe Lab11-02.dll,installer
From here we open up Outlook Express in our VM and set an appropriate account up to send emails from. We’re going to need to set this up with the IP address of our host OS.
Tools > Accounts > Mail
From here on our host OS we can setup a fake smtp daemon debugging server to receive emails with the below (substituting the IP as required).
sudo python -m smtpd -n -c DebuggingServer 192.168.0.17:25
From here if we run Wireshark on this adapter and send an email we can see it is received by our server.
If we take a look at Wireshark we can see the modification of recipients has occurred and it is now also sending an email to [email protected].
Lab 11-3
Analyze the malware found in Lab11-03.exe and Lab11-03.dll. Make sure that both files are in the same directory during analysis.
Question 1
What interesting analysis leads can you discover using basic static analysis?
Answer 1
If we run strings over Lab11-03.exe we can see a number of strings which relate to loading a library (DLL), manipulating (starting) a service called ‘cisvc’ (a quick search reveals this is the content index service), and reference to a non-existant DLL ‘inet_epar32.dll’.
In addition this contains references to ‘VirtualAlloc’, ‘HeapAlloc’, and ‘VirtualFree’ which seems to indicate this will manipulate memory in some fashion. It should be noted that memory manipulation using API’s such as ‘VirtualAlloc’ or ‘VirtualAllocEx’ is often used when injecting shellcode into a process.
If we run strings over Lab11-03.dll we can once again see a number of strings of interest. We can see there’s once again an entry for a non-existant DLL, and an entry for ‘GetAyncKeyState’ which is commonly used in keyloggers.
What leads us to believe this may be a keylogger even more is that it has a specific string for ‘
Question 2
What happens when you run this malware?
Answer 2
If we run Procmon to analyse what happens with this malware is run, we can see that it looks to query Lab11-03.dll prior to creating (and then writing) a file to: C:\WINDOWS\sytem32\inet_epar32.dll, this leads us to believe it’s copied Lab11-03.dll to this location. In addition this gets Generic Read/Write access to C:\WINDOWS\sytem32\cisvc.exe, but doesn’t perform any type of file write operations.
Because we suspect this may have keylogging functionality, we begin typing some text in any application. In addition we expand our procmon search to include any process with the name cisvc.exe, given this seems to be accessed so may hold more information. What immediately is shown is that cisvc seems to look at files from our previous lab11-02, in addition to loading the copied ‘inet_epar32.dll’ file, and creating a file at ‘C:\WINDOWS\sytem32\kernel64x.dll’.
By cross examining the file written by this with the legitimate ‘kernel32.dll’, we can see a number of glaring differences that would indicate this isn’t likely a legitimate DLL. Opening this in notepad confirms that it is indeed logging applications as they shift focus, and appears to be logging keystrokes.
Question 3
How does Lab11-03.exe persistently install Lab11-03.dll?
Answer 3
First we take a look at Lab11-03.exe using IDA. Examining the main method it appears as there’s only a couple of custom function calls which leads us to believe the program may be basic.
When we graph the call flow of this application we can see that it’s far more complicated than we initially thought with many functions being nested.
Drilling into this we first look at the cross references to ‘sub_401070’ which is called prior to starting ‘cisvc’.
Based on the windows API calls we can assume that a file is being mapped into memory (C:\WINDOWS\sytem32\cisvc.exe) with functions occurring on the file prior to UnmapViewOfFile is called which writes the file changes ‘lazily’ to disk.
By examining ‘sub_401070’ more in depth we can see that a number of checks occur based on getting a handle on the file in question, memory, and the binary itself; however if these checks are passed an operation occurs in the bottom right of this flow at ‘loc_40127C’ which is of interest.
This function is of interest because it uses ‘lpBaseAddress’ to get the base address of the mapped file C:\WINDOWS\sytem32\cisvc.exe and has clear modifications occurring prior to ‘UnmapViewOfFile’ being called.
The function uses an unknown variable of ‘var_28’ as an offset from this base before the counter register (ECX) is set to 4Eh (78 in Hex). As the action occurring is ‘MOVSD’ (Move String, Double Word) using this counter register, we know that this is moving 78 DWORDs starting at ‘byte_409030’. At this point it’s important to note that a DWORD is a 32-bit (4-byte) unsigned integer. Due to this the total number of bytes that will be copied is 78 * 4 = 312 bytes. Examining ‘byte_409030’ we see some entries that don’t make a lot of sense.
This is shellcode that will be copied directly as assembly to the binary in question and is stored in Hex. Using ‘c’ we can convert this directly to code to see what it is performing. First we look through to see if there’s any obvious strings. At ‘00409139’ and ‘0040915D’ we find some strings of interest if we convert them to ASCII using ‘A’.
Based on this and the activity we saw running the program we begin to infer that the shellcode will likely dynamically load ‘C:\WINDOWS\System32\inet_epar32.dll’ and run the export ‘zzz69806582’. Looking at the exports of ‘Lab11-03.dll’ which we know is copied to this location, we can see this is a valid export.
Given ‘zzz69806582’ is an obvious unique string we can use this as a pivot point to open the executable in a program such as ‘HxD’ and find the appropriate shellcode for exporting. We also do this by looking for the expected Hex.
After saving the shellcode to a new file (Lab11-3Shellcode.dat) by copying it to a new file using HxD, we can now use a shellcode debugging tool (scdbg) to confirm what actions were taken by the shellcode we’ve found.
scdbg -findsc -f Lab11-3Shellcode.dat
Although an error occurs as we wind up looking into invalid memory, we’re successfully able to step over enough of the shellcode to reveal that it is using ‘LoadLibraryExA’ to load in C:\WINDOWS\System32\inet_epar32.dll, before using ‘GetProcAddress’ to get the exported function ‘zzz69806582’.
Based on this we conclude that Lab11-03.exe will persistently install Lab11-03.dll by infecting the indexing service binary C:\WINDOWS\sytem32\cisvc.exe to run shellcode that uses ‘LoadLibraryExA’ and ‘GetProcAddress’ to load ‘C:\WINDOWS\System32\inet_epar32.dll’ and run the export ‘zzz69806582’ from this DLL.
Question 4
Which Windows system file does the malware infect?
Answer 4
Based on the above analysis we can conclude that this malware infects the indexing service binary C:\WINDOWS\sytem32\cisvc.exe
Question 5
What does Lab11-03.dll do?
Answer 5
Examining Lab11-03.dll in IDA, we start with the export we identified from our previous shellcode analysis (zzz69806582)/
This doesn’t perform much except creating a thread to run actions specified in ‘StartAddress’, so we examine this subroutine for more information. By graphing the user defined cross references to this subroutine we can get an idea of what this may be trying to accomplish.
Based on the Windows API calls we begin to get the feeling that this acts as a keylogger that will create a file if it doesn’t exist, open a mutex to ensure only one instance of it is running, calls ‘GetAsyncKeyState’ to log keystrokes, and writes these to a file before sleeping for a period of time and repeating (this would simulate a poll that occurs on a schedule). To confirm this we look closer at what is occurring at ‘0x10001410’.
Based on this we can determine that the malware creates a Mutex ‘MZ’ and file at ‘C:\WINDOWS\sytem32\kernel64x.dll’. Drilling into the subroutine at ‘sub_10001380’,
Here we can see evidence of information being written to this file before a timeout of ‘0A’ (10) milliseconds occur and it repeats. We can also see evidence of another subroutine being called at ‘sub_10001030’ and if we look into this we can see lots of evidence it is being used as a keylogger. Based on GetAsyncKeyState being used, we can look into Virtual-Key Codes to get an idea of what this is checking for before logging the character “<SHIFT>”.
From this context we can infer that Lab11-03.dll is a keylogger which polls frequently and writes keys pushed to C:\WINDOWS\sytem32\kernel64x.dll.
Question 6
Where does the malware store the data it collects?
Answer 6
Based on the above analysis we can confirm that this malware stores keystrokes and window information it collects at ‘C:\WINDOWS\sytem32\kernel64x.dll’.
This concludes chapter 11, proceed to the next chapter.
