写在前面
员工修改了泄露密码，企业就安全了吗？
不一定。密码只是攻击者已经拿到手的一部分数据。真正需要回答的还有三个问题：密码从哪台电脑泄露？电脑里是否仍有恶意组件？已经泄露的登录会话是否还能继续使用？
近期，思而听江鹭威胁情报中心监测到某制造企业多条账号凭据泄露记录。客户收到预警后，修改了部分业务系统口令，并临时禁用了公共邮箱。我们没有停在这一步，而是继续追踪消息源、下载窃密日志包并开展上机取证，最终定位到该企业海外分公司的一台个人Windows 11电脑。
调查确认，这不是一次简单的账号撞库。该主机遭遇了Vidar信息窃取木马，419条浏览器明文凭据和3,860条Cookie被打包外流。更早之前，一套恶意加载器已经在主机上驻留50余天。窃密发生时，用户正在正常使用浏览器，没有需要其确认的弹窗。
阅读说明：本文基于一起授权溯源事件复盘。客户名称、员工姓名、账号、真实域名、主机名、IP地址和实际国家或地区均不公开，相关配图由发布方在发布前完成打码。文中数量只反映本次主机和日志包，不代表其他企业或样本。对初始入口、加载器与Vidar之间的衔接过程，本文严格区分已确认事实、合理推断和现阶段无法确认的内容。
一、五条泄露记录，指向同一个源头
1.威胁情报不是转发一条暗网消息
目前，威胁情报已经用于我们的日常安全运营、应急响应、红队渗透。江鹭威胁情报中心依托威胁监控平台，对暗网、明网、舆情及特有渠道开展持续监测，再结合客户提供的域名、资产、邮箱等条件进行聚合、过滤、去重和关联。
单条泄露记录往往只有账号、密码和来源地址，直接转发给客户，无法支撑处置。分析人员需要继续核验消息源、样本时间和涉及资产，再由点到面开展多轮迭代关联。确认情报可靠后，团队向客户输出预警报告，并根据事件情况进入上机溯源、隐患清除、持续加固和后续监测环节。
这套流程的重点不是“看到了多少情报”，而是把一条外部消息转化为可执行的处置动作。只修改密码、只加固业务系统，并不能回答终端上是否还留有恶意插件、加载器、远控或其他组件。
2.约半小时内，连续出现五条相关记录
2026年10月24日23:02至23:36，平台连续检出五条相关凭据泄露记录，涉及该企业三套系统和五个账号。
这些记录集中在约半小时内出现，又同时覆盖数据中台、物流管理和邮件系统，初步符合单台终端被信息窃取木马抓取浏览器数据后批量上传的特征。不过，此时这仍只是研判方向，不能代替后续取证。
威胁情报预警报告中的泄露记录、资产命中次数和高风险登录入口，客户及账号信息已脱敏
客户收到预警后反馈，相关业务系统口令已经修改并开展排查，公共邮箱也已临时禁用。这些动作能够降低口令被继续使用的风险，但还不能证明主机已经安全，也不能处理仍然有效的Cookie会话。
二、从暗网日志包确认事件性质
根据平台推送的告警，我们继续追踪消息源，找到泄露源的暗网地址，并下载了源数据包。暗网地址及包内账号、口令不在本文公开。
首先核验的是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日志补全执行与持久化记录
文件存在，不等于文件执行过。为交叉验证，我们查询了Windows Defender的1116、1117事件。
2026年9月1日02:15:59 UTC，Defender首次检出updater_76ab.cmd，检测名为Trojan:Script/Multiverze!rfn。当天13:59:44 UTC，同一载荷再次触发告警，相关记录中同时出现计划任务spoolsv和对应的TaskCache注册表路径。
2026年9月1日10:15:59（UTC+8），updater_76ab.cmd首次检出
2026年9月1日21:59:44（UTC+8），Defender记录中同时出现计划任务spoolsv和TaskCache路径
结合BAT文件、MSBuild工程文件和计划任务，可以还原这套机制的基本工作方式：
updater_76ab.cmd承担运行器角色；- 计划任务
spoolsv负责持续拉起；
MicrosoftDataEdm系列文件借助MSBuild工程结构执行后续恶意逻辑。
spoolsv与Windows打印后台处理组件名称相似，具有明显的伪装特征。到这里，可以确认主机上长期存在一套具备后续载荷执行条件的MSBuild/BAT加载器，而不只是几个静态可疑文件。
3.告警和删除，不等于整条链路已经清除
2026年10月25日，Defender再次检出updater_76ab.cmd，说明9月1日的检测和处置没有彻底移除整套机制。
2026年10月25日17:58:42（UTC+8），Defender再次检出运行器
当天11:46:55 UTC，Defender对相关BAT文件执行了Remove。
2026年10月25日19:46:55（UTC+8），Defender对BAT文件执行Remove
这条记录解释了两个问题。
第一：运行器脚本被删除后，我们已无法取得其原始内容。
第二：删除一个运行器不等于清除计划任务、工程文件、其他副本和已经执行的内存载荷。
正如前面在information.txt中看到的，窃密发生在10月20日，而Defender在10月25日仍在处理同一套运行器。加载器的时间范围完整覆盖了窃密事件，此前仅修改业务密码并不能改变这一事实。
五、窃密时的进程清单，进一步缩小排查范围
除了时间和文件记录，information.txt还保存了窃密发生时的进程清单。清单首项为Setup(2).exe，同时包含FakeClient.exe、gs-server.exe等可疑进程。
窃密日志保存的进程清单，Setup(2).exe等进程是后续排查重点
这些程序在窃密时处于运行状态，但在10月26日采集的EFU文件清单中均未找到同名文件。这种状态符合临时落地后自删除，或未被常规文件清单保留的特征，为进一步排查提供了方向。
从时间关系看，加载器自8月28日起已经驻留，9月1日出现明确执行和计划任务记录，10月25日仍能检测到运行器副本。从能力上看，它具备通过BAT、计划任务和MSBuild执行后续载荷的条件。现有样本链主要是托管代码，而窃密日志指向原生进程运行，二者之间仍需要找到一次原生程序的落地与执行记录。
现阶段可以确认的是“长期加载器覆盖窃密时间并具备投放能力”，不能直接写成“已经证明该加载器投放了Vidar”。原始运行器、Setup(2).exe文件及哈希、父子进程命令行和内存证据均有缺失，唯一执行链无法闭合。
六、逆向分析，加载器如何工作
本次分析样本导出自涉事主机用户目录下的TexasInstruments/ThunderboltHelper路径。目录名称借用了正常硬件厂商和组件名称，实际内容则是一套面向Windows的多阶段恶意加载器和下载器。
MicrosoftDataEdm与TexasInstruments/ThunderboltHelper两个封装包含相同的七个文件。样本利用MSBuild工程属性加载隐藏的.NET程序，从工程文件自身恢复第二阶段，再按时间选择远程地址，解码并反射调用下载组件。核心载荷借用正常库名称和类型结构，通过字符串加密、自定义字节码和函数指针分派隐藏加载逻辑，两层DLL在当前进程内通过原始字节加载和托管反射完成交接。第二阶段还会收集系统和运行环境信息，生成客户端标识，将运行状态加密后发送到指定接口。
加载器从MSBuild工程读取到第二阶段下载、回传的主要流程
| 文件 |
字节数 |
SHA-256 |
| MicrosoftDataEdm.Build.props |
263,765 |
a70fec7c17124f2f3be6742ae032d6cbc3ec93a72ab4dec42390efd1fd81e72a |
| MicrosoftDataEdm.Compile.targets |
646,618 |
f1209f0a18988c89fa58bf939c6fd3b42989cf66dadc2ff6a0d8875ed5235702 |
| MicrosoftDataEdm.csproj |
13,003,368 |
246fe0cf2f0dc09fb4ac500bdb056154132fbf997b5e6817b1d4ede7b55220bb |
| MicrosoftDataEdm.csproj.user |
449,042 |
7118a570ebbde8435d1096d9eab92622db8aec5d0ff03924affb17b6805f65e3 |
| config_ba892.cfg |
123 |
c4708de04f87222974e601fead5d28773d70eb4e8598859e0f6677b492c2afd7 |
| runtime_e3cf.dat |
162 |
9ab3b58f2dde6946d50903353e20674af081048176b54a68deafb4b4b615fe2b |
| settings_307.log |
100 |
d290e1caa88d69b822805ed489f7774171181fb2fcf60647df0acb13345ec3dd |
原始组件的完整 SHA-256
1.工程属性求值阶段就开始加载
第一阶段以MSBuild工程属性求值阶段为执行入口。工程依次导入.csproj.user、.Build.props与.Compile.targets。其中.Compile.targets将三个属性值拼接为十六进制字符串，经SoapHexBinary解析为字节流，再调用AppDomain.Load加载程序集，并通过CreateInstance实例化Microsoft.Data.Edm.FallbackDescriptor。
主工程以'off$(PackageIcon)' == 'on'作为导入条件引用相关属性，因此加载动作发生在工程属性求值路径，而不是一般业务代码的编译执行路径。简单说，攻击者把工程文件同时当成了数据容器和触发入口，并借用Windows自带的MSBuild完成第一阶段加载。
工程文件中存在异常大的属性数据，后续用于还原和加载恶意程序集
该加载路径还有一个运行前提：环境变量_avpr必须指向可读取的原始工程文件，读取完成后即被清除。现有封装没有包含设置该变量的启动脚本。结合前文Defender日志，缺失的updater_76ab.cmd可能承担这一作用，但由于原始脚本已被删除，这仍属于链路推断。
2.第二阶段从工程文件自身重建
第二阶段不是以一个独立DLL文件简单存放在目录中，而是需要从工程文件自身还原。
.csproj、.Build.props、.Compile.targets三段十六进制数据解码后，分别为221,823、130,783、322,722字节，合计675,328字节，构成整数索引流。程序将各整数换算为字节下标，从“0至255字节表与工程原始字节”拼接而成的缓冲区中取值，最终还原为4,302,848字节的PE32+托管DLL。
这个过程依赖工程原始字节。文件编码或换行方式一旦变化，索引指向就可能发生偏移，导致重建失败。这也是分析此类样本时必须保留原始文件、不能只用格式化后的文本副本的原因。
还原后的Microsoft.Data.Edm.dll及其中的FallbackDescriptor类型
3.两层程序集交接，并检查分析环境
程序集还原完成后，样本通过反射调用System.Threading.Tasks.ManifestHelper.EndRandom()，进入SourcePolicy初始化和下载调度。
反调试检查设置在加载前后。托管层读取Debugger.IsAttached，原生层通过动态解析的进程查询接口分别获取信息类7和0，并核验返回结构中偏移2字节的标志位。任一检查成立，当前加载路径就会中止。
样本通过原生进程查询接口检查调试标志
收尾阶段，样本还会清除命令行参数、抹除已加载模块的DOS/PE头部字段、改写模块内存区域，并结束承载进程。这些动作增加了事后文件发现和内存分析的难度，也与本次“磁盘上找不到一个可直接删除的完整窃密程序”的现场情况相符。
4.下载、校验与状态回传
远程内容需要通过字节指纹校验，才能进入程序集加载和反射调用。如果返回内容以DETECT:开头，样本会转入检测状态回传，并终止后续流程。单实例互斥体则用于避免同类组件重复运行。
第二阶段包含反序列化、动态调用和参数处理逻辑
样本通过互斥体维持单实例运行
样本内置15个下载域名，以172,800秒，也就是两天为步长推进，耗尽后固定在末位。地址选择基准为2026年8月26日13:44:42 UTC，下标按当前项及前两项取值，负下标省略。按2026年11月6日计算，三个候选域名依次为：
plebumli.lolvoumloja.cfdcainvulu.lol
通信方面，请求头包含X-Timestamp、X-Nonce、X-Signature和X-Request-Context，签名算法为HMAC-SHA256。状态回传正文通过ECDH P-256协商密钥，再使用AES-128-CBC加密。数据包依次包含65字节临时公钥、16字节IV和密文。
客户端标识由固定前缀nogit与MachineGuid、卷序列号摘要的前16字节拼接构成。样本还具备方法虚拟化、基于模块MVID的配置字符串解密，并使用VaultLibrary Pro和.ntcfg等名称伪装成媒体管理组件。
这些细节说明，它不是一次性脚本，而是一套包含持久化、分阶段加载、远程下载、环境检查、加密回传和痕迹处理的完整加载机制。
5.网络 IOC
下表按样本地址池顺序列出 15 个域名及对应的下载、回传 URL。
七、初始入口只能推测，不能硬凑结论
入口样本已经被Defender删除，无法确定具体是哪一个文件导致初始感染。现有证据能够证明主机长期处于高风险软件使用环境，但不能把某一次下载直接认定为唯一入口。
我们核对到三类相互印证的记录：
- Defender历史检出：2026年1月至10月共检出43条、处置28条，主要涉及激活工具和破解补丁。
- 浏览器下载记录：共67条，集中于KMS激活工具包、Office整合包和游戏破解包。
- 防护配置变更：2026年1月1日09:15:38，Defender检出
Add_Defender_Exclusion.cmd；09:15:45，系统写入八条排除记录，两者相隔七秒。
这些记录说明，主机长期存在缺乏来源校验的软件获取行为，并具备让恶意文件免于常规扫描的客观条件。排除项也不能简单认定全部由用户手工添加，历史告警中出现过投放器和排除项篡改类威胁。
因此，本次初始入口高度疑似来自破解软件、激活工具或游戏外挂生态。这是基于历史下载、检出记录和防护排除项作出的风险判断，不是对某个入口样本的确定性归因。
八、按现有证据还原事件过程
综合窃密日志、主机文件、Defender事件、进程清单和样本逆向结果，本次事件可以还原为以下几个阶段：
- 高风险软件环境形成：主机多次下载激活工具、破解软件和游戏相关程序，部分目录被加入Defender排除项，恶意文件因此获得落地和驻留空间。
- 加载器落地：2026年8月28日，
MicrosoftDataEdm相关文件写入用户目录，并在缓存目录、系统保护目录等四个位置各保留一份。异常大的工程文件同时承担恶意数据存储功能。
- 计划任务驻留：9月1日前后，运行器、MSBuild工程文件和计划任务
spoolsv组成加载链，恶意代码得以借助系统组件反复启动。
- 窃密组件运行：10月20日，Vidar完成浏览器数据窃取。长期加载器覆盖这一时间并具备投放能力，
Setup(2).exe等进程是当时的重要线索，但缺少直接证据证明唯一的原生载荷投递步骤。
- 日志包流通：419条明文浏览器凭据、3,860条Cookie及其他数据被整理为标准日志包，在暗网市场建档流通。后续使用者无需继续控制原主机，也可能利用有效口令和会话访问企业系统。
- 部分组件被清除：10月25日，Defender再次检出并删除运行器，但工程文件、计划任务及其他副本仍需要专项清理，不能将一次
Remove记录视为事件结束。
九、为什么只改密码不够
客户在预警后修改口令、禁用公共邮箱，是必要的止血动作，但仍有三类风险需要处理。
1.终端风险没有随密码修改消失
加载器已经在主机上驻留50余天，并具备远程下载和后续载荷执行能力。只要计划任务、工程文件、运行器副本或防护排除项仍有残留，就可能重新形成执行条件。
因此，账号处置和终端处置必须同时进行。只改密码，不检查主机，无法回答恶意代码是否还会继续窃取新凭据。
2.修改密码不等于注销会话
本次日志包中有3,860条Cookie，部分会话最长有效至2027年10月。如果攻击者拿到的是仍然有效的会话Cookie，就可能绕过再次输入密码的过程。
因此，除重置口令外，还必须强制注销相关账号的全部活动会话，撤销令牌并重新认证。多因素认证也应开启，但不能用开启MFA代替已有会话的失效处理。
3.泄露范围超出五个告警账号
平台最初命中的是三套系统、五个账号，源数据包却同时包含VPN、数据中台、企业网银、个人账号和自动填充信息。处置范围应以整台主机的窃密结果为准，不能只处理预警报告中列出的账号。
写在最后
过去我们处置的多起安全事件中，凭据泄露都是攻击者进入企业网络的常见入口之一。有些事件并不是业务系统先被攻破，而是员工终端先被窃密，攻击者再购买或利用已经流出的口令和会话进入内网，最终造成横向移动、数据泄露甚至勒索加密。
这也是我们在安全运营中保留威胁情报模块的原因。它的价值不只是提前看到一条暗网消息，而是尽早把消息关联到具体资产，再通过主机取证回答泄露时间、恶意组件、持久化方式和影响范围，最后完成清除、加固和持续监测。从我们的工作重心看，这一模块首先服务于勒索防护和入侵预防，而不只是事后的情报汇编。
凭据泄露后的正确处置，不是只把旧密码换成新密码，而是同时处理账号、会话、终端和同源风险。威胁情报与上机溯源结合起来，才能把风险遏制在勒索和业务中断之前。
网络安全不能等事件发生后再追问原因。能在凭据刚出现时发现问题，就有机会少处置一次入侵，少恢复一套业务系统。预防在前，才是这类工作最直接的价值。
发表于 2026-11-10 14:53
分享到朋友圈
