挖矿病毒实战排查与清除：从CPU异常到系统加固的完整指南

从事网络安全工作这些年，处理最多的其实不是那些高深莫测的0day漏洞，反而是挖矿木马这种"脏活累活"。几乎每个月都能遇到几台被入侵后沦为挖矿肉鸡的服务器，有的是内部同事的测试机，有的是客户生产环境里的数据库节点。挖矿病毒这东西有个特点：它不加密你的数据、不勒索你交钱，它就是偷偷占着你的CPU和带宽给你挖币，属于典型的"慢性吸血"。很多团队一开始根本发现不了，直到服务器卡得连远程桌面都点不动，或者云厂商发来"涉嫌挖矿行为"的告警，才意识到问题严重。

这篇文章我用自己的实战排查记录，把"发现和清除挖矿病毒"整个流程完整拆解一遍。包含症状识别、进程定位、持久化清除、文件清理、漏洞修复这几个关键环节，全程都是我在一台模拟被入侵的Linux服务器上的操作实录。无论你是刚入门的安全运维，还是被挖矿问题折磨得焦头烂额的业务负责人，这套方法论都能直接拿去用。

1. 挖矿病毒的特征与前期判断

1.1 挖矿病毒区别于其他木马的明显特征

挖矿木马和普通WebShell、勒索病毒、后门程序最大的不同，在于它的行为模式特别单一。普通木马想尽办法隐藏自己，挖矿木马却必须持续消耗CPU资源才能产生收益，这就注定了它会留下明显的"行为指纹"。我总结过几个典型特征，供大家参考：

• CPU使用率长期居高不下。正常情况下，一台业务服务器的CPU使用率可能有个波动，但很少会连续几小时甚至几天稳定在某个高位。挖矿程序通常多线程跑哈希运算，表现就是CPU的多个核心全部满载。

• 网络连接异常频繁。挖矿程序需要和矿池保持心跳连接，还要提交算力结果。从网络层面看，就是服务器持续向某些陌生IP发起TCP连接，而且这些连接基本是长连接，不断开。

• 系统变卡、IO开销异常。这个很多人容易忽略，挖矿病毒虽然主要压榨CPU，但它落地时往往要释放多个辅助文件、还可能修改系统配置，会带来额外的磁盘读写和网络IO开销。

• 出现陌生进程和计划任务。这是挖矿病毒最典型的行为，几乎所有的挖矿木马都会写入crontab实现开机自启或定时拉起，进程名往往伪装成系统服务名。

1.2 从发现异常到确认被入侵的时间线

我记得很清楚，当时是在某台开发测试服务器上发现的异常。这台机器配置不高，4核8G，跑着几个内部的Java服务。最先收到的是某运维同事的反馈，说这台机器SSH登录特别慢，敲个命令要等好几秒才响应，用top看负载已经到了5以上。这个负载值对于4核机器来说已经是明显过载了。

最开始我们以为是Java服务出现了内存泄漏，顺手重启了一下Tomcat，结果问题完全没解决，负载反而更高了。这时候才觉得不对劲，查了一下网络连接，发现有个进程在大量连接外网IP的4444端口，而且这个进程名伪装成了"systemd-login"，看起来很像是系统组件，但PID对应的时间点又很可疑，正好在几天前的凌晨。

从发现卡顿到确认挖矿，前后大约用了半小时。判断过程并不复杂，核心就是两件事——看进程、看网络。没经验的时候容易瞎转，有经验以后就能快速聚焦到这几个关键点。

1.3 什么时候可以基本确定是挖矿病毒

这里分享一个我自己总结的判断流程，不需要专业工具，只要SSH能登进去就能做初步判断：

第一步，执行top查看CPU占用，重点关注那个CPU占比异常高的进程ID。

第二步，用ls -l /proc/[PID]/exe查看该进程可执行文件的真实路径，如果发现路径在/tmp、/var/tmp、/dev/shm这类临时目录下，基本可以判定是恶意程序。

第三步，用cat /proc/[PID]/cmdline查看进程启动参数，如果出现矿池地址、钱包地址、代理脚本等内容，立刻就能确认身份。

