This post is also available in: 日本語 (Japanese)
Unit 42 has observed a new version of Hworm (or Houdini) being used within multiple attacks. This blog outlines technical details of this new Hworm version and documents an attack campaign making use of the backdoor. Of the samples used in this attack, the first we observed were June 2016, while as-of publication we were still seeing attacks as recently as mid-October, suggesting that this is likely an active, ongoing campaign.
Deconstructing the Threats:
The investigation into this malware began while searching through WildFire execution reports within AutoFocus. Looking for newly submitted malicious samples with no family label, a unique mutex surfaced, “RCSTEST”. Pivoting around the creation of this mutex, as well as other dynamic behaviors, a group of samples slowly began to emerge. The group of samples has common delivery mechanisms, lures and decoy file themes, payloads (Hworm), as well as control infrastructure.
Samples from this attack came in the form of SFX files. The original filenames of these delivery files are related to political figures and groups in the Middle East and the Mediterranean. They include:
Mohamed Dahlan Abu Dhabi Meeting.exe
فضيحة من العيار الثقيل اردوغان يشرب الخمر.exe
صراعات داخلية في صفوف الاخوان المسلمين.exe
عملية اغتيال الدكتور محمد كمال.scr
الملك عبد الله يهدد دول الخليج ويتوعد دحلان.exe
بالفيديو امير سعودي يهين مواطنين على الهواء.scr
When executed each SFX file opens a decoy document, video, or URL, and eventually executes an Hworm payload in the background. The decoy files are similarly themed when compared to the above delivery file names. Figure 1 shows a screenshot from a video one sample opens as a decoy.
Figure 1 Decoy video
Another sample displays a YouTube video by dropping a .url shortcut and opening it using the system’s default web browser. Figure 2 illustrates the .url file contents:
Figure 2 .url file
When the .url file is opened, the above YouTube video is displayed as a decoy. It is unclear at this time if the uploader of this video has any relation to this particular attack
Besides decoys, the samples also execute Hworm payloads, all of which are packed. Each Hworm payload created a unique mutex (while some SFX files delivered the same Hworm payload). All of the samples beaconed to one of three network locations as shown in Figure 3:
Figure 3 C2 Infrastructure
While prior reports on Hworm have been published, we were unable to identify any report detailing this particular version of Hworm. Some previous versions would embed AutoIT scripts in resource sections of PE files while others would execute obfuscated VBS scripts. Some previous versions of the Hworm implant would embed data in the headers of HTTP requests or POST bodies as a method of command and control. Beacons of that HTTP protocol example are easily recognized by the use of ‘<|>’ as a delimiter and the URI of the request. This new version of Hworm uses a mixed binary and ASCII protocol over TCP. Figure 4 is a packet capture of the protocol used by Hworm samples in this attack. It includes the string “new_houdini”, the mutex used by the implant, the name of the user, the operating system version, the version of the implant, and the name of the foreground process:
Figure 4 Packet capture of new communications protocol
During the investigation of this malware a forum post on dev-point[.]com, an Arabic speaking technology and security forum, by a user with the handle “Houdini”, outlined plans for a rewrite of a backdoor in Delphi. This post occurred around July 2015.
Around October 2015, a password protected beta version of the builder used to create Delphi Hworm implants (a4c71f862757e3535b305a14ff9f268e6cf196b2e54b426f25fa65bf658a9242) was uploaded to VirusTotal. Unfortunately, the builder used to create the samples outlined in the above attack was not located. Unit 42 believes the samples used in the above attack are a version which were released after the beta.
Analyzing the Hworm Malcode:
Upon configuring and building a server, the builder prompts the user to save a VBS file and modifies a stub file to create the implant. The VBS file is used to load and inject the implant. It appears that the operators behind the above attack either chose to not use the VBS loader or the newer versions of the builder no longer produce a VBS script.
The VBS Loader:
The script contains three files encoded in base64. The first file is DynamicWrapperX (DCOM_DATA), the second file is the RunPE shellcode (LOADER_DATA), and the third file is the file which gets injected into host process (FILE_DATA). DynamicWrapperX provides access to all Windows APIs from a Visual Basic Script providing a wide range of functionality to this VBS script.
The configuration of the script is at the beginning of the file (Figure 5).
Figure 5 Script configuration section
In the above example, the script will use the registry as a startup method, it will drop itself into the system’s %appdata% directory using the filename myhworm.exe and it will inject itself into svchost.exe.
As the script executes it first adds one of three startup methods which will execute the script on Windows startup:
Registry Run in HKCU
EntryData Wscript.exe //b //e:vbscript <filepath>
/b Specifies batch mode, which does not display alerts, scripting errors, or
/e Specifies the engine that is used to run the script.
Define startup directory
Startup task (not implemented yet)
Following the installation of persistence, the script checks if the current environment is WOW64. If so, the script will execute:
%windir%\syswow64\wscript.exe /b /e:vbscript <filepath>
The script then drops DynamicWrapperX in the configured installation directory with file extension “.bin”.
It will then register DynamicWrapperX:
regsvr32.exe /I /S <filename_dynamic_wrapperx>
Next, the script will load the registered object:
“set DCOM = CreateObject("DYNAMICWRAPPERX")”
It registers /load VirtualAlloc and CallWindowProcW as functions which can be directly called in the script using “dcom.VirtualAlloc <arguments>”.
Using VirtualAlloc it will allocate new memory and copy RunPE shellcode (LOADER_DATA, loader.hex) and the to-be-injected binary (FILE_DATA) into memory.
Using CallWindowProcW the script will jump to the RunPE shellcode and the shellcode will inject the file (FILE_DATA) into the host process. The host process is by default svchost.exe but for .NET files injection can occur into the file:
Figure 6 shows the main routine of the script:
Figure 6 Main routine
Figure 7shows a hex dump of LOADER_DATA (RunPE shellcode):
Figure 7 Hex dump of LOADER_DATA
Similarities in comments and coding styles between previous versions of the Hworm VBS script and the VBS script provided in this beta builder can be seen in Figure 1. Top is the VBS file from the HTTP version of Hworm, compared with the VBS script produced by the beta builder of Hworm (below).
Figure 8 Similarities between HWorm versions
The Beta Server:
The main server which the builder produces is developed in Delphi and is not encrypted. Unit 42 has seen variants packed with VMProtect and ASPack. In some versions of the Delphi Hworm implants discovered (unpacked beta versions) the settings are stored in the resource section RCData\“CONFIG” and are in clear text (Figure 9).
Figure 9 Settings
Some versions also have an unfinished PE spreader in the resource section (a65fd78951590833904bd27783b1032b7cc575220a12c6d6f44cb09061999af3). The spreader will terminate all running processes named “sm?rtp.exe” and execute a VBS file using wscript.exe:
“wscript.exe /e:vbscript <current directory>\$RECYCLE.BIN\u vbs name here”.
Figure 10 Spreader
The server exports some unused functions (they all just have RET instruction). We have seen “wrom.exe” and “server.exe” used as the name in the export table (Figure 11).
Figure 11 Export table
The author used the open source library Indy Components for network communication. They also used BTMemoryModule to load DLLs from memory (without saving it on the disc).
The Hworm implants use a connect-back communication. This means the server (implant) connects back to the client (remotely controlling system). It also has some modules implemented in the server and each module uses its own socket for communication (on the same port defined in the configuration).
The following modules provide features of this malware:
- Screenshot: Provides the ability to capture screenshots in JPEG/BMP formats
- Keylogger: Provides the ability to log key strokes
- Internet IO: Provides the ability to download and execute files from the internet. It also provides the ability to load the executables via the RunPE technique
- File Manager: Provides the ability to list files and directories, delete, rename, and execute files, and upload or download files via TCP or HTTP
- Password: Provides the ability to steal passwords from Firefox, Opera, and Chrome browsers
- Misc: Provides the ability to list processes or modules and kill running processes
- USB Notifier: Provides the ability to notify the controller when a USB device is attached
- Houdini Client: Provides the main client, which contains the server’s configuration.
The similarities in coding styles and features of the server, as well as languages and handles used by the author of the malware, lead us to believe the beta builder is a version of Hworm which was created somewhere between the HTTP version and the version used in the above outlined attack.
As this RAT can be found online in semi-public locations it is possible the malware is used by both surgical threat actors as well as within casual compromises. The above attack is only one such campaign Unit 42 has discovered using the Delphi versions of Hworm.
Palo Alto Networks customers can use AutoFocus to find all versions of Hworm samples using the “Hworm” tag.
Delphi Hworm Beta Builder
Command and Control Network Locations