攻防演练期间那些事
本文由 创作,已纳入「FreeBuf原创奖励计划」,未授权禁止转载
攻防演练的通知下来了,那一张薄薄的书面通知,暗示了我们未来两个月的命运,匆匆一瞥,微信群里的红点点数字疯狂增加。大致扫了一眼,全是蓝初再哀嚎,研判再祈祷;没错他们都在祈求一件事。那就是监控能不能选择对的攻击告警,不然攻防演练群里一堆误报和漏报,这个项目里的人八成会被甲方"指指点点"。
于是为了帮助我们的队友,也为了自己不被坑,我打算利用靶场里的安全设备捕获的流量为例子,帮助我的队友提升一下他的技术能力,本文章就涉及到一些误报分析和处理流程的分析(由于不是真实环境,所以希望大家不要扣住细节不放),给出自己的处置想法与建议,希望大家喜欢!
其实蓝队真的很复杂,一位大老师这样说过。但是蓝队在近几年的市场下变的越来越糟糕,原因有很多,但是这就导致攻防演练带给蓝队的反馈是负面的。工资越低,在某些人眼里,蓝队的可替代性越来越强;一句你不干有得是人干,倒出蓝队的无奈;蓝队的内部也不平衡,强者越强,弱者满塘。话不多说我就举几个监控,经常会遇到的问题,给出我自己的思考,抛砖引玉。
webshell的鼎鼎大名大家一定是清楚的,一旦出现告警那就是非封禁+分析不可的。但是我的队友显然不是这么认为的,他开始高呼大叫,嚷嚷到红队打进来了,打井来了;于是做过前期摸排的我立马捂住他的嘴巴,用Delete键删掉他微信聊天框里敏感的话语,心里暗道,好险差点被这个玩意坑了。
实际情况是怎么回事呢?我们来看如下安全设备的告警(如下图所示):
映入眼前的就是一个内网监测告警,然后发现了尝试字样,扭头看了看我的队友,忍住骂人的冲动。去看了看网络资产规划图,果然不出我所料,误报无疑了。于是我开始问我的队友你为啥觉得它有问题,我的队友开始嚷嚷说判断webshll攻击就是鉴别一些高危的函数,比如eval,assert;然后判断使用工具的特征(一堆八股文),我忍住我的暴脾气,给他找了一个上传webshell的流量图(如下所示)让他自己去研究。
队友八股文如下:
蚁剑:
蚁剑就是ini_set;ini_set_time;ini_set_limit;@ini_set("display_errors","0")和部分代码明文传输,较好辨认
菜刀: 老版本采用明文传输;新版本采用base64加密,发现大量的base64加密密文就需要注意
冰蝎: 冰蝎1:冰蝎1有一个密钥协商过程是明文传输,并且有两次流量,用来校验;冰蝎2:因为内置了很多的UA头,所以当某一个相同IP重复请求,但是UA头不一样;冰蝎3:因为省去了协商过程,所以流量上可以绕过很多,但是其他特征依旧保留,比如ua头 冰蝎数据包总是伴随着大量的content-type:applicationxxxx,无论GET还是POST,请求的http中,content-type为application/octet-stream
哥斯拉: cookie这个值的地方有一个小纰漏,就是正常请求cookie最后结尾是没有分号的,可能后续作者会进行调整修改;哥斯拉会响应三次,且connection这里会是keep-alive
上图代码使用Java和Nashorn JavaScript引擎来执行shell命令。通过创建一个新的Nashorn ScriptEngineManager对象,然后使用该对象获取名为nashor的ScriptEngine对象。其内部包含的shell命令使用了base64编码,使用bash命令执行该文件。
至于内存马的判断和清除就很简单了:
判断方式:先判断是通过什么方法注入的内存马,可以先查看web日志是否有可疑的web访问日志,如果是filter或者listener类型就会有大量url请求路径相同参数不同的,或者页面不存在但是返回200的,查看是否有类似哥斯拉、冰蝎相同的url请求。通过查找返回200的url路径对比web目录下是否真实存在文件,如不存在大概率就是内存马。
清除方式:1.利用条件竞争把shell内容改写或者清除比较好用 2.重启服务 3.提前占用他的目录名 。