重点

Avast 发现并分析了一项恶意软件活动，该活动劫持了 eScan 杀毒软件的更新机制，以分发后门和加密货币挖矿程序Avast 向 eScan 杀毒软件和印度 CERT 披露了该漏洞。2023 年 7 月 31 日，eScan 确认该问题已修复并成功解决该活动由可能与 Kimsuky 关联的威胁行为者组织发现了两种不同类型的后门，目标是大型企业网络GuptiMiner 分发的最终有效载荷也包括 XMRig

引言

我们正在追踪一个有趣的案例。首先，GuptiMiner 是一种高度复杂的威胁，使用了一条有趣的感染链以及几种技术，包括向攻击者的 DNS 服务器进行 DNS 请求、旁加载、从看似无害的图像中提取有效载荷、使用自定义受信任的根证书颁发机构签署其有效载荷等。

GuptiMiner 的主要目标是在大型企业网络中分发后门。我们遇到了这类后门的两种不同变体：第一种是增强版的 PuTTY Link，它提供了对本地网络的 SMB 扫描，允许在网络中进行横向移动，潜在利用 Windows 7 和 Windows Server 2008 系统。第二种后门是多模块的，可以接受攻击者的命令以安装更多模块，并专注于扫描本地系统中存储的私钥和加密钱包。

有趣的是，GuptiMiner 还在受感染的设备上分发 XMRig，这对于这样一个深思熟虑的操作来说有些出乎意料。

GuptiMiner 的背后者利用了印度杀毒软件 eScan 更新机制中的一个安全漏洞，通过实施中间人攻击 (MitM) 来分发恶意软件。我们向 eScan 和印度 CERT 披露了这一安全漏洞，并于 2023 年 7 月 31 日收到了 eScan 确认该问题已修复并成功解决的消息。

GuptiMiner 是一种长期存在的恶意软件，其痕迹可以追溯到 2018 年，虽然很可能它的历史甚至更久。我们还发现 GuptiMiner 与臭名昭著的朝鲜 APT 组织 Kimsuky 可能存在联系，通过观察 Kimsuky 的键盘记录器与 GuptiMiner 操作之间的相似性。

在本分析中，我们将介绍 GuptiMiner 的特性及其随时间的演变。同时我们还将注明特定样本中包含或引入的特性，以支持对大量 IoC 的总体理解。

还需注意，由于用户很少在其机器上安装不止一个杀毒软件，因此我们可能对 GuptiMiner 的活动及其总体范围的可见性有限。因此，我们可能只是在冰山一角，整个操作的真实范围仍有待发现。

感染链

为了说明整个感染过程的复杂性，我们提供了一张包含链中所有部分的流程图。请注意，某些使用的文件名和/或工作流程可能会根据 GuptiMiner 的特定版本略有不同，但下面的流程图展示了总体过程。

这一过程始于 eScan 向更新服务器请求更新，未知的中间人拦截了下载并用恶意更新包替换了更新包。然后，eScan 解包并加载该包，并通过 eScan 的干净二进制文件旁加载一个 DLL。这个 DLL 启用余下的链，并跟随多个 shellcode 和中介 PE 加载器。

最终的 GuptiMiner 由在受感染的机器上使用 XMRig 以及在大型企业网络中部署时激活的后门组成。

GuptiMiner 的感染链

演变与时间线

GuptiMiner 自至少 2018 年以来就活跃。多年来，其开发者对恶意软件进行了显著改进，新增了多种特性。我们将在各个小节中详细描述这些特性。

此外，我们还希望以时间线的形式展示显著的 IoC，重点关注互斥锁 (mutex)、PDB 和使用的域。这些时间线是通过在大样本数据集中扫描 IoC 创建的，取样本的首次和最后编译时间戳，然后形成时间间隔。请注意，扫描的数据集大于 IoC 部分列出的 IoC 列表。欲了解详细的 IoC 列表，请访问我们的 GitHub。

频率与时间的域

一般来说，GuptiMiner 在其操作中使用了以下类型的域：