这里我插一句，判断挖矿病毒不需要抓到矿池地址才算实锤，一个进程的可执行文件放在/tmp下、CPU占用超过300%、并且持续对外网络连接，这三条同时满足，就有九成把握可以按挖矿病毒来处理了。

2. 环境准备与排查工具清单

2.1 排查前需要准备的工具和命令

处理挖矿病毒之前，建议先准备一把趁手的工具。我习惯用一个U盘装着busybox和常用静态编译工具的备份，但很多情况下现场没有这么完备的条件，所以掌握系统自带的命令更实际。Linux自带的工具基本够用，重点掌握以下几类：

老实说，我遇到过很多次现场环境连lsof都没有的情况，所以ss和ps这两个命令一定要熟悉，它们是排查的柱石。ss -anpt可以直接看到进程的PID和网络连接，ps -ef可以看到完整的进程启动参数，这两个组合基本能覆盖90%的排查场景。

2.2 提前做好快照和备份

这里必须强调一个很多人容易忽略的步骤：动手清除之前，先做快照和关键文件备份。

我第一次处理挖矿病毒时比较冲动，确认是恶意程序后直接kill -9把PID杀了，结果不到一分钟进程又自动拉起来了。后来排查发现，它注册了一个systemd服务，进程被kill之后自动重启。而且因为当时没留快照，想回溯分析这个病毒落地时的行为都没有依据，后面做得非常被动。

所以现在的流程固定是：先对虚拟机做快照（云主机就做磁盘快照），然后记录下当前可疑进程的PID、进程名、可执行文件路径、启动参数、网络连接信息，全部记录到一个临时文件里。这个操作不是为了走形式，而是为了后续如果清除不彻底或者需要溯源分析，有完整的现场数据可以回溯。

我当时记录的信息大致是这样的格式，供大家参考：

# 时间点记录 date # 可疑进程 ps -ef | grep -E 'systemd-login|kworker' # PID对应的绝对路径 ls -l /proc/[PID]/exe # 网络连接 ss -anpt | grep [可疑IP]

这些信息保存好以后，再进入正式的排查流程。

3. 定位挖矿进程：从CPU异常到揪出真凶

3.1 用top快速定位高CPU进程

登录服务器后第一件事，运行top，按大写P键让进程按CPU使用率排序，直接从最上面看哪个进程在"吃"CPU。我当时的输出大概长这样：

top - 14:23:11 up 22 days, 3:42, 2 users, load average: 5.61, 4.90, 3.87 Tasks: 289 total, 3 running, 286 sleeping, 0 stopped, 0 zombie %Cpu(s): 95.3 us, 2.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 2.6 st PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6864 root 20 0 361412 5852 1040 R 322.7 0.1 584:32.44 systemd-login

注意看那个systemd-login，一个正常的系统登录管理服务，CPU占用正常应该在0%到1%之间，这里直接飙到322%，相当于占了三个多核的算力，这绝对不正常。还有一个细节，这个进程的启动时间是584分钟，换算一下就是它已经运行了将近10个小时。

这个进程名伪装得非常到位，systemd-login是Linux系统本来就有的服务名，不了解的人很容易被骗过去。如果只看进程列表，很难发现问题。但是结合CPU占用、运行时长和PID，就能看出破绽——真正的systemd-login进程PID通常比较小，是在系统启动早期从systemd主进程派生的，而这里PID是6864，说明是这个时间点之后才启动的。

3.2 用ps查看进程详情并定位可执行文件

定位到可疑PID后，马上执行以下两条命令，把进程的可执行文件和启动参数挖出来：

ls -l /proc/6864/exe cat /proc/6864/cmdline | tr '\0' ' '

第一条命令的结果是：

lrwxrwxrwx 1 root root 0 Jul 20 14:21 /proc/6864/exe -> /tmp/kworker

看到/tmp/kworker这个路径，基本就实锤了。/tmp目录是用来放临时文件的，系统服务和核心程序绝对不会从这里执行，恶意程序之所以喜欢放这里，是因为它通常没有写其他目录的权限，而且临时目录清理相对不频繁，不容易被发现。至于kworker这个名字，也是伪装成内核工作线程的名字，但真正的kworker进程是内核线程，在/proc下的exe链接指向的不是普通文件，这俩完全是两码事。

