{
	"id": "8275d183-28e4-4130-8c76-958c0b14f265",
	"created_at": "2026-04-06T03:36:14.344173Z",
	"updated_at": "2026-04-10T03:25:36.490548Z",
	"deleted_at": null,
	"sha1_hash": "0e8d39dc67c1d1c2d8fe5b1422fa40ec8c95c062",
	"title": "Stealth Falcon preying over Middle Eastern skies with Deadglyph",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 595858,
	"plain_text": "Stealth Falcon preying over Middle Eastern skies with Deadglyph\r\nBy ESET Research\r\nArchived: 2026-04-06 03:26:56 UTC\r\nFor years, the Middle East has maintained its reputation as a fertile ground for advanced persistent threats (APTs).\r\nIn the midst of routine monitoring of suspicious activities on the systems of high-profile customers, some based in\r\nthis region, ESET Research stumbled upon a very sophisticated and unknown backdoor that we have named\r\nDeadglyph. We derived the name from artifacts found in the backdoor (such as 0xDEADB001, shown also in Table\r\n1), coupled with the presence of a homoglyph attack. To the best of our knowledge, this is the first public analysis\r\nof this previously undocumented backdoor, used by a group that exhibits a notable degree of sophistication and\r\nexpertise. Based on the targeting and additional evidence, we attribute Deadglyph with high confidence to the\r\nStealth Falcon APT group.\r\nDeadglyph’s architecture is unusual as it consists of cooperating components – one a native x64 binary, the other a\r\n.NET assembly. This combination is unusual because malware typically uses only one programming language for its\r\ncomponents. This difference might indicate separate development of those two components while also taking\r\nadvantage of unique features of the distinct programming languages they utilize. Different language can also be\r\nharnessed to hinder analysis, because mixed code is more difficult to navigate and debug.\r\nThe traditional backdoor commands are not implemented in the backdoor binary; instead, they are dynamically\r\nreceived by it from the command and control (C\u0026C) server in the form of additional modules. This backdoor also\r\nfeatures a number of capabilities to avoid being detected.\r\nIn this blogpost, we take a closer look at Deadglyph and provide a technical analysis of this backdoor, its purpose,\r\nand some of the additional components we obtained. We are also presenting our findings about Deadglyph at the\r\nLABScon 2023 conference.\r\nKey points of the blogpost:\r\nESET Research discovered a sophisticated backdoor with unusual architecture that we have\r\nnamed Deadglyph.\r\nThe main components are encrypted using a machine-specific key.\r\nTraditional backdoor commands are implemented via additional modules received from its C\u0026C\r\nserver.\r\nWe obtained three out of many modules – process creator, file reader, and info collector.\r\nWe attribute Deadglyph to the Stealth Falcon group.\r\nAdditionally, we found a related shellcode downloader; we postulate it could potentially be used\r\nfor installation of Deadglyph.\r\nThe victim of the analyzed infiltration is a governmental entity in the Middle East that was compromised for\r\nespionage purposes. A related sample found on VirusTotal was also uploaded to the file-scanning platform from this\r\nregion, specifically from Qatar. The targeted region is depicted on the map in Figure 1.\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 1 of 22\n\nFigure 1. Victimology of Deadglyph; the related sample was uploaded to VirusTotal from Qatar (in\r\ndarker color)\r\nStealth Falcon (also known as Project Raven or FruityArmor) is a threat group linked to the United Arab Emirates\r\naccording to MITRE. Active since 2012, Stealth Falcon is known to target political activists, journalists, and\r\ndissidents in the Middle East. It was first discovered and described by Citizen Lab, which published an analysis of a\r\ncampaign of spyware attacks in 2016.\r\nIn January 2019, Reuters published an investigative report on Project Raven, an initiative allegedly employing\r\nformer NSA operatives and aiming at the same types of targets as Stealth Falcon. Based on these two reports\r\nreferring to the same targets and attacks, Amnesty International has concluded (shown in Figure 2) that Stealth\r\nFalcon and Project Raven actually are the same group.\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 2 of 22\n\nFigure 2. Claudio Guarnieri has connected Stealth Falcon with Project Raven\r\nIn September 2019, we published research on a backdoor, attributed to Stealth Falcon, that used an unusual\r\ntechnique, Background Intelligent Transfer Service, for C\u0026C communication. We now reveal the result of our in-depth analysis of what presumably is the newest addition to Stealth Falcon’s espionage toolset.\r\nDeadglyph backdoor\r\nDeadglyph’s loading chain consists of multiple components, as illustrated in Figure 3. The initial component is a\r\nregistry shellcode loader, which loads shellcode from the registry. This extracted shellcode, in turn, loads the native\r\nx64 part of the backdoor – the Executor. The Executor subsequently loads the .NET part of the backdoor – the\r\nOrchestrator. Notably, the only component on system’s disk as a file is the initial component, which is in the form of\r\na Dynamic Link Library (DLL). The remaining components are encrypted and stored within a binary registry value.\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 3 of 22\n\nFigure 3. Deadglyph loading chain components\r\nWhile the precise method of the initial compromise vector is not yet determined, our suspicion is that an installer\r\ncomponent is involved in deploying further components and establishing persistence within the system.\r\nIn the rest of this section, we analyze each component.\r\nRegistry shellcode loader\r\nDeadglyph’s initial component is a tiny DLL with a single export, named 1. This component is persisted using\r\nWindows Management Instrumentation (WMI) event subscription and serves as a registry shellcode loader. It is\r\nexecuted via the command line rundll32 C:\\WINDOWS\\System32\\\\pbrtl.dll,#1.\r\nThe registry shellcode loader begins its operation by decrypting the path to the encrypted shellcode stored within the\r\nWindows registry, using RC4. We suspect the path is unique for each victim; in the case analyzed here, the registry\r\npath was:\r\nSoftware\\Classes\\CLSID\\{5abc7f42-1112-5099-b082-ce8d65ba0c47}\\cAbRGHLg\r\nThe root registry key is either HKLM or HKCU, depending on whether the current process is running with elevated\r\nprivileges or not. The same logic can be found in further components.\r\nFollowing this, the loader derives a machine-specific RC4 key using the system UUID retrieved from the raw\r\nSMBIOS firmware table. Using this key, it loads, decrypts, and then executes the shellcode. It is important to\r\nhighlight that this key derivation approach ensures that proper decryption won’t occur if the loader is executed on a\r\ndifferent computer.\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 4 of 22\n\nInterestingly, the loader can also be configured by a flag in its .data section to use a hardcoded key to decrypt the\r\nshellcode, instead of the machine-specific one.\r\nWe spotted a homoglyph attack mimicking Microsoft Corporation in the VERSIONINFO resource of this and other\r\nPE components. This method employs distinct Unicode characters that appear visually similar, but in this case not\r\nidentical, to the original characters, specifically Greek Capital Letter San (U+03FA, Ϻ) and Cyrillic Small Letter O\r\n(U+043E, о) in Ϻicrоsоft Corpоratiоn.\r\nRegistry shellcode\r\nComprised of two parts, the registry shellcode consists of a decryption routine and an encrypted body. First, the\r\ndecryption routine rotates each byte of the encrypted body to the left by one (ROL 0x01). Subsequently, control is\r\ntransferred to this decrypted body. The decrypted body consists of a PE loader and a PE file, the latter being the\r\nExecutor, which represents the native part of the backdoor. This loader is responsible for parsing and loading the\r\nassociated PE file.\r\nExecutor\r\nThe Executor is the native x64 part of the Deadglyph backdoor, which does the following:\r\nloads its configuration,\r\ninitializes the .NET runtime,\r\nloads the embedded .NET part of the backdoor (the Orchestrator), and\r\nacts as a library for the Orchestrator.\r\nFirst, two default configurations embedded in the .data section are AES-decrypted. The configurations encompass\r\nvarious parameters, including encryption keys, safety and evasion settings, and the entry point of the subsequent\r\ncomponent.\r\nDuring the initial execution, those two default configurations are stored within the Windows registry, from where\r\nthey are loaded on subsequent runs, enabling the implementation of updates. The registry path for each\r\nconfiguration is generated with the following format:\r\n{HKCU|HKLM}\\Software\\Classes\\CLSID\\{\u003cvariable_GUID\u003e}\\(Default)\r\n\u003cvariable_GUID\u003e is a generated GUID, which is unique to each victim.\r\nFollowing this, the .NET runtime is initialized, then the Executor RC4-decrypts the .NET part of the backdoor\r\nknown as the Orchestrator. The Orchestrator is located within the .rsrc section of the Executor. The configuration\r\nspecifies the Orchestrator’s execution method as an entry point. Moreover, a distinct structure is provided to\r\nfacilitate accessibility of the Executor’s functions by the Orchestrator.\r\nAfter launching the Orchestrator, the Executor acts as a support library for the Orchestrator. The Executor contains\r\nmany interesting functions; we describe some of them in the following section, in context of their utilization by the\r\nOrchestrator and further loaded modules.\r\nOrchestrator\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 5 of 22\n\nWritten in .NET, the Orchestrator is the main component of the Deadglyph backdoor. This component’s primary\r\nrole involves establishing communication with the C\u0026C server and executing commands, often facilitated through\r\nthe intermediary role of the Executor. In contrast to the preceding components, the Orchestrator is obfuscated,\r\nemploying .NET Reactor. Internally, the backdoor is referred to as agent, which is a common name for the client\r\npart in various post-exploitation frameworks.\r\nInitialization\r\nThe Orchestrator first loads its configuration and two embedded modules, each accompanied by its own set of\r\nconfigurations, from resources. These resources are Deflate compressed and AES encrypted. They are referenced by\r\nan ID that is SHA-1 hashed into a resource name. An overview of these resources is provided in Table 1.\r\nTable 1. Orchestrator resources\r\n \r\nResource name\r\nID\r\n(decimal)\r\nID (hex) Description\r\n43ed9a3ad74ed7ab74c345a876b6be19039d4c8c 2570286865 0x99337711\r\nOrchestrator\r\nconfiguration.\r\n3a215912708eab6f56af953d748fbfc38e3bb468 3740250113 0xDEEFB001 Network module.\r\n42fb165bc9cf614996027a9fcb261d65fd513527 3740250369 0xDEEFB101\r\nNetwork module\r\nconfiguration.\r\ne204cdcf96d9f94f9c19dbe385e635d00caaf49d 3735924737 0xDEADB001 Timer module.\r\nabd2db754795272c21407efd5080c8a705a7d151 3735924993 0xDEADB101\r\nTimer module\r\nconfiguration.\r\nThe configuration of the Orchestrator and embedded modules is stored in XML format. An example of an\r\nOrchestrator configuration is shown in Figure 4.\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 6 of 22\n\nFigure 4. Orchestrator configuration\r\nThe description of Orchestrator configuration entries is shown in Table 2.\r\nTable 2. Orchestrator configuration entries\r\nKey Description\r\nk AES key used for persisting module configurations.\r\na Network module initialization method name.\r\nb Unknown network module-related flag.\r\nc Timer module initialization method name.\r\nd Flag enabling usage of machine-specific AES key (system UUID) for resources.\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 7 of 22\n\np Network module resource ID.\r\nt Timer module resource ID.\r\nAfter the resource components are loaded, multiple threads are created to carry out distinct tasks. One of these\r\nthreads is responsible for conducting environment checks, a function implemented within the Executor. Another\r\nthread is devoted to establishing periodic communication with the C\u0026C server, enabling the retrieval of commands.\r\nLastly, a set of three threads is employed for the purpose of executing received commands and subsequently\r\ntransmitting any generated output back to the C\u0026C server.\r\nThe environment-checking thread monitors running processes to identify unwanted ones. This thread operates with\r\ntwo distinct lists of process names. If a process on the first list is detected, C\u0026C communication and command\r\nexecution is paused until the unwanted process no longer exists. If there is a match for any process on the second\r\nlist, the backdoor immediately quits and uninstalls itself.\r\nNeither list was configured in the analyzed instance, so we don’t know what processes might typically be checked\r\nfor; we believe it is probably intended to evade analysis tools that could detect suspicious activity and lead to\r\ndiscovery of the backdoor.\r\nCommunication\r\nThe Orchestrator utilizes two embedded modules for C\u0026C communication – Timer and Network. Like the\r\nOrchestrator, these modules are obfuscated with .NET Reactor. The configuration for both modules is supplied by\r\nthe Orchestrator. Within the Orchestrator, a preset configuration for the modules is included; optionally, the\r\nOrchestrator can also load an updated configuration version from the registry:\r\n{HKCU|HKLM}\\Software\\Classes\\CLSID\\{\u003cvariable_GUID\u003e}\\\u003cmod_cfg_res_ID\u003e\r\nThe backdoor contains an interesting safety measure related to communication. If the backdoor is unable to\r\nestablish communication with the C\u0026C server for a duration surpassing a predefined threshold, configured within\r\nthe Executor, a self-uninstallation mechanism is triggered. This time threshold is specified in hours and was set at\r\none hour in the examined case.\r\nThis approach serves a twofold purpose. On one hand, it prevents the generation of redundant network requests\r\ntowards an inaccessible server. On the other hand, it reduces the chances of subsequent detection if the operators\r\nlose control over the backdoor.\r\nTimer module\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 8 of 22\n\nThis small module executes the specified callback at a configurable interval. It is used by the Orchestrator in\r\ncombination with the Network module to communicate with the C\u0026C server periodically. To prevent the creation of\r\ndetectable patterns in network logs, the execution interval is subject to randomization, based on a percentage\r\nspecified in the configuration. In the analyzed instance, the interval was set to five minutes, with a ±20% variation\r\nintroduced for randomness.\r\nAnother method to avoid detectable network patterns in periodic communication can be found in generation of\r\nrequests sent to the C\u0026C server. This mechanism, implemented in the Executor, involves the inclusion of padding\r\nof varying length, comprised of random bytes, within the requests, resulting in requests of diverse sizes.\r\nNetwork module\r\nThe Network module implements communication with the C\u0026C servers specified in its configuration. It can send\r\ndata to a C\u0026C server using HTTP(S) POST requests. Notably, it offers several mechanisms to acquire proxy\r\nconfiguration details. This feature suggests a potential focus on environments where direct internet access is not\r\navailable.\r\nAn example of a decrypted (and beautified) configuration is shown in Figure 5.\r\nFigure 5. Network module configuration\r\nConfiguration entries contain details related to network communications – C\u0026C URLs, HTTP User-Agent, and\r\noptionally a proxy configuration.\r\nWhen communicating with the C\u0026C server, a custom binary protocol with encrypted content is used underneath\r\nHTTPS.\r\nCommands\r\nThe Orchestrator receives commands from the C\u0026C server in the form of tasks, which are queued for execution.\r\nThere are three kinds of tasks processed:\r\nOrchestrator tasks,\r\nExecutor tasks, and\r\nUpload tasks.\r\nThe first two kinds are received from the C\u0026C server and the third is created internally to upload the output of\r\ncommands and errors.\r\nOrchestrator tasks\r\nOrchestrator tasks offer the ability to manage the configuration of the Network and Timer modules, and also to\r\ncancel pending tasks. The overview of Orchestrator tasks is shown in Table 3.\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 9 of 22\n\nTable 3. Orchestrator tasks\r\nType Description\r\n0x80 Set configuration of network and timer modules.\r\n0x81 Get configuration of network and timer modules.\r\n0x82 Cancel task.\r\n0x83 Cancel all tasks.\r\nExecutor tasks\r\nExecutor tasks offer the ability to manage the backdoor and execute additional modules. It’s notable that the\r\ntraditional backdoor functionality is not inherently present within the binary itself. Instead, these functions are\r\nobtained from the C\u0026C server in the form of PE files or shellcode. The full extent of the backdoor’s potential\r\nremains unknown without these additional modules, which effectively unlock its true capabilities. An overview of\r\nmodule tasks is shown in Table 4, which includes details about the few identified modules. Similarly, Table 5\r\nprovides an overview of management tasks associated with the Executor.\r\nTable 4. Executor tasks – modules\r\nType Description\r\n0x??–0x63 Unknown\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 10 of 22\n\n0x64 File reader\r\n0x65 Unknown\r\n0x66 Unknown\r\n0x67 Unknown\r\n0x68 Unknown\r\n0x69 Process creator\r\n0x6A Unknown\r\n0x6B Unknown\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 11 of 22\n\n0x6C Info collector\r\n0x6D Unknown\r\n0x6E Unknown\r\nTable 5. Executor tasks – management\r\nType Description\r\n0x6F-0x76 Not implemented\r\n0x77 Set Executor configuration\r\n0x78 Get Executor configuration\r\n0x79-0x7C Not implemented\r\n0x7D Update\r\n0x7E Quit\r\n0x7F Uninstall\r\nThe command that sets the Executor configuration can change the:\r\nunwanted process lists,\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 12 of 22\n\ntime threshold of C\u0026C communication failure, and\r\ntime limit for execution of additional modules.\r\nModules\r\nWe managed to obtain three unique modules from the C\u0026C server, each corresponding to a different Executor task\r\ntype, as shown in Table 4. Based on available information, we estimate there are nine to fourteen modules in total.\r\nAs the modules are in fact backdoor commands, they have one basic operation to execute and then optionally return\r\ntheir output. The modules we obtained are DLLs with one unnamed export (ordinal 1), in which they resolve\r\nnecessary API functions and call the main function.\r\nWhen executed, the modules are provided with an API resolution function, which can resolve Windows APIs and\r\ncustom Executor APIs. The Windows APIs are referenced by a DWORD hash, calculated from the name of the API\r\nand its DLL. Small hash values (\u003c41) are treated specially, referencing the Executor API function. The Executor\r\nAPI comprises a total of 39 functions that are accessible to the modules. These functions pertain to a variety of\r\noperations, including:\r\nfile operations,\r\nencryption and hashing,\r\ncompression,\r\nPE loading,\r\naccess Token Impersonation, and\r\nutility.\r\nIn the rest of this section, we describe the modules that we obtained.\r\nProcess creator\r\nModule 0x69 executes the specified command line as a new process and provides the resulting output back to the\r\nOrchestrator. The process can be created under a different user, and its execution time can be limited. Notably, an\r\nunusual Job API is used in this module’s functionality.\r\nThis module was served with the command line cmd.exe /c tasklist /v.\r\nWe assume it serves as an idle command issued automatically, while the operators wait for something interesting to\r\nhappen on the compromised computer.\r\nInfo collector\r\nModule 0x6C collects extensive information about the computer via WMI queries and passes it back to the\r\nOrchestrator. Information about the following is collected:\r\noperating system,\r\nnetwork adapters,\r\ninstalled software,\r\ndrives,\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 13 of 22\n\nservices,\r\ndrivers,\r\nprocesses,\r\nusers,\r\nenvironment variables, and\r\nsecurity software.\r\nFile reader\r\nModule 0x64 reads the specified file and passes the content back to the Orchestrator. Optionally, it can delete the\r\nfile after reading.\r\nWe saw this module used to retrieve the victim’s Outlook data file\r\nc:\\Users\\\u003credacted\u003e\\AppData\\Local\\Microsoft\\Outlook\\outlook.ost.\r\nChain with shellcode downloader\r\nIn the process of investigating Deadglyph, we encountered a dubious CPL file signed with an expired certificate and\r\nno countersignature with a timestamp, which had been uploaded to VirusTotal from Qatar. Upon closer examination,\r\nit became evident that this CPL file functioned as a multistage shellcode downloader, sharing certain code\r\nresemblances with Deadglyph. The loading chain is illustrated in Figure 6.\r\nFigure 6. Shellcode downloader loading chain\r\nIn its initial form, which serves as the first stage, this file anticipates having a .cpl extension (Control Panel file) and\r\nis meant to be executed via a double-click action. Upon execution in this manner, the embedded shellcode\r\nundergoes XOR decryption, and the running processes are checked to identify a suitable host process for subsequent\r\ninjection.\r\nIf avp.exe (a Kaspersky endpoint security process) is running, %windir%\\system32\\UserAccountBroker.exe is used.\r\nOtherwise, the default browser is used. Then, it creates the host process in a suspended state, injects the shellcode\r\nby hijacking its main thread, and resumes the thread.\r\nThe second stage, the shellcode, consists of two parts. The first part of the shellcode resolves API hashes, using the\r\nsame unique hash calculation technique employed in Deadglyph, and decrypts strings with process names. It starts a\r\nself-delete thread tasked with overwriting and subsequently erasing the first-stage file. Following this, the shellcode\r\nproceeds to inspect the currently active processes, targeting a security solution.\r\nIf any of the specified processes are detected, the shellcode creates a sleeper thread with the lowest priority\r\n(THREAD_PRIORITY_IDLE) and allows it to remain active for a duration of 60 seconds before terminating its\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 14 of 22\n\noperation. This interval is likely implemented as a precautionary measure to evade certain detection mechanisms\r\nemployed by security solutions. Finally, the shellcode proceeds to invoke the execution of the second part of its\r\ncode.\r\nThe second part of the shellcode loads an embedded PE file with stage three and calls its export with ordinal\r\nnumber 1.\r\nThe third stage, a DLL, serves as a .NET loader and contains the payload in its .rsrc section.\r\nTo load the payload, the .NET runtime is initialized. During the .NET initialization, two intriguing techniques are\r\nperformed, seemingly intended to evade Windows Antimalware Scan Interface (AMSI) scanning:\r\nThe .NET loader temporarily hooks the GetModuleHandleW import in the loaded clr.dll, while calling\r\nICorRuntimeHost::Start. The hook tampers with the return value when GetModuleHandleW is called with\r\nNULL. It returns a pointer to a dummy PE with no sections.\r\nIt then subtly patches the AmsiInitialize import name string in the .rdata section of the loaded clr.dll to\r\namsiinitialize.\r\nThe fourth stage is a .NET assembly, obfuscated with ConfuserEx, that serves as a shellcode downloader. First, it\r\nXOR-decrypts its configuration in XML format from its resources. A beautified version of the extracted\r\nconfiguration is presented in Figure 7. The configuration entries contain details related to network communication\r\nand blocklisted processes.\r\nFigure 7. Shellcode downloader configuration\r\nBefore proceeding, it checks the running processes against a list of blocklisted processes from the configuration. If a\r\nmatch is detected, the execution halts. It is important to note that in the analyzed instance, this blocklist wasn’t set\r\nup.\r\nNext, it sends an HTTP GET request to the C\u0026C server to retrieve some shellcode, using parameters specified in the\r\nconfiguration (URL, User-Agent, and optionally Proxy). Regrettably, during our investigation we were unable to\r\nacquire any shellcode from the C\u0026C server. Nonetheless, we hypothesize that the content being retrieved could\r\npotentially serve as the installer for Deadglyph.\r\nFollowing this, the retrieved shellcode is executed within a newly created thread. After waiting until the shellcode\r\nthread finishes execution, the shellcode downloader removes all files located in the directory\r\n%WINDIR%\\ServiceProfiles\\LocalService\\AppData\\Local\\Temp\\TfsStore\\Tfs_DAV.\r\nFinally, it makes an attempt to delete itself after a 20-second interval, employing the subsequent command, before\r\nconcluding its operation and exiting:\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 15 of 22\n\ncmd.exe choice /C Y /N /D Y /T 20 \u0026 Del /f /q \u003ccurrent_process_exe_path\u003e\r\nThis self-deletion does not make sense in this chain. This is due to the fact that the shellcode downloader is\r\nexecuted within a browser or system process after being injected, rather than operating as an independent\r\nexecutable. Moreover, the initial file was already deleted by the second stage. This observation suggests that the\r\nshellcode downloader might not be an exclusive payload of this chain and may also be used separately in other\r\noperations.\r\nConclusion\r\nWe have discovered and analyzed a sophisticated backdoor used by the Stealth Falcon group that we have named\r\nDeadglyph. It has an unusual architecture, and its backdoor capabilities are provided by its C\u0026C in the form of\r\nadditional modules. We managed to obtain three of these modules, uncovering a fraction of Deadglyph’s full\r\ncapabilities.\r\nNotably, Deadglyph boasts a range of counter-detection mechanisms, including continuous monitoring of system\r\nprocesses and the implementation of randomized network patterns. Furthermore, the backdoor is capable of\r\nuninstalling itself to minimize the likelihood of its detection in certain cases.\r\nAdditionally, our investigation led us to the discovery of a compelling multistage shellcode downloader chain on\r\nVirusTotal. We suspect this downloader chain is likely leveraged in the installation process of Deadglyph.\r\nFor any inquiries about our research published on WeLiveSecurity, please contact us\r\nat threatintel@eset.com.\r\nESET Research offers private APT intelligence reports and data feeds. For any inquiries about this\r\nservice, visit the ESET Threat Intelligence page.\r\nIoCs\r\nFiles\r\nSHA-1 Filename Detection Description\r\nC40F1F46D230A85F702DAA38CFA18D60481EA6C2 pbrtl.dll Win64/Deadglyph.A\r\nRegistry\r\nShellcode\r\nLoader.\r\n740D308565E215EB9B235CC5B720142428F540DB N/A Win64/Deadglyph.A\r\nDeadglyph\r\nBackdoor –\r\nExecutor.\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 16 of 22\n\n1805568D8362A379AF09FD70D3406C6B654F189F N/A MSIL/Deadglyph.A\r\nDeadglyph\r\nBackdoor –\r\nOrchestrator.\r\n9CB373B2643C2B7F93862D2682A0D2150C7AEC7E N/A MSIL/Deadglyph.A\r\nOrchestrator\r\nNetwork\r\nmodule.\r\nF47CB40F6C2B303308D9D705F8CAD707B9C39FA5 N/A MSIL/Deadglyph.A\r\nOrchestrator\r\nTimer\r\nmodule.\r\n3D4D9C9F2A5ACEFF9E45538F5EBE723ACAF83E32 N/A Win64/Deadglyph.A.gen\r\nProcess\r\ncreator\r\nmodule.\r\n3D2ACCEA98DBDF95F0543B7C1E8A055020E74960 N/A Win64/Deadglyph.A\r\nFile reader\r\nmodule.\r\n4E3018E4FD27587BD1C566930AE24442769D16F0 N/A Win64/Deadglyph.A\r\nInfo\r\ncollector\r\nmodule.\r\n7F728D490ED6EA64A7644049914A7F2A0E563969 N/A Win64/Injector.MD\r\nFirst stage\r\nof shellcode\r\ndownloader\r\nchain.\r\nCertificates\r\nSerial number 00F0FB1390F5340CD2572451D95DB1D92D\r\nThumbprint DB3614DAF58D041F96A5B916281EA0DC97AA0C29\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 17 of 22\n\nSubject CN RHM LIMITED\r\nSubject O RHM LIMITED\r\nSubject L St. Albans\r\nSubject S Hertfordshire\r\nSubject C GB\r\nEmail rhm@rhmlimited[.]co.uk\r\nValid from 2021-03-16 00:00:00\r\nValid to 2022-03-16 23:59:59\r\nC\u0026C servers\r\nIP Domain First seen Comment\r\n185.25.50[.]60 chessandlinkss[.]com 2021-08-25 Deadglyph C\u0026C server.\r\n135.125.78[.]187 easymathpath[.]com 2021-09-11 Deadglyph C\u0026C server.\r\n45.14.227[.]55 joinushealth[.]com 2022-05-29 Shellcode downloader C\u0026C server.\r\nMITRE ATT\u0026CK techniques\r\nThis table was built using version 13 of the MITRE ATT\u0026CK framework.\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 18 of 22\n\nTactic ID Name Description\r\nResource\r\nDevelopment\r\nT1583.001\r\nAcquire Infrastructure:\r\nDomains\r\nStealth Falcon has registered domains for C\u0026C\r\nservers and to obtain a code-signing certificate.\r\nT1583.003\r\nAcquire Infrastructure:\r\nVirtual Private Server\r\nStealth Falcon has used VPS hosting providers\r\nfor C\u0026C servers.\r\nT1587.001\r\nDevelop Capabilities:\r\nMalware\r\nStealth Falcon has developed custom malware,\r\nincluding custom loaders and the Deadglyph\r\nbackdoor.\r\nT1588.003\r\nObtain Capabilities:\r\nCode Signing\r\nCertificates\r\nStealth Falcon has obtained a code-signing\r\ncertificate.\r\nExecution\r\nT1047\r\nWindows Management\r\nInstrumentation\r\nDeadglyph uses WMI to execute its loading\r\nchain.\r\nT1059.003\r\nCommand and Scripting\r\nInterpreter: Windows\r\nCommand Shell\r\nShellcode downloader uses cmd.exe to delete\r\nitself.\r\nT1106 Native API\r\nA Deadglyph module uses CreateProcessW and\r\nCreateProcessAsUserW API functions for\r\nexecution.\r\nT1204.002\r\nUser Execution:\r\nMalicious File\r\nThe shellcode downloader chain requires the user\r\nto double-click and execute it.\r\nPersistence T1546.003 Event Triggered\r\nExecution: Windows\r\nManagement\r\nThe initial Deadglyph loader is persisted using\r\nWMI event subscription.\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 19 of 22\n\nInstrumentation Event\r\nSubscription\r\nDefense\r\nEvasion\r\nT1027\r\nObfuscated Files or\r\nInformation\r\nDeadglyph components are encrypted. Deadglyph\r\nOrchestrator and embedded modules are\r\nobfuscated with .NET Reactor.\r\nThe shellcode downloader is obfuscated with\r\nConfuserEx.\r\nT1070.004\r\nIndicator Removal: File\r\nDeletion\r\nDeadglyph can uninstall itself.\r\nThe shellcode downloader chain deletes itself and\r\ndeletes files in the WebDAV cache.\r\nT1112 Modify Registry\r\nDeadglyph stores its configuration and encrypted\r\npayload in the registry.\r\nT1134\r\nAccess Token\r\nManipulation\r\nDeadglyph can impersonate another user.\r\nT1140\r\nDeobfuscate/Decode\r\nFiles or Information\r\nDeadglyph decrypts encrypted strings.\r\nThe shellcode downloader chain decrypts its\r\ncomponents and configurations.\r\nT1218.011\r\nSystem Binary Proxy\r\nExecution: Rundll32\r\nThe initial Deadglyph loader is executed using\r\nrundll32.exe.\r\nT1480.001\r\nExecution Guardrails:\r\nEnvironmental Keying\r\nDeadglyph is encrypted using a machine-specific\r\nkey derived from the system UUID.\r\nT1562.001\r\nImpair Defenses: Disable\r\nor Modify Tools\r\nThe shellcode downloader avoids AMSI scanning\r\nby patching clr.dll in memory .\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 20 of 22\n\nT1620 Reflective Code Loading\r\nDeadglyph reflectively loads its modules using a\r\ncustom PE loader.\r\nDiscovery\r\nT1007\r\nSystem Service\r\nDiscovery\r\nA Deadglyph module discovers services using the\r\nWMI query SELECT * FROM Win32_Service.\r\nT1012 Query Registry\r\nThe shellcode downloader chain queries the\r\nregistry for the default browser.\r\nT1016\r\nSystem Network\r\nConfiguration Discovery\r\nA Deadglyph module discovers network adapters\r\nusing WMI queries SELECT * FROM\r\nWin32_NetworkAdapter and SELECT * FROM\r\nWin32_NetworkAdapterConfiguration where\r\nInterfaceIndex=%d.\r\nT1033\r\nSystem Owner/User\r\nDiscovery\r\nA Deadglyph module discovers users with the\r\nWMI query SELECT * FROM\r\nWin32_UserAccount.\r\nT1057 Process Discovery\r\nA Deadglyph module discovers processes using\r\nWMI query SELECT * FROM Win32_Process.\r\nT1082\r\nSystem Information\r\nDiscovery\r\nA Deadglyph module discovers system\r\ninformation such as OS version, drives,\r\nenvironment variables, and drivers using WMI\r\nqueries.\r\nT1518 Software Discovery\r\nA Deadglyph module discovers installed software\r\nusing WMI query SELECT * FROM\r\nWin32_Product.\r\nT1518.001 Software Discovery:\r\nSecurity Software\r\nDiscovery\r\nA Deadglyph module discovers security software\r\nusing WMI queries SELECT * FROM\r\nAntiVirusProduct, SELECT * FROM\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 21 of 22\n\nAntiSpywareProduct and SELECT * FROM\r\nFirewallProduct.\r\nThe shellcode downloader chain checks running\r\nprocesses for a security solution.\r\nCollection T1005 Data from Local System Deadglyph has a module for reading files.\r\nCommand\r\nand Control\r\nT1071.001\r\nApplication Layer\r\nProtocol: Web Protocols\r\nDeadglyph and the shellcode downloader\r\ncommunicate with the C\u0026C server via the HTTP\r\nprotocol.\r\nT1090 Proxy\r\nDeadglyph and the shellcode downloader can use\r\nHTTP proxy for C\u0026C communication.\r\nT1573.001\r\nEncrypted Channel:\r\nSymmetric\r\nCryptography\r\nDeadglyph uses AES to encrypt C\u0026C\r\ncommunications.\r\nExfiltration T1041\r\nExfiltration Over C2\r\nChannel\r\nDeadglyph uses the C\u0026C channel for exfiltration.\r\nSource: https://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/\r\nPage 22 of 22\n\nhttps://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/ \n0x64 File reader\n0x65 Unknown\n0x66 Unknown\n0x67 Unknown\n0x68 Unknown\n0x69 Process creator\n0x6A Unknown\n0x6B Unknown\n Page 11 of 22",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/"
	],
	"report_names": [
		"stealth-falcon-preying-middle-eastern-skies-deadglyph"
	],
	"threat_actors": [
		{
			"id": "0f47a6f3-a181-4e15-9261-50eef5f03a3a",
			"created_at": "2022-10-25T16:07:24.228663Z",
			"updated_at": "2026-04-10T02:00:04.905195Z",
			"deleted_at": null,
			"main_name": "Stealth Falcon",
			"aliases": [
				"FruityArmor",
				"G0038",
				"Project Raven",
				"Stealth Falcon"
			],
			"source_name": "ETDA:Stealth Falcon",
			"tools": [
				"Deadglyph",
				"StealthFalcon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "77aedfa3-e52b-4168-8269-55ccec0946f7",
			"created_at": "2023-01-06T13:46:38.453791Z",
			"updated_at": "2026-04-10T02:00:02.981559Z",
			"deleted_at": null,
			"main_name": "Stealth Falcon",
			"aliases": [
				"FruityArmor",
				"G0038"
			],
			"source_name": "MISPGALAXY:Stealth Falcon",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "bd084d2f-4233-49b1-b0e6-c7011178dae0",
			"created_at": "2022-10-25T15:50:23.544316Z",
			"updated_at": "2026-04-10T02:00:05.325921Z",
			"deleted_at": null,
			"main_name": "Stealth Falcon",
			"aliases": [
				"Stealth Falcon"
			],
			"source_name": "MITRE:Stealth Falcon",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775446574,
	"ts_updated_at": 1775791536,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0e8d39dc67c1d1c2d8fe5b1422fa40ec8c95c062.pdf",
		"text": "https://archive.orkl.eu/0e8d39dc67c1d1c2d8fe5b1422fa40ec8c95c062.txt",
		"img": "https://archive.orkl.eu/0e8d39dc67c1d1c2d8fe5b1422fa40ec8c95c062.jpg"
	}
}