Emotet’s arrival is usually preceded by a deceptive spam email, which has a malicious attachment. Opening the attachment starts a process which can lead to an Emotet infection.
The Emotet application is an evolved binary, in the sense that it has gone through thousands of iterations over its existence. Its presence as a vehicle for attacks is virtually ubiquitous, almost to the point that security researchers and analysts treat it as “boring,” though it certainly is not, and in any case, would still pose a serious danger to the computer or network it has penetrated.
The Emotet executable follows a well-worn routine when it executes for the first time on a victim’s computer. In the initial setup routine, Emotet makes copies of itself into fixed, standard locations on the Windows filesystem, generating filenames based on values unique to the system and a table of name fragments it pulls from itself, and generates a mutex for itself that follows a predictable pattern.
The main goals of Emotet are to gain persistence on the infected machine, collect a wide range of information about the victim from the machine, and then download payload modules from the C2 designed specifically to take greatest advantage of the victim’s profile or device. But it does so using techniques that also seek to subvert the work of reverse engineers or analysts who fight against it.
Emotet’s paranoia and persistence
The creators of Emotet appear to have spent a lot of time profiling the behavior of malware sandboxes and the other tools a malware analyst might use to tear their malware apart. The creators have used this knowledge to devise a series of schemes the malware uses to ensure that it is running on a real machine, and hasn’t been tampered with.
The Emotet executable is packed in a way that makes it hard for analysts to perform a static analysis; The malware has been packed by its own (quite sophisticated) packer, which itself has been packed in multiple layers of obfuscation. The result is that, among other things, the static Emotet file doesn’t have an Import Address Table, which would otherwise provide important clues about the locations in memory from which the malware will run its own functions or call functions from imported DLLs (plugins).
All of the imported APIs are encrypted, so it decrypts them. It loads the functions from Windows DLLs (eg., advapi32.dll or shell32.dll) dynamically.
All the while, Emotet continuously runs through several “junk functions,” or subroutines that serve no purpose other than to misdirect an analyst, and uses junk strings to complicate the analysis further. The malware may use these embedded, random-looking text strings to determine whether it has been tampered with: The malware compares those strings to values stored in memory. If they don’t match, the malware quits. If they do, it goes on to create new events and mutexes, and continues to run.
Upon initial execution, the Emotet executable makes a copy of itself from the %temp% directory (where the PowerShell script normally saves it to the victim’s hard drive) in a standard Windows location, such as the C:\Windows\SysWOW64 directory, and creates a mutex that starts with the letter M and is followed by a string hash value. It also creates events that start with the letter E followed by a string hash value. The string values in the mutex and event names are made up of the current process identifier value (PID) and its child PID.
The malware always unpacks two instances of itself into memory while the setup phase is ongoing, with one instance watching the other’s back. When the malware has finished its initial setup, it sends a signal that closes both these watchdog processes, but not before injecting itself into the memory space of other running system applications (such as svchost.exe). When setup is complete, the malware deletes itself from the hard drive.
After this initial setup, the behavior of the processes are also determined by the mutexes and events. Emotet uses these to check whether a child process (such as a plugin) is running as a result of being launched by the malware’s process. For example, as the first process created a Mutex of its PID and its parent PID, when the second copy of Emotet (the first Emotet’s child) process creates a mutex with the same parent process, the GetLastError function returns a value of 0xB7 (ERROR_ALREADY_EXISTS), and it and any subsequent Emotet instances self-terminate.
So the malware uses the mutex and event values for multiple reasons. As with many other malware, any Emotet sample will look for the presence of the mutex when it first starts up to prevent multiple copies from running on the infected computer. However, it also sets up a process by which it periodically queries for the mutex, and if it doesn’t find it, will use that to restart the initial malware executable.
Emotet also uses Scheduled Tasks and other more conventional methods to trigger itself to run after the host computer powers off or reboots. It’s also known to set up a Windows service that will keep the main Emotet executable alive.
Hiding in plain sight
Emotet queries a Windows value called GettickCount any time it calls an important function. This GettickCount behavior looks like the malware is checking how much time has elapsed since the system started, or since the Emotet payload launched, as a sort of sanity check. It may use this to determine whether it is running in a sandbox, because some sandbox software may “skip” ticks in order to trigger malware that runs on with a built in, timed delay to begin operation.
The malware generates hash values for all the currently running processes, then performs a hash comparison against them, to determine if debugger or analysis tools are also running on the infected system.
In some cases it also creates global Mutexes and Events from the file system, and generates the mutex and event names using the information it can glean from the volume serial number information (specifically, the lpVolumeSerialNumber argument from the GetVolumeInformationW function call).
These typically follow this naming convention:
Mutex names: Global\I<volume serial number>, Global\M<volume serial number>,
Event names: Global\E<volume serial number>
The executable creates a copy of itself in a location on the filesystem that’s determined, in part, on these serial numbers. Emotet uses its own table of words and phrases, embedded in the malware executable and decoded at runtime. The mixture of these strings can result in the malware generating a realistic-looking name that closely resembles legitimate software. For example, the malware may combine two or more of the following string fragments (subject to change, as they have been extracted from a recent Emotet version) to build the filename:
not,ripple,svcs,serv,wab,shader,single,without,wcs,define,eap,
culture,slide,zip,tmpl,mini,polic,panes,earcon,menus,detect,form,
uuidgen,pnp,admin,tuip,avatar,started,dasmrc,alaska,guids,wfp,
adam,wgx,lime,indexer,repl,dev,mapi,resw,daf,diag,iss,vsc,turned,
neutral,sat,source,enroll,mfidl,idl,based,right,cbs,radar,avg,wordpad,
metagen,mouse,iprop,mdmmcd,jersey,thunk,subs
So, depending on the volume serial number of the machine, the malware may name itself “adminstarted.exe” or “avatarshader.exe” or any other combination of string fragments from the internal list.
Phoning home, collecting information, and other routine functions
The malware creates a hidden program window in order to run malicious code periodically. The window name, like the mutexes and events, follow a predictable naming convention that embeds the volume serial number of the infected host, such as LDWCN<volume serial number>. The hidden window is created using a parameter that instructs the malware to call whatever function is the window’s purpose once every second. It does this in order to perform routine tasks, like collecting information, sending information to the C2, or reading the response from the C2.
For example, in this Emotet sample, the tick timer triggers one of a number of different functions:
- case 1: It loads some DLLs in order to process the following operations: It moves the Emotet binary to the system32 folder, writes it using the dynamically generated naming convention, creates a service, and launches it.
- case 2: Load the suspicious DLLs (the list of which are stored in the form of hashes)
- case 3: Collect information and communicate with the C2 server
- case 4: Exit.
The malware periodically collects the names, and generates hash values, of all the running processes on the system. It checks itself regularly to ensure that it was the parent of the main Emotet application or its plugins. It collects details about the operating system, processor type and architecture, the volume serial number, and other unique identifiers.
Emotet communicates with its command and control servers through nonstandard, encrypted methods, which we’ll talk about in detail in our next chapter.
Acknowledgments
SophosLabs researchers Krisztián Diriczi, Roland Gyorffi, Hajnalka Kópé, Luca Nagy, and Gábor Oravecz contributed to this section of the report.
