Emotet Malware Now Hacks Nearby Wi-Fi Networks to Infect New Victims

Emotet, the notorious trojan behind a number of botnet-driven spam campaigns and ransomware attacks, has found a new attack vector: using already infected devices to identify new victims that are connected to nearby Wi-Fi networks.

Emotet is a highly sophisticated trojan that typically also serves as a loader for other malware. A key functionality of Emotet is its ability to deliver custom modules or plugins that are suited for specific tasks, including stealing Outlook contacts, or spreading over a LAN. Recently, Binary Defense has identified a new loader type that takes advantage of the wlanAPI interface to enumerate all Wi-Fi networks in the area, and then attempts to spread to these networks, infecting all devices that it can access in the process

The newly discovered Emotet sample leverages a "Wi-Fi spreader" module to scan Wi-Fi networks, and then attempts to infect devices that are connected to them. The Wi-Fi spreader has a timestamp of April 16, 2018, indicating the spreading behavior has been running "unnoticed" for close to two years until it was detected for the first time last month.

The development marks an escalation of Emotet's capabilities, as networks in close physical proximity to the original victim are now susceptible to infection.

How Does Emotet's Wi-Fi Spreader Module Work?

Before getting into the analysis, Emotet’s Protocol should be explained. The protocol is based on Google’s Protobufs to serialize data sent to and from the server. The documentation for Protobufs shows that data is defined through the use of protocol buffer message types in a .proto file. While Emotet uses several of these “messages”, the one this analysis will be focusing on is the Deliverable message, which is used when the server sends a response containing data to be loaded/executed. The message is as follows:

message Deliverable {

    required int32 ID = 1;

     required int32 executeFlag = 2;

     required bytes blob = 3;

}

In the above protobuf message, ID is the module ID, blob is the binary data, and executeFlag determines how the binary loaded. The executeFlag field can be one of the following:

1: Reserved for payloads and standalone executables, like Trickbot. Drops in C:\ProgramData and executes.

2: Like Type 1, but duplicates user’s token.

3: Loads the binary into memory. Typically used by modules, as they are mainly DLLs which can be easily loaded into memory.

The updated version of the malware works by leveraging an already compromised host to list all the nearby Wi-Fi networks. To do so, it makes use of the wlanAPI interface to extract the SSID, signal strength, the authentication method (WPA, WPA2, or WEP), and mode of encryption used to secure passwords.

On obtaining the information for each network this way, the worm attempts to connect to the networks by performing a brute-force attack using passwords obtained from one of two internal password lists. Provided the connection fails, it moves to the next password in the list. It's not immediately clear how this list of passwords was put together.

But if the operation succeeds, the malware connects the compromised system on the newly-accessed network and begins enumerating all non-hidden shares. It then carries out a second round of brute-force attack to guess the usernames and passwords of all users connected to the network resource.

After having successfully brute-forced users and their passwords, the worm moves to the next phase by installing malicious payloads — called "service.exe" — on the newly infected remote systems. To cloak its behavior, the payload is installed as a Windows Defender System Service (WinDefService). In addition to communicating with a command-and-control (C2) server, the service acts as a dropper and executes the Emotet binary on the infected host.

Worm.exe is the main executable used for spreading. This executable has a timestamp of 04/16/2018 and was first submitted to VirusTotal on 05/04/2018. The executable with this timestamp contained a hard-coded IP address of a Command and Control (C2) server that was used by Emotet. This hints that this Wi-Fi spreading behavior has been running unnoticed for close to two years. This may be in part due to how infrequently the binary is dropped. Based on our records, 01/23/2020 was the first time that Binary Defense observed this file being delivered by Emotet, despite having data going back to when Emotet first came back in late August of 2019.

Upon startup of Worm.exe, the first action it takes is to copy the service.exe string to a variable that will be used during file spreading. Next, it steps into the main loop and immediately begins profiling the wireless network using wlanAPI.dll calls in order to spread to any networks it can access.

The use of purely wlanAPI.dll calls for network profiling makes sense; it is one of the libraries used by Native Wi-Fi to manage wireless network profiles and wireless network connections. A possibly unintended consequence of this is that researchers running this malware in VMs/automated sandboxes will not see any of worm.exe’s spreading behavior if a Wi-Fi card is not present. This can be bypassed partially by starting the WLAN auto config service in Windows 10; however, this only allows opening a handle to interface with. The subsequent calls will crash the program at that point, so the bypass is not recommended.

Once a handle has been obtained, WlanEnumInterfaces is called. This function enumerates all Wi-Fi devices currently enabled on the local computer, which it returns in a series of structures. These structures contain all the information relating to the Wi-Fi device, including the device’s GUID and description.

Using the first available Wi-Fi device, WlanGetAvailableNetworkList is called to obtain a list of all available networks. Interestingly, this has the dwFlag parameter set to WLAN_AVAILABLE_NETWORK_INCLUDE_ALL_ADHOC_PROFILES, which is an invalid parameter on Windows XP with SP3 and Wireless LAN API for Windows XP with SP2, meaning this malware cannot properly run on Windows XP.

