New Buhtrap Loader
Today we will tell you about the new approach to sending out malware to the Buhtrap group.
On December 19, we learned about a malicious mailing list containing an executable file ( md5: faf833a1456e1bb85117d95c23892368 ). The file accepted various names: “Reconciliation for December.exe”, “Doc-you Wednesday.exe”, “Documents 19.12.exe”, “Closing Documents Wednesday.exe”.
From the interesting - the file is written on .Net, which is not typical for this criminal group. For decompiling .Net, you can take any software: Reflector , dotPeek , dnSpy , ILSpy . In the article we will talk about the features of the implementation of this file and how we analyzed it.
For the analysis we used dnSpy , and all further screenshots will be from it.
Out of habit, open the executable file in IDA Pro and look at the import section. Examples:
The presence of some functions suggests the presence of a packed payload ( LoadCursorW , LoadIconW - got the object from the resources, VirtualProtect - changed the page attributes, then you can execute the code) and simple anti-debugging ( IsDebuggerPresent ). But everything turned out to be even easier. They didn’t even reach IsDebuggerPresent, and LoadCursorW and LoadIconW did no work because they tried to access non-existent resources (LoadCursorW from fiza"And LoadIconW from" saxikulatebutohutejijobodugore "):
But back to the dnSpy decompiler . In the executable file we see a significant amount of unmanaged code:
To understand what constitutes unmanaged code in the studied file, we will use IDA Pro. The easiest way is to look in hex form of the unmanaged code body. To do this, go to the offset File Offset. Using the _main () function as an example :
Next, in IDA Pro , we search by hex-sequence:
At the output, we get the unmanaged _main () function, which can be conveniently operated using the Idov decompiler:
Let's go back to dnSpy. Attention is drawn to the variable payloadData .
We find this sequence in IDA Pro, we get references to it and we find out that the call occurs just in the _main () function : The
decompiled code using this buffer looks like this:
The following functions are responsible for converting this buffer:
Here, the holdrand variable is initialized to 0xEA48CB16 and in the loop the function foo () is called for each byte from payloadData ( sbyte parameter c). It should be noted that the t () function is from an insecure code: if you look at its code, you can make sure that it always returns the value 0x343FD .
Next we arm IDA Pro and, looking at the resulting unpacked buffer, we notice that there is some code at the beginning:
At offset 0x15A0 from the beginning of the buffer is the executable file:
Save it for later analysis.
Well, in the executable code itself, a rather trivial thing is implemented. First, the following structure is formed ( here mz_base is the offset address in the buffer with the unpacked PE, and the remaining fields are the addresses of the required functions and library handles ):
And then using the obtained functions, the process of the same executable file is created (md5: faf833a1456e1bb85117d95c23892368 ), and the unpacked executable file is transferred to the virtual addresses of the new process. After changing the address of the executable instruction (a bunch of GetThreadContext and SetThreadContext ), the thread of the new process starts, and the parent process itself is killed.
Now let's turn to the analysis of the resulting executable file (payload).
The payload ( md5 dump: d8f40c7060c44fab57df87ab709f058f ) is also written on the .Net Framework.
To protect against static and dynamic analysis, the developers of VPO used the latest version of the popular protector ConfuserEx :
ConfuserEx is a well-proven open source protector.
The entry point of files protected by this protector is as follows:
After decryption, the array of bytes is loaded into memory as a module called koi . Then the main method of this module is determined and called. On the .Net platform, a method or constructor in a module can be obtained from the metadata token by calling the function Module.ResolveMethod () . To transfer control to the resulting method, the MethodBase.Invoke () function is used .
The executable code in the koi module is as follows:
To remove the tread, we used the following utilities:
ConfuserEx-Unpacker deciphered the lines and code inside the methods, and de4dot made the names of the methods readable.
The result is a code suitable for static analysis: Of
course, we were lucky to get readable code. Virus writers can modify the source code of the ConfuserEx protector to further complicate the analysis.
There are still two problems that had to be solved for a comfortable analysis of the file.
After removing the tread decompiler could not make out some methods. For example:
If you switch to the IL code, you can notice calls on null pointers:
To correct decompiling errors, we replace incorrect instructions with the nop instructions. (The dnSpy utility allows you to change both the decompiled code and the IL code.)
After the replacement, the decompiled code looks correct:
By changing the IL code in all the problematic methods, we got a fully decompiled file.
The resulting file is unlikely to start, and this eliminates the possibility of dynamic analysis. To solve this problem, you must specify the token of the input method in the structure of the executable file.
You can find it in one of two ways:
Module.ResolveMethod () before unpacking the file:
In this case, the metadata token for the input method is 0x6000106 . Changing it with the CFF Explorer utility :
After saving the changes, the unpacked file starts and debugs correctly.
Immediately after starting work, the bootloader checks whether it is running in a virtual environment.
Running under VMWare or QEMU is determined by searching for the “vmware” and “qemu” strings in the following registry value:
If a virtual machine is detected, the bootloader displays the corresponding window message:
Interestingly, the output of this message does not affect the operation of the process.
After this, the malware attempts to load the libraries from the following list into memory: SbieDll.dll, dbghelp.dll, api_log.dll, dir_watch.dll, pstorec.dll, vmcheck.dll, wpespy.dll, snxhk.dll, guard32.dll .
In addition, using the Debugger.IsLogging () and Debugger.get_IsAttached () function calls, the loader checks whether it is running under the debugger.
If at least one of the libraries loads successfully or the boot loader detects that it is running under the debugger, it will be deleted using the cmd / C ping 8.8.8.8 -n 1 -w 3000> Nul & Del command". Interestingly, the bootloader can run itself even on a real system by loading the dbghelp.dl l library .
Further, the malware checks if it is launched from the directory containing the substring “Mozilla”.
The IP address of the server in the malware sample being analyzed is 213.252.244 [.] 200. The connection is initialized on a randomly selected port from the list:
• 8989,
• 5656,
• 2323.
Immediately after the connection is initialized, the bootloader sends information about the infected system to C & C:
• user ID,
• user name,
• OS version,
• own version (loader v0. 2.1),
• lists of found indicators of banking operations on the infected system.
An example of a line sent by the loader to the management server:
This string will be sent if there is a “1s” folder on the desktop of the infected user, and there are no other indicators.
The function of processing the response from the server is as follows: The
decrypted response from the server is as follows:
As you can see from the screenshot, COMMAND can be one of the following values:
During the bootloader investigation, we managed to get the DW command from the attacker's server. As a result, the Punto Switcher software with the malicious DLL library winmm.dll (md5: 9d25553bb09e2785262b2f7ba7923605), which is a Buhtrap group spyware, was installed in the system.
TCP Stream looks like this: AES-128-ECB
algorithm is used to encrypt the data transmitted between the client and the managing server . The encryption key is initialized with a hard-coded password. After decryption, the traffic looks like this: The NSIS installer is decoded from base64 with the following content: It is interesting that the server responded, although the list of banking operations indicators was empty.
The winmm.dll library is executed using the dll hijacking technique. The malicious module sends information about the infected system and a list of active smart card readers to C & C. In addition, it has a keylogger component and is able to receive other malicious modules from the control server, execute them from the disk or in the memory of the current process. The C & C servers of the sample under study are located at the following addresses:
The infection process can be represented in the form of the following scheme:
Despite a good protection against analysis, it is clear that at the moment the loader does not work correctly and, most likely, is in the process of development:
Finally, we recall the strange window message. Interestingly, this is a developer flaw - or is it done specifically to encourage users to exit the virtual environment and run on a real machine? Wellcome in the comments.
MD5:
faf833a1456e1bb85117d95c23892368
9d25553bb09e2785262b2f7ba7923605
URLs:
hxxp: // my1cprovider xyz [.]: [.] 6060 / klog php
hxxp: [.] // tinderminderorli1999 xyz: 7764 / klog php [.]
IPs:
[.] 213.252.244 200
Bootloader module
On December 19, we learned about a malicious mailing list containing an executable file ( md5: faf833a1456e1bb85117d95c23892368 ). The file accepted various names: “Reconciliation for December.exe”, “Doc-you Wednesday.exe”, “Documents 19.12.exe”, “Closing Documents Wednesday.exe”.
From the interesting - the file is written on .Net, which is not typical for this criminal group. For decompiling .Net, you can take any software: Reflector , dotPeek , dnSpy , ILSpy . In the article we will talk about the features of the implementation of this file and how we analyzed it.
Initial bootloader inspection
For the analysis we used dnSpy , and all further screenshots will be from it.
Out of habit, open the executable file in IDA Pro and look at the import section. Examples:
The presence of some functions suggests the presence of a packed payload ( LoadCursorW , LoadIconW - got the object from the resources, VirtualProtect - changed the page attributes, then you can execute the code) and simple anti-debugging ( IsDebuggerPresent ). But everything turned out to be even easier. They didn’t even reach IsDebuggerPresent, and LoadCursorW and LoadIconW did no work because they tried to access non-existent resources (LoadCursorW from fiza"And LoadIconW from" saxikulatebutohutejijobodugore "):
But back to the dnSpy decompiler . In the executable file we see a significant amount of unmanaged code:
To understand what constitutes unmanaged code in the studied file, we will use IDA Pro. The easiest way is to look in hex form of the unmanaged code body. To do this, go to the offset File Offset. Using the _main () function as an example :
Next, in IDA Pro , we search by hex-sequence:
At the output, we get the unmanaged _main () function, which can be conveniently operated using the Idov decompiler:
Getting payload
Let's go back to dnSpy. Attention is drawn to the variable payloadData .
We find this sequence in IDA Pro, we get references to it and we find out that the call occurs just in the _main () function : The
decompiled code using this buffer looks like this:
The following functions are responsible for converting this buffer:
Here, the holdrand variable is initialized to 0xEA48CB16 and in the loop the function foo () is called for each byte from payloadData ( sbyte parameter c). It should be noted that the t () function is from an insecure code: if you look at its code, you can make sure that it always returns the value 0x343FD .
Next we arm IDA Pro and, looking at the resulting unpacked buffer, we notice that there is some code at the beginning:
At offset 0x15A0 from the beginning of the buffer is the executable file:
Save it for later analysis.
Well, in the executable code itself, a rather trivial thing is implemented. First, the following structure is formed ( here mz_base is the offset address in the buffer with the unpacked PE, and the remaining fields are the addresses of the required functions and library handles ):
And then using the obtained functions, the process of the same executable file is created (md5: faf833a1456e1bb85117d95c23892368 ), and the unpacked executable file is transferred to the virtual addresses of the new process. After changing the address of the executable instruction (a bunch of GetThreadContext and SetThreadContext ), the thread of the new process starts, and the parent process itself is killed.
Now let's turn to the analysis of the resulting executable file (payload).
Payload unpacking
The payload ( md5 dump: d8f40c7060c44fab57df87ab709f058f ) is also written on the .Net Framework.
To protect against static and dynamic analysis, the developers of VPO used the latest version of the popular protector ConfuserEx :
ConfuserEx is a well-proven open source protector.
Primary unpacking
The entry point of files protected by this protector is as follows:
After decryption, the array of bytes is loaded into memory as a module called koi . Then the main method of this module is determined and called. On the .Net platform, a method or constructor in a module can be obtained from the metadata token by calling the function Module.ResolveMethod () . To transfer control to the resulting method, the MethodBase.Invoke () function is used .
The executable code in the koi module is as follows:
To remove the tread, we used the following utilities:
ConfuserEx-Unpacker deciphered the lines and code inside the methods, and de4dot made the names of the methods readable.
The result is a code suitable for static analysis: Of
course, we were lucky to get readable code. Virus writers can modify the source code of the ConfuserEx protector to further complicate the analysis.
There are still two problems that had to be solved for a comfortable analysis of the file.
1st problem
After removing the tread decompiler could not make out some methods. For example:
If you switch to the IL code, you can notice calls on null pointers:
To correct decompiling errors, we replace incorrect instructions with the nop instructions. (The dnSpy utility allows you to change both the decompiled code and the IL code.)
After the replacement, the decompiled code looks correct:
By changing the IL code in all the problematic methods, we got a fully decompiled file.
2nd problem
The resulting file is unlikely to start, and this eliminates the possibility of dynamic analysis. To solve this problem, you must specify the token of the input method in the structure of the executable file.
You can find it in one of two ways:
- look under debugging with which parameter the function was called
Module.ResolveMethod () before unpacking the file:
- in the unpacked file find the method with the label [STAThread] :
In this case, the metadata token for the input method is 0x6000106 . Changing it with the CFF Explorer utility :
After saving the changes, the unpacked file starts and debugs correctly.
Bootloader analysis
Immediately after starting work, the bootloader checks whether it is running in a virtual environment.
Running under VMWare or QEMU is determined by searching for the “vmware” and “qemu” strings in the following registry value:
- [HKLM \ System \ CurrentControlSet \ Services \ Disk \ Enum \ 0].
If a virtual machine is detected, the bootloader displays the corresponding window message:
Interestingly, the output of this message does not affect the operation of the process.
After this, the malware attempts to load the libraries from the following list into memory: SbieDll.dll, dbghelp.dll, api_log.dll, dir_watch.dll, pstorec.dll, vmcheck.dll, wpespy.dll, snxhk.dll, guard32.dll .
In addition, using the Debugger.IsLogging () and Debugger.get_IsAttached () function calls, the loader checks whether it is running under the debugger.
If at least one of the libraries loads successfully or the boot loader detects that it is running under the debugger, it will be deleted using the cmd / C ping 8.8.8.8 -n 1 -w 3000> Nul & Del command". Interestingly, the bootloader can run itself even on a real system by loading the dbghelp.dl l library .
Further, the malware checks if it is launched from the directory containing the substring “Mozilla”.
If the process is not started from the directory containing the substring "Mozilla"
- The malware creates a list of directories that are located on the desktop and contain the following substrings (all strings inside the bootloader are encrypted using the AES-256-ECB algorithm, encryption keys are generated using secure passwords):
- Generates a list of URLs from the browser history that contain the following substrings:
- Generates a list of files that are located in the "% UserProfile% \\ Desktop", "% AppData%", "C: \\ Program Files (x86)", "C: \\ Program Files (x86) (x86)" and have the following names:
- Counts the number of non-empty lists of indicators related to banking operations (in the current version of the loader, this functionality does not affect anything).
- Creates a task to run this file every time a user logs in to the system using the command "schtasks / create / f / sc ONLOGON / RL HIGHEST / tn LimeRAT-Admin / tr".
- If the task could not be created, create the shortcut "% AppData% \\ Microsoft \\ Windows \\ Start Menu \\ Programs \\ Startup \\ MozillaUpdate.lnk", pointing to "% Appdata% \\ Mozilla \\ xaudiodg.exe" that runs the xaudiodg.exe file every time the system is restarted.
- It copies itself along the path "% AppData% \\ Mozilla \\ xaudiodg.exe".
- Removes the <self_path>: Zone.Identifier file, starts xaudiodg.exe and deletes.
If the process is launched from the directory containing the substring "Mozilla"
- VPO similarly searches for the above-listed indicators of banking operations inside the infected system.
- Collects other system information for sending to the management server.
- In a separate thread, it sends information to C & C and waits for a response from the server.
- In another thread in an infinite loop, it sends the encrypted string “PING?” To the server.
Interaction with the managing server
The IP address of the server in the malware sample being analyzed is 213.252.244 [.] 200. The connection is initialized on a randomly selected port from the list:
• 8989,
• 5656,
• 2323.
Immediately after the connection is initialized, the bootloader sends information about the infected system to C & C:
• user ID,
• user name,
• OS version,
• own version (loader v0. 2.1),
• lists of found indicators of banking operations on the infected system.
An example of a line sent by the loader to the management server:
«INFO<NYANxCAT>9D3A4B22D21C<NYANxCAT>IEUser<NYANxCAT> Windows 7 Enterprise SP 1
<NYANxCAT>loader v0.2.1<NYANxCAT><NYANxCAT><NYANxCAT>1c, »
This string will be sent if there is a “1s” folder on the desktop of the infected user, and there are no other indicators.
The function of processing the response from the server is as follows: The
decrypted response from the server is as follows:
COMMAND<NYANxCAT>DATA1<NYANxCAT>DATA2<NYANxCAT>…
As you can see from the screenshot, COMMAND can be one of the following values:
- CLOSE - terminates the connection and closes the current process;
- DW - decodes content from DATA2 from base64, writes it to a file <temp_file_name> with extension from DATA1 and launches the file for execution;
- UPDATE - decodes content from DATA1 from base64, writes it to a file with the name <temp_file_name> and extension .exe, starts a new executable file and deletes itself;
- RD- - sends the string "RD-" in response;
- RD + - sends a screenshot to the management server;
- DEL - removes itself.
During the bootloader investigation, we managed to get the DW command from the attacker's server. As a result, the Punto Switcher software with the malicious DLL library winmm.dll (md5: 9d25553bb09e2785262b2f7ba7923605), which is a Buhtrap group spyware, was installed in the system.
TCP Stream looks like this: AES-128-ECB
algorithm is used to encrypt the data transmitted between the client and the managing server . The encryption key is initialized with a hard-coded password. After decryption, the traffic looks like this: The NSIS installer is decoded from base64 with the following content: It is interesting that the server responded, although the list of banking operations indicators was empty.
Malware DLL
The winmm.dll library is executed using the dll hijacking technique. The malicious module sends information about the infected system and a list of active smart card readers to C & C. In addition, it has a keylogger component and is able to receive other malicious modules from the control server, execute them from the disk or in the memory of the current process. The C & C servers of the sample under study are located at the following addresses:
- hxxp: // my1cprovider [.] xyz: 6060 / klog [.] php
- hxxp: // tinderminderorli1999 [.] xyz: 7764 / klog [.] php
Conclusion
The infection process can be represented in the form of the following scheme:
Despite a good protection against analysis, it is clear that at the moment the loader does not work correctly and, most likely, is in the process of development:
- can even remove itself on a real system;
- It checks the connection of the infected system with banking operations before copying itself to “% AppData% \\ Mozilla \\ xaudiodg.exe” and before interacting with C & C, but does not use this information in any way.
Finally, we recall the strange window message. Interestingly, this is a developer flaw - or is it done specifically to encourage users to exit the virtual environment and run on a real machine? Wellcome in the comments.
Iocs
MD5:
faf833a1456e1bb85117d95c23892368
9d25553bb09e2785262b2f7ba7923605
URLs:
hxxp: // my1cprovider xyz [.]: [.] 6060 / klog php
hxxp: [.] // tinderminderorli1999 xyz: 7764 / klog php [.]
IPs:
[.] 213.252.244 200