第二条命令看启动参数：

/init -t 8 -w 1024 -p 0x746d... (这里是矿池地址和钱包相关参数)

到这里已经完全确定了：这就是一个挖矿程序，伪装成系统进程名，可执行文件放在临时目录下，持续连接矿池挖币。

3.3 不急着kill，先看它有没有守护进程

这里就是我前面说的"踩过坑"之后才养成的习惯：先检查有没有守护进程，再决定杀不杀。

很多挖矿木马为了保活，会内置两层机制。第一层是进程自我守护，也就是运行中的主进程派生出多个子进程，杀掉主进程后子进程会自动拉一个新的。第二层是外部守护，也就是写一个crontab计划任务，每隔几分钟检查一次进程是否存在，不存在就重新下载执行。

检查守护进程的方式很简单：

# 查看当前用户的计划任务 crontab -l # 查看系统级的计划任务 cat /etc/crontab ls /etc/cron.d/ # 查看所有用户的计划任务 for user in $(cut -f1 -d: /etc/passwd); do echo "### $user"; crontab -l -u $user 2>/dev/null; done

我当时执行crontab -l的输出是：

*/5 * * * * /usr/lib/systemd/systemd-update-daily >/dev/null 2>&1 */6 * * * * rm -rf /tmp/.X11-unix/...; cd /tmp/.X11-unix && ./... >/dev/null 2>&1

第二个计划任务很可疑，正常的系统更新检查不会放在/tmp/.X11-unix这种目录。这个任务的意思是每6分钟执行一次特定目录下的脚本，脚本大概率就是负责重新下载和拉起挖矿程序的。看到这个之后，我的处理顺序就变了：先清理计划任务，再杀进程，否则杀了也白杀。

4. 清除挖矿病毒：按顺序操作的完整流程

4.1 先断网，再清理

清除挖矿病毒有一个建议的先后顺序，很多人一上来就杀进程，这是不对的。我推荐的顺序是：

1. 隔离网络：如果是云主机，先在安全组里把所有入方向规则临时改为拒绝（或者直接关掉公网IP）；如果是本机，可以临时停掉网卡或者用防火墙规则屏蔽挖矿程序的连接目标。
2. 清理计划任务：把所有可疑的crontab条目删掉，同时检查systemd服务。
3. 停止进程：用kill命令结束主进程和所有子进程。
4. 删除文件：找到可执行文件、辅助脚本、配置数据，全部删掉。
5. 修复漏洞：排查病毒是通过什么方式进来的，把入口堵上。

之所以先断网，是为了防止你一边清理一边又被远程指挥重新下载。挖矿木马很多是从外部C2服务器接收指令的，主进程被杀了以后，如果网络还通着，C2能立刻下发指令让新进程重新拉起来。先断网相当于切断了对方的指挥链路。

我当时在云主机上直接通过控制台把出口方向规则改成拒绝所有，然后才在服务器上操作，这样保证排查过程中不会产生新的对外连接。

4.2 删除crontab计划任务

删除计划任务前，先把当前的所有crontab内容备份下来，万一误删了正常任务还可以恢复：

crontab -l > /tmp/crontab_backup.txt

然后编辑计划任务，把包含可疑路径和脚本的内容删掉：

crontab -e

编辑时注意看清楚，只删可疑行，不要把正常任务误删。比如下面这种任务就非常典型，需要重点排查：

*/6 * * * * cd /tmp/.X11-unix && ./run >/dev/null 2>&1

删完全局计划任务还不够，系统级的/etc/crontab和/etc/cron.d/目录也要检查一遍。我当时在/etc/cron.d/下还发现了一个名为sysupdate的文件，内容也是一段下载执行脚本的逻辑，同样需要删除。另外还需要检查一下是否有关键目录被写入可疑内容：

ls -la /etc/cron.d/ ls -la /var/spool/cron/

4.3 杀进程和删文件

清理完计划任务之后，再回到进程处理。先找到这个挖矿程序的所有相关进程：

ps -ef | grep kworker ps -ef | grep systemd-login

把属于恶意程序的PID记下来，然后逐个结束：

