Emotet seen distributing bloated files to evade detection

• The SonicWall Capture Labs threat research team has once again observed a surge in Emotet. This the notorious malware, which heavily targets large organizations, uses similar tactics and functionality observed in past variants. Originally a banking Trojan, Emotet has evolved into a dropper-type class of malware. It has been been spreading through malicious Microsoft Office documents via email. Initially it was using Excel 4.0 macros(XLM), currently VBA macros are used to compromise the victims’ machines. Also, this time it is using large file size (Approx. 538 MB) for evading scanners. File size is increased due to padding of extra null bytes which are basically useless.

INFECTION VECTOR

The initial infection vector is a phishing email which has office document attachment. This document file has obfuscated VBA macros. By default, the Document file is opened in protected view, with the macros disabled. To evade this, Emotet document files have one image with instructions (Figure 1) asking user to enable content. Once the user enables the content the macros are then executed in background.

SHA256: 2d59e4dbfa860a68e014227f6bd9c13945d0d474b2d183c2f07e2c7a4864b24c

Fig 1 : Office document in protected view with macro disabled

Fig 2: obfuscated macro in office document file.

Inside the document file, there are multiple macros which have various obfuscated functions and variable names. After debugging this macro, we were able to de-obfuscate the macros and successfully extract all the URLs which are responsible for downloading the payload.

Fig 3: After de-obfuscating macros, we can see all URL which download Payload.

URLs inside document file:

• hxxps://baumart[.]lv/wp-admin/S8jHW33QU77gLz/
• hxxp://beyond[.]psiloveyou[.]co[.]za/dR05Bvq90dvlsVBzn/?135641&c=44
• hxxps://lisaerp[.]com/ncsA/g7zWosP/?135641&c=44
• hxxp://3313v[.]com/ki7xh/QpSQfw9CPTFtNs4/?135641&c=44
• hxxp://www[.]dnautik[.]com/wp-includes/UmAJjAP/
• hxxp://melkovsky[.]com/advice/ZRSaP7QA5yTv1fZs/

These URL downloads the archive file which contains a DLL file.

SHA256: 8a674295c02e40a8bb1518752bfe3e4533eb81b5abb2efbd399dd1681d7b82ad

Fig 4: DLL after Extracting Archive.

Fig 5: Appended Null bytes.

This file is a bloated Emotet DLL file by appending null bytes at the overlay, actual PE size of file is in few hundred KB’s, but since null data appended at the end of file, file size increased up to few hundred MBs. (Here actual size is 667 KB and blotted file size is 538 MB)

DLL Analysis:

Encrypted shell code and encrypted PE file are embedded within the resource section of the binary. Encrypted PE file size is of 0x2B000 bytes.

Fig 6 : embedded encrypted PE file and shell code blob in resource.

It uses “LdrFindresource_u” API to find encoded resource data and LdrAccessResource API to fetch the contents of a resource data. It calls NtAllocateVirtualMemory to allocate memory so it can decrypt shell code and payload in memory. Malware uses hardcoded 0x3B size of decryption key and customized decryption loop to decrypt payload PE file and shell code.

Fig 7 : Decryption Key

Fig 8 : Decryption Loop to decrypt actual payload embedded in resource section

Once it completes the decryption of shell code blob then it transfers execution control to this shell code using NtQueueAPCThread and NtTestAlert. NtQueueApcThread is used to queue an APC to the current thread pool, here shell code is added as an APC to current thread.

NtTestAlert is a system call that’s related to the alerts mechanism of Windows. This system call can trigger execution of any pending APCs that thread has. Once NtTestAlert API gets called shell code will start executing.

Fig 9 : Transfers execution control to injected shell code

Following is a snapshot from the shell code blob where we can see strings has been pushed to stack which will be later used to resolve API addresses dynamically.

Fig 10 : start of shell code

The task of shell code is to map the DLL file in virtual memory the way process aligned in memory and start the execution of actual payload DLL.

Fig 11 : Execution of shell code started

Malware uses API resolving functionality where it passes hard-coded checksum of API to stack or to a register and then compute checksum from the combination of DLL name string and API name. If the checksum matches it found the name of API that it wanted to use. In Fig 11 we can see 0xBDBF9C13 which is checksum DWORD used to resolve API “LdrLoadDll”.

