Worok: The big picture

ESET researchers recently found targeted attacks that used undocumented tools against various high-profile companies and local governments mostly in Asia. These attacks were conducted by a previously unknown espionage group that we have named Worok and that has been active since at least 2020. Worok’s toolset includes a C++ loader CLRLoad, a PowerShell backdoor PowHeartBeat, and a C# loader PNGLoad that uses steganography to extract hidden malicious payloads from PNG files.

Who is Worok?

During the ProxyShell (CVE-2021-34523) vulnerability disclosure in early 2021, we observed activity from various APT groups. One exhibited characteristics common with TA428:

• Activity times
• Targeted verticals
• Usage of ShadowPad

The rest of the toolset is very different: for example, TA428 took part in the Able Desktop compromise in 2020. We consider that the links are not strong enough to consider Worok to be the same group as TA428, but the two groups might share tools and have common interests. We decided to create a cluster and named it Worok. The name was chosen after a mutex in a loader used by the group. Further activity with variants of the same tools was then linked to this group. According to ESET’s telemetry, Worok has been active since late 2020 and continues to be active as of this writing.

Back in late 2020, Worok was targeting governments and companies in multiple countries, specifically:

• A telecommunications company in East Asia
• A bank in Central Asia
• A maritime industry company in Southeast Asia
• A government entity in The Middle East
• A private company in southern Africa

There was a significant break in observed operations from 2021-05 to 2022-01, but Worok activity returned in 2022-02, targeting:

• An energy company in Central Asia
• A public sector entity in Southeast Asia

Figure 1 presents a visual heatmap of the targeted regions and verticals.

Figure 1. Map of the targeted regions and verticals

Considering the targets’ profiles and the tools we’ve seen deployed against these victims, we think Worok’s main objective is to steal information.

Technical analysis

While the majority of initial accesses are unknown, in some cases through 2021 and 2022 we have seen exploits used against the ProxyShell vulnerabilities. In such cases, typically webshells have been uploaded after exploiting these vulnerabilities, in order to provide persistence in the victim’s network. Then the operators used various implants to gain further capabilities.

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 been able to retrieve any of the final payloads. In 2021, the first-stage loader was a CLR assembly (CLRLoad), while in 2022 it has been replaced, in most cases, by a full-featured PowerShell backdoor (PowHeartBeat) – both execution chains are depicted in Figure 2. These three tools are described in detail in the following subsections.

Figure 2. Worok compromise chains

CLRLoad: CLR assembly loader

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 Files\VMware\VMware Tools\VMware VGAuth\xsec_1_5.dll
• C:\Program Files\UltraViewer\msvbvm80.dll
• C:\Program Files\Internet Explorer\Jsprofile.dll
• C:\Program Files\WinRar\RarExtMgt.dll
• C:\Program Files (x86)\Foxit Software\Foxit Reader\lucenelib.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: PowerShell backdoor

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, which we can see in Figure 3.

Figure 3. Excerpt of the decoded main function of the second layer of PowHeartBeat

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. It works as depicted in Figure 4.

Figure 4. PowHeartBeat's functioning

Configuration

The configuration contains multiple fields, including version number, optional proxy configuration, and C&C address. Table 1 describes the meanings of the configuration fields in the different versions we have observed.

Table 1. Configuration field meanings

Figure 5 shows an example of the configuration extracted from a PowHeartBeat sample (SHA-1: 757ABA12D04FD1167528FDD107A441D11CD8C427).

