Lab 11

Lab 11-1

Description

Analyze the malware found in Lab11-01.exe.

Questions

1. What does the malware drop to disk?
2. How does the malware achieve persistence?
3. How does the malware steal user credentials?
4. What does the malware do with stolen credentials?
5. How can you use this malware to get user credentials from your test environment?

Solution

From static analysis, we find that the malware imports lots of functions that start with Wlx which indicates this is a GINA interceptor (Windows XP only), we can also find a resource embedded within the sample.

Extracting this resource, we find that it is actually a DLL which exports most of the gina.dll exports and this could be whatever the malware drops on the disk.

1. The malware seems to drop something onto it’s working directory, named msgina.dll which happens to have the same hashes as the resource pointed above.
   
   We can deduce that this malware drops it’s own copy of msgina.dll to the working directory of the sample where it was executed the first time.

2. The malware adds this dropped DLL to the key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL where it’s called each time you boot up the system because it is loaded by winlogon.exe every time the system boots, thus achieving persistence.
   

3. Since now the credentials are passed to the malicious DLL, the malware must find a way to redirect this back to the legitimate msgina.dll, we can see in Dllmain that the malicious DLLs dynamically loads C:\Windows\system32\msgina.dll to its own process memory, which means that it will now act as the original msgina.dll while also intercepting any user credentials.
   
   All of the imported functions by the DLLs simply redirect back to the original msgina.dll except for WlxLoggedOutSAS which calls the real function and then calls a function that seems to log the credentials before returning.

4. The malware grabs the stolen credentials and saves them onto a file called msutil32.sys which has the date and time the user has logged in and if there was an error during the login process, it also checks if the password has changed for any users and logs it as well.r
   

   The file is located under C:\Windows\System32 where the real msgina.dll lies.

5. For the purposes of testing this malware, we’ll be having two user accounts named User2 and User3 with passwords sneakypassword1 and sneakypassword2 respectively.
   

A little side note, we notice that the GUI of the login process changes, normally it shows the blue welcome screen but when the malware replaces msgina.dll to it’s own version, it also changes the login screen as shown below:

---

Lab 11-2

Description

Analyze the malware found in Lab11-02.dll. Assume that a suspicious file named Lab11-02.ini was also found with this malware.

Questions

1. What are the exports for this DLL malware?
2. What happens after you attempt to install this malware using rundll32.exe?
3. Where must Lab11-02.ini reside in order for the malware to install properly?
4. How is this malware installed for persistence?
5. What user-space rootkit technique does this malware employ?
6. What does the hooking code do?
7. Which process(es) does this malware attack and why?
8. What is the significance of the .ini file?
9. How can you dynamically capture this malware’s activity with Wireshark?

Solution

1. We find one export called installer.
   

2. Nothing seems to be happening, the malware seems to be querying registry keys related to Drivers32 and a seemingly suspicious DLL file to AppInit_DLLs called spoolvxx32.dll (perhaps that’s the DLL itself).

3. In DLLMain(), we find that the malware must find Lab11-02.ini within the system directory for proper installation, otherwise the malware will exit prematurely.

   Remember: DLLMain() is always called first whenever the DLL is loaded, even when run by rundll32.exe with a different export function.

   
   

4. In the installer export, we can see that the malware adds itself to the registry for persistence under the name of spoolvxx32.dll in HKLM\Microsoft\Windows NT\CurrentVersion\Windows at key AppInit_DLLs.
   

   We can also see that the malware copies itself in the system directory as spoolvxx32.dll so that it gets loaded each time a process loads user32.dll.
   

5. This malware uses the inline hooking technique, we can see that the malware checks for process names THEBAT.EXE, OUTLOOK.EXE and MSIMN.EXE (which happen to be email clients)
   
   If the process names happens to be one of these three, then it sets up a function where the hook will be installed.
   

   As we can see, the malware seemingly hooks Hooking_Function to wsock32.dll!send, and we can confirm this by looking at ws_32.dll.

   

6. The hooking code seems to be intercepting the send function and modifies it so that the email sent is also sent to whatever’s contained in the contents of the .ini file, which means that this malware intercepts emails sent and sends a copy to the attacker as well.

   

   If the malware finds the substring, then it proceeds to make it’s own email header (with the same content post-hooking) and set the recipient to the attacker’s email and send it off to send().

   

7. The malware attacks THEBAT.EXE, MSIMN.EXE and OUTLOOK.EXE, because these are emails clients and the malware attacks the send function to send a copy of the email to the attacker.

8. The ini file contains the encoded version of the attacker’s email address, which is later decoded throughout the execution of the program (At function $10B3)
   

9. We’ve setup a pop3 and smtp server through inetsim connected to the infected machine and sent an email from victim@microsoft.org to someguy@microsoft.org, we can see that an email gets sent first to billy@malwareanalysisbook.com and then the actual intended email second with the same subject, in the same exact order as analyzed.
   

   

---

Lab 11-3

Description

