AsyncRAT is a well known malware and widely active since last few years. However, the old variant of AysncRAT is completely destructive, in the latest variant the malware has advances its capabilities by including additional commands support from C2, clipper module, cryptostealer module, keylogger module and ability to prevent system from going to sleep. SonicWall RTDMI detects a JavaScript file which downloads and executes fileless AsyncRAT on the victim’s machine.

JavaScript

The JavaScript contains garbage comments and keeps the name of the variables larger, to make the code illegible. It downloads a VBScript from a compromised website “h[t][t]ps://dnacapitalgroup.com/wp-includes/images/information.txt” to “%Temp%\VB”, using the Windows utility tool BITSAdmin. The VBScript is launched using Windows Scripting Host by specifying the engine type as “VBScript” for executing script. Windows Script Host usually associates the script engine type based on the script extensions but the malware downloads and executes the VBScript without any extension that makes the requirement of providing the engine information explicitly:

 

The tiny and obfuscated VBScript launches a PowerShell script which further downloads and launches next layer PowerShell script:

 

PowerShell Script

The PowerShell script drops a batch script, a VBScript and 2 PowerShell scripts into “C:\ProgramData\TZOQCBINLOLHJQAPYIDAJV”. This PowerShell script distributes the tasks among these dropped scripts to thwart detection from the security vendors. The PowerShell script starts the next layer PowerShell script TZOQCBINLOLHJQAPYIDAJV.ps1:

• TZOQCBINLOLHJQAPYIDAJV.bat
• TZOQCBINLOLHJQAPYIDAJV.ps1
• TZOQCBINLOLHJQAPYIDAJV.vbs
• YPSPPQWKQDKPVWZHQCIIQZ.ps1

TZOQCBINLOLHJQAPYIDAJV.ps1

The PowerShell script schedules a task to execute the VBScript “C:\ProgramData\TZOQCBINLOLHJQAPYIDAJV.vbs” after every 3 minutes:

TZOQCBINLOLHJQAPYIDAJV.vbs

The obfuscated VBScript launches TZOQCBINLOLHJQAPYIDAJV.bat script:

TZOQCBINLOLHJQAPYIDAJV.bat

The batch script hijacks the Common Object Model (COM) server by making the registry entry “Computer\HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{fdb00e52-a214-4aa1-8fba-4357bb0072ec}\InProcServer32” to a not existing DLL and bypasses Antimalware Scan Interface (AMSI) scanning for the unpatched amsi.dll. The batch script executes the next layer PowerShell script YPSPPQWKQDKPVWZHQCIIQZ.ps1:

YPSPPQWKQDKPVWZHQCIIQZ.ps1

The PowerShell script contains a loader and AsyncRAT binary bytes, encrypted using TripleDES algorithm. The PowerShell script invokes method “C” from the loader binary by passing a file path for process hollowing and AsyncRAT binary’s bytes array. The loader binary does the process hollowing in process “C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe” to execute the AsyncRAT on the victim’s machine. AMSI scanning for loader and AsyncRAT bytes buffers does not work, in unfixed variants of amsi.dll as the malware have hijacked the COM server:

 

AsyncRAT

The old variant of AsyncRAT sends the victim’s information to the C2 server, receives and executes commands. The AysncRAT is capable of receiving and executing plugin on the victim’s machine. The latest variant keeps the old functionalities and additionally we have observed below enhancements:

• CryptoStealer module
• Enables Clipper module
• Enables offline keylogger
• Threat actor’s digital wallet addresses
• Updated group name
• Updated hosts and ports

The latest variant uses the same mutex name, used in the old variants “AsyncMutex_6SI8OkPnk“. To prevent detection in sandbox, the malware delays the execution by sleeping 1000 milliseconds, 3 times in a loop and then decrypts configuration information using AES decryption and initializes the variables:

 

The malware contains code to check for anti analysis, anti VM, anti sandbox and make persistence entry but that is disabled using the flag values, similarly to the old variant. In this variant, the malware enables flag for offline Lime keylogger which logs the key strokes into “%temp%\log.tmp”. The malware keeps the system in active state and prevents it from going to sleep, using  Windows API SetThreadExecutionState by enabling flag values ES_CONTINUOUS, ES_SYSTEM_REQUIRED and ES_DISPLAY_REQUIRED:

 

The major change in this variant that we have observed, is inclusion of Clipper module which intends to steal crypto currencies. The Clipper module looks currency addressed using regular expression in the clipboard data which includes wallet addresses of Bitcoin, Ethereum and Tether, and replaces them with malware’s wallet addresses:

 

