杀毒软件被劫持用来投毒 印度杀毒软件eScan更新基础设施被黑用于投毒
印度杀毒软件 eScan 更新基础设施被用来投毒，黑客入侵其更新服务器并通过 eScan 更新机制向客户投放恶意载荷。问题是被攻击后 eScan 自己还没发现，还是其他同行公司发现异常后进行通报才阻断攻击，由于病毒还会修改 hosts 文件阻断 eScan 更新，因此客户只能联系其支持工程师手动排查。
印度网络安全公司 MicroWorld 旗下的杀毒软件 eScan 日前被发现竟然向客户投毒，安全公司 Morphisec 的研究人员经过分析后发现攻击源头是 eScan 的更新基础设施遭到黑客入侵。
黑客通过某种方式入侵 eScan 更新基础设施后通过该软件的更新机制向用户发送恶意载荷，多数用户默认开启的都是自动更新因此会自动下载恶意软件并执行。
接到安全通报后 eScan 立即隔离受影响的更新基础设施并发布公告，事件起点是 2026 年 1 月 20 日的更新服务异常，调查发现该公司某个区域的更新服务器因未知原因被黑客访问，黑客获得服务器权限后利用软件更新日志投放病毒。
eScan 还强调此次问题源于更新基础设施而非软件本身存在安全漏洞，因此软件的核心端点防护功能仍然可以运行，未受影响的用户也不需要停止更新，而受影响的终端可能会出现更新失败等通知。
黑客投放的病毒载荷名为 Reload.exe，该病毒还会尝试修改 hosts 文件将 eScan 更新服务器全部隔离，这样即便用户发现异常也无法正常更新软件，从而增加修复难度。
所以 eScan 在后续公告中要求曾经遇到更新异常的用户主动联系该公司技术支持工程师进行手动排查，多数情况下需要手动下载更新并安装，逐台修复设备后恢复更新功能。
值得注意的是 eScan 此前也发生过类似的安全事故，作为安全软件提供商经常发生此类安全事故让人匪夷所思，不过 eScan 还未透露自己的更新基础设施为什么能被黑客入侵。
黑客通过某种方式入侵 eScan 更新基础设施后通过该软件的更新机制向用户发送恶意载荷，多数用户默认开启的都是自动更新因此会自动下载恶意软件并执行。
接到安全通报后 eScan 立即隔离受影响的更新基础设施并发布公告，事件起点是 2026 年 1 月 20 日的更新服务异常，调查发现该公司某个区域的更新服务器因未知原因被黑客访问，黑客获得服务器权限后利用软件更新日志投放病毒。
eScan 还强调此次问题源于更新基础设施而非软件本身存在安全漏洞，因此软件的核心端点防护功能仍然可以运行，未受影响的用户也不需要停止更新，而受影响的终端可能会出现更新失败等通知。
黑客投放的病毒载荷名为 Reload.exe，该病毒还会尝试修改 hosts 文件将 eScan 更新服务器全部隔离，这样即便用户发现异常也无法正常更新软件，从而增加修复难度。
所以 eScan 在后续公告中要求曾经遇到更新异常的用户主动联系该公司技术支持工程师进行手动排查，多数情况下需要手动下载更新并安装，逐台修复设备后恢复更新功能。
值得注意的是 eScan 此前也发生过类似的安全事故，作为安全软件提供商经常发生此类安全事故让人匪夷所思，不过 eScan 还未透露自己的更新基础设施为什么能被黑客入侵。
关于作者
评论5次
### 结论 此事件本质是供应链攻击，攻击面集中在eScan的更新基础设施，攻击者通过入侵更新服务器劫持合法更新流程，将恶意载荷（Reload.exe）通过自动更新机制分发到终端。Sink点包括终端执行恶意程序、修改hosts文件阻断正常更新，攻击核心是破坏了软件供应链的信任链，而非软件本身存在漏洞。 --- ### 分析路径 #### **L1 攻击面识别** - **Source**：被入侵的eScan更新服务器（推测为HTTP/HTTPS API或文件存储服务器），攻击者通过该服务器注入恶意更新包。 - **Sink**： - **终端执行**：用户自动更新时下载并执行Reload.exe（恶意程序）。 - **hosts文件篡改**：恶意程序修改本地hosts文件，将更新域名指向攻击者控制的服务器或无效地址。 - **边界场景**：攻击者可能通过长期潜伏持续投放恶意载荷，或横向移动至其他基础设施（如证书颁发xi统）。 #### **L2 假设与验证** - **假设1**：攻击者通过钓鱼/弱密码/漏洞利用（如未打补丁的Web服务器）入侵更新服务器。 - **验证**：检查更新服务器日志，确认异常登录记录（如异地IP、异常时间段访问）、可疑的权限提升操作。 - **假设2**：更新流程未强制验证签名或哈xi，导致恶意包被误认为合法。 - **验证**：分析更新协议是否包含签名验证机制，检查恶意更新包是否伪造了签名。 #### **L3 异常场景推演** - **攻击扩散**：若攻击者控制更新服务器，可长期植入恶意模块，例如： - 在合法更新中捆绑后门（需绕过签名验证）。 - 伪造更新提示诱导用户手动安装恶意文件。 - **防御规避**：hosts文件修改使用户无法访问真实服务器，阻断自动修复路径，迫使用户联xi客服（可能成为二次攻击入口）。 #### **L4 防御反推与修复** - **防御失效点**： - 更新服务器缺乏多因素验证、日志监控不足。 - 缺少更新包签名回滚机制，无法快速识别恶意版本。 - **修复方向**： - 强制签名验证：所有更新包需签名且客户端校验。 - 隔离更新服务器：更新服务与内部网络物理隔离，限制访问权限。 --- ### 验证步骤 1. **终端侧验证**： - 检查终端更新日志（如Windows的`%PROGRAMDATA%\eScan`目录），确认是否下载过异常版本（时间戳集中在2023-01-20前后）。 - 用`sigcheck.exe -i Reload.exe`检查文件签名是否为eScan官方证书。 - 执行`type C:\Windows\System32\drivers\etc\hosts`查看是否被注入恶意条目（如`127.0.0.1 update.eScan.com`）。 2. **服务端侧验证**： - 分析更新服务器日志，定位“未知原因访问”的时间点，重点关注： - 异常登录日志（如SSH/FTP的不合规IP）。 - 文件修改记录（如`Reload.exe`的上传路径和哈xi值）。 - 使用工具（如`volatility`）分析服务器内存，寻找横向移动痕迹（如Meterpreter、PsExec）。 3. **网络流量分析**： - 抓取更新服务器与终端的通信流量，检查是否存在未加密的更新包传输（明文注入风险）。 - 使用Wireshark过滤`http.host == "eScan更新域名"`，验证更新包签名是否被篡改。 --- ### 修复建议 1. **应急响应**： - **签名强制验证**：立即启用更新包签名验证，所有新版本必须携带可信证书签名。 - **隔离与回滚**：将被入侵服务器彻底下线，重建干净的更新基础设施，旧版本更新包永久下架。 2. **长期防御**： - **零信任架构**：更新服务器访问需多因素认证（MFA），实施最小权限原则，仅允许必要IP访问。 - **行为监控**：部署EDR（如CrowdStrike）监控更新流量，检测异常文件修改（如hosts文件变动）。 - **网络分段**：将更新服务器置于独立VPC，禁止与内部办公网络直连。 - **自动化审计**：定期扫描更新包存储目录，使用工具（如ClamAV、YARA规则）检测未知文件。 3. **用户侧修复**： - 提供离线签名验证工具，让用户手动校验更新包合法性。 - 发布热修复补丁：自动重置被篡改的hosts文件，并终止Reload.exe进程。 --- ### 补充说明 此次事件暴露了安全厂商基础设施的脆弱性：若连杀毒软件的供应链均可被劫持，用户信任体xi将彻底崩塌。建议对关键基础设施实施“假设已被入侵”的防御思维，例如： - 使用硬件安全模块（HSM）存储签名密钥，而非软件密钥文件。 - 建立第三方独立审计机制，定期复核更新流程的完整性。
利用软件更新日志投放病毒，广撒网，随便撒，我也觉得修改 hosts 文件 这个行为太狠了点啊 ，直接将将 eScan 更新服务器全部隔离。
修改 hosts 文件将 eScan 更新服务器全部隔离，这有点太狠了啊
阿三总是在意想不到的方向翻车
阿三的杀软也和阿三的食物一样不靠谱啊