kill -9 6864

这里建议用kill -9直接强杀，因为普通的kill（默认发SIGTERM）可能会被程序内部的信号处理机制拦截，导致进程拒绝退出。kill -9发送SIGKILL信号，内核直接回收进程，恶意程序没有机会做任何清理或重生操作。

杀完进程后，删除所有相关的恶意文件。我当时找到的文件包括：

• /tmp/kworker— 主挖矿程序
• /tmp/.X11-unix/— 辅助脚本目录，里面有几个脚本文件
• /usr/lib/systemd/systemd-update-daily— 伪装文件，配合计划任务使用
• /etc/cron.d/sysupdate— 恶意计划任务文件

这里要特别提醒，删除前务必备份。我当时的做法是，先打包到一个目录再删除：

mkdir /tmp/malware_backup cp -r /tmp/kworker /tmp/.X11-unix /tmp/malware_backup/ cp /usr/lib/systemd/systemd-update-daily /tmp/malware_backup/ cp /etc/cron.d/sysupdate /tmp/malware_backup/

备份完之后再删除原始文件，以防后续要分析病毒行为或者做取证。如果环境允许，也可以将这些样本提交给专业的分析平台，进一步确认挖矿病毒的具体家族和矿池地址，这对漏洞修复和溯源很有帮助。

4.4 检查Systemd服务和自启动项

挖矿木马除了写crontab，还有一种常见自启动方式是注册systemd服务。我在排查这台服务器时，就发现了一个可疑的systemd服务文件：

cat /etc/systemd/system/systemd-networkd-policy.service

文件内容大致是：

[Unit] Description=System Network Policy [Service] ExecStart=/usr/lib/systemd/systemd-update-daily Restart=always [Install] WantedBy=multi-user.target

这个服务伪装成网络策略服务，但ExecStart指向的却是一个位于/usr/lib/systemd/下的脚本，而不是真正的systemd组件。Restart=always很关键，这意味着服务一旦被kill，systemd会立刻重新拉起它，这就是我第一次只杀进程结果又复活的根本原因。

发现这个服务后，执行以下命令彻底禁用并卸载：

systemctl stop systemd-networkd-policy systemctl disable systemd-networkd-policy rm -f /etc/systemd/system/systemd-networkd-policy.service systemctl daemon-reload

这里解释一下每一步的作用：stop是立即停止服务，disable是移除开机自启动的符号链接，rm是删除服务定义文件，daemon-reload是让systemd重新加载配置、清除已经删除的服务缓存。四个步骤缺一不可，少了任何一步都可能留下隐患。

除了systemd服务，还要检查传统的启动项目录，老系统或者某些发行版还兼容SysVinit的方式：

ls -la /etc/init.d/ ls -la /etc/rc.d/ ls -la /etc/rc.local

如果发现异常的可执行脚本，同样需要查看内容、确认恶意后删除。

4.5 全盘搜索残留文件的技巧

清除了明显的进程、计划任务、服务文件之后，还需要做一次全盘扫描，挖矿木马一般会释放多个文件，不可能只留下一个主程序。我当时用了下面几个命令搜索残留：

# 查找24小时内修改过的可执行文件 find / -name "kworker*" -o -name "systemd-login*" 2>/dev/null # 查找临时目录下的可疑可执行文件 find /tmp /var/tmp /dev/shm -type f -perm /111 2>/dev/null # 查找近期被修改的二进制文件（排除正常的应用目录） find / -mtime -3 -type f -perm /111 2>/dev/null | grep -v -E '^/(proc|sys|usr/share|var/lib)'

/dev/shm这个目录特别值得关注，很多挖矿木马喜欢把文件放这里，因为它是一个基于内存的文件系统，不占磁盘空间，重启后自动清空，能有效规避基于磁盘的杀毒扫描。我当时在/dev/shm下也发现了一个隐藏文件.x，内容是挖矿程序的辅助脚本。

全盘搜索时建议用find的同时限制路径范围，避免去扫/proc、/sys这些虚拟文件系统，否则会产生大量无意义输出，也会拖慢整个排查速度。

5. 彻底清理后的系统加固与修复

5.1 排查入侵路径：堵住漏洞才能不再复发

