Malware Analysis Examples

Let us show three examples of how drltrace can help analysts to reveal important information and significantly reduce amount of work required for malware analysis.

Gootkit Dropper

This example is based on our report available here.

Discovered in the wild in the summer of 2014, GootKit is considered to be one of the more advanced banking Trojans active nowadays. We have undertaken analysis of the most current version of the GootKit dropper. Relying on Drltrace we discovered new advanced anti-research capabilities which is used to bypass detection in virtual machines or sandboxes and improves Gootkit capabilities to ultimately infect more endpoints. Let’s present how Drltrace helped us in detection of these capabilities.

Starting the process:

drltrace.exe -logdir . -print_ret_addr -- 477c305741164815485218f165256126bcd3fa6ce305f187aceb08cab89d8f01.exe

After several seconds, we see that the main process breaks up into three child processes. Drltrace will follow child processes and provide logs for all of them:

While files attrib.exe and cmd.exe looks like a standard windows processes, files drltrace.mstsc.exe.04076.0000.log,drltrace.477c305741164815485218f165256126bcd3fa6ce305f187aceb08cab89d8f01.003376.000.log look suspicious. Let’s look in the log file of the main process.

At the beginning we see Gootkit allocates memory with activated PAGE_EXECUTE permission. So, it looks like the sample is preparing place to unpack and execute some code.

Next, the sample gets command line and compares itself name with mstsc.exe (standard Windows RDP client).

Few hundred API-calls after, we see CreateProcess API call where legitimate mstsc.exe is called with an argument that points to the path of our Gootkit.

Since mstsc.exe was started suspended, we can expect process hollowing technique further. The next figure proves our guess. The sample takes context of a remote thread, creates a new section, maps the section in memory, writes the code in the remote process and resume the thread.

The rest of the main log file is not interesting. Let’s switch to the log of mstsc.exe.

At the beginning, we can see our malware joking at us.

After a few hundred lines, infected mstsc.exe starts a huge loop where it enumerates all the processes running in the memory looking for specific names for anti-research purposes (see our technical report for more details).

After this long loop, the sample removes itself by dropping bat file 36197379.bat and executing it (our previous intuition about cmd.exe and attrib.exe was right).

It looks like something is wrong with environment and our “friend” doesn’t want to work here. Let’s look on output of strings filtering script supplied with drltrace.

These strings are used only once in the log file, so, probably the sample compares them with something that was stored before in the memory. The rest of the file are not interesting for us. So, let’s try to put our executable in one of these folders and execute it again.

In the newly produced log files, the sample again checks for %SystemRoot%\Tasks\ but since the process started from the right place, we can see more behavior. Now, we can see numerous anti-research checks in the log of drltrace:

1. VideoBiosVersion at HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\ looking for substring “VirtualBox” using RegOpenKey/RegQueryValueExW.
2. SystemBiosVersion at HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\ looking for substrings AMI, BOCHS, VBOX, QEMU, SMCI, INTEL–6040000 and FTNT-1 using RegOpenKey/RegQueryValueExW.
3. DigitalProductId at HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion looking for 55274-640-2673064-23950 (JoeBox) and 76487-644-3177037-23510 (CWSandbox) product ID keys using RegOpenKey/RegQueryValueExW.
4. Current Windows user name is compared with "CurrentUser" and "Sandbox" using GetUserNameA.
5. Workstation name is compared with “SANDBOX” and “7SILVIA” using GetComputerNameA (we may guess that Gootkit’s authors owns information about specific configuration details of a specific sandbox which they try to bypass).
6. To avoid execution on servers, the sample looks for “Xeon” substring at ProcessorNameString.

If anti-research checks successfully passed, Gootkit connects to CnC server. We can clearly see API calls used for these purposes.

Since, the CnC is not available, we don’t see downloading of an actual payload of our sample. The rest of the log file doesn’t have interesting behavior.

EmbusteBot

This example is based on this report.

The Brazilian cybercriminal scene is known for its affinity for Delphi-based malcode, and the sample we analyzed is no exception to the popular use of Delphi in Brazilian malware. The malware’s authors in this case employ a scheme where a benign executable is used to load a malicious DLL on the target endpoint to activate the payload. While in general, the sample doesn’t intensively use anti-research tricks, there is some encryption of sensitive strings in several important parts of the DLL, as well as time-based anti-research checks the malware performs.

The overall purpose of EmbusteBot is to:

• Find out which browser window runs on the victim’s machine;
• Match the window title with a list of banks it targets;
• Take over the victim’s endpoint, use fake overlays in some cases;
• Launch fraudulent transactions from the victim’s account.

