For years, the Middle East has maintained its reputation as a fertile ground for advanced persistent threats (APTs). In the midst of routine monitoring of suspicious activities on the systems of high-profile customers, some based in this region, ESET Research stumbled upon a very sophisticated and unknown backdoor that we have named Deadglyph. We derived the name from artifacts found in the backdoor (such as 0xDEADB001, shown also in Table 1), coupled with the presence of a homoglyph attack. To the best of our knowledge, this is the first public analysis of this previously undocumented backdoor, used by a group that exhibits a notable degree of sophistication and expertise. Based on the targeting and additional evidence, we attribute Deadglyph with high confidence to the Stealth Falcon APT group.
Deadglyph’s architecture is unusual as it consists of cooperating components – one a native x64 binary, the other a .NET assembly. This combination is unusual because malware typically uses only one programming language for its components. This difference might indicate separate development of those two components while also taking advantage of unique features of the distinct programming languages they utilize. Different language can also be harnessed to hinder analysis, because mixed code is more difficult to navigate and debug.
The traditional backdoor commands are not implemented in the backdoor binary; instead, they are dynamically received by it from the command and control (C&C) server in the form of additional modules. This backdoor also features a number of capabilities to avoid being detected.
In this blogpost, we take a closer look at Deadglyph and provide a technical analysis of this backdoor, its purpose, and some of the additional components we obtained. We are also presenting our findings about Deadglyph at the LABScon 2023 conference.
Key points of the blogpost:
ESET Research discovered a sophisticated backdoor with unusual architecture that we have named Deadglyph.
The main components are encrypted using a machine-specific key.
Traditional backdoor commands are implemented via additional modules received from its C&C server.
We obtained three out of many modules – process creator, file reader, and info collector.
We attribute Deadglyph to the Stealth Falcon group.
Additionally, we found a related shellcode downloader; we postulate it could potentially be used for installation of Deadglyph.
The victim of the analyzed infiltration is a governmental entity in the Middle East that was compromised for espionage purposes. A related sample found on VirusTotal was also uploaded to the file-scanning platform from this region, specifically from Qatar. The targeted region is depicted on the map in Figure 1.
Figure 1. Victimology of Deadglyph; the related sample was uploaded to VirusTotal from Qatar (in darker color)
Stealth Falcon (also known as Project Raven or FruityArmor) is a threat group linked to the United Arab Emirates according to MITRE. Active since 2012, Stealth Falcon is known to target political activists, journalists, and dissidents in the Middle East. It was first discovered and described by Citizen Lab, which published an analysis of a campaign of spyware attacks in 2016.
In January 2019, Reuters published an investigative report on Project Raven, an initiative allegedly employing former NSA operatives and aiming at the same types of targets as Stealth Falcon. Based on these two reports referring to the same targets and attacks, Amnesty International has concluded (shown in Figure 2) that Stealth Falcon and Project Raven actually are the same group.
Figure 2. Claudio Guarnieri has connected Stealth Falcon with Project Raven
In September 2019, we published research on a backdoor, attributed to Stealth Falcon, that used an unusual technique, Background Intelligent Transfer Service, for C&C communication. We now reveal the result of our in-depth analysis of what presumably is the newest addition to Stealth Falcon’s espionage toolset.
Deadglyph’s loading chain consists of multiple components, as illustrated in Figure 3. The initial component is a registry shellcode loader, which loads shellcode from the registry. This extracted shellcode, in turn, loads the native x64 part of the backdoor – the Executor. The Executor subsequently loads the .NET part of the backdoor – the Orchestrator. Notably, the only component on system’s disk as a file is the initial component, which is in the form of a Dynamic Link Library (DLL). The remaining components are encrypted and stored within a binary registry value.
Figure 3. Deadglyph loading chain components
While the precise method of the initial compromise vector is not yet determined, our suspicion is that an installer component is involved in deploying further components and establishing persistence within the system.
In the rest of this section, we analyze each component.
Registry shellcode loader
Deadglyph’s initial component is a tiny DLL with a single export, named 1. This component is persisted using Windows Management Instrumentation (WMI) event subscription and serves as a registry shellcode loader. It is executed via the command line rundll32 C:WINDOWSSystem32\pbrtl.dll,#1.
The registry shellcode loader begins its operation by decrypting the path to the encrypted shellcode stored within the Windows registry, using RC4. We suspect the path is unique for each victim; in the case analyzed here, the registry path was:
The root registry key is either HKLM or HKCU, depending on whether the current process is running with elevated privileges or not. The same logic can be found in further components.
Following this, the loader derives a machine-specific RC4 key using the system UUID retrieved from the raw SMBIOS firmware table. Using this key, it loads, decrypts, and then executes the shellcode. It is important to highlight that this key derivation approach ensures that proper decryption won’t occur if the loader is executed on a different computer.
Interestingly, the loader can also be configured by a flag in its .data section to use a hardcoded key to decrypt the shellcode, instead of the machine-specific one.
We spotted a homoglyph attack mimicking Microsoft Corporation in the VERSIONINFO resource of this and other PE components. This method employs distinct Unicode characters that appear visually similar, but in this case not identical, to the original characters, specifically Greek Capital Letter San (U+03FA, Ϻ) and Cyrillic Small Letter O (U+043E, о) in Ϻicrоsоft Corpоratiоn.
Comprised of two parts, the registry shellcode consists of a decryption routine and an encrypted body. First, the decryption routine rotates each byte of the encrypted body to the left by one (ROL 0x01). Subsequently, control is transferred to this decrypted body. The decrypted body consists of a PE loader and a PE file, the latter being the Executor, which represents the native part of the backdoor. This loader is responsible for parsing and loading the associated PE file.
The Executor is the native x64 part of the Deadglyph backdoor, which does the following:
loads its configuration,
initializes the .NET runtime,
loads the embedded .NET part of the backdoor (the Orchestrator), and
acts as a library for the Orchestrator.
First, two default configurations embedded in the .data section are AES-decrypted. The configurations encompass various parameters, including encryption keys, safety and evasion settings, and the entry point of the subsequent component.
During the initial execution, those two default configurations are stored within the Windows registry, from where they are loaded on subsequent runs, enabling the implementation of updates. The registry path for each configuration is generated with the following format:
<variable_GUID> is a generated GUID, which is unique to each victim.
Following this, the .NET runtime is initialized, then the Executor RC4-decrypts the .NET part of the backdoor known as the Orchestrator. The Orchestrator is located within the .rsrc section of the Executor. The configuration specifies the Orchestrator’s execution method as an entry point. Moreover, a distinct structure is provided to facilitate accessibility of the Executor’s functions by the Orchestrator.
After launching the Orchestrator, the Executor acts as a support library for the Orchestrator. The Executor contains many interesting functions; we describe some of them in the following section, in context of their utilization by the Orchestrator and further loaded modules.
Written in .NET, the Orchestrator is the main component of the Deadglyph backdoor. This component’s primary role involves establishing communication with the C&C server and executing commands, often facilitated through the intermediary role of the Executor. In contrast to the preceding components, the Orchestrator is obfuscated, employing .NET Reactor. Internally, the backdoor is referred to as agent, which is a common name for the client part in various post-exploitation frameworks.
The Orchestrator first loads its configuration and two embedded modules, each accompanied by its own set of configurations, from resources. These resources are Deflate compressed and AES encrypted. They are referenced by an ID that is SHA-1 hashed into a resource name. An overview of these resources is provided in Table 1.
Table 1. Orchestrator resources
Network module configuration.
Timer module configuration.
The configuration of the Orchestrator and embedded modules is stored in XML format. An example of an Orchestrator configuration is shown in Figure 4.
Figure 4. Orchestrator configuration
The description of Orchestrator configuration entries is shown in Table 2.
Table 2. Orchestrator configuration entries
AES key used for persisting module configurations.
Network module initialization method name.
Unknown network module-related flag.
Timer module initialization method name.
Flag enabling usage of machine-specific AES key (system UUID) for resources.
Network module resource ID.
Timer module resource ID.
After the resource components are loaded, multiple threads are created to carry out distinct tasks. One of these threads is responsible for conducting environment checks, a function implemented within the Executor. Another thread is devoted to establishing periodic communication with the C&C server, enabling the retrieval of commands. Lastly, a set of three threads is employed for the purpose of executing received commands and subsequently transmitting any generated output back to the C&C server.
The environment-checking thread monitors running processes to identify unwanted ones. This thread operates with two distinct lists of process names. If a process on the first list is detected, C&C communication and command execution is paused until the unwanted process no longer exists. If there is a match for any process on the second list, the backdoor immediately quits and uninstalls itself.
Neither list was configured in the analyzed instance, so we don’t know what processes might typically be checked for; we believe it is probably intended to evade analysis tools that could detect suspicious activity and lead to discovery of the backdoor.
The Orchestrator utilizes two embedded modules for C&C communication – Timer and Network. Like the Orchestrator, these modules are obfuscated with .NET Reactor. The configuration for both modules is supplied by the Orchestrator. Within the Orchestrator, a preset configuration for the modules is included; optionally, the Orchestrator can also load an updated configuration version from the registry:
The backdoor contains an interesting safety measure related to communication. If the backdoor is unable to establish communication with the C&C server for a duration surpassing a predefined threshold, configured within the Executor, a self-uninstallation mechanism is triggered. This time threshold is specified in hours and was set at one hour in the examined case.
This approach serves a twofold purpose. On one hand, it prevents the generation of redundant network requests towards an inaccessible server. On the other hand, it reduces the chances of subsequent detection if the operators lose control over the backdoor.
This small module executes the specified callback at a configurable interval. It is used by the Orchestrator in combination with the Network module to communicate with the C&C server periodically. To prevent the creation of detectable patterns in network logs, the execution interval is subject to randomization, based on a percentage specified in the configuration. In the analyzed instance, the interval was set to five minutes, with a ±20% variation introduced for randomness.
Another method to avoid detectable network patterns in periodic communication can be found in generation of requests sent to the C&C server. This mechanism, implemented in the Executor, involves the inclusion of padding of varying length, comprised of random bytes, within the requests, resulting in requests of diverse sizes.
The Network module implements communication with the C&C servers specified in its configuration. It can send data to a C&C server using HTTP(S) POST requests. Notably, it offers several mechanisms to acquire proxy configuration details. This feature suggests a potential focus on environments where direct internet access is not available.
An example of a decrypted (and beautified) configuration is shown in Figure 5.
Figure 5. Network module configuration
Configuration entries contain details related to network communications – C&C URLs, HTTP User-Agent, and optionally a proxy configuration.
When communicating with the C&C server, a custom binary protocol with encrypted content is used underneath HTTPS.
The Orchestrator receives commands from the C&C server in the form of tasks, which are queued for execution. There are three kinds of tasks processed:
Executor tasks, and
The first two kinds are received from the C&C server and the third is created internally to upload the output of commands and errors.
Orchestrator tasks offer the ability to manage the configuration of the Network and Timer modules, and also to cancel pending tasks. The overview of Orchestrator tasks is shown in Table 3.
Table 3. Orchestrator tasks
Set configuration of network and timer modules.
Get configuration of network and timer modules.
Cancel all tasks.
Executor tasks offer the ability to manage the backdoor and execute additional modules. It’s notable that the traditional backdoor functionality is not inherently present within the binary itself. Instead, these functions are obtained from the C&C server in the form of PE files or shellcode. The full extent of the backdoor’s potential remains unknown without these additional modules, which effectively unlock its true capabilities. An overview of module tasks is shown in Table 4, which includes details about the few identified modules. Similarly, Table 5 provides an overview of management tasks associated with the Executor.
Table 4. Executor tasks – modules
Table 5. Executor tasks – management
Set Executor configuration
Get Executor configuration
The command that sets the Executor configuration can change the:
unwanted process lists,
time threshold of C&C communication failure, and
time limit for execution of additional modules.
We managed to obtain three unique modules from the C&C server, each corresponding to a different Executor task type, as shown in Table 4. Based on available information, we estimate there are nine to fourteen modules in total. As the modules are in fact backdoor commands, they have one basic operation to execute and then optionally return their output. The modules we obtained are DLLs with one unnamed export (ordinal 1), in which they resolve necessary API functions and call the main function.
When executed, the modules are provided with an API resolution function, which can resolve Windows APIs and custom Executor APIs. The Windows APIs are referenced by a DWORD hash, calculated from the name of the API and its DLL. Small hash values (<41) are treated specially, referencing the Executor API function. The Executor API comprises a total of 39 functions that are accessible to the modules. These functions pertain to a variety of operations, including:
encryption and hashing,
access Token Impersonation, and
In the rest of this section, we describe the modules that we obtained.
Module 0x69 executes the specified command line as a new process and provides the resulting output back to the Orchestrator. The process can be created under a different user, and its execution time can be limited. Notably, an unusual Job API is used in this module’s functionality.
This module was served with the command line cmd.exe /c tasklist /v.
We assume it serves as an idle command issued automatically, while the operators wait for something interesting to happen on the compromised computer.
Module 0x6C collects extensive information about the computer via WMI queries and passes it back to the Orchestrator. Information about the following is collected:
environment variables, and
Module 0x64 reads the specified file and passes the content back to the Orchestrator. Optionally, it can delete the file after reading.
We saw this module used to retrieve the victim’s Outlook data file
Chain with shellcode downloader
In the process of investigating Deadglyph, we encountered a dubious CPL file signed with an expired certificate and no countersignature with a timestamp, which had been uploaded to VirusTotal from Qatar. Upon closer examination, it became evident that this CPL file functioned as a multistage shellcode downloader, sharing certain code resemblances with Deadglyph. The loading chain is illustrated in Figure 6.
Figure 6. Shellcode downloader loading chain
In its initial form, which serves as the first stage, this file anticipates having a .cpl extension (Control Panel file) and is meant to be executed via a double-click action. Upon execution in this manner, the embedded shellcode undergoes XOR decryption, and the running processes are checked to identify a suitable host process for subsequent injection.
If avp.exe (a Kaspersky endpoint security process) is running, %windir%system32UserAccountBroker.exe is used. Otherwise, the default browser is used. Then, it creates the host process in a suspended state, injects the shellcode by hijacking its main thread, and resumes the thread.
The second stage, the shellcode, consists of two parts. The first part of the shellcode resolves API hashes, using the same unique hash calculation technique employed in Deadglyph, and decrypts strings with process names. It starts a self-delete thread tasked with overwriting and subsequently erasing the first-stage file. Following this, the shellcode proceeds to inspect the currently active processes, targeting a security solution.
If any of the specified processes are detected, the shellcode creates a sleeper thread with the lowest priority (THREAD_PRIORITY_IDLE) and allows it to remain active for a duration of 60 seconds before terminating its operation. This interval is likely implemented as a precautionary measure to evade certain detection mechanisms employed by security solutions. Finally, the shellcode proceeds to invoke the execution of the second part of its code.
The second part of the shellcode loads an embedded PE file with stage three and calls its export with ordinal number 1.
The third stage, a DLL, serves as a .NET loader and contains the payload in its .rsrc section.
To load the payload, the .NET runtime is initialized. During the .NET initialization, two intriguing techniques are performed, seemingly intended to evade Windows Antimalware Scan Interface (AMSI) scanning:
The .NET loader temporarily hooks theGetModuleHandleW import in the loaded clr.dll, while calling ICorRuntimeHost::Start. The hook tampers with the return value when GetModuleHandleW is called with NULL. It returns a pointer to a dummy PE with no sections.
It then subtly patches the AmsiInitialize import name string in the .rdata section of the loaded clr.dll to amsiinitialize.
The fourth stage is a .NET assembly, obfuscated with ConfuserEx, that serves as a shellcode downloader. First, it XOR-decrypts its configuration in XML format from its resources. A beautified version of the extracted configuration is presented in Figure 7. The configuration entries contain details related to network communication and blocklisted processes.
Figure 7. Shellcode downloader configuration
Before proceeding, it checks the running processes against a list of blocklisted processes from the configuration. If a match is detected, the execution halts. It is important to note that in the analyzed instance, this blocklist wasn’t set up.
Next, it sends an HTTP GET request to the C&C server to retrieve some shellcode, using parameters specified in the configuration (URL, User-Agent, and optionally Proxy). Regrettably, during our investigation we were unable to acquire any shellcode from the C&C server. Nonetheless, we hypothesize that the content being retrieved could potentially serve as the installer for Deadglyph.
Following this, the retrieved shellcode is executed within a newly created thread. After waiting until the shellcode thread finishes execution, the shellcode downloader removes all files located in the directory %WINDIR%ServiceProfilesLocalServiceAppDataLocalTempTfsStoreTfs_DAV.
Finally, it makes an attempt to delete itself after a 20-second interval, employing the subsequent command, before concluding its operation and exiting:
cmd.exe choice /C Y /N /D Y /T 20 & Del /f /q <current_process_exe_path>
This self-deletion does not make sense in this chain. This is due to the fact that the shellcode downloader is executed within a browser or system process after being injected, rather than operating as an independent executable. Moreover, the initial file was already deleted by the second stage. This observation suggests that the shellcode downloader might not be an exclusive payload of this chain and may also be used separately in other operations.
We have discovered and analyzed a sophisticated backdoor used by the Stealth Falcon group that we have named Deadglyph. It has an unusual architecture, and its backdoor capabilities are provided by its C&C in the form of additional modules. We managed to obtain three of these modules, uncovering a fraction of Deadglyph’s full capabilities.
Notably, Deadglyph boasts a range of counter-detection mechanisms, including continuous monitoring of system processes and the implementation of randomized network patterns. Furthermore, the backdoor is capable of uninstalling itself to minimize the likelihood of its detection in certain cases.
Additionally, our investigation led us to the discovery of a compelling multistage shellcode downloader chain on VirusTotal. We suspect this downloader chain is likely leveraged in the installation process of Deadglyph.
For any inquiries about our research published on WeLiveSecurity, please contact us at email@example.com.ESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.
Registry Shellcode Loader.
Deadglyph Backdoor – Executor.
Deadglyph Backdoor – Orchestrator.
Orchestrator Network module.
Orchestrator Timer module.
Process creator module.
File reader module.
Info collector module.
First stage of shellcode downloader chain.
Deadglyph C&C server.
Deadglyph C&C server.
Shellcode downloader C&C server.
MITRE ATT&CK techniques
This table was built using version 13 of the MITRE ATT&CK framework.
Acquire Infrastructure: Domains
Stealth Falcon has registered domains for C&C servers and to obtain a code-signing certificate.
Acquire Infrastructure: Virtual Private Server
Stealth Falcon has used VPS hosting providers for C&C servers.
Develop Capabilities: Malware
Stealth Falcon has developed custom malware, including custom loaders and the Deadglyph backdoor.
Obtain Capabilities: Code Signing Certificates
Stealth Falcon has obtained a code-signing certificate.
Windows Management Instrumentation
Deadglyph uses WMI to execute its loading chain.
Command and Scripting Interpreter: Windows Command Shell
Shellcode downloader uses cmd.exe to delete itself.
A Deadglyph module uses CreateProcessW and CreateProcessAsUserW API functions for execution.
User Execution: Malicious File
The shellcode downloader chain requires the user to double-click and execute it.
Event Triggered Execution: Windows Management Instrumentation Event Subscription
The initial Deadglyph loader is persisted using WMI event subscription.
Obfuscated Files or Information
Deadglyph components are encrypted. Deadglyph Orchestrator and embedded modules are obfuscated with .NET Reactor.
The shellcode downloader is obfuscated with ConfuserEx.
Indicator Removal: File Deletion
Deadglyph can uninstall itself.
The shellcode downloader chain deletes itself and deletes files in the WebDAV cache.
Deadglyph stores its configuration and encrypted payload in the registry.
Access Token Manipulation
Deadglyph can impersonate another user.
Deobfuscate/Decode Files or Information
Deadglyph decrypts encrypted strings.
The shellcode downloader chain decrypts its components and configurations.
System Binary Proxy Execution: Rundll32
The initial Deadglyph loader is executed using rundll32.exe.
Execution Guardrails: Environmental Keying
Deadglyph is encrypted using a machine-specific key derived from the system UUID.
Impair Defenses: Disable or Modify Tools
The shellcode downloader avoids AMSI scanning by patching clr.dll in memory .
Reflective Code Loading
Deadglyph reflectively loads its modules using a custom PE loader.
System Service Discovery
A Deadglyph module discovers services using the WMI query SELECT * FROM Win32_Service.
The shellcode downloader chain queries the registry for the default browser.
System Network Configuration Discovery
A Deadglyph module discovers network adapters using WMI queries SELECT * FROM Win32_NetworkAdapter and SELECT * FROM Win32_NetworkAdapterConfiguration where InterfaceIndex=%d.
System Owner/User Discovery
A Deadglyph module discovers users with the WMI query SELECT * FROM Win32_UserAccount.
A Deadglyph module discovers processes using WMI query SELECT * FROM Win32_Process.
System Information Discovery
A Deadglyph module discovers system information such as OS version, drives, environment variables, and drivers using WMI queries.
A Deadglyph module discovers installed software using WMI query SELECT * FROM Win32_Product.
Software Discovery: Security Software Discovery
A Deadglyph module discovers security software using WMI queries SELECT * FROM AntiVirusProduct, SELECT * FROM AntiSpywareProduct and SELECT * FROM FirewallProduct.
The shellcode downloader chain checks running processes for a security solution.
Data from Local System
Deadglyph has a module for reading files.
Command and Control
Application Layer Protocol: Web Protocols
Deadglyph and the shellcode downloader communicate with the C&C server via the HTTP protocol.
Deadglyph and the shellcode downloader can use HTTP proxy for C&C communication.
Encrypted Channel: Symmetric Cryptography
Deadglyph uses AES to encrypt C&C communications.
Exfiltration Over C2 Channel
Deadglyph uses the C&C channel for exfiltration.