1. 从一台"看起来很正常"的机器说起

驱动人生挖矿木马这个话题，我前后跟进过好几次，每次处理完都有新的体会。简单说，它就是一起典型的"正规软件分发链路被污染、静默下发挖矿载荷"的安全事件——用户装的是一个天天用的驱动更新工具，机器却在你不知情的时候跑起了挖矿进程，CPU温度飙升、风扇狂转、笔记本续航腰斩，很多人第一反应是"电脑老了""系统卡了"，根本想不到是软件本身带进来的东西。这篇内容我想聊的不是某一条新闻，而是挖矿木马分析与处置这一整套活儿怎么干：怎么在主机上把痕迹翻出来，怎么在流量里把它抓住，怎么清干净并且让它不再回来。

适合谁来读？做过一线应急的同学，可以把它当成一份可复用的排查清单；刚入行的安全运维，可以顺着每一步的命令和思路走一遍，理解"为什么要看这个地方"；哪怕是普通用户，只要看到机器莫名卡顿、风扇狂响，也能从里面挑几招自己先摸一遍底。我不会只给你结论，重点是把每一步背后的判断逻辑讲透：为什么先看进程而不是先删文件，为什么流量证据比主机日志更难伪造，为什么"杀掉进程"往往只是白忙一场。

在展开之前先定个调子。挖矿木马的处置，本质上不是"杀毒"，而是一次小型的事件响应，讲究的是证据留存、影响界定、彻底清除、验证闭环这四件事按顺序走。跳过任何一步，后面大概率要返工。下面我就按我自己实际处置的节奏，一层一层拆开讲。

2. 处置前先想明白：这类木马为什么难缠

2.1 它不是"病毒式传播"，而是"供应链投毒"

很多人对挖矿木马的印象还停留在"点了个exe中了毒"，但驱动人生这一类场景的关键在于：载荷是从用户信任的、主动安装的正规软件的更新通道里下来的。这就意味着几件事同时成立——用户不会警觉、杀软的白名单机制容易被绕过、企业内部的软件分发系统可能成了扩散帮凶。

我习惯把这类链路分成三个环节来看：分发端（谁把恶意模块塞进了更新包）、落地端（载荷在本机怎么落地和守护）、外联端（算力往哪儿送）。分析的时候一定要把这三段分开看，因为它们的证据形态完全不一样。分发端的证据在安装包哈希、更新请求日志、下载时间点里；落地端在文件系统、注册表、计划任务里；外联端在流量、DNS、防火墙告警里。

注意：判断"是不是供应链投毒"的核心证据，是恶意文件与正常安装包之间的时间戳和路径关系。如果恶意模块的落地时间紧贴软件安装/更新时间，且路径就在该软件目录下或其临时目录里，基本可以锁定这条链路。

为什么要先做这个定性？因为它直接决定你的处置范围。如果是普通钓鱼，你清理这一台就完事；如果是供应链投毒，那所有装过这个版本、走过这条更新通道的机器，都是潜在受害者，你得去拉一份资产清单出来做批量核查。这个判断做错，后面就是无限返工。

2.2 挖矿木马的真实目标：稳、隐蔽、长命

普通木马追求的是"控制"和"窃取"，挖矿木马追求的是稳定产出。这个目标差异导致了它一系列很特别的行为特征，理解这些特征，排查时才有方向感。

它希望活得久，所以持久化做得比一般木马更细致；它不希望被用户发现，所以会想办法限制CPU占用（很多挖矿木马会主动设置CPU使用率上限，比如只吃50%～70%的核，避免把机器卡死引起怀疑）；它会做守护，进程被杀了马上拉起来；它会做对抗，检测到任务管理器或调试工具就暂停挖矿。

我第一次遇到的时候就被这个"温柔"骗过：机器只是有点卡，CPU占用也就60%上下，看着像某个后台服务在跑，不像恶意程序那种一口吃满的表现。后来才发现是故意留了余量。所以判断挖矿木马，千万别只盯着"CPU 100%"这个特征，那是比较老派的做法了。

2.3 处置优先级：先隔离还是先取证

这是每次都要吵一遍的问题。我的原则是：先快速取证，再做网络隔离，最后动手清除。顺序乱掉会出问题。

如果一上来就断网，进程可能因为连不上矿池而触发自我保护逻辑，比如自杀式删除载荷、抹掉配置文件，反而把证据毁了；如果一上来就杀进程，内存里的东西没了，持久化点可能还活着，你清不干净。反过来，如果只取证不隔离，算力还在外送，影响面在扩大，某些木马还会横向尝试扩散。

实操上我一般这样走：先用只读方式抓一遍现场（进程列表、网络连接、启动项、近期文件），几分钟就能完成；然后把机器从网络里摘出来（拔网线或防火墙阻断），再做深度分析和清除。几分钟的取证窗口，换来的是后面溯源时的主动权，非常值。