Following are steps It follows:

• Pushed hardcoded Hash to register (or it would be pushed on stack )
• Call API resolver Function.
• Access PEB structure.
• Access PEB_LDR_DATA from PEB structure which is at 0x18 offset in PEB.
• Access InLoadOrderModuleList from PEB_LDR_DATA which is at 0x10 offset in PEB_LDR_DATA
• Using InLoadOrderModuleList it accesses address where DLL got loaded in memory and its wide character name in memory.
• It checks if export directory is present in loaded module, if not then move to next loaded module in list.
• If export directory present, then it calculates the checksum with the DLL name.
• It traverses loaded DLL file in memory, to access export directory and access function names RVA and add this RVA to base address of DLL.
• It goes to last exported function name by multiplying NumberOfNames (Function Counter ) and adding function name RVA .
• Then One by one it accesses every API name and calculates the checksum of API Name.
• It finally adds API name checksum to DLL name checksum and compares with previously pushed hard-coded DWORD value, if it matches then malware gets API name otherwise enumerate all loaded DLL in memory.
• If malware gets API name, it accesses exported function and read the RVA of exported Function. Then it adds RVA to the base address of DLL where it was loaded, this way it resolves all API addresses dynamically.

After resolving LdrLoadDll it resolves LdrGetProcedureAddress API using hardcoded DWORD checksum  0x5ED941B5h.

Fig 12 : API resolver Function which takes Hard-coded DWORD HASH and resolve API address.

Fig 13 : API resolver Function where traverse export directory of every module

It uses LdrLoadDll and LdrGetProcedureAddress to resolve following API. All this API names has been pushed on to the stack at the start of shellcode execution.

• VirtualAlloc
• LoadLibraryA
• VirtualProtect
• GetNativeSystemInfo
• RtlAddFunctionTable
• FlushInstructionCache

These APIs will be used to map payload DLL in memory so it can start its execution.

DLL Mapping Functionality In memory

• It enumerates the section header from payload DLL file to calculate size of Image which would be in memory for DLL payload. Basically, it adds Virtual Address of each section to Raw Size of that section.
• It allocates Memory to map DLL in memory using VirtualAlloc API then it copies first 0x400 bytes decrypted Payload DLL but it skips DOS header while coping first 0x400 bytes to newly allocated memory.

Fig 14 : copy payload header data without DOS header and without string  “This program cannot be run in DOS mode”

• It moves each section of Payload DLL file in newly allocated memory each section on new page.
• It changes memory protections of each section.

Fig 15 : changes protections of each section of mapped DLL in memory

• Finally, it calls RtlAddFunctionTable to add dynamic function table to the dynamic function table list and call FlushInstructionCache API to make changes permanent.
• It parses loaded DLL file and find out entry point of it at the start execution of DLL from Address of entry point.

It simply comes out of main entry of payload DLL and starts executing “DLLregisterServer” function from main DLL file. “DllRegisterServer” from main DLL (not the mapped payload DLL), there is “DllRegisterServer” function in injected payload as well. Objective of this function to check whether exported function of injected payload is “DllRegisterServer” or not. To check whether exported function is “DllRegsiterServer” it calculates the checksum of string “DllRegisterServer” and check with hard-coded DWORD checksum, if matches then continue its execution otherwise exits. It transfers execution to “DllRegisterServer” from the payload DLL.

Fig 16 :  check exported function is “DllRegisterServer” from injected payload DLL

Payload DLL file

It decodes all necessary DLL names which needs to be loaded.
Following are DLL which are loaded by payload.

• bcrypt.dll
• crypt32.dll
• shell32.dll
• shlwapi.dll
• urlmon.dll
• userenv.dll
• winhttp.dll
• wtsapi32.dll

It loads all DLLs from above list.
API Resolve Functionality in Payload DLL
It resolves windows API Address of from the hardcoded DWORD checksum and it uses almost similar functionality as is used while resolving LdrFindresource_u, LdrAccessResource in main DLL.
The difference here is for every API it passes two hardcoded checksums, one for DLL name and another for API name while previously it was passing single DOWRD checksum ( combination of DLL name and API name )