恶意 DNS GuptiMiner 建立自己的 DNS 服务器，通过 DNS TXT 响应提供 CampC 服务器的真实目标域地址请求域 恶意软件查询 DNS 服务器的域PNG 下载 用于下载有效载荷的PNG文件。这些 PNG 文件是有效图像TMobile 的 logo，其末尾包含附加的 shellcode配置挖掘池 GuptiMiner 包含两个不同的挖掘池配置。其中一个在 XMRig 配置中被硬编码，属于该组修改的挖掘池 GuptiMiner 能够修改预定义的挖掘池，属于该组最终 CampC 用于 GuptiMiner 最后一个后门阶段的域，提供后门系统中的额外恶意程序功能其他 用于不同目的的域，例如用于脚本中

请注意，由于恶意软件直接连接到恶意 DNS 服务器，DNS 协议完全与 DNS 网络隔离。因此，任何合法的 DNS 服务器将永远不会看到来自该恶意软件的流量。此处使用 DNS 协议作为 telnet 的功能等效。在此情况下，该技术并不是 DNS 欺骗，因为欺骗通常发生在 DNS 网络上。

此外，GuptiMiner 请求的 请求域 类别中存在的服务器实际上存在只是巧合，或缓解网络监控工具和分析师的网络混淆。

时间线展示 GuptiMiner 使用的域

从这条时间线可以明显看出，GuptiMiner 的作者认识到正确设置其 DNS 服务器对整个链的正常功能至关重要。因此，我们观察到在 恶意 DNS 组中有最大的轮换和更短的时间框架。

而且，由于 请求域 组中的域是无关的至少从技术角度来看，我们可以注意到作者在更长的时间内重用相同的域名。

频率与时间的互斥锁

互斥锁有助于确保软件的正确执行流程，恶意软件作者通常使用这些命名对象出于同样的目的。自 2018 年以来，GuptiMiner 变更了多次互斥锁。最显著的是，我们注意到自 2021 年以来，作者将互斥锁更改为反映新版本的编译/分发日期。

时间线展示 GuptiMiner 使用的互斥锁

细心的读者可能会看到两个结论：第一是使用 MIVOD6、SLDV15、SLDV13 和 GlobalWed Jun 2 094303 2021 的明显异常值。根据我们的数据，这些互斥锁确实在不同的构建中被重用，形成比预期更大的时间框架。

另一个观点是在去年年底重新引入的 PROCESS 互斥锁。在这一时期，作者以 UTF16 编码字符串重新引入了该互斥锁，我们进行了单独说明。

频率与时间的 PDBs

关于调试符号，GuptiMiner 的作者在其二进制文件中留下了多个 PDB 路径。大多数情况下，它们包含诸如 MainWork、Projects 等字符串。

时间线展示 GuptiMiner 中的 PDBs

阶段 0 安装过程

拦截更新

每个人都应该更新他们的软件，对吧？通常，个人要么从官方供应商的网站手动下载新版本，要么 更好 软件本身在没有用户太多思考或操作的情况下自动执行更新。但当有人能够劫持这个自动过程时会发生什么呢？

我们的调查开始于我们开始观察到一些用户从本来合法的请求中收到不寻常的响应，例如：

http//update3[]mwti[]net/pub/update/updll3dlz

这个确实是一个合法 URL，用于下载 updll3dlz 文件，该文件在正常情况下是一个包含 eScan 杀毒软件更新的合法压缩包。然而，我们开始在一些客户那里看到来自此类 URL 的可疑行为。

我们发现，GuptiMiner 的行为者正在执行中间人MitM攻击，将受感染的安装程序下载到受害者的 PC，而不是更新。不幸的是，我们目前没有有关如何进行 MitM 的信息。我们假定受害者的设备或其网络上必须存在某种预先感染的情况，从而导致了 MitM。

更新包

c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3 (versiondll 20180419 094741 UTC)

在整个分析中，我们将尝试描述不仅仅是感染链的流程、恶意软件技术和阶段功能，还将关注不同版本的演变，描述恶意软件作者如何随着时间的推移开发和修改 GuptiMiner。

我们能够发现的第一个 GuptiMiner 样本的编译时间为 2018 年 4 月 19 日星期二094741，并于次日从印度上传到 VirusTotal，随后又由德国上传：c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3

这个文件被命名为 CProgram FileseScanVERSIONDLL，这表明目标受众确实是 eScan 用户，并且它来自由杀毒软件下载的更新包。

尽管此版本缺乏新版本中存在的几个特性，但安装过程仍然相同，如下所示：

