The recent Wannacry and Petya outbreaks have demonstrated the potency of ransomware coupled with a propagation component (spreader). While typical ransomware infections lead to the denial of access of data on a single victim system, it becomes an enterprise threat when it can propagate out, via mounted shares or the use of exploits (WannaCry – EternalBlue/MS17-010) or even both (Petya).
It stands to reason that crimeware authors have taken note of the broad impact observed in these particular events and are looking to incorporate spreader components in their toolkits. This post describes our observations of such techniques in the Emotet loader.
- Emotet is a loader that has been observed in multiple campaigns globally, originally focused on credential theft but also seen to have delivered banking trojans.
- In recent months, Emotet has been seen using spam for propagation using some basic but effective social engineering techniques.
- Fidelis Threat Research has observed Emotet samples that have internal network propagation capabilities built in. This greatly adds to the potential impact of the loader.
- The propagation techniques mostly rely on credential brute-forcing but this points to intent of the actors involved. The Wannacry and Petya campaigns have clearly demonstrated how inclusion of other techniques like credential dumpers (Mimikatz) and exploits (EternalBlue) can greatly accelerate propagation across enterprises.
- The Fidelis platform detects, validates and automatically responds to Emotet across the stages discussed in this paper.
Indicators of Compromise as well as the password list used in the brute force attack are made available with this post. We advise enterprises to scan for these IOCs as well as ensure that these passwords aren’t in use within the environment, especially on privileged accounts.
Emotet, like many other crime malware, utilizes a crypter to protect itself from detection and make reverse engineering efforts more complicated. The Emotet variant analyzed here was found to be using a crypter also leveraged by MAN1 for Chanitor deliveries.
Emotet is a delivery mechanism for other malware (“loader”). It is sometimes referred to as Emotet/Geodo together, but the recent version of Emotet is distinct having moved to delivering many different banking trojans. Emotet has greatly evolved over time with its recent evolution being excellently explained in a post by Cert-PL(1). This latest version of Emotet does not appear to be pushing Geodo. Emotet instead distributes payloads by geolocation, which are not packed using the same packer as previously seen. Emotet payloads can also be delivered as standalone executable files, which indicates the files aren’t compiled as part of the same framework, but instead are pushed by the actor utilizing Emotet as a loader.
Emotet Network Spreader
For over a month now we have had speculations that Emotet had a network spreader component, a technique that has recently gained in popularity for using leaked exploits involving the worming of multiple forms of malware(documented here, here and here) that it was using primarily to spread in internal networks with some notable exceptions scanning the internet as well. Tracking the Emotet deliveries over time, we finally discover a very odd standalone executable which is actually a self-extracting RAR file containing two files.
The bypass component is responsible for enumerating network resources to find shares that it can write to or trying to brute credentials so it can write. After finding available systems it then writes the service component and creates a service on the remote system.
The service component is responsible for writing Emotet to disk and then executing it while also making a callout to a hardcoded URL with the computer name as the POST request data.
One interesting note is the difference between this package and normal Emotet modules in which the modules are typically wrapped in a layer that resembles Emotet code including having their own onboard RSA public key and C2 IP addresses. On the other hand, this spreader package is not wrapped in such a manner, so it could simply be a package delivered by one specific actor or group utilizing Emotet and not a direct component of Emotet itself.
What follows is a description of each piece of this spreading component.
Spreader bypass component
The bypass component enumerates network resources looking for servers and for each one it finds will try to brute the user accounts and the Administrator account for IPC$ (5).
When the resource is passed off to another function it is checked that it is a server by decrementing the dwDisplayType field of the passed in NETRESOURCE structure by 2.
Next it makes sure the resource it’s looking at isn’t associated with the current computer by doing a simple string comparison against the remote name.
After those checks are complete then a connection is attempted to the IPC$ share.
If the connection fails then the program will attempt to enumerate the normal user accounts with NetUserEnum. With a list of usernames in hand it will then attempt to brute the passwords for each user with an onboard password list.
If no successful accounts are bruted then the program will attempt the password list against the ‘Administrator’ account.
If an account is bruted out the program will then copy the service component over to the remote computer and add a new service using the account.
In the analyzed sample the remote service created is “Windows Defender System Service” and functions to start the C:my.exe program which would be the service component copied over. After all network resources have been enumerated the program simply exits.
Spreader service component
The service component is fairly simplistic as it’s just a generic service project that was designed to write an onboard executable file and perform an http request. The main thread of the program maps out very nicely.
So immediately the gist of this program can be derived after mapping out only 2 routines. The first function is simply to write an exe file and then execute it which is a common activity for a ‘Dropper’ malware.
Upon success of that function, the program will get the current computer name and write it into the format string ‘c=%s’ which can also be seen in Figure 10. This data is then passed off to a function that will perform a POST request to a hardcoded IP using an hardcoded URI on port 7080.
This feature is probably a quick way to track spreading statistics by sending off the computer name. Using a port number like Emotet C2 traffic brings us back to our original speculation of this being potentially a test package for a spreading component related to Emotet itself or a package related to a specific actor. Proving such speculation will of course require further research.
With the recent addition of spreading capabilities being added to ransomware it’s not at all surprising to see other malware families start to look into adding similar capabilities. It seems to be a common trend lately for malware developers to add in functionality based on what’s in the news which recently has been filled with all things wormable, which could mean this might be a continued trend for malware in the future.
|e3c4e5f0700ff6c0f7b2c4711e1cc6b8||SFX Pkg MD5|
|8d8b45aa8724458ea7711f13ee237bbd3e4c77669ebd91109b94620ecc52bc72||SFX Pkg SHA256|
|C:my.exe||Spreader File Activity|
|%TEMP%setup.exe||Spreader File Activity|