eScan杀毒软件供应链攻击剖析和解读：一次针对信任链的精准打击

作为一名从事恶意代码分析与应急响应的网络安全工程师，每当看到安全软件自身成为攻击载体时，我都会感到一阵寒意------因为安全软件通常是系统中最受信任的组件，一旦被攻破，攻击者便能轻易绕过层层防护，长驱直入。2026年1月20日，印度杀毒软件厂商MicroWorld Technologies旗下的eScan产品就遭遇了这样一场供应链攻击。攻击者入侵了eScan的区域更新服务器，向用户推送了恶意更新，在全球范围内（尤其是南亚地区）掀起了一场隐蔽的感染浪潮。本文将从技术视角，深度还原此次攻击的完整链条、恶意软件的工作机制，并提供实用的检测与修复建议。

一、事件概述：安全软件成为"特洛伊木马"

2026年1月20日，eScan的用户像往常一样接收杀毒软件更新，殊不知更新包中包含了一个经过精心篡改的组件------reload.exe。这个文件在用户系统上启动后，会触发一个多阶段的感染链，最终在受害主机上植入两个持久化后门，并彻底破坏eScan的更新能力，使用户无法接收后续的病毒库更新，陷入"断网"状态。

卡巴斯基与Morphisec的安全研究人员几乎同时发现了此次攻击。根据eScan官方的声明，攻击者仅入侵了一个区域更新服务器，并非产品本身存在漏洞，而是由于基础设施的访问凭证被窃取 。被替换的reload.exe文件带有一个伪造的无效数字签名，企图蒙混过关。值得庆幸的是，由于攻击者使用的技术手段并不算顶尖（用户态组件+计划任务），卡巴斯基的行为检测引擎成功拦截了相关攻击。然而，仍有数百台设备（主要位于印度、孟加拉国、斯里兰卡、菲律宾）在更新窗口期内被感染。

二、攻击链分析：从reload.exe到三个隐藏载荷

2.1 入口点：恶意reload.exe的启动

被替换的reload.exe位于C:\Program Files (x86)\eScan\目录下。这个文件本身是eScan的正常组件，但攻击者将其替换为恶意版本。该恶意样本经过重度混淆，包含大量常量展开和间接跳转，增加了分析难度。它首先会检查自己是否真的从Program Files目录启动，如果不是则直接退出------这是一种反沙箱/反调试技巧。

一旦确认处于正确路径，恶意程序会在当前进程内初始化CLR（公共语言运行时）环境 ，并加载一个内嵌的、很小的.NET可执行文件（SHA1: eec1a5e3bb415d12302e087a24c3f4051fca040e）。这个.NET程序基于开源项目 UnmanagedPowerShell 修改而来，攻击者为其添加了 AMSI绕过 功能，使其可以在任意进程中执行PowerShell代码。随后，它利用该程序执行一段三行的PowerShell脚本，每行都是一个Base64编码的载荷：

powershell 复制代码

# 实际执行的三行脚本（简化）
[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("<base64_1>")) | iex
[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("<base64_2>")) | iex
[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("<base64_3>")) | iex

这三个Base64载荷分别承担不同的任务：篡改eScan、绕过AMSI、受害验证与持久化。

2.2 第一载荷：瘫痪eScan，为后门铺路

第一个解码执行的PowerShell脚本主要针对eScan本身进行破坏，具体操作包括：

删除关键文件 ：例如删除远程支持工具 tvqssapp.exe，但在删除前会将其打包备份到 C:\ProgramData\esfsbk\ 目录下，以ZIP格式保存。这一行为表明攻击者可能留了一手，以防误删导致系统崩溃。
添加排除路径 ：修改注册表项 HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\MwMonitor，将 C:\Windows、C:\Program Files 和 C:\Program Files (x86) 添加到杀毒软件的监控排除列表中，使后续的恶意活动免于被扫描。
劫持更新域名 ：修改 hosts 文件，将 update1.mwtnet 等eScan更新域名指向IP地址 2.3.4.0，彻底阻断用户接收官方修复更新。
篡改病毒库版本 ：在注册表 HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\ODS 下新建 WTBasensew 值，并设置为 999，可能用于使主程序误认为病毒库已最新，从而不再尝试更新。
替换eScan组件 ：将另一个eScan合法组件 CONSCTLX.exe 替换为恶意版本，作为后续持久化后门之一。

值得一提的是，该载荷在执行过程中会向 C:\ProgramData\euapp.log 写入调试日志，这为我们提供了明确的检测指标。不过，在我们的测试环境中，eScan的自保模块成功阻止了某些操作（如修改hosts），但最终更新功能仍被破坏，用户界面会弹出诡异的"操作成功完成"错误提示，实际上并未下载任何更新。

2.3 第二载荷：AMSI绕过，隐藏PowerShell活动

第二个载荷是经典的AMSI绕过代码。它通过获取 amsi.dll 中 AmsiScanBuffer 函数的地址，并在其内存中打补丁，使其始终返回 AMSI_RESULT_CLEAN，从而使后续任何PowerShell脚本都不会被AMSI拦截。这种技术虽不新鲜，但配合供应链攻击，足以让攻击者在不触发告警的情况下运行恶意脚本。

2.4 第三载荷：受害验证与植入持久化后门

第三个载荷负责判断当前机器是否值得进一步感染，并部署持久化后门。它首先检查系统中安装的软件、运行中的进程和服务，与一个黑名单进行比对。黑名单中包含常见的安全分析工具（如Wireshark、Process Monitor）以及各大安全厂商的产品------卡巴斯基赫然在列。这意味着，如果目标机器上安装了卡巴斯基产品，该阶段将直接放弃植入，避免被发现。

若验证通过，载荷会进行以下操作：

写入注册表 ：将真正的持久化PowerShell载荷（Base64编码）写入 HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E 的 Core1 值中。
创建计划任务 ：名为 Microsoft\Windows\Defrag\CorelDefrag 的计划任务，每天在随机时间执行一条PowerShell命令。该命令从注册表读取 Core1 值，Base64解码后执行。
发送心跳 ：无论验证成功与否，载荷都会向以下C2域名发送GET请求，附带状态码和错误信息（若有）：
- https://vhs.delrosal[.]net/i
- https://tumama.hns[.]to
- https://blackice.sol-domain[.]org
- https://codegiant.io/dd/dd/dd.git/download/main/middleware[.]ts

至此，受害机器上已经存在两个持久化后门：被替换的CONsCTLX.exe 和 基于计划任务的PowerShell后门。

三、持久化机制的双重保险

3.1 CONSCTLX.exe：伪装成合法组件的CLR加载器

被替换的 CONSCTLX.exe 与 reload.exe 采用相同的混淆和CLR加载技术。它启动后，同样会执行一段内嵌的PowerShell脚本，该脚本从注册表的 Core1 值中取出主载荷并执行。此外，它还会修改 C:\Program Files (x86)\eScan\Eupdate.ini 文件，将eScan的最后更新时间改为当前时间。这样，用户在eScan主界面上看到的更新日期总是最新的，从而掩盖了更新已被阻断的事实。

除了执行主载荷，CONSCTLX.exe 还会尝试从备用C2（https://csc.biologii[.]net/sooc 和 https://airanks.hns[.]to）下载RC4加密的shellcode，解密后直接执行。这为攻击者提供了一条与主载荷完全独立的控制通道，即使计划任务被发现，攻击者仍能通过此通道下发新指令。

3.2 PowerShell主载荷：灵活的远程控制工具

计划任务每天执行的PowerShell主载荷同样包含AMSI绕过和环境验证逻辑。它首先向上述C2域名发送GET请求，但这次会在Cookie中携带一个名为 s 的值，该值是RC4加密并Base64编码的系统信息（包括受害者ID、用户名、当前进程名）。C2服务器可选择性地返回另一个PowerShell脚本，由受害者执行。这使得攻击者能够动态更新任务或下发临时指令。

