Emotet, the polymorphic malware of whose actions we have already heard news at INCIBE-CERT (USA and Spain), has not ceased evolving from its inception, when it was catalogued as a banking Trojan, to now, where its main function is to act as a “downloader”, that is, allowing downloading and execution of other malware such as Trickbot, file encryptors, etc.
Its modus operandi is that attackers normally use fraudulent emails with attachments or links to malicious office files which, using macros, try to download and run Emotet, thus seeking to evade antivirus software.
This post will examine one of these office documents, a .doc file with macros, using static and dynamic analysis of the sample in a controlled environment, in order to identify the actions executed by this harmful code.
The study sample was obtained from VirusTotal, as it was identified during the search for the Emotet family.
- Table 1. Details of the malware sample. -
The information obtained by using the command file from a Linux operating system is as follows:
Composite Document File V2 Document, Little Endian, Os: Windows, Version 10.0, Code page: 1252, Template: Normal.dotm, Revision Number: 1, Name of Creating Application: Microsoft Office Word, Create Time/Date: Tue Jul 21 23:37:00 2020, Last Saved Time/Date: Tue Jul 21 23:37:00 2020, Number of Pages: 2, Number of Words: 5, Number of Characters: 30, Security: 0
The first thing observed during the analysis is that the macros in the document use a bypass technique to hide their content from the specific Microsoft Office viewer. However, though they cannot be displayed, the warning for the execution of macros keeps appearing, as shown in the following image:
- Figure 1. Warning of macros in malicious document. -
If the user allows execution and his/her computer is connected to the Internet, the macros will download the malicious code.
Through the tool OleVBA it is possible to see the content of the macro that is to be run, besides displaying the content it also has decoding options that make possible friendlier viewing.
- Figure 2. Macros seen from OleVba. -
The TLS versions that will be used in future communication with a possible C&C are laid out below by means of a base64-encoded statement through the PowerShell console.
After the macros are run automatically from the “Document_Open” function, the document downloads a file to the disk using a WMI object.
Downloading the malicious Emotet binary leaves an executable in the current path with the name “262.exe”. Said executable is moved to the following location, changing its name to execute it:
After a static analysis, it is possible to see certain information, such as the date on which the file was created, some APIs that handle the process’s memory and even the path and the project’s compilation name.
Running this sample on a debugger also identifies an attempt to load “taskmgr.exe” as if it was a library. Later, a routine is responsible for moving a large-scale array of bytes to a specific area of the executable code generated after the iteration with the VirtualAllocExNuma API. This code is wholly obfuscated, so another XOR-based decryption routine is needed to generate the payload in that section of memory.
Once the memory fragment is copied with the executable, a 35KB binary is seen. The static analysis of the file does not offer much information, since it shows compression patterns in its header, that is to say, it is possible that an application external to its compilation will modify the dimensions of the original executable. The only visible string in the interior of the executable is in some offsets belonging to the EOF of the file with the text “dave”. This again indicates that the binary was modified after it was compiled, since no known compiler writes information to that location.
- Figure 3. "dave" string. -
From the debugger, it is possible to see dynamic loading of libraries after using LoadLibraryW. This action is partly complemented by the following routine, which is responsible for deciphering the name of the libraries to be loaded.
Synchronisation events and mutex are created by using different names for each system on which it is run, since to generate this array the hard disk identifier VolumeSerialNumber is used, using the patterns “Global\\E%X”, “Global\\I%X” and “Global\\M%X”, also seen in other recent samples from Emotet. Thus, names of the following type are generated:
The installation of Emotet begins after the creation of the BWUnpairElevated folder in the following path:
/CALL to CreateFileW from SHELL32.75FC02EA |FileName = "C:\Users\incibe\AppData\Local\BWUnpairElevated" |Access = 80 |ShareMode = FILE_SHARE_READ|FILE_SHARE_WRITE|4 |pSecurity = NULL |Mode = OPEN_EXISTING |Attributes = NORMAL|BACKUP_SEMANTICS \hTemplateFile = NULL
The current file is later moved to the created location, using the name “shell32.exe” to complete its installation.
/CALL to MoveFileExW from SHELL32.761B267B |ExistingName = "C:\Users\incibe\Desktop\DUMP.exe" |NewName = "C:\Users\incibe\AppData\Local\BWUnpairElevated\shell32.exe" \Flags = REPLACE_EXISTING|COPY_ALLOWED
The binary then eliminates the zone identifier file, if it exists, using the following run syntax.
If you obtain execution privileges as the administrator, the copy of the executable is made in the same way but at the following location:
Finally, it is executed from the new location.
/CALL to CreateProcessW from DUMP.000534B3 |ModuleFileName = "C:\Users\incibe\AppData\Local\BWUnpairElevated\shell32.exe" |CommandLine = NULL |pProcessSecurity = NULL |pThreadSecurity = NULL |InheritHandles = FALSE |CreationFlags = 0 |pEnvironment = NULL |CurrentDir = NULL |pStartupInfo = 0034F96C \pProcessInfo = 0034F9B0
This process is the same, except for the installation; however, an entry is now included in the registry to be executed automatically after each startup. This is visible from a tool such as Autoruns or the system’s own msconfig.
- Figure 4. Persistence in the system. -
The following execution events will initiate the loading of cryptographic functions from the “rsaenh.dll” library, the “Microsoft Enhanced RSA and AES Cryptographic Provider”.
By using the API GetComputerName, it extracts the name of the infected system. In this case, “INCIBE-PC”. After being formatted using the string “% s_% 08X”, the word “INCIBEXPC_78C28DF8” is generated.
It then retrieves information about the system’s architecture using the API GetNativeSystemInfo, besides copying the name of the processes being run using the API Process32.
Once Emotet collects all the necessary information, it encrypts it using the public RSA key that it houses inside it. Once encrypted, the information is sent over the Internet using an HTTP request that begins with the load in memory of the following string
r\n--%S\r\nContent-Disposition: form-data; name=\"%s\"; filename=\"%s\"\r\nContent-Type: application/octet-stream\r\n\r\n
The string “%u.%u.%u.%u” is formatted, forming the IP address 18.104.22.168 after a decryption process. Moreover, the use of a random character generation routine is identified by using the RtlRandomEx function. With it, words are generated that end up being joined together in a sentence using the separating character “/”. A random URL is thus generated for each execution, with the aim of being difficult for Firewall/IDS systems to block it.
It makes this communication as a POST request pretending to be IE 7 on Windows XP.
Although an analysis of the downloaded modules has not been made, it was possible to identify part of Emotet’s behaviour during this action. As with the current executable, a binary was downloaded by it into the installation folder BWUnpairElevated.
The execution of the new module is done with the CreateProcess function as follows:
The text encoded in base64 corresponds to the initial execution location for the purposes of verification.
Once installed and in communication with its Command and Control server, EMOTET will be ready to execute the actions indicated to it on the computer.
During the analysis of this sample, no evidence of the infection procedure was found; however, the most obvious way to execute this type of attack is by mass sending of SPAM emails, without discounting the possibility of using any other means that allows the malicious document to be shared.
Protection against reverse engineering and detection
In the sample, various techniques used to avoid detection and reverse engineering of the file were found, specifically:
- concealment of macros,
- use of packer,
- different encryption routines,
- code compression,
- using base64 encoding,
- using a public RSA key.
Another type of protection that has been observed is the use of different RSA keys for each Emotet campaign, including the public key embedded in the malicious code, which is used to encrypt the information obtained from the system before sending it to the C&C responsible for communication with the infected machines. This tactic tries to avoid being noticed by firewalls that contain rules for other known versions of this threat.
During the import of the RSA key, said key was identified after the call to the CryptImportKey function. As shown in the following image, it is in the Hex/ASCII section with the header RSA1, which includes the use of the CryptoAPI.
- Figure 5. Upload of the public RSA key. -
Part of the configuration of the malware includes the installation paths and the name used for the process.
It also includes the names used for the registration key and the service to launch automatically after a restart.
Autorun Key Shell32 Service MSJET35
The RSA key and the IP address 22.214.171.124 are also Emotet-configurable items.
The following location is used by the malicious code to establish persistence in the system:
If administrator privileges are obtained, the creation of a service has been identified using the CreateServiceW API.
ServiceName MSJET35 CommandLine C:\Windows\system32\TabSvc\MSJET35.exe
Emotet is transmitted mainly by email, hence, special precautions must be taken when running any type of attachment or link from the mail, including those from known contacts, since Emotet can steal your identity.
Both urls and attachments can be analysed using tools, such as Virus Total or URLhaus. It is also recommendable to disable third-party macros by default, and to never enable it unless you are sure it is legitimate.
Emotet also uses known vulnerabilities, such as EternalBlue/DoublePulsar and brute force attacks, so you should always ensure your systems are updated to the latest available version and use strong passwords.
It is also possible to monitor possible sources of infection by using different indicators of compromise (IOC).
Detection and elimination
The Japanese CERT has published in its GitHub repository a tool called EmoCheck which aims to check whether the Emotet malware is present on the device.
If this software detects evidence, it will offer information for it to be disinfected, such as the name of the process, the process identifier and the absolute path where the malware is housed. In the event of infection, it is recommendable to terminate the process identified and to delete the malicious file.
It is also recommendable to scan the system with other antimalware tools.
For more information, you may look up the blog post ‘Preventing and disinfecting Emotet malware’.
A spike in the number of malware Emotet campaigns has been detected recently. Over the course of this blog post, the results obtained during the analysis of the malicious file are laid out in order to make known their nature and how they work. With this information, it will be much easier to be ready, both to prevent, and to detect and respond to this malware, in order to react and prevent its deployment in our systems.
As with other attacks based on social engineering, it is very important for the user to know of the existence of the threat and how it works, in order to recognise it in time and avoid being deceived, or to eliminate it if he/she has been affected.
INCIBE-CERT, as Spain’s National CSIRT for companies and individuals, has received data from users infected by Emotet, making this information available to those affected. Below, answers to frequently asked questions are provided as a summary:
Emotet is malicious software that infects computers and allows actions such as stealing information or installing additional malware with other functionalities (control of the computer by third parties, encryption of computers with ransomware, etc.), as detailed in the article.
INCIBE-CERT receives information from all over the world concerning infected Spanish computers, within the shared scope of action of collaborative and information-sharing activities that are carried out among various CERTs and also with external organisations. The data related to the Emotet infection comes from third parties external to INCIBE-CERT.
No, although in certain cases credentials associated with a website appear, the theft of these credentials has been carried out by means of an infected computer used by the user, the website has not been compromised.
- Check the logs of the system and your firewall, to verify whether the affected IP address makes connection to any of the addresses considered to be Emotet’s C&C.
- You can download the EmoCheck tool from the Japanese CERT to verify whether it detects the threat: https://github.com/JPCERTCC/EmoCheck.
- Consult the Indicators of Compromise of the threat: https://paste.cryptolaemus.com/.
- Run antimalware software such as MalwareBytes or any of those specified in: /ciudadania/es/servicio-antibotnet/cleaners.
INCIBE-CERT cannot carry out Emotet-related checks on private computers. Furthermore, it is not expected that any further information will be received about new infected machines or updates with respect to the status of the infection of those already reported. Although it is practically impossible to achieve absolute certainty that a machine is free of infections, we believe that the use of suggested tools accompanying an update to your database of threats should be to able successfully to eliminate the infections you may have. At all events, you can become more confident that the machine is free of infections by formatting it and reinstalling the latest software update you need on it.
It is possible that the information about the Emotet infection on your machine is old and that it was fixed at the time, or it may have been a false positive.
You have given me a list of users of my website that are infected, but I am running the antimalware on the server and I can't find anything
This casuistry may be due to the fact that, in reality, it is the users of your website who are affected, i.e. the list we have provided you with. We would be grateful if you could contact them to inform them of the incident and provide them with the recommendations we have indicated. Thank you very much for your cooperation.
Emotet binaries that have received the update will be automatically uninstalled on 25 April 2021, leaving the file quarantined in a temporary path for possible investigation on the infected system. However, this does not solve all security problems if as a result of the installation of Emotet other malware has been installed or data and/or passwords have been stolen from your computer. Even if this date has passed, we recommend that you still check your system with the EmoCheck tool and anti-malware programmes.