Worok: The big picture

Focused mostly on Asia, this new cyberespionage group uses undocumented tools, including steganographically extracting PowerShell payloads from PNG files

Focused mostly on Asia, this new cyberespionage group uses undocumented tools, including steganographically extracting PowerShell payloads from PNG files

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


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

Field nameDescription
nouse / ikuyrtydyfg
(other samples)
ClientIdClient identifier, used for the following purposes:
· As a value when constructing the Cookie header for C&C communications.
· As a cryptographic artifact for sent data encryption.
VersionVersion number of PowHeartBeat.
ExecTimesNumber of allowed execution attempts when issuing a RunCmd (command running) command.
UserAgentUser agent used for C&C communications.
RefererReferer header used for C&C communications.
Values used to construct the Cookie header for C&C communications.
UrlHttpsProtocol to use for C&C communications.
URL, domain(s), or IP address used as the C&C server. If Domains is not empty, it is chosen instead of IPAddress. In other cases, IPAddress is taken.
UrlSendHeartBeatURL path used when the backdoor asks the C&C server for commands.
UrlSendResultURL path used when the backdoor sends the results of the command back to the C&C server.
GetUrlComplete URL, used by PowHeartBeat to request commands from the C&C server. It is the concatenation of the URL elements above.
PutUrlSame as GetUrl but used to send the results of the command back to the C&C server.
ProxyEnableFlagFlag indicating whether the backdoor must use a proxy or not in order to communicate with the C&C server.
ProxymsgAddress of the proxy to use if ProxyEnableFlag is set to $true.
IntervalTime in seconds that the script sleeps for between GET requests.
BasicConfigPathPath to an optional configuration file containing UpTime, DownTime, DefaultInterval, and Domains. Those values will be overridden if the file is present.
UpTimeTime of day from which the backdoor starts operating, meaning it starts making GET requests to the C&C server.
DownTimeTime of day until which the backdoor can operate, meaning the time when it stops making requests to the C&C server.
DomainIndexIndex of the current domain name to use for communications with the C&C server. In case a request returns an error message different from 304 (“Not modified”), DomainIndex is increased.
SecretKeyKey used to decrypt/encrypt the configuration. Configuration is encrypted with multiple-byte XOR.
IfLogFilePathFlag indicating whether logging is enabled.
logpathPath of the log file.
ProxyFileFile path of the optional proxy configuration. If it is empty or not found in the file system, the backdoor retrieves the user’s proxy settings from the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer .
IfConfigFlag indicating whether to use a configuration file.

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

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.


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:

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.

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.


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

NameCommand IdentifierDescription
Cmd0x02Execute a PowerShell command.
Exe0x04Execute a command as a process.
FileUpload0x06Upload a file to the victim machine. File content is gzip-compressed.
FileDownLoad0x08Download a file from the victim machine, and return file path, file length, creation time, access times, and file content to the C&C server.
FileView0x0AGet file information of a specific directory, in particular:
· Filenames
· File attributes
· Last write times
· File contents
FileDelete0x0CDelete a file.
FileRename0x0ERename or move a file.
ChangeDir0x10Change the current working location of the backdoor.
Info0x12Get a category of information according to the specified argument:
· “Basic information”: ClientId, Version, host name, IP addresses, explorer.exe version and size information, OS (architecture and flag indicating if the machine is a server), Interval, current directory, drive information (name, type, free space and total size), current time
· “Time-Interval information”: Interval and current time
· “Domain information”: decrypted configuration file content
Config0x14Update the configuration file content and reload the configuration.
N/A0x63Backdoor exit.

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.


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.

For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com.

ESET Research also offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.



SHA-1FilenameESET Detection nameComment
CE430A27DF87A6952D732B4562A7C23BEF4602D1tmp.ps1PowerShell/PowHeartBeat.A PowHeartBeat
EDE5AB2B94BA85F28D5EE22656958E4ECD77B6FFscriptPowerShell/PowHeartBeat.A PowHeartBeat

