HTML Application (.HTA) files are being used to distribute Smoke Loader malware
Threat actor always targets under the radar file types to deliver malware to the victim’s machine. HTML Applications (HTA) files are known as less suspicious file types by various security providers. SonicWall Capture Labs Threat Research team has observed an HTA file inside an archive is being delivered to the victim’s machine, which further downloads and executes Smoke Loader malware.
Infection Cycle:
The archive file name is in German “Zahlungserinnerung-BV-Green-Golfm.zip” acted as a payment reminder for the victim. The HTA file has HTML code to display service estimation by “LM Classic Cars” for Ferrari 348 TB for an Autria customer, additionally it includes JavaScript code to download malware using PowerShell script:
The JavaScript code executes the PowerShell executable which further executes another instance of the PowerShell executable using Command Prompt:
The PowerShell script contains code to perform below actions on MS Office files:
- Enables all macros
- Disable protected view for files belongs to internet zone
- Disable protected view for attachments opened in Outlook
- Disable protected view for files in unsafe locations
The PowerShell downloads malware from URL h[t][t]p://www.trimm.at/error/upx.exe
The Smoke Loader malware works in multi stages and layers. It uses code obfuscation, anti debugging, anti VM and Living of The Land techniques. The malware makes sure that a memory dump should not expose its intention at any point of time.
First Stage Executable
The first stage executable is highly obfuscated, it contains large loops with garbage API calls followed by a conditional jump. The malware uses opaque predicate technique as control never goes to garbage API calls, they are just kept to make analysis difficult. In a long iterations loop, only few operations are actually required by the malware which are executed on a particular iteration. The below iteration loop is intended to calculate the encrypted bytes size at 0x40Ath iteration:
The malware decrypts the shellcode into memory which further brings second stage executable:
The shellcode uses PEB_LDR_DATA from Process Environment Block, iterates through InLoadOrderModuleList to get the API addresses. The shellcode decrypts next stage executable in memory and does process hollowing to replace current process from the address space and starts execution of new process from entry point:
Second Stage Executable:
Second stage executable code is full of techniques used to investigate the controlled environment execution.
Anti-Debug
Checking the BeingDebugged and NtGlobalFlag in Process Environment Block is common across the malware. Here the tricky part is, instead of branching the code based on the flag values, the malware uses the flag values to compute a jump offset. If the malware is running inside a debugger then it will compute a invalid address which makes an impression of corrupted file to the researcher:
On-Demand Decryption
The malware decrypts the code on demand just before executing it and once the code is executed, the malware encrypts it back. The malware does this, to prevent its complete code exposure in one shot:
Loaded module
The malware checks for below modules in the current process, if any of them is loaded malware terminates the execution.
- sbiedll (Sandboxie module)
- aswhook (Avast module)
- snxhk (Avast module)
Virtual Environment
The malware examines registry values “\REGISTRY\MACHINE\System\CurrentControlSet\Enum\IDE” and “\REGISTRY\MACHINE\System\CurrentControlSet\Enum\SCSI” for below substrings to check for virtual environment.
- qemu
- virtio
- vmware
- vbox
- xen
The malware enumerates through all the running processes and looks for below processes. If any of the process is found the malware terminates the execution. The malware shows laziness in the code here, instead of dynamic size for individual process name, the malware keeps the size to 0x20 bytes for all the process names:
- qemu-ga.exe
- qga.exe
- windanr.exe
- vboxservice.exe
- vboxtray.exe
- vmtoolsd.exe
- prl_tools.exe
The malware looks for below 7 bytes substrings of filenames into victim’s machine. If any of them is found the malware terminates the execution:
- vmci.s
- vmusbm
- vmmous
- vm3dmp
- vmrawd
- vmmemc
- vboxgu
- vboxsf
- vboxmo
- vboxvi
- vboxdi
- vioser
Code Injection
The malware gets the explorer.exe process id using APIs GetShellWindow and GetWindowThreadProcessId:
The malware creates and maps two sections in explorer.exe, one section has PAGE_READWRITE access attributes to store data and second section has PAGE_EXECUTE_READ access attributes to inject shellcode. Not enabling WRITE access to the shellcode memory makes the debugging little more difficult as this will prevent from putting software breakpoints and modifying code as per researcher’s need:
The malware injects shellcode into the mapped section and does NtCreateThreadEx passing data section address as parameter:
ShellCode Execution:
The Injected shellcode into explorer.exe spawns two sub-threads which keep an eye on monitoring tools. If the researcher opens any of the monitoring tool or analysis tool that will be immediately terminated by the sub-threads while the main thread doing its job.
Thread 1
This thread enumerates through all running processes, computes hash of the running process name and compares it with its list of hashes to terminate below processes:
- 56DAB1A9 → Autoruns.exe
- F3E35F5E → procexp.exe
- 2407724B → procexp64.exe
- FBC25850 → procmon.exe
- 27151A96 → procmon64.exe
- E6ED4551 → Tcpview.exe
- 27D7E006 → Wireshark.exe
- 2CEB6C62 → ProcessHacker.exe
- EDCD7F5E → ollydbg.exe
- 70A30042 → x32dbg.exe
- 4EA30D45 → x64dbg.exe
- 0CCD4A10 → idaq.exe
- 0CCD4C3A → idaw.exe
- 0956AD95 → idaq64.exe
- 337CAD95 → idaw64.exe
Thread 2
The malware enumerates through windows, computes hash value of windows name and compares it to terminate processes attached with below windows list:
- 61C75CDC → Autoruns
- 4DFA76EB → PROCEXPL
- 95E8B472 → PROCMON_WINDOW_CLASS
- 62DC4674 → TCPViewClass
- 6A0FAA84 → Wireshark
- 7FF991A1 → ProcessHacker
- BEDA6295 → OLLYDBG
- 62DD69FD → IDA
Main Thread
The main thread starts with Process Environment Block (PEB) traversal, to get ImageBase of ntdll.dll and kernel32.dll. The malware then enumerates the export functions to get the the addresses of required APIs. Instead of direct API names the malware keeps the hash values list, which is being compared to the hash value of the exported function name:
The malware keeps list of RC4 encrypted strings in a structure, in which first bytes tells the string size followed by encrypted string. The malware perform RC4 decryptions just before using them:
The malware computes a unique identifier for the victim’s machine using below formula:
MD5(computer name + hardcoded DWORD value + system drive serial number) + system drive serial number
The malware creates mutex with the unique identifier to restrict execution of another instance of the shellcode and if another instance is already running malware terminates its execution:
The malware reads Internet Explorer version information from registry and gets user agent string for it:
The malware drops self copy into %APPDATA% directory and the file name is computed by encoding initial 7 bytes from the unique identifier:
The malware deletes the current instance of the malware and it deletes zone identifier from the self copy dropped in %APPDATA%:
The malware sets dropped file property as FILE_ATTRIBUTE_HIDDEN and FILE_ATTRIBUTE_SYSTEM. The malware steals creation time from advapi32.dll and mark the same creation time for the dropped file to avoid being red flagged from any of the security providers.
C&C Communication
The malware contains 4 C&C servers:
- ostgotahusbilsuthynring.de
- autoland-ls.de
- autogalerieseud.de
- autohuas-e-c.de
The malware calculate CRC32 checksum for one of the C&C server before communicating, to make sure that the C&C has not been modified by the researcher and if the C&C is modified malware terminates the execution. The malware prepares post data which includes the variant id, unique identifier for the victim’s machine, computer name and random 0xA1 bytes. The data is then encrypted by RC4 algorithm and sent to its C&C server:
At the time of analysis all 4 C&C server were not responding but digging deep into the malware code reveals that malware is expecting response from C&C server which should contain Variant ID (0x7E6), Plugin size and plugin modules.
Unavailability of the archive file in any of the popular threat intelligence sharing portals like the VirusTotal and the ReversingLabs indicates its uniqueness and limited distribution:
Evidence of detection by RTDMI ™ engine can be seen below in the Capture ATP report for this file:
