多年来，中东一直享有高级持续威胁（APT）沃土的声誉。在对知名客户（其中一些位于该地区）系统上的可疑活动进行例行监控时，ESET Research 偶然发现了一个非常复杂且未知的后门，我们将其命名为 Deadglyph。我们从后门中发现的工件（例如0x DEAD B001，也显示在表1中）中得出了这个名称，再加上同形字形的存在攻击。据我们所知，这是对这个先前未记录的后门的首次公开分析，该后门由一个表现出相当复杂程度和专业知识的组织使用。根据目标和其他证据，我们高度确信 Deadglyph 属于 Stealth Falcon APT 组织。
Deadglyph 的架构很不寻常，因为它由协作组件组成 - 一个是本机 x64 二进制文件，另一个是 .NET 程序集。这种组合很不寻常，因为恶意软件通常只使用一种编程语言作为其组件。这种差异可能表明这两个组件是单独开发的，同时还利用了它们所使用的不同编程语言的独特功能。不同的语言也可能被用来阻碍分析，因为混合代码更难以导航和调试。
后门二进制文件中没有实现传统的后门命令；相反，它们以附加模块的形式从命令和控制 (C&C) 服务器动态接收。该后门还具有许多避免被检测到的功能。
在这篇博文中，我们仔细研究了 Deadglyph，并对这个后门、其目的以及我们获得的一些附加组件进行了技术分析。我们还在LABScon 2023会议上展示了有关 Deadglyph 的发现。
博文要点：
ESET Research 发现了一个具有不寻常架构的复杂后门，我们将其命名为 Deadglyph。
主要组件使用机器特定的密钥进行加密。传统的后门命令是通过从其 C&C 服务器接收的附加模块来实现的。
我们从众多模块中获得了三个——进程创建器、文件读取器和信息收集器。
我们将 Deadglyph 归为 Stealth Falcon 团体。
此外，我们还发现了一个相关的shellcode下载器；我们假设它有可能用于安装 Deadglyph。
所分析渗透的受害者是中东的一个政府实体，该实体因间谍目的而受到损害。在 VirusTotal 上发现的相关样本也从该地区（特别是卡塔尔）上传到文件扫描平台。目标区域如图1中的地图所示。
图 1. Deadglyph 的受害者学；相关样本已从卡塔尔上传至VirusTotal（颜色较深）
据 MITRE 称， Stealth Falcon（也称为 Project Raven 或 FruityArmor）是一个与阿拉伯联合酋长国有联系的威胁组织。Stealth Falcon 自 2012 年以来一直活跃，以中东地区的政治活动家、记者和持不同政见者为目标。它首先由Citizen Lab发现和描述，该实验室发布了对 2016 年间谍软件攻击活动的分析。
2019 年 1 月，路透社发布了一份关于 Project Raven 的调查报告，该计划据称雇用了前 NSA 特工，其目标与 Stealth Falcon 相同类型。根据这两份涉及相同目标和攻击的报告，国际特赦组织得出结论（如图2所示）：Stealth Falcon 和 Project Raven 实际上是同一组织。
图 2. Claudio Guarnieri 将 Stealth Falcon 与 Project Raven 连接起来
2019 年 9 月，我们发表了关于 Stealth Falcon 后门的研究，该后门使用了一种不寻常的技术，即后台智能传输服务，用于 C&C 通信。现在，我们揭示了对 Stealth Falcon 间谍工具集最新成员的深入分析结果。
Deadglyph后门
Deadglyph 的加载链由多个组件组成，如图3所示。初始组件是注册表 shellcode 加载器，它从注册表加载 shellcode。提取的 shellcode 反过来会加载后门的本机 x64 部分——执行器。执行器随后加载后门的.NET部分——Orchestrator。值得注意的是，系统磁盘上唯一作为文件的组件是初始组件，它采用动态链接库（DLL）的形式。其余组件被加密并存储在二进制注册表值中。
图 3. Deadglyph 加载链组件
虽然初始妥协向量的精确方法尚未确定，但我们怀疑安装程序组件参与了部署其他组件并在系统内建立持久性。
在本节的其余部分中，我们将分析每个组件。
注册表 shellcode 加载器
Deadglyph 的初始组件是一个带有单个导出的小型 DLL，名为1。该组件使用Windows Management Instrumentation (WMI) 事件订阅进行持久化，并充当注册表 shellcode 加载程序。它通过命令行rundll32 C:WINDOWSSystem32\pbrtl.dll,#1执行。
注册表 shellcode 加载器通过使用 RC4 解密 Windows 注册表中存储的加密 shellcode 的路径来开始其操作。我们怀疑每个受害者的路径都是独一无二的；在这里分析的情况下，注册表路径是：
软件类CLSID{5abc7f42-1112-5099-b082-ce8d65ba0c47}cAbRGHLg
根注册表项是HKLM或HKCU ，具体取决于当前进程是否以提升的权限运行。在其他组件中可以找到相同的逻辑。
此后，加载程序使用从原始 SMBIOS 固件表检索的系统 UUID 派生机器特定的 RC4 密钥。使用此密钥，它加载、解密，然后执行 shellcode。需要强调的是，这种密钥派生方法可确保如果加载程序在不同的计算机上执行，则不会发生正确的解密。
有趣的是，加载程序还可以通过其.data部分中的标志进行配置，以使用硬编码密钥来解密 shellcode，而不是特定于机器的密钥。
我们在这个和其他PE组件的VERSIONINFO资源中发现了一个模仿微软公司的同形字攻击。该方法使用不同的Unicode字符，这些字符在视觉上与原始字符相似，但在本例中不相同，特别是icrósóft Corpóratión中的希腊大写字母San（U+03FA，Ϻ）和西里尔文小写字母O（U+043E，ó）。
注册表shellcode
注册表 shellcode 由两部分组成，包括解密例程和加密主体。首先，解密例程将加密主体的每个字节向左循环一位 ( ROL 0x01 )。随后，控制权被转移到这个解密的主体。解密后的主体由PE加载器和PE文件组成，后者是Executor，代表后门的原生部分。该加载器负责解析并加载相关的PE文件。
执行者
Executor 是 Deadglyph 后门的原生 x64 部分，它执行以下操作：
加载其配置，
初始化.NET运行时，
加载后门的嵌入式 .NET 部分（Orchestrator），以及
充当 Orchestrator 的库。
首先，.data部分中嵌入的两个默认配置是 AES 解密的。这些配置包含各种参数，包括加密密钥、安全和规避设置以及后续组件的入口点。
在初始执行期间，这两个默认配置存储在 Windows 注册表中，在后续运行时从此处加载它们，从而实现更新。每个配置的注册表路径均按以下格式生成：
{HKCU|HKLM}SoftwareClassesCLSID{}（默认）
是生成的 GUID，对于每个受害者来说都是唯一的。
接下来，.NET 运行时被初始化，然后执行器 RC4 解密后门的 .NET 部分（称为 Orchestrator）。Orchestrator 位于执行器的.rsrc部分内。配置将 Orchestrator 的执行方法指定为入口点。此外，还提供了一种独特的结构，以方便协调器访问执行器的功能。
启动 Orchestrator 后，Executor 充当 Orchestrator 的支持库。Executor包含许多有趣的函数；我们将在下一节中描述其中的一些，并结合 Orchestrator 和进一步加载的模块的使用情况。
协调者
Orchestrator 用 .NET 编写，是 Deadglyph 后门的主要组件。该组件的主要角色涉及与 C&C 服务器建立通信并执行命令，通常通过执行器的中介角色来促进。与前面的组件相比，Orchestrator 是混淆的，采用 .NET Reactor。在内部，后门被称为agent，这是各种后利用框架中客户端部分的通用名称。
初始化
Orchestrator 首先从资源加载其配置和两个嵌入式模块，每个模块都有自己的一组配置。这些资源经过Deflate压缩和AES加密。它们通过 SHA-1 散列到资源名称中的 ID 引用。表1概述了这些资源。
表 1. Orchestrator 资源
Orchestrator 和嵌入式模块的配置以 XML 格式存储。Orchestrator 配置的示例如图4所示。
图 4. Orchestrator 配置
Orchestrator配置条目的描述如表2所示。
表 2. Orchestrator 配置条目
加载资源组件后，将创建多个线程来执行不同的任务。其中一个线程负责执行环境检查，这是执行器内实现的功能。另一个线程致力于与 C&C 服务器建立定期通信，从而能够检索命令。最后，采用一组三个线程来执行接收到的命令并随后将任何生成的输出传输回 C&C 服务器。
环境检查线程监视正在运行的进程以识别不需要的进程。该线程使用两个不同的进程名称列表进行操作。如果检测到第一个列表上的进程，C&C 通信和命令执行将暂停，直到不需要的进程不再存在。如果第二个列表中的任何进程有匹配项，后门将立即退出并自行卸载。
在分析的实例中这两个列表都没有配置，因此我们不知道通常会检查哪些进程；我们认为它可能是为了逃避可以检测可疑活动并导致发现后门的分析工具。
沟通
Orchestrator 利用两个嵌入式模块进行 C&C 通信 - 计时器和网络。与 Orchestrator 一样，这些模块也使用 .NET Reactor 进行混淆。两个模块的配置均由 Orchestrator 提供。Orchestrator 中包含模块的预设配置；或者，Orchestrator 还可以从注册表加载更新的配置版本：
{HKCU|HKLM}SoftwareClassesCLSID{}
后门包含一个与通信相关的有趣的安全措施。如果后门在超过执行器中配置的预定义阈值的时间内无法与 C&C 服务器建立通信，则会触发自卸载机制。该时间阈值以小时为单位指定，在所检查的案例中设置为一小时。
这种方法有双重目的。一方面，它可以防止向无法访问的服务器生成冗余网络请求。另一方面，如果操作员失去对后门的控制，它会降低后续检测的机会。
定时器模块
这个小模块以可配置的时间间隔执行指定的回调。Orchestrator 与 Network 模块结合使用，定期与 C&C 服务器进行通信。为了防止在网络日志中创建可检测的模式，执行间隔将根据配置中指定的百分比进行随机化。在分析的实例中，间隔设置为五分钟，并引入了 ±20% 的随机性变化。
另一种避免周期性通信中可检测到的网络模式的方法是生成发送到 C&C 服务器的请求。这种机制在执行器中实现，涉及在请求中包含不同长度的填充（由随机字节组成），从而产生不同大小的请求。
网络模块
网络模块实现与其配置中指定的 C&C 服务器的通信。它可以使用 HTTP(S) POST 请求将数据发送到 C&C 服务器。值得注意的是，它提供了多种获取代理配置详细信息的机制。此功能表明可能会关注无法直接访问互联网的环境。
图5显示了解密（和美化）配置的示例。
图 5. 网络模块配置
配置条目包含与网络通信相关的详细信息 – C&C URL、HTTP 用户代理和可选的代理配置。
与 C&C 服务器通信时，在 HTTPS 下使用具有加密内容的自定义二进制协议。
命令
Orchestrator 以任务的形式从 C&C 服务器接收命令，这些命令排队等待执行。处理的任务分为三种：
Orchestrator tasks,
Executor tasks, and
Upload tasks.
前两种是从 C&C 服务器接收的，第三种是内部创建的，用于上传命令和错误的输出。
协调器任务
Orchestrator 任务提供了管理网络和计时器模块的配置以及取消待处理任务的能力。Orchestrator 任务的概述如表3所示。
表 3. Orchestrator 任务
执行者任务
执行器任务提供了管理后门和执行附加模块的能力。值得注意的是，传统的后门功能并不是固有地存在于二进制文件本身中。相反，这些函数是以PE文件或shellcode的形式从C&C服务器获取的。如果没有这些额外的模块，后门的全部潜力仍然未知，这些模块有效地释放了其真正的功能。表4显示了模块任务的概述，其中包括有关少数已识别模块的详细信息。同样，表5提供了与执行器相关的管理任务的概述。
表 4. 执行器任务 – 模块
表 5. 执行器任务 – 管理
设置 Executor 配置的命令可以更改：
不需要的进程列表，
以及C&C通信失败的时间阈值，
执行附加模块的时间限制。
模块
我们成功地从C&C服务器获取了三个独特的模块，每个模块对应于不同的Executor任务类型，如表4所示。根据现有信息，我们估计总共有九到十四个模块。由于这些模块实际上是后门命令，因此它们需要执行一项基本操作，然后可以选择返回其输出。我们获得的模块是具有一个未命名导出（序号1）的 DLL，它们在其中解析必要的 API 函数并调用 main 函数。
执行时，模块提供API解析功能，可以解析Windows API和自定义Executor API。Windows API 由 DWORD 哈希引用，该哈希是根据 API 及其 DLL 的名称计算得出的。小哈希值（