File Paths

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

C:\Program Files\VMware\VMware Tools\C:\Program Files\VMware\VMware Tools\VMware VGAuth\readme.txtC:\Program Files\VMware\VMware Tools\VMware VGAuth\VMWSU_V1_1.dll
C:\Program Files\WinRar\C:\Program Files\WinRar\rarinstall.logC:\Program Files\WinRar\des.dat
C:\Program Files\UltraViewer\C:\Program Files\UltraViewer\‌CopyRights.datC:\Program Files\UltraViewer\uvcr.dll




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


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.

ReconnaissanceT1592.002Gather Victim Host Information: SoftwarePowHeartBeat gathers explorer.exe's information.
T1592.001Gather Victim Host Information: HardwarePowHeartBeat gathers information about drives.
T1590.005Gather Victim Network Information: IP AddressesPowHeartBeat gathers IP addresses of the compromised computer.
Resource DevelopmentT1583.004Acquire Infrastructure: ServerWorok uses its own C&C servers.
T1588.002Obtain Capabilities: ToolWorok deployed multiple publicly available tools on the compromised machines.
T1583.001Acquire Infrastructure: DomainsWorok has registered domains to facilitate C&C communication and staging.
T1588.005Obtain Capabilities: ExploitsWorok has used the ProxyShell vulnerability.
T1587.001Develop Capabilities: MalwareWorok has developed its own malware: CLRLoad, PNGLoad, PowHeartBeat.
T1587.003Develop Capabilities: Digital CertificatesWorok has created Let’s Encrypt SSL certificates in order to enable mutual TLS authentication for malware.
ExecutionT1059.001Command and Scripting Interpreter: PowerShellPowHeartBeat is written in PowerShell.
PersistenceT1505.003Server Software Component: Web ShellWorok uses the webshell ReGeorg.
Defense EvasionT1140Deobfuscate/Decode Files or InformationWorok uses various custom XOR-based schemes to encrypt strings and logs in PowHeartBeat, PNGLoad, and CLRLoad.
T1036.005Masquerading: Match Legitimate Name or LocationPNGLoad samples are deployed in legitimate-looking VMWare directories.
Credential AccessT1003.001OS Credential Dumping: LSASS MemoryWorok uses Mimikatz to dump credentials from LSASS memory.
DiscoveryT1082System Information DiscoveryPowHeartBeat gathers OS information.
T1083File and Directory DiscoveryPowHeartBeat can list files and directories.
T1046Network Service DiscoveryWorok uses NbtScan to obtain network information on compromised machines.
T1124System Time DiscoveryPowHeartBeat gathers the victim’s time information.
CollectionT1005Data from Local SystemPowHeartBeat gathers data from the local system.
T1560.002Archive Collected Data: Archive via LibraryPowHeartBeat gzip-compresses data before sending it to the C&C server.
Command and ControlT1071.001Application Layer Protocol: Web ProtocolsSome PowHeartBeat variants use HTTP as the communication protocol with the C&C server.
T1090.001Proxy: Internal ProxyPowHeartBeat handles proxy configuration on the victim’s machine.
T1001.002Data Obfuscation: SteganographyPNGLoad extracts pixel values from .png files to reconstruct payloads.
T1573.002Encrypted Channel: Asymmetric CryptographyPowHeartBeat handles HTTPS communications with the C&C server.
T1095Non-Application Layer ProtocolSome PowHeartBeat variants use ICMP as the communication protocol with the C&C server.
T1132.001Data Encoding: Standard EncodingWorok uses XOR encoding in PowHeartBeat, and PNGLoad.
T1132.002Data Encoding: Non-Standard EncodingWorok uses XOR encoding algorithms that make use of an additional salt.
ExfiltrationT1041Exfiltration Over C2 ChannelPowHeartBeat uses its C&C communication channel to exfiltrate information.

Sign up to receive an email update whenever a new article is published in our Ukraine Crisis – Digital Security Resource Center