3. 主机侧痕迹排查：Windows上我会按这个顺序翻

3.1 第一步永远是进程与网络连接

最快的突破口是进程和它对应的网络连接。挖矿木马必须联网才能干活，所以"谁在连接什么地址"是最高价值的线索。

我在现场通常会先跑这几条：

tasklist /v /fo csv > proc.csv wmic process get ProcessId,ParentProcessId,Name,ExecutablePath,CommandLine /format:csv > proc_path.csv netstat -ano | findstr ESTABLISHED

第一条给进程名和会话信息，第二条给进程的可执行路径和完整命令行（这条最关键，很多木马会把真实路径藏在命令行里），第三条把连接和PID对应起来。

看的时候重点抓三类东西：

• 路径异常：真正的系统进程，路径一定在C:\Windows\System32这类地方。如果看到svchost.exe跑在C:\Users\Public或软件安装目录下，基本可以判死。
• 命令行异常：挖矿木马的启动参数里经常带矿池地址、钱包地址、--cpu这类参数，虽然现在很多会做混淆，但特征还是能看出来。
• 父进程异常：如果某个挖矿进程的父进程是驱动更新类软件的进程或它的更新服务，那链路就清楚了。

提示：任务管理器里"详细信息"标签页的"命令行"列默认是不显示的，右键列头把它勾上，排查时能省很多事。但注意，遇到有对抗能力的样本，任务管理器可能被监控，优先用命令行方式取证。

3.2 计划任务、服务、注册表启动项，老三样依然有效

持久化是挖矿木马的重头戏，Windows上最常见的几个位置我列一下，实际排查时按这个顺序过一遍基本不会漏：

计划任务这块我踩过坑：有样本会把任务名起成Microsoft\Windows\UpdateOrchestrator\...这种看着完全正常的名字，藏在系统目录下，肉眼扫一遍很容易放过。排查时要看"动作"而不是看"名字"，动作里如果指向了Users目录下的可执行文件或者一段脚本，那就要打问号。

服务的话，重点看三个属性：服务名、显示名、二进制路径。挖矿类服务经常出现"显示名是中文描述、路径却在临时目录"这种明显错配。还有一种更隐蔽的，是通过修改已有合法服务的路径实现持久化，这种情况下你得对比服务的原始配置。

3.3 冷门但高频：WMI订阅与COM劫持

如果你把前面几个位置都翻干净了，机器重启后还是复发，那就要往更冷门的方向找了。WMI事件订阅是挖矿木马很喜欢的一类持久化，因为它几乎不落地文件，普通杀软容易漏。

排查命令：

Get-WmiObject -Namespace root\subscription -Class __EventFilter Get-WmiObject -Namespace root\subscription -Class __EventConsumer Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding

正常的Windows系统里，这三者一般是空的或者数量极少。如果看到里面绑定了CommandLineEventConsumer并且命令行指向一段脚本或远程地址，那就是它了。

另一个方向是COM劫持和AppInit_DLLs这类老手法。老归老，但在挖矿场景里依然有人用，尤其是配合DLL侧加载。这些都是"看着不起眼、清起来很烦"的位置，建议做成固定清单，每次排查都过一遍，不要靠记忆。

3.4 文件系统与时间线：用时间戳串起整条链

主机取证的灵魂是时间线。单个文件看不出问题，但把落地时间、创建时间、修改时间排一起，故事就出来了。

我的做法是先圈定一个时间窗口——通常是软件安装或更新的那个时间点前后24小时——然后按修改时间排序找：

dir /a /s /tc /o:d C:\Users\ > file_timeline.txt dir /a /s /tw /o:d C:\ProgramData\ > pd_timeline.txt

重点关注这几个目录：%TEMP%、%APPDATA%、%ProgramData%、C:\Users\Public、C:\Windows\Temp。挖矿木马因为要自启动又不能申请系统权限，往往就落在这些"谁都能写"的地方。

文件本身也有特征。挖矿载荷经常是体积偏大的可执行文件（里面打包了挖矿核心），或者是几个文件配合：一个加载器、一个配置、一个挖矿本体。配置里通常有矿池地址、钱包地址、worker名。看到这类文本内容，直接就是铁证。

注意：取证阶段尽量用只读方式，不要直接打开样本文件，更不要双击运行。如果必须分析样本，放到隔离环境里做，别在生产机上"顺手看看"。

3.5 日志侧的证据：安全日志、PowerShell日志、任务计划日志

前面几块是"现场"，日志是"回放"。两者结合，才能既知道现在有什么，也知道发生过什么。

几个我必看的地方：

• 安全日志：关注进程创建（4688）和登录事件，看有没有异常账号或异常父进程。
• PowerShell操作日志：Microsoft-Windows-PowerShell/Operational，挖矿木马爱用PowerShell做下载和执行，脚本内容会留在这里。
• 任务计划日志：任务注册和启动事件，能帮你定位持久化是什么时候建立的。
• 系统日志：服务安装事件。

日志取证有个现实问题：很多机器上PowerShell日志默认没开，或者日志被覆盖了。所以如果条件允许，在处置前先把日志导出备份，尤其是安全日志和PowerShell日志，导出成evtx文件留存。这一步花不了几分钟，后面要写报告或者做复盘时是救命的。

4. 网络侧：怎么在流量里把它认出来

4.1 Stratum协议：挖矿通信的"口音"

主机排查解决"这台机器干净不干净"，流量分析解决"它到底把算力送去了哪儿、还有哪些机器在送"。挖矿木马和矿池之间最常用的是Stratum协议，这是专门为矿池设计的通信协议，JSON格式、明文或半明文，特征非常明显。

如果你能抓到包，Stratum的关键特征包括：

• 客户端发mining.subscribe、mining.authorize这类方法名；
• 服务端返回mining.notify、挖矿难度设置；
• 报文里通常能看到钱包地址、worker名。

用Wireshark或tcpdump抓一段流量，直接搜mining.或者stratum关键字，命中率很高：

tcpdump -i eth0 -A -s 0 'tcp port 3333 or tcp port 5555 or tcp port 14444' -w mining.pcap

很少数的样本会用TLS把Stratum包一层，那就看不到方法名了，这时候只能靠连接行为特征：目的端口常见3333/4444/5555/7777/14444这类非标准端口、连接持续且心跳规律、单台机器长期保持少量长连接。

4.2 DNS和TLS指纹：看不见内容时的替代方案

很多企业环境里HTTPS流量没法解密，这时候DNS就是最好的朋友。矿池域名虽然会做域名生成、频繁切换，但总有一些规律：请求时间有周期性、同一域名被多台内网主机同时解析、域名本身是随机字符串或明显与品牌无关。

我通常会在DNS日志或者镜像流量里做两件事：一是按解析频次排序，看有没有某个陌生域名被几十台机器反复请求；二是按时间聚合，看有没有整点在批量请求的情况（很多木马有心跳或重连的固定节奏）。

TLS层面可以看JA3指纹。同一批挖矿样本的TLS指纹往往是一致的，因为用的是同一套库和同样的配置。当你从某台机器上提取出可疑样本后，算出它的JA3，再拿这个值去全网流量里搜，能快速找到同源感染的机器。这个思路在批量处置时特别有用。

4.3 热点预警与告警联动

企业里一般有防火墙、终端防护、威胁情报几套系统，处置这类事件时要把它们串起来用。威胁情报的价值不在于"检测到了"，而在于"告诉你还有谁在同一条链路上"：样本哈希、恶意域名、C2地址这些IOC下发到防火墙和终端，可以快速做全网普查。

实际联动时我建议先做两件事：一是把本次事件提取出IOC（矿池域名、样本哈希、持久化文件路径），二是把IOC同时下发到流量侧和主机侧做历史回溯。历史回溯经常能挖出"三个月前就已经中招"的机器——那些才是真正的大头，因为新告警往往只覆盖最近一段时间。

提示：防火墙告警从"某IP访问了可疑矿池地址"这种单点告警，升级到"某主机多次访问同一批矿池地址集群"的聚合视角，误报率会明显下降。单次访问可能只是浏览器误触或CDN误判，成簇的访问才是真感染。

4.4 反查入口：从矿池回推到更新服务器

溯源的目标是找到"第一跳"：恶意载荷到底是从哪里下来的。这一步的抓手是主机上的下载记录和网络日志的对应关系。

我会按这个顺序推：先从挖矿进程的父进程和命令行确认它的启动来源，再从加载器的配置文件或脚本里找下载地址，然后拿这个地址去比对主机侧和网络侧在相同时间点的请求记录。如果请求地址正好是某个软件更新域名，且时间点与软件更新事件吻合，链路就闭环了。

这一步的价值不只是"搞清楚怎么进来的"，更在于确定影响范围。如果入口是某个更新服务节点，那所有从该节点更新的客户端都要核查；如果入口是一次钓鱼点击，那范围就小很多。溯源结论直接决定处置规模，这比单纯写个报告重要得多。

5. 清除与加固：清干净，还要不复发

5.1 隔离先行，取证留档

在动手删除任何东西之前，把该留的证据留全。我一般会做这几样：

1. 导出进程列表、网络连接、计划任务、服务列表、启动项的完整快照；
2. 复制可疑文件到隔离目录，计算哈希；
3. 导出关键日志；
4. 截取可疑进程的内存（如果工具支持）。