四、攻击者的准备与本次攻击的特点

要实施如此精确的供应链攻击，攻击者必须完成以下几项准备工作：

渗透更新服务器：获取eScan区域更新服务器的访问权限，能够替换合法文件。
逆向eScan产品：深入了解eScan的更新机制、文件路径、注册表项、自保功能，确保篡改后不会引起系统崩溃。
定制化恶意软件：开发出能够与eScan共存的载荷，并实现双持久化、C2备用通道等高级功能。

从技术层面看，此次攻击并未使用内核级组件或0day漏洞，而是依赖于用户态脚本和计划任务，手法相对传统。然而，其真正危险之处在于利用用户对安全软件的信任------谁会怀疑杀毒软件推送的更新包呢？正是这种信任，让攻击者得以绕过层层防线。

五、检测与修复：实战中的应急响应指南

5.1 检测指标（IoCs）

若怀疑系统遭受感染，请重点检查以下痕迹：

文件哈希（恶意组件）
- reload.exe (SHA256): 1617949c0c9daa2d2a5a80f1028aeb95ce1c0deea928bddfaa536c11c28c8d2c5d16e27cbeaf6357ebaf9715d7f34a77a6e1fd455fe0702274958e2069cdd8476faa7c6a7d2ad285658d3559855b168d
- CONSCTLX.exe (SHA1): 2d2d58700a40642e189f3f1ccea41337486947f5
目录与文件 ：
- C:\ProgramData\esfsbk\（备份文件夹）
- C:\ProgramData\euapp.log（调试日志）
计划任务 ：
- 名称：Microsoft\Windows\Defrag\CorelDefrag
注册表项 ：
- HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E
- HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\ODS 下的 WTBasensew 值为 999
hosts文件 ：
- %WinDir%\System32\drivers\etc\hosts 中是否存在将eScan更新域名指向 2.3.4.0 的条目
网络IoCs ：
- 域名：vhs.delrosal[.]net、tumama.hns[.]to、blackice.sol-domain[.]org、codegiant.io、csc.biologii[.]net、airanks.hns[.]to

5.2 修复步骤

联系eScan技术支持：eScan官方已开发专用清除工具，用户可通过邮件或客服渠道获取。该工具可移除恶意组件、恢复被篡改的配置并恢复更新功能。
手动清理（备用方案） ：
- 删除恶意计划任务。
- 删除上述注册表键值。
- 恢复 hosts 文件，移除恶意条目。
- 从干净备份或官方渠道恢复 reload.exe 和 CONSCTLX.exe 文件。
- 检查eScan的排除列表，移除添加的排除路径。
更新杀毒软件：确保eScan病毒库已更新至最新，同时可使用其他可靠杀毒软件（如卡巴斯基）进行二次扫描。
监控可疑行为：检查系统是否有其他异常进程、网络连接或计划任务。

5.3 卡巴斯基用户防护

卡巴斯基的全线产品（如Kaspersky Next）已通过行为检测组件有效检测此次攻击中使用的所有恶意软件。建议用户保持安全软件实时开启，并及时更新。

六、总结与反思

eScan供应链攻击事件再次提醒我们：安全软件并非绝对可信，任何软件都可能成为攻击者的跳板。对于厂商而言，必须严格保护基础设施，实施多因素认证、最小权限原则，并定期审计第三方组件。对于用户而言，应保持警惕，即使安全软件提示更新，也应注意更新的来源是否异常（例如数字签名无效、更新后出现异常错误等）。

此次攻击虽然技术上不算高明，但其针对安全软件供应链的精准打击，充分展示了现代网络攻击的复杂性。作为安全从业者，我们需要不断反思：如何保护那些保护我们的软件？答案也许在于更严格的供应链安全审查、更深度的威胁情报共享，以及始终如一的怀疑精神。

（本文基于卡巴斯基Securelist报告《Supply chain attack on eScan antivirus: detecting and remediating malicious updates》整理分析，日期：2026年2月18日）