Analysis of the new version of Miniduke
Recently, our analysts discovered a new version of the malware MiniDuke (Kaspersky, Symantec), which was distributed using an exploit for the CVE-2014-1761 vulnerability . All versions of MS Word 2003-2013 were affected by this vulnerability until the release of the corresponding MS14-017 fix. MiniDuke is a small backdoor (about 20 KB) and allows attackers to gain full access to the compromised system. It is so small in size because it was designed using assembly language. ESET detects MiniDuke as Win32 / SandyEva .
In the new version of this malicious program, attackers have added an auxiliary component executed in JavaScript. It is designed to work with a remote C & C server via Twitter.
')
Fig. RTF document with exploit CVE-2014-1761 on board.
The above document was called Proposal-Cover-Sheet-English.rtf . We received it on April 8th, just three days after the new MiniDuke executable file was compiled (time stamp on April 5th from the PE header). This executable file is delivered by the exploit and its size is 24 KB.
The functionality of the shellcode that is executed after the vulnerability has been triggered is fairly simple and straightforward. After decrypting his code and getting the addresses of some functions exported by the library kernel32.dll, he decrypts the payload file and places it in the% TEMP% directory and the "al" file. This file flushed to disk is a library, which will then be loaded into memory using the standard kernel32! LoadLibraryA function.
The shellcode contains anti-debugging mechanisms and checks the first bytes of the called APIs for the presence of hooks or breakpoints used by the debuggers. If there are any anomalies (mismatch of the function prologue with the original), the shellcode skips the first five initial bytes of the function by manually executing the prologue (mov edi, edi; push ebp; mov ebp, esp) from its code.
Fig. The shell code checks the function prologue for the presence of instructions to transfer control to a third-party code. It is seen that in the case of the presence of a modification, the prolog is executed directly from the shell code.
The following diagram shows the execution flow (execution flow) of the malware code, in case of successful exploitation of the vulnerability. As we mentioned above, this version of the MiniDuke payload consists of two components, which we call the main module and the TwitterJS module.
Fig. Malware actions.
As soon as the malicious DLL MiniDuke gets control, it checks the context of its process for belonging to rundll32.exe, as well as the current directory for a match with% TEMP%. If these conditions are met, the malware assumes that it was launched for the first time and begins its installation process in the system. MiniDuke collects system information and encrypts its configuration data based on this information. This method was used in OSX / Flashback and was named watermarking (Bitdefender). This leads to the fact that the configuration data stored in the DLL cannot be retrieved on another computer. Information collected by malicious code, on the basis of which the data will be encrypted, has not changed from the previous version and is based on the following values.
When MiniDuke generated an encrypted version of its DLL, it writes it to a file in the% ALLUSERSPROFILE% \ Application Data directory. The file name, as well as the extension, is selected based on the values ​​listed here . To ensure its survival after rebooting, MiniDuke creates a hidden shortcut file .LNK in the Startup directory, which points to a component of the malware. The name of the label file is generated using one of the following values.
As it is easy to guess, rundll32.exe will be used to execute dll via .LNK. In this case, the command will be:
"C: \ Windows \ system32 \ rundll32.exe% path_to_main_module%, export_function"
"C: \ Windows \ system32 \ rundll32.exe C: \ DOCUME ~ 1 \ ALLUSE ~ 1 \ APPLIC ~ 1 \ data.cat, IlqUenn"
When rundll32 executes the MiniDuke DLL, the code from this library will already be executed according to another script (not launched for the first time). To decrypt its data, the malicious code begins to collect information about the system we mentioned above. As in the case of the previous version of MiniDuke, this version checks the following running processes in the system.
If one of these processes is detected in the system, the malicious code incorrectly decrypts its data, which makes it impossible to work with a remote C & C server. In the case of the correct decryption of its data and the absence of running processes from the list above, MiniDuke gets the Twitter account service page @FloydLSchwartz to search for the URLs of the remote C & C server. To search the page, use the tag "X)))" (the previous modification of the malicious program searched for the tag "uri!"). If the tag is found, the malicious code decrypts the URL from the data that follows the tag. The @FloydLSchwartz Twitter account we found contains only retweets on its page without mentioning the above tag.
Fig. Twitter account, which is used to extract information about the C & C server of the malware.
In the next step, MiniDuke collects the following information on the infected system:
This information is then sent to the C & C server along with a special request for payload. The final URL that is used to interact with the C & C server is as follows: " <url_start> /create.php? <Rnd_param> = <system_info> ".
An example of such a URL is shown below.
The payload is loaded using the urlmon! URLDownloadToFileA API and is a file called “fdbywu”.
Fig. The function of obtaining the payload.
Loaded payload is a fake GIF8 image file. This file contains the encrypted executable code. MiniDuke handles this downloaded file in the same way as its previous version. Data integrity is verified using RSA-2048, then the executable file data is decrypted and stored in a separate file. Next, the file is launched for execution. To verify the integrity of the executable file inside the GIF, the public key RSA-2048 is used, which is similar to that used in the previous version of the malicious program.
In case MiniDuke cannot get the address of the C & C server from a Twitter account, it generates a special username for the search based on the current date. The search query changes every seven days and resembles the backup mechanism in previous versions of the malware that used Google search. An implementation of this DGA algorithm in Python can be found here .
The TwitterJS module is embedded in a copy of the Windows cryptdll.dll system file. The malicious code inserts a block of code into this system dll, redirecting one of the exported functions to this code. The screenshot below shows the export table for a modified version of this library.
This file (a modified copy of cryptdll.dll) is then saved as an NTFS data stream (ADS) for the NTUSER.DAT file in the% USERPROFILE% directory (the system file, which is part of the system registry). Further the call of this library is registered as the Open command for the disk. Thus, it will be invoked each time the user tries to open the logical drive through explorer. The following is the contents of the init.cmd script file that is used by the malware to install the TwitterJS module (cryptdll.dll) into the system.
Once loaded, TwitterJS initiates the creation of an instance of the COM object JScript and decrypts the JScript file itself, which contains the logic of the module.
Before launching it, MiniDuke applies obfuscation to it. The screenshots below show the result of two different obfuscations. We can see that variables have different meanings. Perhaps this is done in order to prevent them from being investigated by various detection systems that scan the code at the JScript entry point.
Fig. The result of the first obfuscation.
Fig. The result of the second obfuscation.
The purpose of this script is to use Twitter to find C & C and extract JScript code for execution. It generates a Twitter user account to search for information. The search is performed using an expression that changes every seven days. Next, the bot visits the Twitter user profiles that were received as a result of the search query and looks for tweets that end in “.xhtml”. Once such a URL has been found, the bot takes the link string and replaces “.xhtml” with “.php”. Information about the computer is embedded in the Accept parameter of the HTTP header.
The first link on the resulting page should contain base64 encoded data. The name of the link attribute is used as a key for the XOR algorithm used to decrypt JScript. Finally, Miniduke calculates the hash of the extracted script and compares it with the hash wired in its TwitterJS code. If they match, the resulting script is executed using the eval () call.
The hashing algorithm used in this component is very similar to SHA-1, but is not identical to it, since different hashes are output. We decided to find out what exactly the authors changed in the original algorithm. One of the possible hypotheses was that the algorithm was modified in such a way as to allow possible collisions (bug). However, outwardly, everything looks similar to the original scheme: the same mathematical steps and constants are used. We observed a difference for short messages, for example, the second 32-bit double word in the hash was different from the one generated by regular SHA-1.
SHA1 (“test”): a94a8fe5 ccb19ba6 1c4c0873d391e987982fbbd3
TwitterJS_SHA1 (“test”): a94a8fe5 dce4f01c 1c4c0873d391e987982fbbd3
We found out why the second double word in the hash does not match the original algorithm. The problem is caused by improper use of the scope of variables (scope). As shown below, in the SHA-1 code, the variable f is used twice. But in the Z function, before using it, the var keyword is not available, which would declare it as a local variable. It can be seen that the function Z is then called again with the global variable f , which has already been initialized by the function itself.
A possible explanation for this error is that the variable names were generated by some kind of automatic tool before the script was directly introduced into the payload. Most likely, in the original version of the script, these two variables had different names.
We were able to generate the proposed Twitter account names for 2013-2014. and check if they are active now. At the time of our research, only one account @ AA2ADcAOAA was active. This account was generated by the above script between August 21st and 27th, 2013 and did not have tweets.
Trying to detect potential victims of this malicious code, we registered special Twitter accounts and generated tweets with links for bots. We managed to get several connections from four computers located in Belgium, France and the UK. We contacted the CERT rapid response centers of these countries to notify about infected computers.
We find the RTF document with the exploit as Win32 / Exploit.CVE-2014-1761.D and the MiniDuke component as Win32 / SandyEva.G .
In the new version of this malicious program, attackers have added an auxiliary component executed in JavaScript. It is designed to work with a remote C & C server via Twitter.
')
Fig. RTF document with exploit CVE-2014-1761 on board.
The above document was called Proposal-Cover-Sheet-English.rtf . We received it on April 8th, just three days after the new MiniDuke executable file was compiled (time stamp on April 5th from the PE header). This executable file is delivered by the exploit and its size is 24 KB.
The functionality of the shellcode that is executed after the vulnerability has been triggered is fairly simple and straightforward. After decrypting his code and getting the addresses of some functions exported by the library kernel32.dll, he decrypts the payload file and places it in the% TEMP% directory and the "al" file. This file flushed to disk is a library, which will then be loaded into memory using the standard kernel32! LoadLibraryA function.
The shellcode contains anti-debugging mechanisms and checks the first bytes of the called APIs for the presence of hooks or breakpoints used by the debuggers. If there are any anomalies (mismatch of the function prologue with the original), the shellcode skips the first five initial bytes of the function by manually executing the prologue (mov edi, edi; push ebp; mov ebp, esp) from its code.
Fig. The shell code checks the function prologue for the presence of instructions to transfer control to a third-party code. It is seen that in the case of the presence of a modification, the prolog is executed directly from the shell code.
The following diagram shows the execution flow (execution flow) of the malware code, in case of successful exploitation of the vulnerability. As we mentioned above, this version of the MiniDuke payload consists of two components, which we call the main module and the TwitterJS module.
Fig. Malware actions.
As soon as the malicious DLL MiniDuke gets control, it checks the context of its process for belonging to rundll32.exe, as well as the current directory for a match with% TEMP%. If these conditions are met, the malware assumes that it was launched for the first time and begins its installation process in the system. MiniDuke collects system information and encrypts its configuration data based on this information. This method was used in OSX / Flashback and was named watermarking (Bitdefender). This leads to the fact that the configuration data stored in the DLL cannot be retrieved on another computer. Information collected by malicious code, on the basis of which the data will be encrypted, has not changed from the previous version and is based on the following values.
- The serial number of the volume (through the use of kernel32! GetVolumeInformationA ).
- CPU information (using the cpuid instruction).
- Computer name ( kernel32! GetComputerNameA ).
When MiniDuke generated an encrypted version of its DLL, it writes it to a file in the% ALLUSERSPROFILE% \ Application Data directory. The file name, as well as the extension, is selected based on the values ​​listed here . To ensure its survival after rebooting, MiniDuke creates a hidden shortcut file .LNK in the Startup directory, which points to a component of the malware. The name of the label file is generated using one of the following values.
As it is easy to guess, rundll32.exe will be used to execute dll via .LNK. In this case, the command will be:
"C: \ Windows \ system32 \ rundll32.exe% path_to_main_module%, export_function"
"C: \ Windows \ system32 \ rundll32.exe C: \ DOCUME ~ 1 \ ALLUSE ~ 1 \ APPLIC ~ 1 \ data.cat, IlqUenn"
When rundll32 executes the MiniDuke DLL, the code from this library will already be executed according to another script (not launched for the first time). To decrypt its data, the malicious code begins to collect information about the system we mentioned above. As in the case of the previous version of MiniDuke, this version checks the following running processes in the system.
If one of these processes is detected in the system, the malicious code incorrectly decrypts its data, which makes it impossible to work with a remote C & C server. In the case of the correct decryption of its data and the absence of running processes from the list above, MiniDuke gets the Twitter account service page @FloydLSchwartz to search for the URLs of the remote C & C server. To search the page, use the tag "X)))" (the previous modification of the malicious program searched for the tag "uri!"). If the tag is found, the malicious code decrypts the URL from the data that follows the tag. The @FloydLSchwartz Twitter account we found contains only retweets on its page without mentioning the above tag.
Fig. Twitter account, which is used to extract information about the C & C server of the malware.
In the next step, MiniDuke collects the following information on the infected system:
- computer name and domain name;
- the country code of the IP address of the infected computer obtained through www.geoiptool.com;
- OS version information;
- the name of the domain controller, the name of the user and the groups that belong to him;
- list of AV-products installed in the system;
- Internet proxy configuration;
- version of the malware.
This information is then sent to the C & C server along with a special request for payload. The final URL that is used to interact with the C & C server is as follows: " <url_start> /create.php? <Rnd_param> = <system_info> ".
- url_start - the URL received through your Twitter account;
- rnd_param - arbitrarily generated lowercase characters;
- system_info - information about the system, encrypted, and then encoded via base64.
An example of such a URL is shown below.
The payload is loaded using the urlmon! URLDownloadToFileA API and is a file called “fdbywu”.
Fig. The function of obtaining the payload.
Loaded payload is a fake GIF8 image file. This file contains the encrypted executable code. MiniDuke handles this downloaded file in the same way as its previous version. Data integrity is verified using RSA-2048, then the executable file data is decrypted and stored in a separate file. Next, the file is launched for execution. To verify the integrity of the executable file inside the GIF, the public key RSA-2048 is used, which is similar to that used in the previous version of the malicious program.
In case MiniDuke cannot get the address of the C & C server from a Twitter account, it generates a special username for the search based on the current date. The search query changes every seven days and resembles the backup mechanism in previous versions of the malware that used Google search. An implementation of this DGA algorithm in Python can be found here .
The TwitterJS module is embedded in a copy of the Windows cryptdll.dll system file. The malicious code inserts a block of code into this system dll, redirecting one of the exported functions to this code. The screenshot below shows the export table for a modified version of this library.
This file (a modified copy of cryptdll.dll) is then saved as an NTFS data stream (ADS) for the NTUSER.DAT file in the% USERPROFILE% directory (the system file, which is part of the system registry). Further the call of this library is registered as the Open command for the disk. Thus, it will be invoked each time the user tries to open the logical drive through explorer. The following is the contents of the init.cmd script file that is used by the malware to install the TwitterJS module (cryptdll.dll) into the system.
Once loaded, TwitterJS initiates the creation of an instance of the COM object JScript and decrypts the JScript file itself, which contains the logic of the module.
Before launching it, MiniDuke applies obfuscation to it. The screenshots below show the result of two different obfuscations. We can see that variables have different meanings. Perhaps this is done in order to prevent them from being investigated by various detection systems that scan the code at the JScript entry point.
Fig. The result of the first obfuscation.
Fig. The result of the second obfuscation.
The purpose of this script is to use Twitter to find C & C and extract JScript code for execution. It generates a Twitter user account to search for information. The search is performed using an expression that changes every seven days. Next, the bot visits the Twitter user profiles that were received as a result of the search query and looks for tweets that end in “.xhtml”. Once such a URL has been found, the bot takes the link string and replaces “.xhtml” with “.php”. Information about the computer is embedded in the Accept parameter of the HTTP header.
The first link on the resulting page should contain base64 encoded data. The name of the link attribute is used as a key for the XOR algorithm used to decrypt JScript. Finally, Miniduke calculates the hash of the extracted script and compares it with the hash wired in its TwitterJS code. If they match, the resulting script is executed using the eval () call.
The hashing algorithm used in this component is very similar to SHA-1, but is not identical to it, since different hashes are output. We decided to find out what exactly the authors changed in the original algorithm. One of the possible hypotheses was that the algorithm was modified in such a way as to allow possible collisions (bug). However, outwardly, everything looks similar to the original scheme: the same mathematical steps and constants are used. We observed a difference for short messages, for example, the second 32-bit double word in the hash was different from the one generated by regular SHA-1.
SHA1 (“test”): a94a8fe5 ccb19ba6 1c4c0873d391e987982fbbd3
TwitterJS_SHA1 (“test”): a94a8fe5 dce4f01c 1c4c0873d391e987982fbbd3
We found out why the second double word in the hash does not match the original algorithm. The problem is caused by improper use of the scope of variables (scope). As shown below, in the SHA-1 code, the variable f is used twice. But in the Z function, before using it, the var keyword is not available, which would declare it as a local variable. It can be seen that the function Z is then called again with the global variable f , which has already been initialized by the function itself.
A possible explanation for this error is that the variable names were generated by some kind of automatic tool before the script was directly introduced into the payload. Most likely, in the original version of the script, these two variables had different names.
We were able to generate the proposed Twitter account names for 2013-2014. and check if they are active now. At the time of our research, only one account @ AA2ADcAOAA was active. This account was generated by the above script between August 21st and 27th, 2013 and did not have tweets.
Trying to detect potential victims of this malicious code, we registered special Twitter accounts and generated tweets with links for bots. We managed to get several connections from four computers located in Belgium, France and the UK. We contacted the CERT rapid response centers of these countries to notify about infected computers.
We find the RTF document with the exploit as Win32 / Exploit.CVE-2014-1761.D and the MiniDuke component as Win32 / SandyEva.G .
Source: https://habr.com/ru/post/223995/
All Articles