Worok – The big picture

Once access had been acquired, the operators deployed multiple, publicly available tools for reconnaissance, including Mimikatz, EarthWorm, ReGeorg, and NBTscan, and then deployed their custom implants: a first-stage loader, followed by a second stage .NET loader (PNGLoad). Unfortunately, we have not able to retrieve any of the final payloads.
In previous cases the first-stage loader was a CLR assembly (CLRLoad), while in later ones it has been replaced, in most cases, by a full-featured PowerShell backdoor (PowHeartBeat).

CLRLoad is a generic Windows PE that we have seen in both 32-and 64-bit versions. It is a loader written in C++ that loads the next stage (PNGLoad), which must be a Common Language Runtime (CLR) assembly DLL file. That code is loaded from a file located on disk in a legitimate directory, presumably to mislead victims or incident responders into thinking it is legitimate software.

Some CLRLoad samples start by decoding the full path of the file whose content they will load as the next stage. These file paths are encoded with a single-byte XOR, with a different key in every sample. Decoded or cleartext, these file paths are absolute, with the following being those we have encountered:

C:Program FilesVMwareVMware ToolsVMware VGAuthxsec_1_5.dll
C:Program FilesUltraViewermsvbvm80.dll
C:Program FilesInternet ExplorerJsprofile.dll
C:Program FilesWinRarRarExtMgt.dll
C:Program Files (x86)Foxit SoftwareFoxit Readerlucenelib.dll
Next, a mutex is created and we’ve seen a different name in every sample. The loader checks for this mutex; if found, it exits, because the loader is already running. In one of the samples, the mutex Wo0r0KGWhYGO was encountered, which gave the group its name of Worok.

CLRLoad then loads a CLR assembly from the possibly decoded file path. As unmanaged code, CLRLoad achieves this via CorBindToRuntimeEx Windows API calls in 32-bit variants, or CLRCreateInstance calls in 64-bit variants.

PowHeartBeat is a full-featured backdoor written in PowerShell, obfuscated using various techniques such as compression, encoding, and encryption. Based on ESET telemetry, we believe PowHeartBeat replaced CLRLoad in more recent Worok campaigns as the tool used to launch PNGLoad.

The first layer of the backdoor code consists of multiple chunks of base64-encoded PowerShell code. Once the payload is reconstructed, it is executed via IEX. Once decoded, another layer of obfuscated code is executed.

The second layer of the backdoor first base64 decodes the next layer of its code, which is then decrypted with Triple DES (CBC mode). After decryption, this code is decompressed using the gzip algorithm, thus giving the third layer of PowerShell code, which is the actual backdoor. It is divided into two main parts: configuration, and handling backdoor commands.

The main layer of backdoor code is also written in PowerShell and uses HTTP or ICMP to communicate with the C&C server.

PNGLoad is the second-stage payload deployed by Worok on compromised systems and, according to ESET telemetry, loaded either by CLRLoad or PowHeartBeat. While we don’t see any code in PowHeartBeat that directly loads PNGLoad, the backdoor has the capabilities to download and execute additional payloads from the C&C server, which is likely how the attackers have deployed PNGLoad on systems compromised with PowHeartBeat.