0X00 前言

攻防演练的通知下来了，那一张薄薄的书面通知，暗示了我们未来两个月的命运，匆匆一瞥，微信群里的红点点数字疯狂增加。大致扫了一眼，全是蓝初再哀嚎，研判再祈祷；没错他们都在祈求一件事。那就是监控能不能选择对的攻击告警，不然攻防演练群里一堆误报和漏报，这个项目里的人八成会被甲方"指指点点"。

于是为了帮助我们的队友，也为了自己不被坑，我打算利用靶场里的安全设备捕获的流量为例子，帮助我的队友提升一下他的技术能力，本文章就涉及到一些误报分析和处理流程的分析（由于不是真实环境，所以希望大家不要扣住细节不放），给出自己的处置想法与建议，希望大家喜欢！

0X01 监控的起源

其实蓝队真的很复杂，一位大老师这样说过。但是蓝队在近几年的市场下变的越来越糟糕，原因有很多，但是这就导致攻防演练带给蓝队的反馈是负面的。工资越低，在某些人眼里，蓝队的可替代性越来越强；一句你不干有得是人干，倒出蓝队的无奈；蓝队的内部也不平衡，强者越强，弱者满塘。话不多说我就举几个监控，经常会遇到的问题，给出我自己的思考，抛砖引玉。

webshell流量特征

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.提前占用他的目录名 。

l