$Script:nouse = 100;
if(Test-Path $MyInvocation.MyCommand.Path){Remove-item $MyInvocation.MyCommand.Path -Force;}
$Script:ClientId = "83";
$Script:Version = "2.1.3.0003";
$Script:ExecTimes = 10;
$Script:UserAgent = "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3487.100 Safari/537.36";
$Script:Referer = "www.adobe.com";
$Script:AcceptEncoding = "text/html,app1ication/xhtml+xml,app1ication/xml;q=0.9,*/*;q=0.8";
$Script:CookieClientId = "s_ecid";
$Script:CookieTaskId = "aam_uuid";
$Script:CookieTerminalId = "AAMC_adobe_0";
$Script:UrlHttps = "http://";
$Script:UrlDomain=  " 118.193.78[.]22:443";
$Script:UrlSendHeartBeat = "/latest/AdobeMessagingClient.js";
$Script:UrlSendResult = "/content/dam/offers-homepage/homepage.jpg";
$Script:GetUrl = $Script:UrlHttps + $Script:UrlDomain + $Script:UrlSendHeartBeat;
$Script:PutUrl = $Script:UrlHttps + $Script:UrlDomain + $Script:UrlSendResult;
$Script:currentPath = Split-Path -Parent $MyInvocation.MyCommand.Definition;
$Script:ProxyEnableFlag = $false;
$Script:Proxymsg;
$Script:Interval = 10 ;
$Script:BasicConfigPath = "C:\ProgramData\unins.dat";
$Script:UpTime = 0;
$Script:DownTime = 24;
$Script:Domains;
$Script:DomainIndex;
$Script:SecretKey = "###ConfigKey###";

#$Script:IfLog = $true;
$Script:IfLogFilePath = "C:\ProgramData\tpncp.dat";
$Script:logpath = "C:\ProgramData\unins000.dat";
$Script:ProxyFile = "C:\ProgramData\hwrenalm.dat";

$Script:IfConfig = $false;

Figure 5. Configuration example

Data encryption

PowHeartBeat encrypts logs and additional configuration file content.

Log file content is encrypted though multiple-byte XOR with a key specified in cleartext in the sample. Interestingly, clientId is used as a salt for the index into the key array. The key is a 256-byte array, which was identical in every sample that we encountered. Additional configuration file content is encrypted through multiple-byte XOR with the value from SecretKey as its key.

C&C communications

PowHeartBeat used HTTP for C&C communications until version 2.4, and then switched to ICMP. In both case the communication is not encrypted.

HTTP

In an infinite loop, the backdoor sends a GET request to the C&C server, asking for a command to issue. The encrypted answer is decrypted by the backdoor, which processes the command, and writes the command output to a file whose content is then sent to the C&C server via a POST request.

The format of the GET requests is the following:

GET <UrlSendHeartBeat> HTTP/1.1
User-Agent: <UserAgent>
Referer: <Referer>
Host: <Domain>
Cookie: <CookieClientId>=<ClientId>
Connection: close

Note that the request is constructed using the eponymous configuration fields.

In the response from the C&C server, the third byte of the content is the command identifier that indicates the command to be processed by the backdoor. We’ll call it command_id. The remaining content of the response will be passed as an argument to the command that is processed. This content is encrypted with the algorithm shown in Figure 6, taskId being the value of the cookie named after CookieTaskId‘s value from the configuration.

o[int] $pos = $taskId % 256;
for ($i = 0; $i -lt $tmpBytes.Value.Length; $i++)
{
	   $pos = $pos + $clientId;
	   if ($pos -ge 256)
	   {
			  $pos = $pos % 256;
	   }
	   $tmpBytes.Value[$i] = [byte]($tmpBytes.Value[$i] -bxor $hexEnc[$pos]);
}

Figure 6. Requests content data encryption algorithm

The response from the C&C server also contains another cookie, whose name is specified by the backdoor’s CookieTerminalId configuration variable. The value of this cookie is repeated in the POST request from the backdoor, and it must not be empty. After executing the backdoor command, PowHeartBeat sends the result as a POST request to the C&C server. The result is sent as a file whose name is <command_id>.png.

ICMP

Starting from version 2.4 of PowHeartBeat, HTTP was replaced by ICMP, sent packets having a timeout of six seconds and being unfragmented. Communication through ICMP is most likely a way to evade detection.

There is no major change in versions 2.4 and later, but we noticed some modifications in the code:

• PowHeartBeat sends a heartbeat packet at each loop that contains the string abcdefghijklmnopqrstuvwxyz, before requesting a command. This informs the C&C server that the backdoor is ready to receive commands.
• Requests to get commands performed by the backdoor contain the string abcdefghijklmnop.

Heartbeat packets have the format described in Figure 7.

Figure 7. Heartbeat packet layout

The difference between client ID and client flag is that client ID differs in every sample whereas client flag is the same in every sample that uses ICMP. heartbeat flag indicates that the backdoor is sending a heartbeat. The response from the C&C server has the format described in Figure 8.

Figure 8. C&C server response layout