病毒清完了，如果不修复漏洞，过几天还会再中标。这台服务器后来分析入侵路径时发现，问题出在一个对外开放的Nacos服务上。

挖矿木马最常见的几种入侵路径我整理了一下，基本就是这些：

• 弱口令爆破：SSH、MySQL、Redis、Nacos等服务的弱密码是最常见入口
• 未授权访问：Redis、Docker API、Kubernetes等组件默认开放且无认证
• Web漏洞利用：如Struts2、Log4j2、反序列化漏洞等
• 供应链投毒：基于开源组件或镜像仓库投毒的恶意程序

这里根据该服务器的实际情况，重点检查的是对外开放的应用服务和组件端口：

ss -anpt | grep LISTEN

发现有大量端口暴露在外网，包括一些内部管理组件没有加访问控制。后续修复措施包括：

• Nacos控制台开启认证，修改默认密码
• Redis关闭公网访问，改用内网并启用密码
• SSH修改默认端口，限制来源IP
• 数据库、管理平台只允许内网和堡垒机访问

5.2 修改密码和密钥

确认系统被入侵后，措施的优先级里有一项是及时更新密码和密钥。因为攻击者可能已经拿到了管理员权限，掌握了系统口令和SSH密钥，如果不更换，他随时可以再次登录服务器种植新的木马。

我当时做的操作是：

# 修改root密码 passwd root # 修改其他高权限用户密码 passwd admin # 检查SSH授权密钥，删除可疑内容 cat /root/.ssh/authorized_keys

检查SSH密钥时，特别注意里面是否混入了攻击者的公钥。有的攻击者会在拿下权限后把自己生成的公钥写入authorized_keys，实现长期的免密登录。authorized_keys里每一行对应一个公钥，逐行检查，任何一条不是你自己生成的公钥都要删掉。

5.3 配置安全基线，降低再次中招的概率

系统清理干净后，我当时顺手做了几件加固的事，这里也分享给读者：

第一，设置云安全组的白名单策略。原来是放开了所有入方向端口，现在只放行业务必须的端口（如80、443），其余全部关闭。

第二，启用fail2ban或者类似防爆破工具，对SSH的连续失败登录进行封禁。配置可以参考：

yum install fail2ban systemctl enable fail2ban systemctl start fail2ban

第三，定期备份系统配置和关键数据，同时开启云平台自带的安全告警，将"异常登录""出现挖矿行为"作为重点监控事件。

这些操作做完以后，长期观察下来，服务器没有再出现CPU异常升高或矿池连接等行为，标志着这次清除工作真正收尾。不过说实话，"清除干净"和"不再中招"是两码事，后者更考验整个安全防护体系的持续运营能力，不能指望一次清理就一劳永逸。

6. 实战经验总结与常见问题速查

6.1 挖矿病毒排查思路五步法

处理多了以后，我把整个排查流程浓缩成了五步法，现在遇到疑似挖矿的事件基本都是按这个节奏走：

第一步，看负载。执行uptime查看load average，如果明显高于CPU核心数，需要进入下一步。

第二步，看进程。执行top按CPU排序，找到占用异常的进程，再用ls -l /proc/[PID]/exe确认它的可执行文件路径。

第三步，看网络。执行ss -anpt查看异常连接，重点关注连接外部陌生IP、非常用端口的长连接。

第四步，看计划。执行crontab -l和检查/etc/cron.*目录，确认是否有可疑的计划任务。

第五步，看服务。执行systemctl list-unit-files | grep enabled，找新增的、伪装成系统服务的可疑项目。

这套流程不需要任何商业化工具，纯靠系统命令就能完成，适合各种基础环境。熟练以后整个排查过程基本上可以在十分钟之内完成。

6.2 处理过程中的几个关键坑，我都替你踩过了

这里整理几个处理挖矿病毒时容易踩的坑，每一个都是经验之谈：

第一个坑，上来就kill进程。很多新手看到可疑进程直接kill -9，结果发现没过多久进程又出现了，反复杀反复活，心态崩溃。正确做法是像前面说的，先清理计划任务和服务，再杀主进程。

