20220817123000 - BLG - My First Malware Sample Analysis

Topics Covered

1. Introduction
2. Analyzing the sample
3. Extraction of the Main and Cryptor Stub
4. Analyzing the Cryptor Stub
5. Analyzing the Main Stub
6. Conclusion

Introduction

This is the first ever malware that I have taken a look. This sample was chosen because keylogger is something of interest to me. Keyloggers are one of the simplest forms of malware. They typically capture keystrokes, mouse clicks, screenshots and browser histories. It allows an attacker to log passwords, keystrokes, documents, chats, photos and browsing history. Now, Keylogger can be used in the forensics and intelligence communities, to aid in investigations. However, it is also commonly used by criminals to steal credit card numbers, by corporate spies for industrial espionage, or by government agents for surveillance.

This brief reverse engineering effort aims to understand how this sample of the HawkEye Keylogger works and how it is able to steal data from its victim. This analysis was conducted in stages:

1. Analyzing the downloaded sample
2. Extraction of the stubs
3. Understanding what information are stolen
4. Understanding how the logs are being sent back to the operator

Note that this post will not cover very in-depth details of the implementations of how information are stolen but you can follow along the extraction steps to learn more about them!

I have chosen this particular keylogger to analyze as it is pretty straight forward to do so since it has little to no obfuscation, no anti-VM, and no anti-debug going on here.

Analyzing the Sample

To begin, obtain the sample from vx-underground with the hash value of 019A689DCC5128D85718BD043197B311. We can determine that this program is written in C#.

Determining the type of executable

Interestingly, the original filename of the sample is “payment slip.exe”. This suggests that this might have been used in a phishing campaign. Further inspection in the file property would show some red flags. For example, the supposed “payment slip” has the product name of Windows Internet Explorer and the Legal Trademarks was misspelled as “Corporation.” without the letter ‘n’.

File properties of the sample

Opening the file in dnSpy, we see that function names were stripped off and there were some obfuscation going on here. The base64 strings present in those variables contains non-printable characters as seen in the next figure.

First function to be run after application starts

After reversing, we will see that :

• During the window setup, it was purposefully hidden
• The function njZ5r2Fw does AES Decryption based on the input ( decoded base64 values ) with the hard-coded key “hlNCwqLIdBYdaloFZajsnThCVnhYFN”

# The four decrypted strings that we see in the previous figure  

JavaUpdater.exe  
C:\Users\Ebecco\AppData\Local\Temp\  
Software\Microsoft\Windows NT\CurrentVersion\Windows  
Load

• The sample will copy this malware into C:\Users\Ebecco\AppData\Local\Temp\JavaUpdater.exe
• The function bVNHfv96 would set the registry key of “load” with the value “C:\Users\Ebecco\AppData\Local\Temp\JavaUpdater.exe” for persistence.

Registry key being added

• The juiciest part is in the function z9xuEPEt which comes right before setting the registry. This function is responsible for extracting the main and cryptor stub and running them.

Extraction of the Main and Cryptor Stub

Reading the decompiled code, we see that resources (“miXq.resources” and “hzmvffT.resources”), in the form of bitmap, were being extracted and later ran in another thread in TxtJzxfvU function.

Extractor functions

To figure out how to extract, have to look at what Y8NhCEeC function does because its values are being placed into the created array in z9xuEPEt which is being used to start a new thread.

Function Y8NhCEeC return array of bytes for new thread

We can set a break point right before the return statement to check and we can indeed see the PE header present in the memory window!

Presence of the PE file bytes

With that, we want to write those bytes into a new file each time the bytes are returned referencing the resource’s name. To extract the those executables, it is a simple matter of writing the file write function.

Modified function to get the extracted bytes labelled with the resource’s name

Analyzing the Cryptor Stub

After running, there are two extractions here. Opening on dnSpy, we see that there is the stub and Binary.Lib files. If you recall, there was a reference to a function from the Binary.Lib ’s Help.Lib.Run_it function.

Referencing the method in the Cryptor stub

This Run_it.Run function is invoked with vals which contains two parameters :

1. main stub executable data
2. C:\Windows\system32\svchost.exe

Interesting, according to Avast :

The Service Host (svchost.exe) is a shared-service process that Windows uses to load DLL files. As its name suggests, the Service Host helps host the different files and processes that Windows needs to run efficiently.

There are quite a number of other functions that involves things like changing of more registry values, but at this point of execution, we have not reached that stage yet which I believe would be called again in the main stub later on.

