xmlns="http://www.w3.org/2000/svg"

style="display:

none;">

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\启动，如果不是则直接退出——这是一种反沙箱/反调试技巧。

一旦确认处于正确路径，恶意程序会在当前进程内初始化CLR（公共语言运行时）环境，并加载一个内嵌的、很小的.NET可执行文件（SHA1:eec1a5e3bb415d12302e087a24c3f4051fca040e）。

这个.NET程序基于开源项目UnmanagedPowerShell修改而来，攻击者为其添加了AMSI绕过功能，使其可以在任意进程中执行PowerShell代码。

随后，它利用该程序执行一段三行的PowerShell脚本，每行都是一个Base64编码的载荷：

#
实际执行的三行脚本（简化）[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\与文件：
  • 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

修复步骤

1. 联系eScan技术支持：eScan官方已开发专用清除工具，用户可通过邮件或客服渠道获取。

   该工具可移除恶意组件、恢复被篡改的配置并恢复更新功能。

2. 手动清理（备用方案）：
   • 删除恶意计划任务。

   • 删除上述注册表键值。

   • 恢复hosts文件，移除恶意条目。

   • 从干净备份或官方渠道恢复reload.exe和CONSCTLX.exe文件。

   • 检查eScan的排除列表，移除添加的排除路径。

3. 更新杀毒软件：确保eScan病毒库已更新至最新，同时可使用其他可靠杀毒软件（如卡巴斯基）进行二次扫描。

4. 监控可疑行为：检查系统是否有其他异常进程、网络连接或计划任务。

5.3

卡巴斯基用户防护

卡巴斯基的全线产品（如Kaspersky

Next）已通过行为检测组件有效检测此次攻击中使用的所有恶意软件。

建议用户保持安全软件实时开启，并及时更新。

六、总结与反思

eScan供应链攻击事件再次提醒我们：安全软件并非绝对可信，任何软件都可能成为攻击者的跳板。

对于厂商而言，必须严格保护基础设施，实施多因素认证、最小权限原则，并定期审计第三方组件。

对于用户而言，应保持警惕，即使安全软件提示更新，也应注意更新的来源是否异常（例如数字签名无效、更新后出现异常错误等）。

此次攻击虽然技术上不算高明，但其针对安全软件供应链的精准打击，充分展示了现代网络攻击的复杂性。

作为安全从业者，我们需要不断反思：如何保护那些保护我们的软件？答案也许在于更严格的供应链安全审查、更深度的威胁情报共享，以及始终如一的怀疑精神。

（本文基于卡巴斯基Securelist报告《Supply

chain

updates》整理分析，日期：2026年2月18日）