Next, the malware begins profiling the network, saving the following information to a buffer:

SSID:               %s

SIGNAL:             %d

SECURITY:           [WPA|WPA2|UNKNOWN|WEP|OPEN]

encryption:         [UNKNOWN|WEP104|CCMP|TKIP|WEP40|NONE]

Note: [Current Connecting| OR

      WLAN_AVAILABLE_NETWORK_HAS_PROFILE| OR

      WLAN_AVAILABLE_NETWORK_CONSOLE_USER_PROFILE]

This information is gathered for every available network in the list of networks. Then, a massive switch case used to handle connection notifications is passed to the Wi-Fi device using WlanRegisterNotification. Finally, the network authentication method is obtained and encryption is parsed again. This can be one of the following:

• WPA2PSK
• WPAPSK
• UNKNOWN
• WEP
• OPEN

The encryption method can be one of the following:

• TKIP
• NOEN (None misspelled)
• WEP
• AES

once each the information for each network has been obtained, the malware moves into the connection, brute-forcing loops. The first step is to zero out two important flags and then to use the data obtained to fill in the below template that will be used to create the Network Profiles:

Once a connection is established with the Wi-Fi network, worm.exe begins enumerating users and attempting to brute-force passwords for all users on the network.

With the infected victim now connected to a new network, the malware begins enumerating all non-hidden shares on the network. Once shares have been discovered, the malware attempts to connect to the IPC$ share for the network resources. Using IPC$, it attempts to enumerate all users connected to the network resource. Using the second password list contained in the malware, the malware attempts to then brute-force its way into all users enumerated, saving each successful attempt to 2 buffers: one for the username and one for the password.

If it is unable to guess passwords for any users, it pivots to attempting to brute-force the “Administrator” account for the network resource.

If either of these brute-force attempts are successful, it then moves onto the spreader function.

With buffers containing either a list of all usernames successfully brute-forced and their passwords, or the Administrator account and its password, worm.exe can now begin spreading service.exe to other systems.

The malware first attempts to gain access to the C$\\ share for the connected network resource. This gives it access to the C drive of the specified username. From there, it drops service.exe as my.exe in C:\\. Additionally, it adds a new service with the following information using the recently dropped my.exe.

Binary Path Name: C:\\my.exe

Desired Access: SERVICE_ALL_ACCESS

Display Name: WinDefService

Service Name: Windows Defender System Service

It then starts this service, executing service.exe as my.exe on a remote system.

Service.exe’s startup is simple. It has a ServiceMain setup, which calls StartServiceCtrlDispatcher to connect the main thread of the service process to the service control manager, meaning the main thread is run when the service is executed.

In the main thread, service.exe starts a new thread, which serves two purposes:

1. Communicate back to a new C2 when the service is installed.
2. Drop and execute the Emotet binary embedded in service.exe.

After service.exe has installed itself and communicated back to the C2, it begins dropping the embedded Emotet executable. First, it obtains the path to %TEMP%, and concatenates “setup.exe” to the end of it. Next, it enters a function which locates the embedded executable by specifying a hard-coded buffer offset. Once the embedded executable is located, it creates a new file at %Temp%\\setup.exe and writes the embedded executable to this file. It then calls CreateProcess in order to create a new process running the Emotet Executable

The fact that Emotet can jump from one Wi-Fi network to the other puts onus on companies to secure their networks with strong passwords to prevent unauthorized access. The malware can also be detected by actively monitoring processes running from temporary folders and user profile application data folders.

Emotet: From Banking Trojan to Malware Loader

Emotet, which was first identified in 2014, has morphed from its original roots as a banking Trojan to a "Swiss Army knife" that can serve as a downloader, information stealer, and spambot depending on how it's deployed. Over the years, it has also been an effective delivery mechanism for ransomware. Lake City's IT network was crippled last June after an employee inadvertently opened a suspicious email that downloaded the Emotet Trojan, which in turn downloaded TrickBot trojan and Ryuk ransomware.

Although Emotet-driven campaigns largely disappeared throughout the summer of 2019, it made a comeback in September via geographically-targeted emails with local-language lures and brands, often financial in theme, and using malicious document attachments or links to similar documents, which, when users enabled macros, installed Emotet.

With this newly discovered loader-type used by Emotet, a new threat vector is introduced to Emotet's capabilities. Emotet can use this loader-type to spread through nearby wireless networks if the networks use insecure passwords.

With this newly discovered loader-type used by Emotet, a new threat vector is introduced to Emotet’s capabilities. Previously thought to only spread through malspam and infected networks, Emotet can use this loader-type to spread through nearby wireless networks if the networks use insecure passwords. Binary Defense’s analysts recommend using strong passwords to secure wireless networks so that malware like Emotet cannot gain unauthorized access to the network. Detection strategies for this threat include active monitoring of endpoints for new services being installed and investigating suspicious services or any processes running from temporary folders and user profile application data folders. Network monitoring is also an effective detection, since the communications are unencrypted and there are recognizable patterns that identify the malware message content.