Learning about malware persistence through the lens of “Hydraq” Malware

In this series of posts, I’m continuing the Open Security Training materials, with this set of post being more focused on the Malware Analysis class.

You may find reviewing the material from Open Security more beneficial. However, if you do choose to stick with this I hope you find it helpful.

In the first post, we learned about persistence mechanism through the registry. In the second post we saw persistence through both the registry and the “Startup” folder. In this post we will learn about persistence through Windows Services. This will be achieved through analyzing Hydraq.

Since I’m already aware that Hydraq delete itself upon launch, I’ve gone ahead and setup “ProcessHacker” to watch the process creation. Below is snapshot of before execution. In this snapshot, we see the malware is listed in “Windows Explorer”.

… and here is a snapshot after execution.

As can be seen above, the “malware.exe” process got created (svchost.exe in green) then it immediately deleted (malware.exe in red) itself. It then created a new “svchost.exe” process with PID “1448”. Creating another “svchost.exe” process allows it to blend it quite easily.

Additionally as seen in the lower right hand corner, a service also got created with the name “UpsQjd”.

Taking a look at an AutoRuns comparison before and after execution, we see below that a service has been registered as “RaS4mg6” and leverage a DLL which has a path of “C:\WINDOWS\system32\Rasmon.dll”

Files added: 2

C:\WINDOWS\Prefetch\MALWARE.EXE-2391A9A8.pf C:\WINDOWS\system32\Rasmon.dll

Looking at the entries added via the registry we see:

HKLM\SYSTEM\ControlSet001\Enum\Root\LEGACY_UPSQJD\NextInstance: 0x00000001
HKLM\SYSTEM\ControlSet001\Enum\Root\LEGACY_UPSQJD\0000\Service: "UpsQjd"
HKLM\SYSTEM\ControlSet001\Enum\Root\LEGACY_UPSQJD\0000\Legacy: 0x00000001
HKLM\SYSTEM\ControlSet001\Enum\Root\LEGACY_UPSQJD\0000\ConfigFlags: 0x00000000
HKLM\SYSTEM\ControlSet001\Enum\Root\LEGACY_UPSQJD\0000\Class: "LegacyDriver"
HKLM\SYSTEM\ControlSet001\Enum\Root\LEGACY_UPSQJD\0000\ClassGUID: "{8ECC055D-047F-11D1-A537-0000F8753ED1}"
HKLM\SYSTEM\ControlSet001\Enum\Root\LEGACY_UPSQJD\0000\DeviceDesc: "UpsQjd"
HKLM\SYSTEM\ControlSet001\Enum\Root\LEGACY_UPSQJD\0000\Control\*NewlyCreated*: 0x00000000
HKLM\SYSTEM\ControlSet001\Enum\Root\LEGACY_UPSQJD\0000\Control\ActiveService: "UpsQjd"

From above we see the service “UpsQjd” is being created in the registry. Leveraging “reg query” we see the following output:

This also corresponded to:

The funny thing though is this service does not have any binary path as shown below:
Except for a few services of type “Driver” or “FS driver” every other service had a “Binary Path”. The snapshot below shows that for the “Share process”, all processes had a “binary path” except “UpsQjd”.

The above definitely stands out.

Additionally, the following keys were created:
HKLM\SYSTEM\ControlSet001\Services\RaSQjdO\ErrorControl: 0x00000000
HKLM\SYSTEM\ControlSet001\Services\RaSQjdO\Start: 0x00000002
HKLM\SYSTEM\ControlSet001\Services\RaSQjdO\Type: 0x00000020
HKLM\SYSTEM\ControlSet001\Services\RaSQjdO\ImagePath: "%SystemRoot%\System32\svchost.exe -k netsvcs"
HKLM\SYSTEM\ControlSet001\Services\RaSQjdO\ObjectName: "LocalSystem"
HKLM\SYSTEM\ControlSet001\Services\RaSQjdO\Parameters\ServiceDll: "c:\windows\system32\rasmon.dll"
HKLM\SYSTEM\ControlSet001\Services\RaSQjdO\Security\Security: 01 00 14 80 90 00 00 00 9C 00 00 00 14 00 00 00 30 00 00 00 02 00 1C 00 01 00 00 00 02 80 14 00 FF 01 0F 00 01 01 00 00 00 00 00 01 00 00 00 00 02 00 60 00 04 00 00 00 00 00 14 00 FD 01 02 00 01 01 00 00 00 00 00 05 12 00 00 00 00 00 18 00 FF 01 0F 00 01 02 00 00 00 00 00 05 20 00 00 00 20 02 00 00 00 00 14 00 8D 01 02 00 01 01 00 00 00 00 00 05 0B 00 00 00 00 00 18 00 FD 01 02 00 01 02 00 00 00 00 00 05 20 00 00 00 23 02 00 00 01 01 00 00 00 00 00 05 12 00 00 00 01 01 00 00 00 00 00 05 12 00 00 00

This corresponds to:

However, while the service "UpsQjd" had a corresponding service, the service “RaSQjdo” has no readily available service as shown below:

However, if we pay closer attention to the information above, we can see the line “HKLM\SYSTEM\ControlSet001\Services\RaSQjdO\ImagePath: "%SystemRoot%\System32\svchost.exe -k netsvcs". What this tells me is while the process may start with its own “svchost.exe” process currently with PID “1448” it becomes part of the “netsvcs” group upon reboot.

Looking at the current “netsvcs” group, we see no trace of “RaSQjdO” as shown below:

However, if we look at he “netsvc” group for “svchost” we see:
C:\>reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion\svchost" /v netsvcs

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\svchost

    netsvcs     REG_MULTI_SZ    6to4\0AppMgmt\0AudioSrv\0Browser\0CryptSvc\0DMServer\0DHCP\0ERSvc\0EventSystem\0FastUserSwitchingCompatibility\0HidServ\0Ias\0Iprip\0Irmon\0LanmanServer\0LanmanWorkstation\0Messenger\0Netman\0Nla\0Ntmssvc\0NWCWorkstation\0Nwsapagent\0Rasauto\0RaSQjdO\0Rasman\0Remoteaccess\0Schedule\0Seclogon\0SENS\0Sharedaccess\0SRService\0Tapisrv\0Themes\0TrkWks\0W32Time\0WZCSVC\0Wmi\0WmdmPmSp\0winmgmt\0wscsvc\0xmlprov\0napagent\0hkmsvc\0BITS\0wuauserv\0ShellHWDetection\0helpsvc\0WmdmPmSN\0

As we can see above upon reboot, the malware will be migrating from its current “svchost” to another “svchost”. Without a doubt this level of persistence makes it difficult for anyone to easily detect.

Time to move on …

… but before we move on, let’s reboot and see if the malware is truly part of the “svchost” that manages the group “netsvcs”.

As can be seen above, the malware has truly migrated to a different “svchost”.

Time to move on.

That’s all for this post.

References:

Open Security Training
HKLM\SYSTEM\CurrentControlSet\Services Registry Tree