HORUS Protector Part 2: The New Malware Distribution Service

Recently, the SonicWall Capture Labs threat research team came across a new Horus FUD (Fully Un-Detectable) malware crypter used for spreading different malware families including AgentTesla, Remcos, Snake, NjRat and many others. Here, we will be discussing the infection chain/spreading mechanism followed by payloads distributed using Horus Protector. If you want to learn more about Horus Protector, please read our previous blog.

Most malicious files are distributed through scripts contained in archive files. Recent infections have been attributed to VBE scripts, which are encoded VBS scripts that can be decoded using various tools.

Figure 1: Infection Chain

Upon execution, the VBE script downloads all the required data from its CnC server hxxp://144.91.79[.]54. From this server, it initially retrieves a few encoded files hxxp://144.91.79[.]54/1109/s, hxxp://144.91.79[.]54/1109/r and hxxp://144.91.79[.]54/1109/H011yiDJHSNr3TuAtkpt.txt. All this downloaded data is stored in a particular registry. The registry path is [HKEY_CURRENT_USER\SOFTWARE\uOITNhlpKJsMLJx], where uOITNhlpKJsMLJx is predefined as a SystemPath variable in the VBE script.

All this data is stored in different subkeys of this registry which we will discuss further. The data mostly contains executables and instructions. Below are the registries and their values.

Figure 2: Registry Entries

Another registry named \donn is formed under the same parent registry, with the main payload in hexadecimal format distributed across several subkeys based on the size of the payload. The subkeys are named as segment1, segment2, …, segmentn. In few instances we have also observed the names as data1, data2, …, datan.

Figure 3: Main Payload

After this, it creates a new VBS script at "\AppData\Roaming" location with the same name uOITNhlpKJsMLJx.VBS.

Later, the VBS file is written with the data downloaded from the URL hxxp://144.91.79[.]54/1109/file. A task scheduler with same name is created for this VBS script, with a trigger configured to execute it once a minute.

Figure 4: Task Scheduler

Afterward, it checks for existence of antivirus software using "winmgmts:\\.\root\SecurityCenter2". It particularly verifies the presence of Windows Defender by looking for the string "Windows Defender Enabled" in this object.

Figure 5: Check Antivirus

If Windows Defender is enabled on the system, the script executes the file located in the registry subkey [HKEY_CURRENT_USER\SOFTWARE\uOITNhlpKJsMLJx\s] essentially functioning as a loader(Elfetah.exe) using the following command parameters:

"PowerShell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -NoExit."

Conversely, if the defender is not enabled, the VBS script \AppData\Roaming\uOITNhlpKJsMLJx.vbs is automatically executed through the already scheduled task.

The uOITNhlpKJsMLJx.vbs script first checks for existence of genuine process name provided in registry subkey [HKEY_CURRENT_USER\SOFTWARE\uOITNhlpKJsMLJx\i], here, MSBuild.exe in the running processes.

In case the process is not running, it runs powerShell and executes command in registry [HKEY_CURRENT_USER\Software\uOITNhlpKJsMLJx\v]. This command perticularly decodes the loader file from [HKEY_CURRENT_USER\SOFTWARE\uOITNhlpKJsMLJx\s] registry and passes the path uOITNhlpKJsMLJx as a parameter.

Execution Step 1:

As discussed above, the registry value [HKCU:\Software\uOITNhlpKJsMLJx\s] contains reversed base64 data. Using this data, the dropped VBS executes module named Elfetah.exe. The exclusive purpose of this file is to load and execute assembly of next injector file stored in registry [HKCU:\Software\uOITNhlpKJsMLJx\r]. The registry key path i.e. "uOITNhlpKJsMLJx" is passed to Elfetah.exe as a parameter. Using this it retrieves data from registry [HKCU:\Software\uOITNhlpKJsMLJx\r], reverse it and converts from hex to ascii to form raw binary.

Figure 6: Call to second stage

The new assembly is loaded by calling the r method from in newly loaded DotNet dll, erezake.dll.

Execution Step 2:

The second stage of the malware execution is the injector erezake.dll, which injects the payload into the target process provided by service user.

Here, we already know that the intended target process is MSBuild.exe which is stored in registry [HKCU:\Software\uOITNhlpKJsMLJx\i].

Figure 7: Search Target Process

This MSBuild.exe is searched in the directories shown in the image. These paths may vary according to the target process to be searched. So, there is a possibility that this dll file might be generated separately for specific user requests.

The main payload which is stored in [HKEY_CURRENT_USER\SOFTWARE\uOITNhlpKJsMLJx\donn] key with subkeys segment1, segment2, …, segment, etc. is concatenated and reversed to form a PE file.

Figure 8: Extract Payload

The payload is then injected into the target process by using an image hollowing process injection technique. All win APIs are wrapped using French function names as mentioned in the below image.

Figure 9: Process Hollowing

After the process injection, it checks for the presence of the value in the registry [HKEY_CURRENT_USER\SOFTWARE\uOITNhlpKJsMLJx\b]. Although we're not sure of its use, there is a large possibility that it is used for a BotKill option which was provided by the Horus Crypter service provider. Also, it will be present only if the user has opted or ticked the BotKill checkbox while creating the payload.

Figure 10: BotKill Check

If the registry value is "1", then it removes all the persistence of the malware from the victim's system. This also includes Scheduled Task deletion from the system.

Figure 11: Delete Persistence

Here, the injected payload was the SNAKE Keylogger. The SNAKE Keylogger is infamous for stealing sensitive data, such as:

• Key logs
• Screenshots
• Clipboard data
• Application data (browsers, email clients, etc.)

Figure 12: SNAKE Keylogger Strings

You can read more about SNAKE Keylogger in our old blog.

We have observed similar mechanisms spreading different malware over this period. It would be interesting to see what new versions authors will bring in future.

IOCs:

c39a2e4fbcce649cb5ac409d4a2e1b1f

f0fe04a3509d812ade63145fd37a1cb2

8acccb571108132e1bbe7c4c60613f59

405377b1469f31ff535a8b133360767d

fd4302cdfacbc18e723806fde074625b

Ips:

144.91.79[.]54