Emotet: Catch Me If You Can (Part 2 of 3)

• Emotet is a highly modular banking Trojan that has a proper decision tree-based algorithm to perform designated tasks.
• Due to Emotet’s capability to deliver obfuscated payloads and extend its capabilities through self-upgradable modules, it has become a commonly-used payload launcher in targeted attacks on organisations. Emotet’s use in multi-stage and multi-vector attacks has given it its nasty reputation.
• Emotet’s operators have adopted a “malware-as-a-service” business model, where the Trojan is used to download and distribute other types of malware, such as ransomware.

This is in continuation of James Wright’s post on Emotet, where he explained the level of risk that Emotet poses to the enterprise. James details how Bromium can detect an attack delivering Emotet, which has been missed by other security tools.

Since its inception in 2014 as a banking Trojan, Emotet continues to evolve as a multi-component malware family. Over the years it has adopted a highly flexible code base, which now includes the following functionalities:

• Use of packers to evade malware classification
• Use of anti-analysis techniques
• Indirect execution of a payload to break process chain-based analysis
• Privilege escalation via launching payload as a service or by stealing administrator credentials
• Obfuscated code across stages of attack
• Use of multiple persistence mechanisms
• Encrypted imports and function names
• Multiple JMP instructions in code to confuse reverse engineering tools
• Self-upgradable modules
• Ability to move laterally within a compromised network
• Ability to make infected hosts send phishing email campaigns by stealing address books and credentials from web browsers and email clients

Sponsorships Available

Analysis

We have conducted the analysis of Emotet in three parts. Part one, as previously mentioned, can be found here. Part two breaks down the behavioral analysis of a phishing campaign delivering Emotet. In this post, we’ll take a deep dive into its ability to drop a payload by running an obfuscated VBA macro from a Microsoft Word document. Part three, coming soon, is a binary analysis of an Emotet sample, where we will explore how the malware works.

For this analysis we obtained a sample from a recent attack that was isolated by Bromium Secure Platform.

File: Receipt (1).doc

Dropper

The Emotet campaign here was being spread as a hyperlink, which downloads a Microsoft Word document. When opened, the document prompts the user to click ‘Enable content’. By default, if a document contains a macro or ActiveX controls, Microsoft Word prompts the user with a security warning. Typically, malware authors trick users into clicking the ‘Enable content’ button using social engineering to run the next stage of the attack.

In this case, enabling content causes the document to execute a VBA AutoOpen macro. As expected in Emotet VBA scripts, the strings are heavily obfuscated and include many fragmented strings. This is a well-known technique to make it harder for static analysis engines to detect malicious content.

We will walk through the script to find interesting patterns and deobfuscate the code.

Obfuscated AutoOpen macro

Variable ‘dBCwQQZ’ is defined with the string ‘winmgmts:Win32_Process’

Variable ‘TCXD_U’ is defined with the string ‘GetObject(winmgmts:Win32_ProcessStartup)’

Variable ‘jDD_UwDB’ is defined with the string ‘GetObject(winmgmts:Win32_Process).Create’

Sets the parameter of ‘GetObject(winmgmts:Win32_ProcessStartup).ShowWindow’ to a value of 0

Constructs the string ‘powershell -e’

We can see that the VBA script references WMI classes winmgmts:Win32_ProcessStartup and winmgmts:Win32_Process. On execution, the autoopen() Sub uses these WMI classes to launch an instance of PowerShell that runs a Base64 encoded command in the background.

Indirect Execution

Base64 encoded PowerShell command viewed in Bromium Controller

Since the macro uses WMI to run PowerShell, the process is launched in the background using WmiPrvSe.exe (WMI Provider Host). By executing PowerShell this way, malware authors can evade process chain-based detection.

As explained in our article about evasion techniques used by Ursnif, this is a known technique to launch PowerShell from a macro using a legitimate Windows process. Bromium detects this type of indirect execution and attributes any related process creations to the original executable responsible for running the malicious VBA code, in this case WINWORD.exe.

Obfuscated PowerShell command

After decoding the Base64 encoded string, the output in the image below is produced. The command is obfuscated using the same string joining and case mismatch techniques to make it harder for an analyst and scanning engines to understand.

