文档概述

本文档记录了云服务器遭遇挖矿病毒入侵后的应急响应与深度清理最佳实践，适用于云服务器运维人员、安全工程师及系统管理员。当您的服务器出现 CPU 负载异常飙升、系统响应缓慢、核心命令被篡改 等疑似挖矿病毒感染的场景时，可参考本文档进行排查与处置。

操作提示

• 备份前置要求：挖矿病毒通常会篡改系统核心命令、动态链接库及定时任务，清理过程可能影响系统稳定性，请务必在操作前完成 系统快照备份 与 重要数据备份。
• 环境适配说明：本文档以 Linux 系统为例，不同发行版的命令路径与工具可能存在差异，请根据实际环境调整。
• 权限要求：所有操作需使用 root 或具备同等权限的账号执行。
• 最小影响原则：建议在测试环境验证方案后，再对生产环境执行操作。

最佳实践

问题现象

用户反馈Linux服务器CPU资源利用率达到100%，严重影响业务正常运行。

问题分析

1. 资源利用率检查

通过BCM（Baidu Cloud Monitor）查看服务器资源利用率，发现CPU使用率达到100%。

2. 登录服务器排查

通过VNC控制台进入服务器操作系统，执行 top 命令发现屏幕不断滚动且未设置任何参数，怀疑top进程存在异常。

3. 系统命令完整性检查

检查top命令发现其被替换为shell脚本文件（正常情况下top应为二进制程序），确认系统命令已被篡改。

病毒使用top.lanigiro命令替代原top命令，并通过grep -v kthreaddl过滤病毒进程，试图隐藏其存在。

4. 暴露病毒进程

直接执行top.lanigiro命令（不使用grep -v过滤），kthreaddl进程就显示出来了。

5. 定位病毒程序路径

尝试终止kthreaddl进程，但发现进程会自动重启。通过以下命令定位病毒程序所在路径：

1ls -lrt /proc/29360/exe  # 替换为实际进程号

5. 病毒程序分析

进入病毒所在路径，发现kthreaddl.sh为病毒的启动脚本，kthreaddl为ELF 64位可执行文件：

1[root@instance-8iwcfx9g ...]# file kthreaddl
2kthreaddl: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), statically linked, stripped

通过.threaddl.log日志文件获取病毒详细信息：

1 * ABOUT        XMRig/6.16.5-C3Pool gcc/9.3.0
2 * LIBS         libuv/1.43.0 OpenSSL/1.1.1m hwloc/2.7.0
3 * HUGE PAGES   supported
4 * 1GB PAGES    disabled
5 * CPU          Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz (1) 64-bit AES VM
6                L2:2.0 MB L3:27.5 MB 2C/4T NUMA:1
7 * MEMORY       7.3/15.7 GB (46%)
8                DIMM 0: 16 GB RAM @ 0 MHz DIMM 0
9 * MOTHERBOARD  Baidu Cloud - Baidu Cloud BCC
10 * DONATE       0%
11 * ASSEMBLY     auto:intel
12 * POOL #1      auto.c3pool.org:19999 algo auto
13 * COMMANDS     hashrate, pause, resume, results, connection

6. 病毒特征验证

计算病毒文件MD5值：

1[root@instance-8iwcfx9g ...]# md5sum kthreaddl
2b7805ca64bcb053c6a44e8a7a675d26c  kthreaddl

通过威胁情报平台（如微步在线或VirusTotal）检索确认该文件为已知挖矿病毒变体。

8. 扩展检查

1） 定时任务与密钥检查

• 检查crontab配置未发现异常
• 发现密钥文件存在异常，疑似黑客植入
• 确认ps、top、chattr等关键系统命令均被篡改

2） 自启动机制检查

发现病毒通过systemd服务实现自启动：

• /etc/systemd/system/kthreaddl.service
• /etc/systemd/system/multi-user.target.wants/kthreaddl.service

3） 日志系统检查

发现系统rsyslog服务被停止，日志文件/var/log/messages和/var/log/secure为空，且/usr/sbin/rsyslogd文件被删除，推测黑客意图掩盖攻击痕迹。

处理方案

1. 清理病毒文件

1# 删除病毒目录及相关文件
2rm -rf /root/...  # 替换为实际病毒目录
3rm -f /usr/bin/ps.lanigiro
4rm -f /usr/bin/top.lanigiro
5rm -f /usr/bin/top
6rm -f /usr/bin/ps
7rm -f /bin/top~
8rm -f /etc/systemd/system/kthreaddl.service
9rm -f /etc/systemd/system/multi-user.target.wants/kthreaddl.service

2. 修复系统文件

• 从系统备份或正常系统中拷贝恢复被篡改的top、ps、chattr命令
• 重新安装并启动rsyslog服务

3. 终止病毒进程

1# 查找并终止所有相关病毒进程
2pkill -f kthreaddl
3pkill -f top.lanigiro

4. 全面系统排查

• 进程分析：检查所有运行进程，识别并清理可疑进程
• 服务检查：执行systemctl list-unit-files --state enabled分析异常服务
• 文件对比：与标准环境对比/bin、/sbin等目录下新增的可疑文件
• 隐藏文件检查：扫描/lib、/etc、/root等目录下的隐藏文件，确认无异常
• 启动项排查：检查crontab、/etc/init.d、/etc/rc.local、/etc/systemd/system等目录下的可疑配置
• 账户检查：验证/etc/passwd和/etc/shadow文件，清理非法账户
• 端口扫描：检查对外开放端口，排查可疑服务

结果验证

1. 系统命令恢复

• top命令正常显示系统资源使用情况

• ps命令可正常查看进程列表，未发现病毒进程重启

2. 日志系统恢复

• rsyslog服务正常运行

• 系统日志文件恢复记录功能

3. 自启动服务验证 执行systemctl list-unit-files --state enabled确认无异常自启动服务。

安全加固建议

1. 基础配置加固

   • 修改 SSH 默认端口（如从 22 改为 2022, Linux修改默认远程端口），并禁用 root 直接登录。
   • 使用安全组限制对外开放的端口，仅放行必要业务端口。
   • 服务器使用高强度密码，并定期更换。
   • 定期做数据备份，可使用自动快照功能。

2. 入侵检测增强

   • 部署主机安全防护工具，实时监控进程异常、文件篡改与登录行为。
   • 开启系统日志审计，配置 /var/log/secure、/var/log/cron 等关键日志的远程备份与告警。
   • 安全漏洞预警。

3. 权限与访问控制

   • 遵循最小权限原则，避免业务进程使用 root 权限运行。
   • 定期清理无用账号与密钥，限制 SSH 登录 IP 范围。

4. 网络安全组优化

   • ICMP协议：按需开放给需要探活的IP地址
   • 敏感端口：3306（MySQL）、6379（Redis）、22（SSH）等端口仅对授权IP开放
   • Web服务：80/443端口可根据业务需求决定是否对外开放
   • 安全组拆分：不同用途服务器使用独立安全组配置

5. 系统监控与审计

   • 启用并监控系统关键日志
   • 配置异常资源使用告警
   • 定期进行系统完整性检查