国内消费电子巨头被 Everest 组织勒索

原创

威胁猎人
威胁猎人

OSINT情报分析师

2026年10月21日 21:32
北京

去阅读

北京时间2026年10月21日，我们通过 OSINT 渠道发现，Everest 勒索组织在其数据泄露站点上发布了涉及国内某头部消费电子企业的勒索信息，威胁在约6至7天后公开文件。

目前，这条线索来自攻击者一侧的公开信息，所涉数据的真实性、来源和影响范围仍待核实。本文沿用匿名处理，不披露企业名称。

对涉事企业来说，眼下需要尽快弄清楚的是：对方手里究竟有没有真实数据；如果有，数据从哪里流出，相关访问是否还在继续。

这个团伙既做勒索 也卖企业入口

Everest 至少自2020年年底开始活跃。研究人员发现，该组织早期窃取数据，后来运营勒索软件，同时越来越多地出售对企业网络的非法访问权限。研究人员还发现，它会删除部分售卖权限的帖子，公开页面未必能完整反映这些交易。

这类交易在安全行业被称为初始访问经纪业务，简称 IAB。获得一个能用的企业账号，或在内网留下远程访问入口后，攻击者可以自行继续窃取数据，也可以将访问权限卖给另一批犯罪者。买家再进入网络，寻找自己感兴趣的资产。

因此，企业不能仅根据有没有出现加密文件来判断事件是否结束。数据可能已经被复制走，原来的账号也可能仍能登录。如果访问权限又经过转售，后续进来的人员、使用的工具和行动时间都可能变化。仅清除最初发现的恶意文件，未必能关掉所有入口。

Everest 也没有放弃加密。AttackIQ 在2026年7月发布的样本分析中，仍记录到其加密程序破坏恢复条件、削弱安全设置等行为。这意味着处置时需要同时考虑数据外泄和业务破坏，不能因为暂时没有宕机就缩小排查范围。

不过，攻击者公布的信息也需要核对。ZeroFox 在2026年2月对 Everest 的评估中指出，它可能夸大所持数据的数量和敏感程度，个别情况下甚至可能编造数据。对本次事件的判断，应当落到可验证的文件、账号和访问记录上，不能直接沿用勒索页面给出的结论。

数据可能从供应商那里流出

2025年12月3日，华硕发布过一份值得参考的官方声明：一家供应商遭到攻击，影响到部分华硕手机摄像头源代码；华硕表示，其产品、内部系统和用户隐私未受影响。

这件事说明，看到某个品牌的代码出现在外部，仍要追查代码原本由谁保管。联合研发、功能调试和项目交付，都可能让合作伙伴合法持有同一套资料。供应商遭到入侵后，品牌方也可能需要介入调查，即便自己的系统没有被直接攻破。

对这次被点名的消费电子企业，建议先由安全、研发和采购人员一起核对攻击者展示的材料。若能取得可依法核验的样本，就从项目名称、代码分支、版本、文件时间及交付范围入手，查清哪些部门和合作伙伴持有过同样的内容。相同文件在多处留存时，还要结合访问与传输记录判断，不能只凭文件里出现公司名称就认定来源。

供应商调查也应当落到具体项目。除了询问对方是否发生安全事件，还要核对交付目录、文件传输记录、项目账号和远程维护权限。合作已经结束却仍然有效的账号、多个项目共用的凭据，以及能够跨项目访问的目录，都值得优先检查。

如果确认涉及源代码，还需要查看代码包里是否夹带访问令牌、数据库连接信息或签名材料，并评估这些秘密是否需要轮换。代码外泄本身不能证明产品被植入后门；但若构建系统、发布账号或签名密钥也被访问，排查就必须继续延伸到产品构建与发布过程。

先沿着账号查 再还原数据去了哪里

NCC Group 在一次部署了 Everest 勒索软件的事件中，观察到攻击者使用被攻陷的账号，通过 RDP 远程桌面横向移动，并实施凭据转储。其记录还涉及 AnyDesk、Splashtop、Atera 等远程访问工具，其中 Splashtop 被用于数据外传。这是历史个案中的行为，不能当作本次事件已经查明的经过，但可以用来确定核查重点。

企业应先保全 VPN、身份平台、远程桌面网关和相关主机日志，把公开勒索前的活动串起来。回溯范围需要随着最早异常继续向前扩展，不能只查被挂上站点的当天。值得关注的是账号从哪里登录、访问了哪些主机，以及这些活动是否能与实际工单和人员操作对应。

在已开启相应审计的 Windows 环境中，可以从安全日志的4624成功登录事件入手，关联账号、来源和目标主机；其中登录类型10对应远程桌面等远程交互式登录。再结合4625失败登录事件，查看是否存在反复失败后成功、非工作时段使用或陌生来源访问。日志字段的完整程度取决于认证方式，必要时应与网关记录交叉核对，单条登录事件不能直接判定入侵。

发现可疑账号后，应结合业务影响及时限制其访问，并检查新加入的认证方式、关联设备、应用授权及持久化入口。在使用云身份的平台上，还要按平台机制撤销相关会话和刷新令牌；仅修改密码，可能不足以终止所有已建立的访问。应用自己维护的会话也可能需要单独处理。

终端侧则要把远程工具的安装、启动时间与上述登录记录对起来。工具本身可能用于合法运维，需要确认是谁部署的、连向哪里、对应哪个维护任务。对于异常访问凭据进程、创建计划任务或服务、停止安全和备份服务等行为，应结合进程树、文件落地和变更记录判断是否存在关联。

数据侧的核查可以从代码仓库、研发共享盘和文件服务器展开。查看是否有异常的批量读取、仓库克隆、归档压缩或集中导出，再与出口代理、防火墙及云存储访问日志对应。外传可能分批完成，不能只筛选一次性的大流量。若只能证明存在异常连接，就应保留这一判断边界；要确认哪些文件流出，还需要终端和存储侧的证据。

排查记录中应保留证据来源、涉及账号和设备、发生时间及待确认事项。这样，身份、终端、网络和供应商几条线索才能相互核对，也便于在出现新的数据样本后继续追查。

查清范围以后 再安排恢复和沟通

在仍有异常访问的情况下，安全团队应按既有响应流程控制受影响账号和设备，同时保留后续分析需要的日志及取证材料。恢复业务要与清除入口、处理持久化访问一起推进，避免系统恢复后再次被进入。

这次线索给企业的一个直接启示，是把数据外泄单独纳入响应。离线备份和恢复演练可以帮助应对加密破坏，却无法收回攻击者已经复制走的资料。确认外泄后，哪些秘密需要轮换、哪些客户或合作伙伴需要告知，都要依据实际数据内容和受影响范围安排。

对外沟通前，安全、业务和供应商负责人应当先对齐已经查明的事实。攻击者宣称持有多少数据、企业确认哪些系统受影响、调查还没有排除哪些可能，应分别说明。

目前，这家消费电子企业的具体情况仍待进一步核实。对其他企业而言，可以先做一件与这次线索直接相关的事：选一个正在交付的研发项目，查一遍代码和测试资料交给了谁，相关账号现在能访问什么，合作结束后由谁收回。若连这些问题都需要临时四处询问，真正发生泄露时，确认影响范围也会花费更长时间。