Run_it.Run

This function is worth looking into since this is what causes the execution of a new process and I have always been interested to find out some of the ideas that are available to such operations.

There is a fallback in case the input executable byte array failed in the Run_it.NetRunfunction. What Run_it.NetRun does is to create a thread running the NetRun function accepting the assembly ( input executable byte array ).

Run_it.NetRun accepting assembly data bytes

If the NetRun function fails, then it would manually do process hollowing, selecting “C:\Windows\System32\svchost.exe as the victim process” and inject the executable bytes of the malware into it. What we can see in the following snippet shows a typical process hollowing sequence:

1. Victim process is created with suspended state via CreateProcessW and value 4 to make the process memory editable.
2. Thread CONTEXT is obtained via GetThreadContext .
3. Based on the context, retrieve the image base header.
4. Execute NtUnmapViewOfSection is used to unmap the view of a section from the virtual address space of a subject process.
5. Allocate a (Read, Write, eXecutable) heap memory with size of the image with VirtualAllocEx.
6. Write the data bytes into that memory with WriteProcessMemory.
7. Correct the Thread Context via SetThreadContext.
8. Resume the thread for running via ResumeThread.

Fallback when Run_it.NetRun function fails to load the executable data bytes.

Here are two places that helped me understand the how and what of process hollowing.

1. m0n0ph1 GitHub on Process Hollowing showing example code that highly resembles what was seen.
2. andreafortuna with high level overview on process hollowing.

Analyzing the Main Stub

Upon successful running of Run_it.Run function. It would start the main stub which is involved in a lot of the malicious executions.

TL;DR : This stub contains code that would connect back to the operator, sending the operator the stolen credential data and keylogger logs. It also contains tons of configuration data that are set based on the needs or goal of the operator.

The following shows available configuration flags that would be used to determine the behavior of the malware.

Some of the many configuration flags

Seeing that there are base64 values, we can either decrypt them in dotnetfiddle.net or get the values from dnSpy during dynamic analysis as well as shown in the following figure.

The Decrypted Credentials of the operator.

For the rest of this section, I will list the flow of events of the more important events really briefly from Form1_Load . If there are places that interests you, feel free to explore !

WARNING : This section is lengthy

1. Check if the current application name is C:\Users\<user>\AppData\Roaming\Windows Update.exe.
2. If the current application is not “Windows Update.exe”, then it will check if the melt configuration flag is set as Disablemelt. For this sample, it is set to melt.
3. If it is set to melt, then check if the application’s executable path is C:\Users\<user>\Appdata\Roaming\Windows Update.exe. If not the same, delete the C:\Users\<user>\AppData\Local\Temp\SysInfo.txt string if it exists and write the application’s executable path into a new created SysInfo.txt file in the same directory. After doing this, copy the content of the current application (malware) to C:\Users\<user>AppData\Local\Temp\SysInfo.txt. Finally, start a new process of the new meltLocation and end the application.
4. If it is set to Disablemelt, it will simply delete the SysInfo.txt from the temp folder.
5. Delete and create a new file in C:\Users\<user>\AppData\Roaming\pid.txt if it exists and write the PID of the process.
6. Delete and create a new file in C:\Users\<user>\AppData\Roaming\pidloc.txt if it exists and write the path of the executable in the file.
7. Decrypt the values of emailstring, passstring, smtpstring, ftphost, ftpuser, ftppass, phplink as seen in the previous figure.
8. Get the Internal IP address by looking into HostEntry and retrieving the addresslist.
9. Get External IP Address by getting and downloading the request to http://whatismyipaddress.com
10. Get any anti-virus information by querying for AntivirusProduct via the ManagementObjectSearcher in the scope of \\DESKTOP-XXXXXXX\root\SecurityCenter2
11. Get any Firewall information by querying for FirewallProduct the same way it did for the anti-virus information.
12. Start a new thread to call FakemsgInstall which essentially just checks against flags and display the corresponding message boxes based on configured strings as well.
13. Start a new thread to call Foldersinstall
14. Start a new thread to call ServerInstall which would generate information of the current status and configurations and send it back to the operator if it is connected to the internet either via FTP, PHP or SMTP as per the configuration to confirm execution of the malware on the victim’s machine.
15. Start a new thread each to call Minecraftsub if stealers flag is set and is connected to the internet.
16. Start a new thread each to call Pins if stealers flag is set and is connected to the internet. This is used specifically to steal the
17. Start a new thread to call Disabler which essentially enumerates running processes and killing Taskmgr, taskmgr , cmd, msconfig, regedit based on the configuration flags. It can also add the WindowsUpdate.exe to the “CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run” registry for persistence.
18. Check if the Disableloggerflag is set to logger, the malware will then hook Keyboard Callback via the [SetWindowsHookEx](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa) function with the WH_KEYBOARD_LL flag. This callback KeyboardCallback function is the actually keylogger code. It would then send logs via FTP or PHP or SMTP depending on the configuration flags.
19. Depending on configuration clip, set the clipboard viewer so that it can get clipboard data.
20. Attempt to bind executable files whose data is appended as base64 at the end of the binder flag and starting the process for each of those files.
21. If there is internet connection, attempt to download files if downloadfiles flag is set. The flag would contain the URL address to download the executables DFile_X.exe and start a new process with that executable.
22. If there is internet connection, check if websitevisitor flag is set. IF set, then access the URL that is present in the flag value.
23. If dontclearie flag is set to clear, then delete every files in C:\Users\<user>\AppData\Local\Microsoft\Windows\INetCookies directory if that directory exists. This essentially clear cookies for Internet Explorer.
24. If dontclearff flag is set to clear, then delete all files in “C:\Users<user>\AppData\Roaming\Mozilla\Firefox\Profiles” that contains the word “cookie”.
25. If websiteblocker is set to block, then append \n127.0.0.1 <site> into C:\Windows\system32\drivers\etc\hosts file, where <site> is present in the configuration flag. This essentially reroutes the site to localhost and therefore blocking.
26. If Disablesteam is set to disable, enumerate the running processes for “steam” and delete both C:\Program Files (x86)\Steam\config\SteamAppData.vdf and C:\Program Files (x86)\Steam\ClientRegistry.blob files.
27. If Disablespreaders is set to spread, then get drives information, and create autorun.inf files for drive that are removable. This means that this malware would attempt to propagate to removable drives like USB Flash Drives. Details is that autorun file will run Sys.exe which is set to contain the data for the malware. Autorun and Sys.exe file’s attributes are then set to be hidden as well. These are all done in a new thread.