C2 Communication

The malware selects a random host and port from the list of host domains/IPs and ports respectively, and tries to connect with it. If the connection to the C2 server fails, the malware tries the next random combination, after a sleep of 5000 milliseconds. Once the connection with C2 sever is established, malware sends below information from the victim’s machine:

• Packet type as “ClientInfo”
• Hardware ID
• Username
• Operating System info
• Execution path
• Version
• Execution mode (Admin | User)
• Active GUI window name
• Antivirus
• Chrome MetaMask extension
• Digital wallet information
  • Bitcoin core
  • Exodus
  • Atomic
  • Electrum
  • Coinomi
  • Ledger
• Chrome Two Factor Authenticator (2FA) extension
• Bitcoin core information
• Exodus information
• Executable time
• Pong as empty string
• Group as “newmekha”
• Last input time

 

The malware creates 3 threads, first thread keeps sending ping messages to ensure the C2 server that the client is alive, second thread counts the time interval for the connection and third thread reads data from the C2 server.

Commands

This variant has increased the supported commands compare to the old variants. The malware receives data in an encoded and compressed message format which is decoded to get the command. Based on the received command, the message may include additional data (eg. plugin bytes, killing processes names and URL to download payload etc.). The malware supports below commands and after executing the command, the result is sent back to the C2 server.

• ResetScale
  • Overrides Dots Per Inch (DPI) scaling using Windows API SystemParametersInfoA and sends back “Reset Scale succeeded!”.
• passload
  • The malware receives plugin bytes along with the command which is loaded in the memory and “PL” method from the plugin is invoked. The Plugin result is sent back to the C2 server.
• killps
  • The command includes names of comma separated processes which are terminated by the malware.
• plugin
  • The malware receives the plugin command along with the plugin hash value. The malware checks if the plugin is already installed on the victim’s machine by looking the hash value into registry “HKEY_CURRENT_USER\Software\<HWID>“. If the plugin is already installed on the victim’s machine, the malware executes the plugin in memory else the malware sends the plugin hash value by setting the packet type to “sendPlugin“:
• savePlugin
  • The malware receives the “savePlugin” command along with the plugin bytes and its hash value. The malware saves the compressed plugin bytes into the registry entry “HKEY_CURRENT_USER\Software\<HWID>” with value name to hash of the plugin. The plugin bytes are decompressed and invoked by the malware.
• getscreen
  • The malware receives plugin bytes along with the command which is loaded in the memory and “PL” method from the plugin is invoked. The Plugin result is sent back to the C2 server.
• uacoff
  • The malware receives plugin bytes along with the command which is loaded in the memory and “PL” method from the plugin is invoked. The Plugin result is sent back to the C2 server.
• DicordTokens
  • The malware receives plugin bytes along with the command which is loaded in the memory and “PL” method from the plugin is invoked. The Plugin result is sent back to the C2 server.
• weburl
  • The malware receives an URL, to download a payload along with the commands. The payload from the URL is downloaded into a temporary file and executed.
• Net35
  • The malware receives plugin bytes along with the command which is loaded in the memory and “PL” method from the plugin is invoked. The Plugin result is sent back to the C2 server.
• pong
  • The malware has registered a timer which keeps increasing the interval value. Once the malware receives pong command, the interval value is sent to the C&C server by setting the packet type to “pong”.
• Avast
  • The malware receives plugin bytes along with the command which is loaded in the memory and “PL” method from the plugin is invoked. The Plugin result is sent back to the C2 server.
• WDExclusion
  • The malware receives plugin bytes along with the command which is loaded in the memory and “PL” method from the plugin is invoked. The Plugin result is sent back to the C2 server.
• KillProxy
  • The malware receives plugin bytes along with the command which is loaded in the memory and “PL” method from the plugin is invoked. The Plugin result is sent back to the C2 server.
• gettxt
  • The malware sends the clipboard text to the C2 server.
• klget
  • The malware sends the stolen keystrokes file which is created by the Lime keylogger.
• backproxy
  • The malware receives plugin bytes along with the command which is loaded in the memory and “PL” method from the plugin is invoked. The Plugin result is sent back to the C2 server.
• WebBrowserPass
  • The malware receives plugin bytes along with the command which is loaded in the memory and “PL” method from the plugin is invoked. The Plugin result is sent back to the C2 server.

 

Unavailability of the archive file in any of the popular threat intelligence sharing portals like the VirusTotal and the ReversingLabs at the time of writing this blog indicates its uniqueness and limited distribution:

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

• 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: