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编码的载荷# 实际执行的三行脚本简化[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/ihttps://tumama.hns[.]tohttps://blackice.sol-domain[.]orghttps://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还会尝试从备用C2https://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):1617949c0c9daa2d2a5a80f1028aeb95ce1c0deea928bddfaa536c11c28c8d2c5d16e27cbeaf6357ebaf9715d7f34a77a6e1fd455fe0702274958e2069cdd8476faa7c6a7d2ad285658d3559855b168dCONSCTLX.exe(SHA1):2d2d58700a40642e189f3f1ccea41337486947f5目录与文件C:\ProgramData\esfsbk\备份文件夹C:\ProgramData\euapp.log调试日志计划任务名称Microsoft\Windows\Defrag\CorelDefrag注册表项HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114EHKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\ODS下的WTBasensew值为999hosts文件%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[.]to5.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日