Our latest report exposing Emotet’s supply chain would not have been possible without custom-made tools, tailored to analyze the core Emotet component and the modules distributed by the botnet. One such tool is EmoLoad, a small but practical program to successfully execute Emotet modules in isolation. In light of its convenience, we decided to share the source code of this tool with the community on GitHub: .
EmoLoad will also be presented at BlackHat Arsenal in London on Wednesday at 3:30PM, December 7, 2022, on Thursday at 1:45 PM, December 8, 2022. BlackHat Arsenal is a space for researchers and developers to showcase the latest tools and products to the BlackHat attendees. We will demonstrate the tool in an open, informal environment. Feel free to stop by and ask your questions!
What is EmoLoad?
EmoLoad is a bespoke loader able to run Emotet modules. It allocates the required data structures, and invokes the custom entry point while allowing customization of the execution environment. It easily allows dynamic analysis without depending on the core module potentially infecting the system, thereby enabling security research tasks such as debugging, IoC extraction, or analysis of the resulting network activity (critical when analyzing Emotet modules that are able to propagate laterally). To further simplify analysis at scale, EmoLoad offers an option to embed the module and the loader together into a standalone executable, making it the perfect candidate for automated submissions to standard sandboxes.
Why Emotet?
Emotet is one of the most prominent multi-component threats in recent years. Besides the core component, which is often attached to a spam email or downloaded from a malicious URL, Emotet is known to retrieve from its C2 infrastructure additional modules; these modules can be either designed to propel its own operations by, for example, stealing email credentials to be used in future spam waves, or, when the attack is more targeted, engineered to be more a destructive artifact, like ransomware provided by an affiliated group.
These additional components are meant to be executed by the core module directly from memory, and they are never dropped on disk. Even when payload extraction using dynamic analysis techniques succeeds, loading the extracted modules in isolation inexorably fails as the existence of a custom entry point requires specially crafted data structures to be allocated in memory. These data structures are normally allocated by the core module for various purposes, with only a portion being required by the loaded module.
How to Use EmoLoad
EmoLoad can be executed as follows:
emotet-loader64.exe -d ${dll_path} -e ${epoch} [-c ${computer_name}] [-s ${root_serial}] [-o ${output_path}]
Where:
- ${dll_path} is the path to the Emotet module to be loaded (mandatory parameter).
- ${epoch} is the identifier of the epoch (i.e., a specific Emotet botnet) that the module belongs to; only identifiers to currently online botnets are supported, i.e., either 4 or 5 (mandatory parameter).
- ${computer_name} specifies the computer name; the tool generates a random computer name if this parameter is not specified.
- ${root_serial} specifies the C: volume serial number, which is a 32-bit hexadecimal number; the tool will generate a random serial number if this parameter is not specified.
- ${output_path} is the output file path when using the “-o” option; this option builds a standalone executable containing the module rather than loading the module.
Specifying computer name and root serial allows for the customization of the execution environment; while we have not seen any modules blacklisting specific computer names and root serials, Emotet modules contacting the botnet are known to get blacklisted based on specific values corresponding to known sandboxes. See below two examples:
Example 1: Loading a module (coming from the epoch 5 botnet) with computer name WIN-1234 and C: volume serial number 0x123ABC:
emotet-loader64.exe -d C:\path\to\emotet-module.dll -e 5 -c WIN-1234 -s 0x123ABC
Example 2: Embedding a module (coming from the epoch 5 botnet) into a standalone executable, with a random computer name and random C: volume serial number:
emotet-loader64.exe -d C:\path\to\emotet-module.dll -e 5 -o emotet-standalone-module.exe
In the last example, the resulting executable emotet-standalone-module.exe requires no parameters, and it will drop the original emotet-module.dll on disk and subsequently load it into memory; the computer name and the C: volume serial number will be generated automatically at each execution.
Practical Usage
To showcase how EmoLoad can support dynamic analysis, we perform in this section a quick analysis of two Emotet components:
- Thunderbird email client account stealer from epoch 5 (SHA1: 0a610c6de3419ce165d05d770637c8084d584ffd).
- Generic email account stealer from epoch 5 with embedded Mail PassView (SHA1: e43ab14163b01e2983bdc224a8c40cb08e20e297).
For each sample we create an executable bundle with the help of the “-o” parameter, and we submit each bundle to NSX Advanced Threat Protection (NSX ATP). The screenshots below are the output of the dynamic analysis process.
The Thunderbird stealer gets detected as Potentially malicious application/program (Emotet), as shown in the figure below.
Figure 1: The NSX ATP detects the Thunderbird stealer as Emotet.
As expected, as shown in Figure 2, the stealer is detected trying to access the current user’s AppData\Roaming\Thunderbird\Profiles folder, where Thunderbird saves personal information such as messages, passwords and user preferences. This is a clear indicator of compromise.
Figure 2: The NSX sandbox detects access to the Thunderbird’s profile folder.
NSX ATP triggers multiple detection rules on the generic email account stealer, such as Accessing Windows Protected Storage, Targeting Windows Saved Credential and Targeting Outlook Mail Password (Figure 3).
Figure 3: The NSX ATP triggers many detections on the MailPassView module.
Another behavior detected by NSX ATP is loading the pstorec.dll library, which contains a set of Windows Protected Storage APIs that can be used to retrieve website credentials stored by Internet Explorer, Outlook, and other applications (see Figure 4).
Figure 4: The NSX sandbox detects loading of the library giving access to Windows Protected Storage.
EmoLoad can also help and guide the reverse engineering process. For example, after loading EmoLoad into a debugger, and amending the command line as shown in Figure 5, EmoLoad will load the specified DLL as soon as you continue execution.
Figure 5: EmoLoad, loading the Thunderbird stealer, being debugged under x64dbg.
At this point it is possible to add a DLL breakpoint, so that after the tool loads it, one could put additional breakpoints on the specific functions of that DLL. For example, in Figure 6, the code stops at a breakpoint after retrieving the address of LoadLibraryW. It is then possible to trace the code a bit further to reveal the function, that is trying to call LoadLibraryW. All this would not be possible without EmoLoad, as the code would not even run if not properly loaded.
Figure 6: The Thunderbird stealer retrieved the address of LoadLibraryW (stored in RAX).
Conclusion
As a matter of fact, there are many cybersecurity vendors worldwide tracking Emotet at the moment. As a consequence, there are also many tools developed to analyze samples and techniques. We believe that collective effort is key to slow down the growth of this threat, which is the reason why we share EmoLoad with the community: https://github.com/vmware-research/emotet-loader.
We hope this will foster similar efforts from other researchers, ultimately leading to more freely available tools, more technical articles, and better defenses for our customers.