0x00 前言
刚开始写博客的时候还不认识这么多眼花缭乱的博客/静态页面生成器框架，当时只知道一个比较有名的WordPress，而且还有很多现成的好看主题可以选，于是就入了WordPress的坑，殊不知三年之后回旋镖落到了我的头上，半年内连续被一句话木马干了三次，最后被迫关掉了PHP的文件上传。
不过虽然但是，这次的挖矿木马并不是PHP的锅。6号那天是工作日，我趁中午午休时间回了趟家，键盘都敲冒烟了，总算是定位到了是谁的漏洞导致被木马入侵。严格意义上来说，这是我第一次进行网络防御实战，之前打CTF比赛都可以算是攻击，虽然因为经验不足走了些弯路，但最后结果还算顺利，感觉从零开始定位木马的过程和经验还是有一定参考价值的，之后再遇到也可以作为cheatsheet参考，所以在这里总结一下~
0x01 开端
事情要从1月6日的11:21开始说起，当时我正在一边开会一边摸鱼，美美地想着中午吃什么好吃的，突然手机一阵震动，收到了一条来自腾讯云的短信：
看到之后马上我就急了，饭也来不及吃了，等到午休马上就飞奔回家了。
0x02 应急响应
到家之后先登上腾讯云控制台，发现给的告警是拦截到恶意请求，具体信息如下图所述：
百度可知这个gulf.moneroocean.stream是一个挖矿木马的服务器，但是木马本体肯定不是systemd-resolved，估计是被systemd拉起来的。一时半会找不到这个木马在哪，所以先在腾讯云的服务器安全里配置下拦截策略，把所有关于这个域名的请求都拦截掉。
0x03 定位
暂时阻断木马和服务器的连接只是临时规避方案，木马还在运行，而且我们还需要找到木马的攻击路径，发现漏洞并进行修复，从根本上解决问题。
刚开始是参考了腾讯云提供的文档进行定位：主机安全 Linux 入侵类问题排查思路_腾讯云，但是试着试着就发现这文档显然是AI写的，还有好多命令是错误的（也可能因为他用的是CentOS，我用的是Ubuntu），总之最后还是决定靠自己的linux运维经验来搞定。
（1）看进程
在刚才腾讯云的告警中，我们得知了挖矿木马的服务器，那么接下来就要htop挨个进程审查（top或者ps也可以，喜欢哪个用哪个），看哪个比较可疑，像挖矿木马。
结果还真被我找到了：
# ps -ef | grep moneroocean lightho+ 2933279 2520568 0 Jan04 ? 00:00:13 /tmp/.x/m -o gulf.moneroocean.stream:10128 -u 43yiB8RenFLGQdK97HGVpLjVeQaCSWDbaec2ZQcav6e7a3QnDEmKq3t3oUoQD9HgwXAW8RQTWUdXxN5WGtpStxAtRrH5Pmf -p a36a512c_mjyklalh --cpu-max-threads-hint=75 -B --
（2）找进程
找到的木马进程的可执行文件是/tmp/.x/m，可是到/tmp目录下找并没有这个文件，这是怎么回事呢，难道通过什么方式隐藏掉了，于是想到用lsof命令看一下它打开的文件：
# lsof -c m m 2933279 lighthouse cwd DIR 0,52 4096 816187 / m 2933279 lighthouse rtd DIR 0,52 4096 816187 / m 2933279 lighthouse txt REG 0,52 7047392 833771 /tmp/.x/m m 2933279 lighthouse 0r CHR 1,3 0t0 6 /dev/null m 2933279 lighthouse 1w CHR 1,3 0t0 6 /dev/null m 2933279 lighthouse 2w CHR 1,3 0t0 6 /dev/null m 2933279 lighthouse 3r CHR 1,9 0t0 11 /dev/urandom m 2933279 lighthouse 4u a_inode 0,14 0 11274 [eventpoll] m 2933279 lighthouse 5r FIFO 0,13 0t0 3106306227 pipe m 2933279 lighthouse 6w FIFO 0,13 0t0 3106306227 pipe m 2933279 lighthouse 7r FIFO 0,13 0t0 3106307444 pipe m 2933279 lighthouse 8w FIFO 0,13 0t0 3106307444 pipe m 2933279 lighthouse 9u a_inode 0,14 0 11274 [eventfd] m 2933279 lighthouse 10u a_inode 0,14 0 11274 [eventfd] m 2933279 lighthouse 11u a_inode 0,14 0 11274 [eventfd] m 2933279 lighthouse 12r CHR 1,3 0t0 6 /dev/null m 2933279 lighthouse 13u sock 0,9 0t0 3115274657 protocol: TCP m 2933279 lighthouse 14u sock 0,9 0t0 3115274965 protocol: TCP m 2933279 lighthouse 15u sock 0,9 0t0 3115274971 protocol: TCP
结果还是/tmp/.x/m，然后就发现/proc里有进程的各种信息，就可以直接把可执行文件和实际执行的命令行导出来：
# cat /proc/2933279/exe > ~/m.bin # cd /proc/2933279/pwd lobe-chat
大吃一惊啊，我本来以为是WordPress又被攻破了，结果居然是lobe chat，这个是我去年玩llm的时候随手搭的，是通过Docker部署的，后来虽然不玩了但是懒得关掉，结果没想到居然有漏洞，看来得去GitHub上看一眼了。
还没等我点开issue我突然就想起了什么，lobe chat居然是next.js写的，原来是React干的，前几天闹得沸沸扬扬的React Server Components漏洞，攻击者可以利用该漏洞实现任意代码执行，极其严重，网上有不少人都中招了，我本以为我没有用React的服务就没管，结果我也中招了TAT
紧急！React 19 RSC、RSF 存在严重漏洞，官方发布紧急修复版本！-腾讯云开发者社区-腾讯云
（3）杀进程
知道是lobe chat干的那上面的/tmp/.x/m也能解释了，这应该是在容器内的路径，所以想办法进入容器，在容器目录下找到了/tmp/.x/m和另一个疑似木马的可执行文件/app/.system-update/system-service，由于本人逆向水平有限，只打开ida看了一眼就放弃了，太复杂了，所以在本文最后会放出样本，有兴趣的同学可以下载下来自己研究。
有意思的是在我把木马从docker里拷出来的时候腾讯云开始隔离了，早干嘛去了（
知道是docker里拉起来的就好办了，解决方法就更简单了，把lobe chat容器删掉就行，反正我也玩够了。
（4）收尾工作
最后检查下systemd、supervisor、docker、cron等进程守护、计划任务、容器工具，看还会不会拉起木马进程。
0x04 总结
之前log4j的严重漏洞我没有中招还沾沾自喜，这下被React gank了真得用Vue吧，这次的事件也警醒了我，不要以为自己没用到就懒得排查，服务器上跑了这么多服务，很容易就对log4j或者React这种基础库产生直接或间接依赖，一定不能抱有侥幸心理。
最后在这分发一下挖矿木马的样本，压缩包密码是事件发生的日期（YYYYMMdd）
0x05 后话
这件事还没完，虽然挖矿木马解决了，但是腾讯云很大方地送了我一周的服务器安全旗舰版，这就意味着一年前的WordPress一句话木马的样本可以下载下来研究一下了，看起来都很简单，就是利用了文件上传绕过和代码执行漏洞，由于时间已经过了很久了，当时的环境和日志都没有了，没法复原攻击路径了，就把样本放在这里，供大家学习webshell，密码同上。
最后还是想说，PHP这门语言设计之初就只考虑了方便开发，而没有对安全做任何考虑，例如文件包含、命令执行、反序列化、隐式类型转换等特性，这些特性确实方便了开发，但是带来了巨大的安全隐患，即使是和JavaScript比起来都有过之而无不及。例如文件包含可以动态包含远程服务器上的PHP脚本，命令执行可以用来做webshell执行任意代码，更别提反序列化和类型转换，如果使用不当很容易出现一堆漏洞。PHP作为一门主要用于后端的语言，更不应该不考虑安全性，也难怪那个年代全是写PHP和攻击PHP的。总而言之，言而总之，在2026年，我的建议是使用一些更注重安全的语言编写后端，最好是静态语言（现在PHP后端少了都变成攻击Python和Node.js了），如果不得不使用PHP写的服务一定要进行审计，例如WordPress要及时更新，不要装来历不明的插件，或者要审计下插件的代码，否则下一个中招的就是你。
或者干脆像我一样，在php.ini里把file_uploads关掉