The malware’s execution on target endpoints begins with dynamic loading of a malicious DLL to find out what browser the victim uses, and what’s on the active tab.

Let’s start EmbusteBot under drltrace:

drltrace.exe -logdir . -print_ret_addr – vdeis.exe

The sample will stop very early and in the log file we can clearly see that it requires vdeis2.dll to be in the C:\Users\Public\Media\.

If we place the DLL in the right directory, the malware initiates a search queue where it scans for specific window class names that represent targeted web browsing applications, such as Internet Explorer:

EmbusteBot checks for window classes of the top 3 most popular web-browsers, Internet Explorer (IEFrame in figure above), Google Chrome, Mozilla Firefox, checking if any appear on the victim’s screen’s foreground. The overall flow of events here is as follows:

1. Get handle of a foreground window.
2. Get class name of a foreground window.
3. Compare class name with decrypted strings:
   • IEFRAME (Internet Explorer),
   • CHROME_WIDGETWIN_1 (Google Chrome),
   • MOZILLAWINDOWCLASS (Mozilla Firefox),
   • SUNAWTFRAME (Java),
   • APPLICATIONFRAMEWINDOW (Window 10 Applications),
   • BUTTONCLASS, MAKROBROWSER (generic bundled Internet browsers).
4. If the class name contains one of the substrings, jump to step 5. If not, return to step 1 after a short pause.
5. Get text title of a foreground window.
6. Compare the title with an elaborate list of decrypted strings of 50 Brazilian bank names and banking web application names in the uppercase (CharUpperBuffW API call is used, see figure below).

7. If the window title contains one of the above substrings and the activation file 171703.reg (depends on the current system date) presented in C:\Users\Public\Media (see figure below), the malware commences its malicious activity. If note, it returns to step 1 after a short pause.

Upon confirming that the victim is browsing their bank’s website, and an active window was successfully matched with a target bank, EmbusteBot collects general information about the infected endpoint’s OS (using API calls presented in figure below) and hardware environment in the following format:

MACHINE_NAME;Windows X Service Pack X(version X.X, BUILD XXXX XX-bit Edition)Disabled;XX-XX-XX-XX;Disabled;0.0.4
XX-XX-XX-XX is the MAC-address of a victim’s machine.

The fun fact about UuidCreateSequential is that the API call was introduced by Microsoft to allow creation of UUIDs using the MAC address of a machine's Ethernet card. Thus, malware uses this API call to get a MAC address. It can be also used to detect VM (for example, VMware uses the Organizationally Unique Identifier (OUI) 00:50:56). The second fun fact, if we want to fool our malware and change MAC via the standard Windows interface it wouldn’t work. For some reason (probably it uses some low-level interface to get MAC), UuidCreateSequential returns a real MAC-address of Ethernet card. Thus, we should change it using the interface provided by our VM.

Then, the sample installs a hook procedure that monitors low-level keyboard events along with the screen capturing.

NotPetya

Inspired by WannaCry ransomware campaign, NotPetya was first discovered in June 2017 and attracted huge media attention. The authors employed two schemes of propagation: the same EternalBlue/EternalRomance exploits used in WannaCry along with embedded Mimikatz for stealing user and admin credentials.

Let’s try to get some technical details of this sample using drltrace:

drltrace.exe -logdir . -print_ret_addr – rundll32.exe perfc.dll,#1

The NotPetya main module is distributed as a DLL, we can simply execute it using rundll32.exe and apply an external script to select API calls that belongs to our DLL by specifying unique module id, listed in the module table at the end of the log file.

python filter_dlls.py drltrace.exe.rundll32.exe.00336.0000.log 45

The first part of the log, shows that NotPetya tries to adjust high level privileges (via AdjustTokenPrivileges API call) in the OS. The sample needs Shutdown, Debug and TCB privileges (to be able to use low level OS features to re-write MBR).

The next part of the drltrace log file allows us to easily find a famous kill-switch for NotPetya. The sample will stop if PathFileExistsW(C:\Windows\perfc.dll) will return true.

The actual malicious behavior starts few hundred lines after kill-switch. The sample opens PhysicalDrive0 and overwrite MBR.

Moreover, NotPetya also encrypts all files stored in all sub directories of all available drives in the OS starting from C:\*. As drltrace shows in Figure below, the sample generates a key using standard Windows CryptoAPI and enumerates files via FindFirstFile/FindNextFile.

Then if a file extension matches a certain pattern, the encryption takes place. The sample opens a file, maps it in the memory, encrypts it and saves it back on the disk. We can easily find which file extensions our sample wants to encrypt.