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 220.127.116.11 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 18.104.22.168 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.