这几步做完，再开始清除。很多人图快，先删了再说，结果复盘时发现什么痕迹都没有，报告写不出来，也没法验证是不是真清干净了。

5.2 按"自下而上"的顺序清除

清除的顺序很重要，我的经验是先断持久化，再断外联，最后删文件。顺序反过来，会遇到"删了又回来"的情况。

具体步骤：

1. 阻断外联：防火墙或hosts层面切断矿池地址，让挖矿进程失去目标；这一步同时能防扩散。
2. 清除持久化：逐个删除计划任务、服务、注册表启动项、WMI订阅。注意每删一个都要确认删掉，某些样本会互相守护，删一个另一个给你加回来。
3. 终止进程树：从最顶层的父进程往下杀，不要只杀挖矿本体。杀掉加载器和守护进程，防止它重新拉起挖矿。
4. 删除文件：清理临时目录、软件目录下的恶意模块。注意有些文件被占用时删不掉，需要先停掉占用它的进程。
5. 重启复验：重启后再过一遍前面所有排查点，确认没有残留。

注意：如果发现多个进程互相守护，直接杀可能会陷入拉锯。更稳妥的做法是先停掉持久化点（让它重启后起不来），再一次性结束整棵树，然后立即删除文件，别给它反应时间。

5.3 加固：把这条链路的每个环节都补上

清除只是把这一台救回来，加固才是防止再来一次。针对这条链路，我会从三个层面加固：

软件分发层面：企业内部如果有统一的软件分发和更新机制，要校验安装包的完整性和签名，禁止客户端直接从外部更新通道拉包。这一步能从根本上堵住供应链投毒。

主机层面：限制普通用户对临时目录、用户目录的可执行权限，开启PowerShell脚本块日志和命令行审计，把前面提到的持久化位置纳入常态化巡检。

网络层面：把非标准高端口的出站连接纳入监控，尤其是向陌生IP的长时间心跳连接。配合威胁情报做域名和IP的持续比对。

这三层里，主机层面的审计收益最大，因为很多中小环境没有完整的流量可见性，但主机日志是现成的，把日志开起来、集中收起来，就能覆盖大部分场景。

5.4 处置库与知识沉淀

每次处置完，我都会把这次的IOC、排查命令、特殊手法整理成一个可复用的"处置包"：样本哈希、矿池地址、持久化路径特征、对应的清除命令。这样下次遇到同类样本，直接导入比对，几分钟就能定位，不用从头再来。

这个习惯我觉得比什么都值钱。安全事件处置最怕的就是每次都从零开始。你手上积累的处置库越厚，响应速度就越快，判断也越准。可以按样本家族或者按事件类型来组织，配合简单的检索工具，就够用了。

6. 常见问题与排查速查表

6.1 高频问题一览

6.2 几个我踩过的坑

第一个坑：只杀进程不查父进程。有一次我杀了挖矿本体，机器安静了半天，第二天又回来了。后来才发现父进程是一个常驻的软件更新服务，它会定期检测并重新拉起挖矿模块。从那以后我养成习惯，杀任何东西之前先把进程树理清楚。

第二个坑：忽视时间线。刚开始我只看"现在有什么"，不关注"什么时候来的"。结果报告写不清影响范围，也不知道是不是还有更早中招的机器。现在我做任何事件都会先画一条时间线，把安装、落地、外联、告警这些节点排上去，一眼就能看出关联。

第三个坑：信任白名单。有些样本把恶意模块伪装成正规软件的一部分，靠签名或白名单机制绕过检测。所以我会额外看"这个文件是不是真的该出现在这个位置""它的签名是不是真的有效"，而不是简单地"看到签名就放行"。

第四个坑：取证时动了现场。早期图省事，直接在生产机上双击看样本内容，结果样本的自我保护直接把配置删了，证据没了。这个教训让我记住：分析样本永远在隔离环境里做，现场只做只读取证。

6.3 一点个人体会

网络安全事件处置这件事，工具和脚本只是辅助，真正决定成败的是思路的顺序。先定性再定量，先取证再隔离，先断持久化再删文件，先验证再收工。每一步都问自己一句"我这么做，会不会把后面的路堵死"，很多返工都能避免。

还有一点，别迷信某个"一键清除工具"。挖矿木马的变种太多，持久化手法一直在变，工具能覆盖的永远是常见那几种。真正靠谱的是你自己脑子里那份排查清单——从进程到网络、从持久化到日志、从主机到流量，按顺序走一遍。这份清单是你自己的，谁也拿不走。

至于这类事件的处置库和IOC共享，我的建议是能沉淀就沉淀，哪怕只是记在一个表格里。下次再遇到类似的供应链投毒，你能省下的不是几分钟，而是一整轮的摸索时间。