eScan 更新器触发更新下载的包文件因缺少 HTTPS 加密而在线被替换为恶意文件进行 MitM 攻击恶意包 updll62dlz 被下载并由 eScan 更新器解压包的内容包含一个恶意 DLL通常称为 versiondll，由 eScan 旁加载。由于旁加载，该 DLL 以与源进程 eScan 相同的权限运行，并在下次运行 eScan 时被加载，通常在系统重启后如果系统中不存在互斥锁取决于版本，例如 MutexONLYMEV1，恶意软件将搜索 servicesexe 进程，并将其下一个阶段注入到第一个找到的进程中进行清理，删除更新包

恶意 DLL 包含在干净 DLL 中不存在的其他功能。值得庆幸的是，名称非常详细，因此大多数情况下不需要分析。下列功能可见。

其他导出功能

但是某些功能是唯一的。例如，X64Call 函数提供“天堂之门”，即这是一个帮助在 64 位系统上运行 32 位进程中的 x64 代码的函数。该恶意软件需要这个功能来能够根据操作系统版本运行注入的 shellcode，从而决定 servicesexe 进程的位数。

当需要时在 x64 环境中运行 shellcode 的天堂之门

为了保持原始 eScan 的功能完整，恶意的 versiondll 也需要处理原始旧版 versiondll 的功能。这是通过转发所有来自原始 DLL 的导出函数来实现的。当识别到调用旧版 DLL 功能时，GuptiMiner 解析原始函数并随后调用它。

解析功能，确保所有原始 versiondll 导出可用

在 servicesexe 中注入的 Shellcode

在 shellcode 被注入到 servicesexe 后，它作为下一个阶段的加载器。通过以明文形式读取嵌入的 PE 文件来完成这一过程。

由 shellcode 加载的嵌入 PE 文件

此 PE 文件通过标准方式加载，但此外，shellcode 还销毁 PE 的 DOS 头，并通过调用其入口点运行它，同时将嵌入的 PE 从原始内存位置完全移除。

命令行操作

在整个 GuptiMiner 感染链中，加载和注入 PE 文件的每个 shellcode 还操作了当前进程的命令行。通过操控 GetCommandLineA/W 的结果来实现，这样改动了显示在任务管理器中的命令行结果。

命令行操作函数

经过检查，我们认为此功能要么未如作者所愿发挥作用，要么我们未理解其用法。长话短说，命令行被改为在第一个 parameter 之前的所有内容被跳过，然后将该参数附加到进程名称。

为此，我们可以举个命令的例子：notepadexe param1 XX param2将转变为：notepadexeXX param2

然而，我们未曾见过像 power shellexe param1 param2 这样的用法，它将结果转变为：powershellexe param1 param2也未曾见到参数如 XMRig 的用户名和密码被隐蔽，这种情况我们估计当遇到这类情况时会预期有此类行为。不过，在任何情况下，此功能正在模糊命令行的外观，值得一提。有兴趣的读者可以在 awesome godboltorg 上玩玩这个功能在这里。

vpn梯子

代码虚拟化

7a1554fe1c504786402d97edecc10c3aa12bd6b7b7b101cfc7a009ae88dd99c6 (versiondll 20180612 033001)

引入了代码虚拟化后的版本中，添加了一个名为 vlizer 的额外部分。这个部分后来在后续构建中也曾几次重命名。

新部分包含被虚拟化的代码，称为 vlizer

幸运的是，混淆相对较弱，提供的 shellcode 以及嵌入 PE 文件仍以明文形式存在。

此外，作者们还开始在安装程序阶段将 versiondll 阶段和由 shellcode 加载的 PE 文件之间区分开来，使用额外的互斥锁。以前阶段之间共享的互斥锁 ONLYMEVx 现在的旁加载使用的是 MTXV101。

阶段 09 安装改进

3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c (20210328 144107 UTC)

安装过程多次经历了改进，并且由于与老版本相比较为不同，因此我们决定将其单独描述为中间阶段 09。通过这些改进，作者引入了计划任务、WMI 事件、两种不同加载的下一个阶段阶段 1 PNG 加载器、关闭 Windows Defender 和安装精心制作的证书到 Windows。

在这个阶段，还会投放多个文件，以为恶意软件提供进一步的旁加载。这些文件是干净的，仅用于旁加载。所旁加载的恶意 DLL 有两个 PNG 加载器阶段 1：

