New Buhtrap Loader
Today we will tell you about the new approach to the distribution of malware for 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 wednes.exe”, “Documents 19.12.exe”, “Closing documents wedis.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 tell 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 even easier. Prior to IsDebuggerPresent, the execution did not even reach, and LoadCursorW and LoadIconW worked out uselessly because they tried to access non-existing 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 file being examined, 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 example of the _main () function:
Next, in IDA Pro, we will perform a hex-sequence search:
At the output, we get the unmanaged _main () function, with which you can conveniently work using the Ida 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:
Decompiled code using this buffer looks like this:
The following functions are responsible for converting this buffer:
Here, the holdrand variable is initialized with the value 0xEA48CB16 and the foo () function is called in the loop for each byte of payloadData ( sbyte c parameter ). It should be noted that the t () function is from an unsafe 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 in it 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 unpacked PE, and the remaining fields are the addresses of the required functions and library handles ):
And then, using the obtained functions, a process of the same executable file is created ( md5: faf833a1456e1bb85117d95c23892368 ), and the unpacked executable file is mapped 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.
Well, now 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 byte array 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 obtained method, the MethodBase.Invoke () function is used.
The executable code in the koi module looks like this:
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 disassemble some methods. For example:
If you switch to the IL-code, you can notice calls on null pointers:
To fix decompiling errors, we replace incorrect instructions with 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:
Changing the IL-code in all problem methods, we received 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 . Change it with the CFF Explorer utility:
After saving the changes, the unpacked file is correctly launched and debugged.
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” substrings in the following registry value:
If a virtual machine is found, 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 automatically retry 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.
Next, 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,
• Username,
• OS version
• its 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 folder “1s” 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, traffic looks like this:
From base64, the NSIS installer is decoded with the following contents:
Interestingly, the server responded, although the list of banking 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 as the following scheme:
Despite the good protection against analysis, it is clear that at the moment the loader is not working correctly and, most likely, is in the process of development:
Finally, we recall the strange window message. Interestingly, this is a flaw in the developers - 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 wednes.exe”, “Documents 19.12.exe”, “Closing documents wedis.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 tell 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 even easier. Prior to IsDebuggerPresent, the execution did not even reach, and LoadCursorW and LoadIconW worked out uselessly because they tried to access non-existing 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 file being examined, 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 example of the _main () function:
Next, in IDA Pro, we will perform a hex-sequence search:
At the output, we get the unmanaged _main () function, with which you can conveniently work using the Ida 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:
Decompiled code using this buffer looks like this:
The following functions are responsible for converting this buffer:
Here, the holdrand variable is initialized with the value 0xEA48CB16 and the foo () function is called in the loop for each byte of payloadData ( sbyte c parameter ). It should be noted that the t () function is from an unsafe 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 in it 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 unpacked PE, and the remaining fields are the addresses of the required functions and library handles ):
And then, using the obtained functions, a process of the same executable file is created ( md5: faf833a1456e1bb85117d95c23892368 ), and the unpacked executable file is mapped 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.
Well, now 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 byte array 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 obtained method, the MethodBase.Invoke () function is used.
The executable code in the koi module looks like this:
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 disassemble some methods. For example:
If you switch to the IL-code, you can notice calls on null pointers:
To fix decompiling errors, we replace incorrect instructions with 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:
Changing the IL-code in all problem methods, we received 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 . Change it with the CFF Explorer utility:
After saving the changes, the unpacked file is correctly launched and debugged.
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” substrings in the following registry value:
- [HKLM \ System \ CurrentControlSet \ Services \ Disk \ Enum \ 0].
If a virtual machine is found, 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 automatically retry 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.
Next, 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 with the help of the "schtasks / create / f / sc ONLOGON / RL HIGHEST / tn LimeRAT-Admin / tr" command.
- 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, launches xaudiodg.exe and deletes.
If the process is started 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,
• Username,
• OS version
• its 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 folder “1s” 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 runs 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, launches a new executable file and deletes itself;
- RD- - sends the string "RD-" in response;
- RD + - sends a screenshot to the management server;
- DEL - self-deleted.
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, traffic looks like this:
From base64, the NSIS installer is decoded with the following contents:
Interestingly, the server responded, although the list of banking 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 as the following scheme:
Despite the good protection against analysis, it is clear that at the moment the loader is not working correctly and, most likely, is in the process of development:
- can even remotely 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 flaw in the developers - 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
Source: https://habr.com/ru/post/434626/
All Articles