一起站库分离的数据库对内扫描事件

一起站库分离的数据库对内扫描事件

    一入应急深似海，从此休息是路人。攻击队评分13.0，应急评分30，应急就是躺赢狗，攻击队拿了MVP!又到了新一周的经验分享了，没错这次又遇到该死的攻击队了，为什么会有攻防演练这种东西，难顶啊！

事件背景

    客户反馈有台数据库服务器对内网横向扫描，自行排查后发现回收站存在多个异常文件，想知道是怎么失陷的，方便写防守报告，我一看就知道是攻击队的行为了，那能怎么办，给客户查呗。

现场排查

    先来分析一下上面的异常文件，首先1.txt就是down.exe，只不过base64编码了一下（文件头部MZ表示可执行文件），算是比较常规的一个绕防护操作吧

    然后f.exe是fuso反向代理工具，用于流量转发，都不用逆向，直接看字符串就能发现用了大量fuso的库文件

    其它的不展开了，一个后门，一个添加用户的，反正实锤是攻击队的行为，直接开始溯源，异常文件中最早的落地时间，0点55分 ，数据库服务器没有其它Web业务，站库分离的，那可以直接查看应用程序日志的15457，在前一天的17点00分开启了xp_cmdshell功能

    这样的话大概率是前台的Web业务存在SQL注入漏洞，之前分享的经验里面也遇到过类似的站库分离情况，找前台Web业务就对了，我们来看看前台的Web业务的访问日志，根据IIS日志日常减8小时，那就是9点00分左右了，发现有POST一个可疑的接口SQLFunction.aspx，攻击IP 210.*.*.119

    从接口名字也能看出来和SQL语句有关，就是看不到数据包呢容，不过还好客户还有安全设备，走安全设备上找到了完整的POC

    站库分离还是比较好查的，理清思路一步步来就可以正常溯源出完整路径

原文始发于微信公众号（sec0nd安全）：一起站库分离的数据库对内扫描事件