de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739 atiadlxxdll e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee BrLogAPIdll

WMI 事件

de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739 (atiadlxxdll 20210328 143011 UTC)

在这个阶段，WMI 事件用于加载第一个 PNG 加载器。此加载器被提取至路径：CPROGRAMDATAAMDCNextatiadlxxdll

除此之外，额外的干净文件也会被投放，这些文件用于旁加载，可能位于以下位置可以是两个位置都存在：CProgramDataAMDCNextslsnotifexe CProgramDataAMDCNextmsvcr120dll或CProgram Files (x86)AMDCNextCCCSlimslsnotifyexe CProgram Files (x86)AMDCNextCCCSlimmsvcr120dll

干净文件 slsnotifyexe 通过 WMI 事件注册，以便在满足以下条件时执行：

触发旁加载的 WMI 条件

换句话说，旁加载在工作日中的 1 月、7 月或 11 月进行。 d 表示的数字是随机选择的。两次可能的小时数正好相差两个小时，且落在 11 至 16 或 13 至 18 的范围内包括。这种调节进一步突出了 GuptiMiner 操作的持久性。

计划的任务

e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee (BrLogAPIdll 20210328 141027 UTC)

与 WMI 事件类似，GuptiMiner 还会在此位置投放一个干净的二进制文件供旁加载：CProgramDataBrotherBrmfl14cBrRemPnPexe

随后，恶意的 PNG 加载器将放置在以下一个或两个位置：CProgram Files (x86)BrotherBrmfl14cBrLogAPIdll CProgram FilesBrotherBrmfl14cBrLogAPIdll

计划任务是通过调用任务调度器创建的。这个计划任务具有以下特性：

它是在 CWindowsSystem32TasksMicrosoftWindowsBrotherBrmfl14c 创建并命名的 执行 CProgramDataBrotherBrmfl14cBrRemPnPexe 执行是在包含将被旁加载的 DLL 的文件夹下，例如： CProgram Files (x86)BrotherBrmfl14c 执行是在每次启动时进行TASKTRIGGERBOOT，且具有 系统 权限

在关机时部署

3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c (20210328 144107 UTC)

接下来，让我们来看看这些干净和恶意文件是如何被部署的。GuptiMiner 的一个技巧是，它只在系统关机过程中投放最终有效载荷，其中包含 PNG 加载器阶段。因此，这发生在其他应用程序关闭时，可能不会再保护用户。

阶段 09 变体的主要流程 在系统关机时投放最终有效载荷

从上面的代码中，我们可以观察到，只有当 SMSHUTTINGDOWN 指标非零时，表示当前会话正在关机，并且所有支持的干净文件成功投放时，最终有效载荷 DLL 才会被投放。

有心读者还可以注意到，在上面的代码中，第一个调用的函数是禁用 Windows Defender。此功能通过修改注册表键的常规方式完成。只有在 Defender 被禁用时，恶意软件才能继续执行恶意行为。

将证书添加到 Windows

大多数时候，GuptiMiner 使用自签名的二进制文件进行其恶意活动。然而，这一次，攻击者走得更远。在这种情况下，两个投放的 PNG 加载 DLL 均使用自定义受信任的根证书颁发机构进行签名。这意味著，签名本质上并不受信任，因为攻击者的证书颁发机构无法通过 Windows 中常见的验证流程获得信任。

然而，在恶意软件安装期间，GuptiMiner 还向 Windows 的证书存储中添加了一根根证书，使该证书颁发机构受到信任。因此，当执行这样的签名文件时，它会被视为正确签名。这一过程使用了 CertCreateCertificateContext、CertOpenStore 和 CertAddCertificateContextToStore API 函数。

添加 GuptiMiner 的根证书到 Windows 的函数

该证书在 GuptiMiner 二进制文件中以明文形式存在。

以明文形式存在的证书，在恶意软件中被添加为根证书

在我们的研究中，我们发现了三个不同的证书颁发者在 GuptiMiner 操作中被使用：

GTE 3 证书颁发机构VeriSign 3 类代码签名 2010DigiCert Assured ID 代码签名 CA

请注意，这些名称是人造的，任何与合法证书颁发机构的相似之处都应视为巧合。

在注册表中存储有效载荷

