攻防演练期间那些事
2024-7-23 13:12:10 Author: www.freebuf.com(查看原文) 阅读量:4 收藏

freeBuf

主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

0X00 前言

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

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

0X01 监控的起源

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

webshell流量特征

webshell的鼎鼎大名大家一定是清楚的,一旦出现告警那就是非封禁+分析不可的。但是我的队友显然不是这么认为的,他开始高呼大叫,嚷嚷到红队打进来了,打井来了;于是做过前期摸排的我立马捂住他的嘴巴,用Delete键删掉他微信聊天框里敏感的话语,心里暗道,好险差点被这个玩意坑了。

实际情况是怎么回事呢?我们来看如下安全设备的告警(如下图所示):

1721711074_669f39e26809d6dd42078.png!small?1721711072050

映入眼前的就是一个内网监测告警,然后发现了尝试字样,扭头看了看我的队友,忍住骂人的冲动。去看了看网络资产规划图,果然不出我所料,误报无疑了。于是我开始问我的队友你为啥觉得它有问题,我的队友开始嚷嚷说判断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

1721711084_669f39ecce86f8b6ba645.png!small?1721711082632

上图代码使用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.提前占用他的目录名 。

log4j流量特征

好家伙,我整理个威胁情报的攻防,他又开始框框报log4j的流量了,这下好一点知道看目的IP与源IP之间的关系了,我的火气降低了一点,觉得这孩之应该还有救,结果一看气个半死;流量截图(如下图所示),base64解码后发现是两个系统之间的正常交互....我只能跟他说base64解码不会?就这还CTF蓝桥杯50名的水平???

1721711155_669f3a3353e8eff566ed4.png!small?1721711153003

没办法我只能,又给我的队友构造了如下误报,帮助它理解什么是log4j攻击,以及为啥会有误报产生...

1721711118_669f3a0ee9b17380784a5.png!small?1721711116615

log4j攻击主要是利用日志在打印时当遇到${后,以:号作为分割,将表达式内容分割成两部分,前面一部分prefix,后面部分作为key,然后通过prefix去找对应的lookup,通过对应的lookup实例调用lookup方法,最后将key作为参数带入执行,引发远程代码执行漏洞 特征:

已在FreeBuf发表 0 篇文章

本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022


文章来源: https://www.freebuf.com/defense/406757.html
如有侵权请联系:admin#unsafe.sh