Executive Summary

Emotet, a banking trojan turned downloader, continues to make waves in the downloader scene despite recent hibernations. Emotet is a modular malware, first reported in 2014 as a banking trojan that quickly evolved into its current modular form which supports everything from spamming to theft of emails, propagation using worm-like exploits, and even incorporates the notorious Trickbot malware as a module.

In May 2019, Emotet’s activity started to decline. This hiatus lasted for approximately four months when it made a resurgence in September 2019. The activity picked up as if it never left with evolving spam campaigns and new delivery mechanisms. Its evolution brought many changes and innovation which we explore in this report.

NOTE: NETSCOUT AED/APS enterprise security products detect, and block Emotet activity using our ATLAS Intelligence Feed (AIF).

Key Findings

Emotet shares obfuscation techniques with Trickbot, further cementing their symbiotic relationship.

Emotet authors use a new list of words to generate process names and keep track of installed modules.

A new export function now appears on Emotet binaries, which is unusual as these are usually consistent with DLL files rather than an executable.

Overview

Packed Binary

In the recent samples, the executable binary files now include an export function, consistent in style with both Emotet and Trickbot binaries. Below are two of the observed export names used:

DSAXZCTYHJKIOP

Run

The packed binary resolves API names by iterating through the export list of loaded DLLs attempting to find APIs using the hash of the API name. A similar style and order of resolving for the API calls is seen in the packers by both malware families (Emotet and Trickbot) (Figure 1).

Figure 1: Packed code with same API hashing. Left: Emotet, Right: Trickbot

Next, the packed binary checks for a string present in its resource section. Using the API LoadStringA, it passes a uID to retrieve the string from the resource section (Figure 2). The string itself is a file path. If the current path of the file execution is not in this path, the packed binary will copy the file to the path and execute it from there.

Figure 2: Function that calls LoadStringA

During analysis for one particular investigation, the uID of the string was present for the Trickbot packed binary and not in Emotet’s packed binary. This could mean that the operators use a builder or kit to pack the binaries prior to distribution; and that the adversaries packaging the malware chose to remove options/features like running the file from %PROGRAMDATA% despite the fact that the malware still checks the location.

Following that check, there is a long list of BASE64 strings that the packed binary concatenates in an allocated memory region (Figure 3).

Figure 3: Long list of BASE64 strings

The malware passes the concatenated BASE64 strings into the API CryptStringToBinaryA with the flag set to CRYPT_STRING_BASE64. Afterward, the malware copies the converted bytes over to a memory region allocated by the API VirtualAlloc. Using the API LoadStringA, the packed binary loads another string which functions as a key to XOR the bytes (Figure 4). After the bytes are XOR’ed, we see the typical Emotet loader code. Similarly, we see the same code in packed Trickbot binaries.

Figure 4: Packer Routine

Loader

The loader (Figure 5) remains unchanged since before the Emotet resurgence in September 2019.

Figure 5: Loader Code in memory

At the end of the PE file in memory is a string “dave” (Figure 6). the loader does not reference the code and it is unclear if it plays any significant role. However, it is consistent with previous versions of the malware and useful for creating signatures to identify Emotet malware.

Figure 6: String "dave" seen in memory

The last phase of the loader places the PE file in an allocated memory region and resumes execution.



Main Payload

Emotet’s main payload continues to use its previous techniques, which may suggest that it is quite successful in avoiding detection.

Portions of the Emotet malware almost always change from version to version, such as the C2 list and RSA key, but one notable change includes the list of words used to create a predictable process name for its bot. This list of words is essential for the C2 to track the progression of the bot’s update and module installation.

When Emotet first came back in September 2019, it contained the following list of words used for building process names:

chunk,counter,drawa,isve,two,next,mapi,rtapi,nlsdl,defs,tenant,rstrt,window,machine,mira,system,stream,cursor,structs,history,watched,hash,report,program,durable,offc,rsat,folders,shell,yellow,sounds,adjust,toner,tlb,sorted,loop,post,txt,icons,intel,inset,move,reports,trc,based,wim,lumber,violet,dom,easy,cvt,center,even,readand,xinput,mem,cues,layer,tools,wfd,running,mail,gesture,misc

Fast forward to today, and the malware now uses the following list of words for building process names (Keep in mind these list of words updates with newer binaries):

engine,finish,magnify,resapi,query,skip,wubi,svcs,router,crypto,backup,hans,xcl,con,edition,wide,loada,themes,syc,pink,tran,khmer,chx,excel,foot,wce,allow,play,publish,fwdr,prep,mspterm,nop,define,chore,shlp,maker,proc,cap,top,tablet,sizes,without,pen,dasmrc,move,cmp,rebrand,pixel,after,sms,minimum,umx,cpls,tangent,resw,class,colors,generic,license,mferror,kds,keydef,cable

The bot acquires the volume ID of the machine using the API GetVolumeInformationW and uses the returned value to generate a process name from the words list above.

Below is the pseudocode of the process name generation.

for _ in range(2):

index = volumeID % len(words)

volumeID = ~(volumeID / len(words_1))

start = words.rfind(',', 0, index) + 1

end = words.find(',', index, len(words))

name += words[start:end]

return name + “.exe”

Using the list of potential process names, analysts and researchers can create signatures to hunt for possible Emotet infections on machines.



Statistics

Since returning to operation in September, nearly every day yields a newly compiled Emotet packed binary showing the continuous updates by the malware authors. Each binary contains approximately 40 to 80 C2 indicators. This list does not include the C2s seen in some of its plugin modules. Even after its return, the number of Emotet binaries in the wild remains much lower than previously seen(Figure 7).

Figure 7: Binaries observed after Resurgence

Though the binaries ebb and flow, the number of C2s in the wild remains fairly consistent since September 2019 (Figure 8).

Figure 8: Binaries (bar graph) and unique C2 count (line graph)

We also track the location of the Emotet C2 servers and though some places have heavier concentration, it doesn’t appear overwhelmingly isolated to any particular region (Figure 9).

Figure 9: Distribution of C2s since resurgence

Conclusion

The evolution of malware in the crime world evolves at a rapid pace. New features, modules, and techniques emerge with startling frequency resulting in the need for a fresh look and analysis of those changes and capabilities. Observing changes in the way Emotet malware authors pack their binaries, other distributed malware, and alter the configuration data to defeat signatures showcases the aggressive behavior of the malware authors. It ensures that not only their binaries avoid detection, but that of their distributed malware as well making this a very effective operation that persists despite efforts to eliminate the threat posed by Emotet.

IOCs