8e96d15864ec0cc6d3976d87e9e76e6eeccc23c551b22dcfacb60232773ec049 (upgradeshowdll 20231123 164134 UTC)

在后期开发阶段，GuptiMiner 的作者开始通过将有效载荷存储在注册表键中来集成更好的持久性。此外，payload 还通过固定密钥进行 XOR 加密。这确保有效载荷在肉眼看来毫无意义。

我们已经发现这些注册表键位置被用于存储有效载荷：

SYSTEMCurrentControlSetControlNlsSortingIdsenUS SYSTEMCurrentControlSetControlPnPPciCardList SYSTEMCurrentControlSetControlWdfDMCF SYSTEMCurrentControlSetControlStorVSPParsers

阶段 1 PNG 加载器

ff884d4c01fccf08a916f1e7168080a2d740a62a774f18e64f377d23923b0297 (20180419 094525 UTC)

当 PE 文件的入口点被来自阶段 0 的 shellcode 执行时，恶意软件首先创建一个计划任务，试图清除初始感染，删除 updll62dlz 压缩档案和 versiondll 库。

此外，此 PE 作为额外阶段的投放器，通过联系攻击者的恶意 DNS 服务器进行操作。此过程通过向攻击者的 DNS 服务器发送 DNS 请求，获取包含响应的 TXT 记录。TXT 响应包含实际 CampC 服务器的加密 URL 域，应请求以获取额外的有效载荷。该有效载荷是一个有效的 PNG 图像文件TMobile 的 logo，其末尾也包含一个附加的 shellcode。接着，恶意软件以单独的线程执行该 shellcode，提供下一阶段的进一步恶意功能。

请注意，由于 DNS 服务器本身是恶意的，所请求的域名实际上并不重要，或者更抽象地说，可以认为这种功能类似于传递给服务器的“密码”，决定 DNS 服务器是否提供所需的 TXT 响应及其携带的指令。

如我们在域时间线部分提到，这里使用了多个这样的“请求域”。在此引用的版本中，我们可以看到以下两个域被使用：

extpeepzo[]com crlpeepzo[]com

且在这种情况下，恶意 DNS 服务器地址为：

ns1peepzo[]com

在这里，我们可以看到使用 Wireshark 捕获的 DNS TXT 响应。请注意 Transaction ID = 0x034b 在 GuptiMiner 操作的所有这些年中保持不变。我们觉得这很有趣，因为我们本希望这可能会很容易被防火墙或 EDRs 标记。

使用 Wireshark 捕获的 DNS TXT 响应

当恶意软件执行查询时的请求间隔是随机的。在 PNG 加载器执行后的头20分钟内执行初始请求以获取 DNS TXT 记录。之后的请求，这些请求用于恶意软件的更新例程，每次请求之间的间隔最长可达69小时。

这种更新机制通过创建与 shellcode 版本号相对应的独立互斥锁来反映，版本信息用作解密的 DNS TXT 响应的前两个字节见下文解密过程。这确保同一版本的 shellcode 不会在系统上运行两次。

互斥锁由 shellcode 的版本信息编号

DNS TXT 记录解密

在收到 DNS TXT 记录后，GuptiMiner 使用 base64 解码内容，并使用 MD5 作为密钥派生函数和 RC2 加密算法进行解密。请注意，在此恶意软件的后续版本中，作者通过使用校验和和其他解密密钥改进了解密过程。

对于密钥派生函数和解密过程，作者决定使用标准 Windows CryptoAPI 函数。

标准 Windows CryptoAPI 函数的典型使用

有趣的是，细心观察的读者可以发现此初始化过程中的一个疏忽，特别是在 CryptHashData 函数中。 CryptHashData API 函数 的原型如下：

BOOL CryptHashData( [in] HCRYPTHASH hHash [in] const BYTE pbData [in] DWORD dwDataLen [in] DWORD dwFlags )

这个函数的第二个参数是一个指向长度为 dwDataLen 的字节数组的指针。然而，该恶意软件在 Unicode (UTF16) 格式中提供了字符串 LPOVO@1，被表示为字节数组 pbData。

因此，该数组的前六个字节仅为 db P 0 O 0 V 0，这有效地将密钥削减到一半，并用零填充。尽管恶意软件作者在这些年中更改了解密密钥，但他们从未修复这个疏忽，直到最新版本的 GuptiMiner。