flag here indicates whether there is a command to issue to the backdoor. Requests to get commands have the format described in Figure 9.

Figure 9. Layout for requests to get commands

Note that the backdoor’s ICMP mode allows receiving an unlimited amount of data, divided into chunks, and the variables data length, current position and total length are used to keep track of the transmitted data. Responses to these requests have the format described in Figure 10.

Figure 10. Layout of responses to requests for getting commands

As in HTTP responses, the command identifier is the third byte of data.

After seven consecutive ICMP replies with empty or inconsistently formatted content, transfers between the backdoor and C&C server are considered finished.

Concerning the requests to send the result of the issued command to the C&C server, server mode is changed for post mode, and the final string (abcdefghijklmnop) is changed for the result data.

Backdoor commands

PowHeartBeat has various capabilities, including command/process execution and file manipulation. Table 2 lists all commands supported by the various analyzed samples.

Table 2. PowHeartBeat command descriptions

In case of errors on the backdoor side, the backdoor uses a specific command identifier 0x00 in the POST request to the C&C server, thus indicating an error occurred.

Note that before sending the information back to the C&C server, the data is gzip-compressed.

PNGLoad: Steganographic loader

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. PNGLoad is a loader that uses bytes from PNG files to create a payload to execute. It is a 64-bit .NET executable – obfuscated with .NET Reactor – that masquerades as legitimate software. For example, Figure 11 shows the CLR headers of a sample masquerading as a WinRAR DLL.

Figure 11. Example of a fake WinRAR DLL

Once deobfuscated, only one class is present. In this class, there is a MainPath attribute containing the directory path the backdoor searches, including its subdirectories, for files with a .png extension, as shown in Figure 12.

Figure 12. .png file listing

Each .png file located by this search of MainPath is then checked for steganographically embedded content. First, the least-significant bit of each pixel’s R (red), G (green), B (blue), and A (alpha) values are fetched and assembled into a buffer. Should the first eight bytes of that buffer match the magic number seen in Figure 13 and the next eight-byte value, control, be non-null, the file passes PNGLoad’s steganographic content check. For such files, processing continues with the remainder of the buffer decrypted with a multiple-byte XOR, using the key stored in PNGLoad’s SecretKeyBytes attribute, and then the decrypted buffer is gzip-decompressed. The result is expected to be a PowerShell script, which is run immediately.

Figure 13. Format of buffer PNGLoad creates from processing .png files

Interestingly, operations performed by PNGLoad are logged in a file whose path is stored in the variable LogFilePath. Operations are only logged if a file is present whose path is specified by the internal variable IfLogFilePath.

We have not been able to obtain a sample .png file used along with PNGLoad, but the way PNGLoad operates suggests that it should work with valid PNG files. To hide the malicious payload, Worok uses Bitmap objects in C#, which only take pixel information from files, not the file metadata. This means that Worok can hide its malicious payloads in valid, innocuous-looking PNG images and thus hide in plain sight.

Conclusion

Worok is a cyberespionage group that develops its own tools, as well as leveraging existing tools, to compromise its targets. Stealing information from their victims is what we believe the operators are after because they focus on high-profile entities in Asia and Africa, targeting various sectors, both private and public, but with a specific emphasis on government entities. Activity times and toolset indicate possible ties with TA428, but we make this assessment with low confidence. Their custom toolset includes two loaders – one in C++ and one in C# .NET – and one PowerShell backdoor. While our visibility is limited, we hope that shedding light on this group will encourage other researchers to share information about this group.

IOCs

Files

File Paths

Some of the MainPath, LogFilePath and IfLogFilePath values that we encountered in PNGLoad samples:

Network

Mutexes

In CLRLoad samples, the mutex names that we encountered are:

aB82UduGX0EX
ad8TbUIZl5Ga
Mr2PJVxbIBD4
oERiQtKLgPgK
U37uxsCsA4Xm
Wo0r0KGWhYGO
xBUjQR2vxYTz
zYCLBWekRX3t
3c3401ad-e77d-4142-8db5-8eb5483d7e41
9xvzMsaWqxMy

A comprehensive list of Indicators of Compromise (IoCs) and samples can be found in our GitHub repository.

MITRE ATT&CK techniques

This table was built using version 11 of the MITRE ATT&CK framework.