It Access PEB structure and get the InLoadOrderModuleList by traversing PEB structure and then access Name of DLL , it calculates the checksum for every DLL and matches to passed DWROD checksum.
For e.g. it compares with hard-coded hash 0xAA83E8EA to find out loaded base address for kernel32.dll
If it resolves Base address for DLL, it enumerates export directory of each loaded DLL and calculate checksum of API name and compare with hard-coded DWORD checksum. If API name found, then take RVA from export directory and add it to base address of loaded DLL.
Here function which calculates checksum for DLL name and API Name are quite complex as compare to function found in main DLL.

Fig 17 : Function which resolve API address

Fig 18 : Calculate checksum for API name

Fig 19 : Decryption loop to get encoded DLL names

The following are some API Names and their respective DWORD checksum used in payload.

6AE056F0h : memset

609FD004h : CreateEventW

87CA8415h : CreateTimerQueue

9BD9AB80h : CreateTimerQueueTimer

160FBC8Dh : WaitForMultipleObjects

0E9E794B7h: BCryptOpenAlgorithmProvider

11B5B47Ah : BCryptGenRandom

35BF9169h : BCryptCloseAlgorithmProvider

69230A13h : GetModuleFileNameW

1D50CF79h : OpenSCManagerW

32655658h : CloseServiceHandle

0ABE413E5h: CreateToolhelp32Snapshot

0C60B628h : Process32FirstW

91BB593Ah : GetCurrentProcessId

0A2188CCBh: Process32NextW

6B466D98h : GetProcessHeap

D84B3D0A : GetModuleHandleA

8B1AD334h : HeapAlloc

3434C63Dh : CloseHandle

25A83B18h : OpenProcess

0B2D79594h: QueryFullProcessImageNameW

5D2B782Fh : PathFindFileNameW

0FC917Eh : SHGetFolderPathW

305B4B5Ah : lstrlenA

0C019E25Ah: StrCmpNIW

0AE929DCDh: lstrcpyW

32C0D23Ch : SHFileOperationW

0AE9B6EABh: _snwprintf

6A53AC4Dh : DeleteFileW

0A9867BD9h: CreateProcessW

73BF5525h : kernel32_SetEvent

0D3711A37h: DeleteTimerQueueEx

9D1964ACh : kernel32_ExitProcess

661CE361h : RtlExitUserProcess

It checks for folder path from which process is being run, if it is not being run from %appdata\Local% directory, then it moves main DLL to %AppData\Local% directory, Regsvr32.exe spawns a child process by passing command line argument as file path of moved DLL to %AppData\Local% directory and kills the parent, becoming a ‘non-existent process’; this is an anti-analysis technique that prevents debuggers from attaching to the process.

Fig 20 : Regsvr32.exe restarted with dropped DLL as argument.

It sends data over internet using WinHttp API.

Fig : 21 : encoded data send over C2 server

We have found various C2 URLs, from which it performs the command-and-control activity.

C2 URL:

hxxps://91[.]121[.]146[.]47:8080/wueylobjdxujn/   

hxxps://72[.]15[.]201[.]15:8080/wueylobjdxujn/   

hxxps://187[.]63[.]160[.]88:80/wueylobjdxujn/     

hxxps://104[.]168[.]155[.]143:8080/             

hxxps://91[.]207[.]28[.]33:8080/wueylobjdxujn/     

hxxps://167[.]172[.]199[.]165:8080/wueylobjdxujn/      

hxxps://72[.]15[.]201[.]15:8080/wueylobjdxujn/     

hxxps://187[.]63[.]160[.]88:80/wueylobjdxujn/     

hxxps://164[.]90[.]222[.]65/wueylobjdxujn/     

Evidence of the detection by RTDMI(tm) engine can be seen below in the Capture ATP report for file:

Security News

The SonicWall Capture Labs Threat Research Team gathers, analyzes and vets cross-vector threat information from the SonicWall Capture Threat network, consisting of global devices and resources, including more than 1 million security sensors in nearly 200 countries and territories. The research team identifies, analyzes, and mitigates critical vulnerabilities and malware daily through in-depth research, which drives protection for all SonicWall customers. In addition to safeguarding networks globally, the research team supports the larger threat intelligence community by releasing weekly deep technical analyses of the most critical threats to small businesses, providing critical knowledge that defenders need to protect their networks.