【案例分享】你的密码出现在暗网，问题可能出在自己的电脑上

写在前面 员工修改了泄露密码，企业就安全了吗？ 不一定。密码只是攻击者已经拿到手的一部分数据。真正需要回答的还有三个问题：密码从哪台电脑泄露？电脑里是否仍有恶意组件？已经泄露的登录会话是否还能继续使用？ 近期，思而听江鹭威胁情报中心监测到某制造企业多条账号凭据泄露记录。客户收到预警后，修改了部分业务系统口令，并临时禁用了公共邮箱。我们没有停在这一步，而是继续追踪消息源、下载窃密日志包并开展上机取证，最终定位到该企业海外分公司的一台个人Windows 11电脑。 调查确认，这不是一次简单的账号撞库。该主机遭遇了Vidar信息窃取木马，419条浏览器明文凭据和3,860条Cookie被打包外流。更早之前，一套恶意加载器已经在主机上驻留50余天。窃密发生时，用户正在正常使用浏览器，没有需要其确认的弹窗。 阅读说明：本文基于一起授权溯源事件复盘。客户名称、员工姓名、账号、真实域名、主机名、IP地址和实际国家或地区均不公开，相关配图由发布方在发布前完成打码。文中数量只反映本次主机和日志包，不代表其他企业或样本。对初始入口、加载器与Vidar之间的衔接过程，本文严格区分已确认事实、合理推断和现阶段无法确认的内容。 一、五条泄露记录，指向同一个源头 1.威胁情报不是转发一条暗网消息 目前，威胁情报已经用于我们的日常安全运营、应急响应、红队渗透。江鹭威胁情报中心依托威胁监控平台，对暗网、明网、舆情及特有渠道开展持续监测，再结合客户提供的域名、资产、邮箱等条件进行聚合、过滤、去重和关联。 单条泄露记录往往只有账号、密码和来源地址，直接转发给客户，无法支撑处置。分析人员需要继续核验消息源、样本时间和涉及资产，再由点到面开展多轮迭代关联。确认情报可靠后，团队向客户输出预警报告，并根据事件情况进入上机溯源、隐患清除、持续加固和后续监测环节。 这套流程的重点不是“看到了多少情报”，而是把一条外部消息转化为可执行的处置动作。 只修改密码、只加固业务系统，并不能回答终端上是否还留有恶意插件、加载器、远控或其他组件。 2.约半小时内，连续出现五条相关记录 2026年10月24日23:02至23:36，平台连续检出五条相关凭据泄露记录，涉及该企业三套系统和五个账号。 这些记录集中在约半小时内出现，又同时覆盖数据中台、物流管理和邮件系统，初步符合单台终端被信息窃取木马抓取浏览器数据后批量上传的特征。不过，此时这仍只是研判方向，不能代替后续取证。 威胁情报预警报告中的泄露记录、资产命中次数和高风险登录入口，客户及账号信息已脱敏 客户收到预警后反馈，相关业务系统口令已经修改并开展排查，公共邮箱也已临时禁用。这些动作能够降低口令被继续使用的风险，但还不能证明主机已经安全，也不能处理仍然有效的Cookie会话。 二、从暗网日志包确认事件性质 1. information.txt 给出了第一组关键答案 根据平台推送的告警，我们继续追踪消息源，找到泄露源的暗网地址，并下载了源数据包。暗网地址及包内账号、口令不在本文公开。 首先核验的是 information.txt 。文件头部同时出现 STEALER-VIDAR 2.0 和 Version: 3.1 ，并记录了主机名、用户名、操作系统、硬件标识、进程清单和软件清单。日志中的主机名和用户名与后续取证对象一致，说明这份日志对应的就是本次排查的主机。 information.txt 记录了窃密家族标识、时间、运行路径和主机信息 日志还记录了 Path: C:\WINDOWS\explorer.exe 和 Work Dir: In memory 。这两个字段将Windows资源管理器记录为运行路径，并将工作目录标为内存，这个提示，将让我们重点检查内存执行和进程寄生。 但这两个字段不能单独证明完整的进程注入链。 要还原父子进程关系，还需要命令行、内存或其他主机侧证据。后文对加载器的分析，正是在寻找这部分缺失的链路。 2.泄露的不只是几个业务密码 对日志包进一步统计后，我们确认其中包含419条明文浏览器凭据和3,860条Cookie，部分会话最长有效至2027年10月。泄露范围同时覆盖个人与企业数据，包括： 企业邮箱三个身份； VPN两条通道； 关务、物流等多个业务系统； 一个数据中台管理员令牌； 一个企业网银账号； 浏览器自动填充信息和加密钱包相关数据。 这解释了为什么五条平台告警会同时出现在不同系统中。攻击者未必逐一攻击了这些业务平台，更可能是从同一台终端一次性拿走了浏览器中保存的访问凭据。 日志中的出口信息、主机名和用户名，则帮助我们把排查范围收敛到客户海外分支的一台具体电脑。至此，溯源目标已经从“几个账号泄露”变成了“哪台主机在什么时间被窃密，恶意代码如何进入并持续运行”。 三、上机取证，先锁定窃密时间 确定涉事分支和主机后，我们在客户授权下开展上机取证，运行取证脚本，采集EFU文件清单、浏览器历史、程序执行记录、Windows Defender日志和可疑样本等数据。 取证工具下载页 1.窃密时间为2026年10月20日09:38:51 information.txt 记录的时间为2026年10月20日01:38:51， TimeZone: 0 表明该时间为UTC。换算成北京时间，窃密时间为 2026年10月20日09:38:51 。 时间本身还需要其他记录印证。主机浏览器历史显示，在窃密前的01:16至01:36 UTC，用户正在访问Netflix。窃密发生后约四分钟，即01:42:46 UTC，Chrome又完成了版本升级。 窃密前，主机存在连续的视频网站访问记录 Chrome主程序在窃密发生后数分钟出现执行和更新相关记录 Chrome升级目录中的文件修改时间与程序记录相互印证 三组记录放在一起，可以确认主机当时处于开机和活跃状态，用户正在正常使用浏览器。窃密过程不需要用户再次输入密码，也没有必须由其确认的提示。 这也是信息窃取木马危险的地方。浏览器为了方便用户保存了密码和会话，恶意程序一旦获得相应权限，就可以集中读取这些数据。用户看到的可能只是一次普通上网，日志包里却已经出现了一批企业系统的入口。 四、向前回溯，发现驻留50余天的加载器 1.异常的 MicrosoftDataEdm 工程文件 确认10月20日的窃密时间后，我们继续向前检查文件和执行记录。EFU文件清单显示，早在 2026年8月28日05:20:10 UTC，北京时间当日13:20:10 ，用户目录下就已经出现一组名为 MicrosoftDataEdm 的可疑文件，比窃密早50余天。 这些文件表面上是.NET工程文件，体积却明显异常。其中 MicrosoftDataEdm.csproj 约为13 MB，相关的 .targets 、 .props 和 .csproj.user 文件也远大于正常配置文件的常见体量。 MicrosoftDataEdm 相关文件在8月28日已经出现，工程文件体积异常 正常工程配置通常不需要占用这样的空间。结合后续逆向结果看，这些文件不仅用于描述工程结构，还被用作恶意数据的存储介质。因此，我们将这组文件列为窃密前的重点持久化载荷，而不是把它们当成普通的软件开发残留。 2.Defender日志补