我的服务器被挖矿程序攻击了（顺便攻击了别人）

我最近遇到了一次服务器被挖矿程序攻击的真实事件，这篇文章将完整记录整个排查、处理和防护的过程。即便你不是专业运维人员，也可以参考我的经验做出应对，特别是使用了 AI 辅助之后，整个流程变得更高效。

文章提纲：

如何发现服务器中运行着挖矿程序 XMRig
XMRig 与伪装成 apache2 的高 CPU 恶意进程分析
新一轮攻击：服务器竟然主动在攻击别人
如何彻底清理恶意程序并加强安全防护

一、初次警告：检测到 Stratum 协议

7 月 11 日凌晨，我收到运营商的邮件警告：

在您的系统磁盘上发现了可疑文件，建议您先确认文件合法性并进行处理。通常黑客入侵后会植入挖矿程序赚取收益，该类程序占用 CPU 等资源，影响用户正常业务，危害较大。

邮件中提到检测到了 Stratum 协议的网络流量——这是挖矿行为的常见特征。

我第一时间尝试 SSH 登录服务器，还好还能正常登录。运行 htop 后，我看到两个进程 CPU 占用极高：

xmrig（CPU 占用 99%）
apache2（同样接近满载）

二、处理 XMRig 挖矿进程

首先处理明显的挖矿程序 xmrig：

PID: 2955486
Command: ./xmrig --url pool.hashvault.pro:443 --user 8Zp...
CPU: 99%

我尝试直接终止它：

sudo kill -9 2955486

幸运的是，它没有立刻重启。

接着我查找其文件路径：

sudo find / -iname '*xmrig*'
# 找到位置：/var/tmp/m/xmrig

GPT 建议我删除整个目录：

sudo rm -rf /var/tmp/m

出于谨慎，我先查看了该目录的内容：

ls -alt /var/tmp/m

total 3284
drwxr-xr-x  2 root root    4096 Jul 16 15:29 ./
drwxrwxrwt 11 root root    4096 Jul 16 15:28 ../
-rw-r--r--  1 root root    1684 Jul 11 02:24 config.json
-rw-rw-rw-  1 root root       6 May 27 23:26 test.pid
-rw-r--r--  1 root root       5 May 27 22:09 bash.pid
-rw-r--r--  1 root root      47 May 27 22:08 cron.d
-rw-r--r--  1 root root       8 May 27 22:08 dir.dir
-rwxr--r--  1 root root     223 May 27 22:08 upd*

还特地看了下这个config.json里有什么：

$ cat /var/tmp/m/config.json

{
  #….
    "pools": [
    {
      "algo": null,
      "coin": null,
      "url": "pool.hashvault.pro:443",
      "user": "82pZnwKcMJ9QFZ4Ja….”,
      "pass": "x",
      "rig-id": null,
      "nicehash": false,
      "keepalive": false,
      "enabled": true,
      "tls": true,
      "tls-fingerprint": "420c7850e09….”,
      "daemon": false,
      "self-select": null
    }
  ],
}

其中的 config.json 指向一个 Monero 矿池，包含攻击者的钱包地址。GPT 还帮我查到，这个目录的时间戳（5 月 27 日）与一次名为 RedisRaider 的挖矿攻击活动时间吻合：

Go-Based Malware Deploys XMRig Miner on Linux Hosts via Redis Configuration Abuse

该攻击通过滥用 Redis 配置命令写入 cron 任务，从而植入 XMRig（伪装为 apache2）。

回头一想，我的服务器上确实运行着 Redis，可能错误地开放了公网访问。我随后关闭了 Redis 的对外访问。

三、伪装成 Apache 的进程

除了 XMRig，htop 中还有一个 apache2 进程也非常可疑。但我并没有用 Apache，而是用的 Caddy。

尝试关闭 apache 服务：

sudo systemctl stop apache2
sudo service apache2 stop

但都提示找不到服务。

查看进程路径：

/usr/sbin/apache2 -k start

尝试查看文件：

ls -l /usr/sbin/apache2
# 提示不存在该文件

说明这个 apache2 进程并非真正的 Apache。

通过 ps auxfww 进一步排查：

PID 2510277 /usr/sbin/apache2 -k start （7 月 1 日启动，CPU 占用 91%）

我选择强制终止它：

sudo kill -9 2510277

它没有重启，但也暂时无法定位源文件。

四、第二次警告：服务器正在攻击别人？

以为一切结束后，7 月 16 日又收到新的警告：

您的云服务器由于被检测到对外攻击，已阻断该服务器对其它服务器端口（TCP:22）的访问，请及时进行安全自查。

这意味着，我的服务器正在向外发起 SSH 攻击？

立刻查看 22 端口活动：

sudo netstat -anp | grep ':22'

发现大量向外连接的 SSH 攻击，进程名为 Acronis：

tcp [my_ip]:34014 [target_ip]:22 SYN_SENT 3309431/./Acronis

我首先终止它：

sudo kill -9 3309431

然后查找文件来源：

sudo find / -name Acronis -type f
# 结果：/tmp/.mvwwttudfg/k/Acronis

再删除整个目录：

sudo rm -rf /tmp/.mvwwttudfg

五、后续清理与排查

完成以上操作后，我还做了一些系统层面的清理与排查：

sudo apt update && sudo apt upgrade -y  # 升级系统组件
sudo passwd root                         # 重置 root 密码
sudo reboot                              # 重启系统

确认没有可疑进程：

ps aux | grep -E 'xmrig|Acronis|apache2'
sudo netstat -anp | grep ':22'

一些教训和建议

Redis 千万不要暴露公网端口。
定期检查 /var/tmp/ 和 cron，是防范入侵的重要方式。
恶意程序喜欢伪装成常见系统服务（如 apache2）。
AI 工具有时在排查安全问题时非常有帮助。

希望这篇文章能帮到你识别或处理类似攻击！

Hegwin.Me