DNS TXT 记录解析

在此，我们希望展示解密后的 TXT 记录和解析方式。在此示例中，在访问攻击者的恶意 DNS 服务器 nssrnmicro[]net 以及请求的域 spfmicrosoft[]com 时，服务器返回以下 DNS TXT 响应：

VUBw2mOgagCILdD3qWwVMQFPUd0dPHO3MS/CwpL2bVESh9OnF/Pgs6mHPLktvph2

经过完全解码和解密，此字符串，我们得到：

此结果包含多个字段，且可以解释如下：

名称 值版本 1 1 版本 2 5 密钥大小 r (= 0xD) 密钥 Microsoftcom CampC URL http//wwwdeanmiller[]net/m/ 校验和 xde

前两个字节，版本 1 与版本 2，构成 PNG shellcode 版本。目前尚不清楚为什么有两个版本，因为在程序中实际上从未使用版本 2。只有版本 1 在决定是否执行更新时被考虑即，是否下载并加载 PNG shellcode。在任何情况下，我们可以将这些数字视为主要版本和次要版本，仅主要版本作为更新过程的触发器。

第三个字节是密钥大小，表示后续应该读取多少字节，然后构成密钥。此外，在密钥和 URL 之间不需要额外的分隔符，因为密钥大小是已知的，且 URL 紧随其后。最后，两个字节的校验和可以通过计算所有字节的和取模 0xFF进行验证。

在 DNS TXT 记录解码和解密后，恶意软件会从提供的 URL 下载下一阶段，有效载荷以 PNG 文件的形式。这是通过使用标准的 WinINet Windows API 完成的，其中 UserAgent 设置为包含当前正在运行的进程的位数信息。

恶意软件向 CampC 服务器报告当前进程的位数

CampC 服务器使用 UserAgent 信息有两个功能：

提供以正确位数的格式传递下一阶段 (shellcode) 过滤任何不包含此信息的 HTTP 请求，作为保护机制

解析 PNG 文件

下载的文件是有效的 PNG 文件，并且其末尾也包含一个附加的 shellcode。该图像是 TMobile 的 logo，并且恰好为 805 字节。恶意软件在解析这 PNG 文件时会跳过这些字节，文件的其余部分从偏移量 0x325 开始，通过使用从 TXT 响应中提供的密钥通过 MD5 派生使用 RC2 解密。使用图像作为前缀的原因是为了进一步隐藏网络通信，其中有效载荷看起来像合规的图像，可能会遗漏附加的恶意代码。

PNG 文件，shellcode 从 0x325 开始

从位置 0x325 加载的 shellcode 继续从内存中加载额外的 PE 加载器，以解压下一个阶段，使用 Gzip。

IP 地址隐藏

294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a (20231109 141945 UTC)

在 2023 年末，作者决定放弃多年使用 DNS TXT 记录分发有效载荷的方式，转而使用 IP 地址隐藏技术。

这一新方法包括几个步骤：

通过使用标准的 gethostbyname API 函数，以标准方式获取注册到攻击者的服务器名称的 IP 地址 对于该服务器，返回两个 IP 地址第一个是一个被隐藏的地址，第二个表示可用有效载荷版本，并以 23195 为前两个八位字节开头 如果版本比当前版本新，则被隐藏的 IP 地址将被解密，并得到实际的 CampC IP 地址 实际的 CampC IP 地址与硬编码的常量字符串用于 URL 路径一起用于下载包含 shellcode 的 PNG 文件

解密过程通过对 IP 地址的每个字节进行异或 (XOR) 运算，使用的是 0xA 0xB 0xC 0xD 的顺序。这一结果随后被加入到 URL 路径中使用的硬编码常量字符串。

举个例子，我们观察到的一个服务器是 wwwelimpacific[]net。在当时，它返回的如下：

地址 23195101[]1 表示一个版本，如果它大于当前版本，则通过下载 PNG 文件的方式执行更新叶子文件。该更新文件通过请求来自实际 CampC 服务器的 PNG 文件，地址是通过解密 17938204[]38 地址得来的：

然后发出的请求包括计算好的 IP 地址18545192[]43 和硬编码常量elimp。像这样的常量的使用可视为一种额外的密码，实际上：18545192[]43/elimp/

[](https//decodedavastio/wpcontent