The decoded string contains a ‘+’ character, which is used to join strings, and a mixture of upper case and lower case characters

One can simply remove all ‘+’ characters to reveal the deobfuscated command.

Command output after removing all of the ‘+’ characters

The above PowerShell command deflates and decodes a Base64 encoded string and reads it as a stream until it reaches the end of the string. It then runs the resulting output in memory using the ‘iex’ alias for the Invoke-Expression cmdlet, another popular technique among malware authors to execute commands. In order achieve this, it used the variable $Verbosepreference which contains the string ‘SilentlyContinue’. The first and third characters (‘i’ and ‘e’) are selected from the string, which are then joined with ‘X’, to form the string ‘ieX’.

Formation of the string ‘ieX’, which is the alias for the Invoke-Expression cmdlet

Deobfuscated PowerShell Script

The deobfuscated PowerShell script first splits the string assigned to the variable $XXQCZAxA using the ‘@’ character as a delimiter and then enters a ForEach loop, which iterates the resulting array of URIs to download an executable to the victim’s filesystem using the Net.WebClient class. The script uses the environment variable $env:userProfile to fetch the user profile directory of the currently logged-in user. The downloaded file is saved to the victim’s user profile directory (e.g. C:\Users\[Username]) with the filename ’15.exe’. If the size of a downloaded file is greater than 40KB, the script exits the ForEach loop and runs ‘15.exe’ using the Invoke-Item cmdlet.

Deobfuscated PowerShell command

HTTP GET request

As you can see from the screenshot below, the PowerShell command sends a HTTP GET request to retrieve the first-stage Emotet executable from hxxp://dautudatnenhoalac[.]com/wp-admin/DYAsI. The response from the web server indicates that the file served is called ‘s17zjCTuWfNF.exe’ and that the payload is a PE format file as indicated by the ASCII representation of the magic bytes 0x4D5A (‘MZ’) at the start of the file.

HTTP GET request, which downloads the first-stage Emotet payload

Behavioral Analysis

After downloading the payload, PowerShell runs ’15.exe’ (PID: 2600). The process then launches another instance of ’15.exe’ (PID: 2412) from the same location.

Process launch of 15.exe by PowerShell

The second instance of ’15.exe’ (PID: 2412) copies itself to the C:\Windows\SysWOW64 directory with the name ‘ipropmini.exe’. It then creates a service where the BinaryPath points to C:\Windows\SysWOW64\ipropmini.exe and the DesiredAccess is 18. DesiredAccess ‘18’ grants SERVICE_CHANGE_CONFIG and SERVICE_START access permissions to the service.

Service creation to establish persistence

Launching a binary through a Windows service is a popular technique for several reasons. First, it breaks process-chain based detection and second, upon the start of the service, the binary is always executed even though it is not a valid service executable.

The executable ‘ipropmini.exe’ (launched by services.exe) spawns another instance of itself which then downloads the next stage payload from the Internet. Afterwards, the executable performs process hollowing on the first Emotet process (‘15.exe’), where modified code is written.

Process Hollowing on first Emotet process ’15.exe’ (PID: 2600)

When left to run, Emotet downloads more payloads from remote servers and spawns several processes and collects system information and sends it through an encrypted channel to a command and control (C2) server.

Process interaction graph as viewed in Bromium Controller

High severity events raised during the Emotet infection lifecycle

HTTP POST request

Emotet sends system-related information to C2 servers using HTTP POSTs and receives further commands and payloads from the servers as a response.

HTTP POST requests to C2 servers

Indicators of Compromise (IOCs)

The post Emotet: Catch Me If You Can (Part 2 of 3) appeared first on Bromium.

Recent Articles By Author

• Ransomware Goes Fileless, Uses Malicious Documents and PowerShell to Encrypt Files
• Reawakening of Emotet: An Analysis of its JavaScript Downloader
• Agent Tesla: Evading EDR by Removing API Hooks

More from Ratnesh Pandey

*** This is a Security Bloggers Network syndicated blog from Bromium authored by Ratnesh Pandey. Read the original post at: https://www.bromium.com/emotet-analysis-catch-me-if-you-can/