关于近期cs服务端被反打的原因分析

Part1 前言

最近几天，不少朋友的cs服务端被反打了，相信很多网友都知道了，大家也都在讨论，各种各样说法都有。具体事件描述如下：部分网友的cs服务端被不明攻击者拿下权限，之后攻击者将cs上的shell全部通过云函数的方式反弹到自己的cs上，之后将原有cs端的shell权限清空，在cs控制台留下一句话“CS RCE全版本通杀 Please v Me 获取详情”等之类的信息。由于攻击者是通过云函数方式反弹的权限，暂时很难溯源到攻击者。（以下图片来源于网络）


随后cs被打的消息就小范围流传开了，大家都在讨论cs被反打的原因。我听到了好几个版本，大致如下：
1. 某某云被搞了；
2. 某云函数出问题了；
3. 某供应链出问题了；
4. CS出现了远程代码执行漏洞；
5. 前期下载的CS马被捆绑了后门。
6. 收集汇总各家设备报警的ip，对这些ip全端口扫描，爆破出cs密码；
7. 踩了蜜罐，利用了mysql任意文件读取，读取测试人员电脑的配置文件。
8. 通过fafo检索出cs服务端的ip，然后批量猜解cs密码。
等等。。接下来做一下简单的分析。

Part2 技术研究过程

简单分析各种猜测

1  某某云被搞、某云函数被搞、某供应链被搞等等说法，我一开始听到这个推论就觉得不太可能，先不从技术角度上分析，且从逻辑上就讲不通：首先他们是有src漏洞提交平台的，挖这么一个漏洞是费很多心力的，为啥不去交src，用来批量打一圈cs实在是有点大材小用，况且去定位哪些ip是cs的服务端，也是一个麻烦事（这里我说的很隐晦，大家自己体会），实在是讲不通。

2  前期下载的cs马被捆绑了后门，这个也不太可能，因为我问过一个cs被打的小孩，它的cs是自己魔改的，不存在捆绑后门的可能性，但是也被打了。所以这个原因暂且排除。

3  爆破cs的服务端密码，这个就更不可能了。因为我问过几个cs被打的朋友，密码设置的足够长、足够复杂，而且cs的服务端端口设置的很偏门，但凡有些经验的测试人员，都会把默认端口改掉。所以不存在暴力破解的可能性。

4  cs出现了远程代码执行漏洞，这个可能性是有，但是与此次攻击事件关联不大。我相信有大牛肯定可以挖到这样的漏洞，但是存在这样的漏洞且与此次事件相关的话，那应该大部分人的cs都被打才对，所以技术上行得通，但是逻辑上还是讲不通。

5  踩了mysql蜜罐，然后蜜罐通过mysql本地文件读取漏洞读取了测试人员电脑的cs客户端的配置文件，从而获取到了cs的ip地址、端口、用户名密码。这是我到目前为止听到的一个最能让我接受的cs被反打的原因，因为cs本地的配置文件是明文存储密码的，对此我之前去逆向cs源码时发现过这个问题，对应的安全问题也就是配置文件中的关键信息是明文存储的。


Mysql蜜罐读取电脑配置文件

关于Mysql蜜罐的具体技术细节，网上文章介绍的太多了，大家可以自己从网上搜索文章，我写一个简介吧：mysql中有一个load data local infile函数能够读取本地文件到mysql数据库中。当攻击者用爆破mysql密码的扫描器扫描到我们的mysql并连接上的时候（注，这里我纠正一下，只要连接一下蜜罐mysql，就可以被蜜罐读取到本地配置文件，不需要提供正确的用户名密码），客户端（攻击者）会自动发起一个查询，我们（服务端）会给与一个回应，我们在回应的数据包中加入load data local infile读取攻击者的本地文件到我们数据库中，达到反制的目的。（以下图片来源于网络搜索）

cs的配置文件明文存储密码
只要是使用cs客户端连接过cs服务端的电脑，cs客户端都会在固定的文件夹下生成一个.aggressor.prop配置文件。如果是Windows系统，那么文件位置是：C:\Users\Administrator\.aggressor.prop，这个配置文件里面就包含了cs远控的ip地址、端口、用户名及密码，而且都是明文的！如下图所示：

每次打开cs都会显示出曾经登录后的ip地址、端口、用户名、密码等信息，这些信息都是存储在本地.aggressor.prop文件中的，大致内容如下图所示：

因此我们得到结论，搭建一个mysql蜜罐，一旦攻击者连接这个蜜罐，那么这个蜜罐利用msyql本地文件读取漏洞去自动读取C:\Users\Administrator\.aggressor.prop这个文件内容，蜜罐就可以成功得到攻击者的cs服务端ip地址、端口、用户名密码。

搭建环境实验成功
为了验证一下上述猜测，还是要实战测试一下的，从github上找到一个python写的mysql蜜罐脚本，本地简单修改一下，将文件读取的路径改为C:\Users\Administrator\.aggressor.prop，将脚本运行起来。如下图所示，一个监听本地端口3306的mysql蜜罐就搭建好了。

为了模拟红队人员连接mysql的行为，使用navicat远程连接一下这个蜜罐的ip地址。（再次强调一下，无需知道mysql的用户名密码即可，输入一个错误的用户名密码，mysql蜜罐同样可以读取本地文件）

成功使用蜜罐获取到的ip地址、端口、用户名及密码连上cs服务端（以下图片来源于网络）


Part3 总结

1.  尽量在虚拟机下连接或者爆破mysql密码，避免踩到mysql蜜罐，避免被读取到电脑的各种明文密码配置文件。

2.  反编译魔改cobaltstrike，将.aggressor.prop配置文件去掉，更改为其它方式加载。

3.  配置文件明文密码存储、绝对路径泄露等等，这些不受重视的漏洞还是会造成很大安全隐患的，本公众号反复提到过，大家还是要注意这些低危漏洞，及时修复掉。本次事件就是一个教训。

4.  mysql蜜罐还可以读取微信id号、qq号、手机号等等信息，大家在日常的测试工作中，一定要注意不要随便连接mysql数据库，以免个人信息被获取到。

5.  本篇文章只是提供一个分析思路，一个可行思路，不一定就是最终的标准答案，抛砖引玉，期待大牛们的文章。

duanchy

学到了，学到了

热心网友6

楼主的分析很透彻，特别是从逻辑上排除其他猜测，然后通过实验验证MySQL蜜罐读取配置文件这条路径，思路清晰且可操作性强。之前确实没太留意CS客户端那个明文配置文件的问题，经过这次事件确实是个重要教训。建议部分也很实用，特别是虚拟机隔离和魔改CS去除明文存储，值得大家参考。感谢分享！