Analyze the malware found in Lab11-03.exe and Lab11-03.dll.
Make sure that both files are in the same directory during analysis.
Questions

1. What interesting analysis leads can you discover using basic static analysis?
2. What happens when you run this malware?
3. How does Lab11-03.exe persistently install Lab11-03.dll?
4. Which Windows system file does the malware infect?
5. What does Lab11-03.dll do?
6. Where does the malware store the data it collects?

Solution

1. The malware seems to be having references of a service name using the net start command, and also names of DLLs, namely C:\WINDOWS\System32\inet_epar32.dll, an initial guess can be made that this malware will rename Lab11-03.dll to that name because the malware imports CopyFileA(), we can also see imports of LoadLibraryA() and GetProcAddress() which means that the malware can import virtually anything at runtime.
   
   

2. When the malware is run, we notice a command line window saying that the The indexing service is starting. and then the window disappears after a brief second, we also notice that a service called CiSvc (which matches our initial guess in question 1)

   

3. Searching the registry entry for the service, we find that the malware actually is an interactive process with it’s own executable cisvc.exe
   

   So thus far, we’ve reached the conclusion that the malware somehow uses the cisvc service, loading the malware in IDA we can see that the malware may appear as a simple program, that copies Lab11-03.dll to inet_epar32.dll to the system directory and then starts the cisvc service, but what we don’t pay attention to, is the call to sub_401070.
   

   Looking at the flowchart of this function, we can see that it does lots of memory file mapping, and file creation (or opening).
   
   The function takes C:\Windows\System32\cisvc.exe as an argument as shown above.

   The malware attempts to obtain a handle to the file cisvc.exe and then creates a file mapping with its size equal to the file’s size.

   

   At this stage, we can make an assumption that the malware might attempt to modify cisvc.exe in it’s memory freely and then attempt to write it back to disk.

   After creating the file mapping object, the malware then maps cisvc.exe to the file mapping object which is equivalent to loading the file in its memory.

   

   Afterwards, the malware does some modifications to the file itself, perhaps modifying it’s PE header.

   

   Inside the sub_401000 function, we can see the usage of IsBadReadPtr() and some references to the .text section literally.

   

   After which we can see that the malware begins to setup a loop and does some checks based on the PE file, and then uses qmemcpy() to copy from some location within the malware to the file mapped cisvc.exe.

   We can see that the malware initializes ECX with 0x4E == 78 and sets ESI == unk_409030 and then sets EDI to var_28 which is setup in the previous loops.

   From this we can deduce that the malware writes (78*4)+2 bytes which is equal to 314.

   We add 2 other bytes because there’s a movsw instruction which moves 2 other bytes.

Keep in mind

We also notice that the loop conditions above are at 314 bytes.

From that we need to check unk_409030 and see what the malware moves to cisvc.exe.

It seems to be copying around a bunch of random bytes, unless we’re viewing it differently…

We’ll attempt to view it as code, and see if it perhaps makes any difference:

Which means that the malware injects shellcode to cisvc.exe!

At the far end of the code, we can see two interesting strings:

We know that inet_epar32.dll is the malicious DLL bundled with the exe but the second entry seems a bit weird, so its best to check how the DLL plays part in all of this.

We can see that the DLL has this export zzz69806582 which is found in the shellcode but we don’t know how it’s used, so its best to analyze this shellcode somehow..

We’ll have to export the binary and analyze it separately.

I’ve used Imhex because it has binary patterns which can help us identify the shellcode faster, I’ve located it and exported it with 314 bytes (exactly as how it is supposed to be written)


We can use scdbg.exe which is a tool used for shellcode analysis, we’ll be using the arguments -s -1 which will step over unlimited steps over the shellcode and hopefully gives us a better view of the shellcode.

We can see that the malware attempts to load the malicious (newly renamed) DLL and loads up the single export it has (and possibly execute it later throughout the shellcode)

Which concludes: This malware infects cisvc.exe so that it loads up the malicious DLL with it’s export zzz69806582 and runs it which counts as a persistence mechanism each time this service is run.

4. The malware infects the file cisvc.exe which makes it import a malicious export.

5. As for the DLL, the DLLMain function seems to be doing nothing, but the export zzz69806582 seems to be calling CreateThread with a function called StartAddress()
   
   As for the StartAddress() function, we can see that there’s plenty of stuff: The malware creates a mutex called MZ in which it checks if there’s any other instances of it running which exits if any other instances are found.
   

   Then the malware creates a new file called kernel64x.dll, after the file has been opened, the malware sets the file pointer to the end and then calls a function sub_10001380().
   
   Within this function, we can see the function calls by it, in which we see keylogging related functions.
   

   This makes us believe that the malware logs keystrokes in kernel64x.dll and categorizes these keystrokes by the currently selected window (as there are calls to GetForegroundWindow() and GetWindowTextA(), as shown below.
   

6. The malware stores the logged keystrokes in a file called kernel64x.dll in the system directory.
   

Next Lab: Lab 12
Previous Lab: Lab 10