第二个坑，只删文件不删自启动项。如果你把进程杀了、文件删了，但忘了检查crontab和systemd，那么只要机器重启或者等到计划任务触发的时间点，病毒又会从备份文件或其他路径重新拉起来。

第三个坑，不备份就删。直接删除可疑文件确实很爽，但后续做溯源分析、确认病毒家族、评估影响范围时没有素材可用，相当于把线索抹掉了。我建议所有可疑文件都先复制一份再删，哪怕放到一个加密压缩包里都行。

第四个坑，清理完不修漏洞。挖矿病毒通常是用户密码泄露、未授权访问或者Web漏洞导致的，如果入口不堵上，攻击者可以随时再进来。清理完病毒只是治标，修复漏洞才是治本。

第五个坑，忽略了容器场景。如果你的服务跑在Docker里，挖矿木马有可能只装在容器内部，宿主机的排查就不够全面。这种情况下需要进入容器内排查，同时检查Docker的守护进程配置和镜像的完整性。

6.3 常见问题速查表

6.4 日志分析与后续观察

清理完病毒后，我习惯再花时间看看系统日志，了解攻击者什么时候进来、做了什么、有没有留下其他后门。重点看下面几个日志文件：

# 登录日志 tail -200 /var/log/secure # 历史命令 tail -100 /root/.bash_history # 系统日志中与恶意进程相关的记录 journalctl --since "2024-07-20 00:00:00" | grep -i "systemd-login\|kworker"

我在查看历史命令时发现，攻击者曾经在系统里执行过useradd、wget、curl等命令，大概率是通过漏洞拿到初始权限后下载挖矿程序，同时可能留了一个隐藏账号作为后门。所以排查时一定要检查/etc/passwd和/etc/shadow里是否有新增的账号：

cat /etc/passwd | grep -E "/(bin/bash|bin/sh)" | grep -v "nologin\|false"

有异常账号要立即删除，然后再次确认系统的密码策略是否足够强壮。

后续观察也很重要。清理完病毒并不代表安全，需要连续观察一周左右，每天固定时间看一下CPU和网络连接情况。如果再次出现异常，就要考虑是否还有隐藏的后门没有清除干净。我把这个周期性检查写成了简单脚本，放在crontab里定时执行：

*/10 * * * * echo "$(date) $(ps -eo pid,comm,%cpu --sort=-%cpu | head -6)" >> /var/log/cpu_check.log

这个脚本每10分钟把CPU占用前五的进程记录到日志，如果有异常会留下痕迹，方便追溯。

7. 个人经验：挖矿病毒清除的总体观感

处理挖矿病毒这件事，很多人把它当成一个单纯的"杀毒"工作，我觉得不太准确。它更像是一次系统性的安全运维检查——病毒只是结果，根因往往是系统暴露面太大、口令太弱、补丁更新不及时。你杀掉了病毒，修复了入口，优化了基线，整台服务器的安全水平反而是提升的。

我在实际排查中还有个体会：不要因为挖矿病毒"低级"就轻视它。它确实不需要太高深的技术，但传播效率高、变种速度极快，很多攻击者专门利用自动化工具批量扫描弱口令和未授权服务，一台机器从被扫描到植入木马可能只需要几分钟。正因为门槛低，所以它的覆盖面特别广，可以说挖矿病毒是很多安全团队接到的第一类安全事件，也是培养新人排查能力最好的训练场。

如果你只记得住一句话，那就记住这句话：挖矿病毒藏不住CPU。无论它把进程名伪装得多像系统组件，无论它把文件藏在多深的目录，它始终要消耗CPU资源来挖矿，只要你在CPU监控上花心思，就一定能抓住它。

最后再分享一个小技巧。如果你怀疑服务器中了挖矿病毒但还没确认，先把安全组或防火墙的出方向规则里把常见矿池端口（如4444、14444、5555等）全部封掉，很多挖矿程序在连不上矿池时会自动退出，这样可以争取到从容的排查时间。我自己遇到高负载告警时，第一反应不是杀进程，而是先在防火墙上把可疑端口堵死，让CPU降下来，然后再从容地定位问题。这套"先堵后查"的思路，在处理多台机器同时中招的情况下格外好用。