For more context about autorun.inf from Wikipedia :

An **autorun.inf** file is a text file that can be used by the AutoRun and AutoPlay components of Microsoft Windows operating systems. For the file to be discovered and used by these component, it must be located in the root directory of a volume. As Windows has a case-insensitive view of filenames, the autorun.inf file can be stored as AutoRun.inf or Autorun.INF or any other case combination.

AutoRun enabled application CD-ROMs to automatically launch a program which could then guide the user through the installation process

This means that when the USB has this autorun.inf file in it, and the user plugs that removable drive into another PC, with the right permission, it might infect or propagate to another machine.

Conclusion

This keylogger appears to be part of a possible phishing campaign, targeting the user Ebecco. It is believed that the sample is hidden as an Internet Explorer file of which, its sample contains at least two other executables which are involved in Process hollowing of a legitimate looking process, and the action of stealing, logging and forwarding logs to the operator either via FTP, PHP or SMTP. During its run, it would also copy its content into another legitimate named files and have itself stored in the registry for persistence. After the main sample was completed, it was also set to delete itself as well.

The sample is known to be Hawkeye Keylogger since it’s name was used as a key for decryption of sensitive information that is used by the operator. In this keylogger, it also contains many configurations that could have been automatically set based on operator’s needs.

On top of these, there were little to no mind blowing or extraordinarily difficult de-obfuscations , packing, anti-VM or anti-Debugging mechanisms set in place, making this relatively easy to understand and reverse engineer. Important executables are usually hidden in the embedded resources and it was trivial to extract them. Apart from the above, there are many changes in registry changes primarily for persistence and to hide itself.

Example of Registry Changes

In conclusion, I do suggest using this analyze a DotNet malware since I believe that this is relatively easier than other more sophisticated DotNet Malware samples. It is also a good introduction.

Some after-thoughts that I have is to attempt to :

1. enumerate and track altered the state of registry keys before and after the malware sample was ran in the sandbox.
2. rewrite some of its functionalities in C/C++ to further reinforce some knowledge.
3. Experiment with YARA to further track or detect possible variants from the archive.
4. Go through and verify if the methods implemented still work in the current world since these could be outdated.

Functions worth exploring further for fun sake

As this is the first malware sample I have analyzed, and I have to say that this has been a really exciting and fruitful experience !