文章讲述了在外包项目中，一名安全专家通过分析一系列看似可疑的数据包，发现了一个误报的webshell事件。故事强调了日常安全研判的细致性和精确性，提醒安全从业者避免过度解读和误操作。
- 安全事件
今天外包仔按时拿着9.9瑞幸奔赴工位，负责看监控的同事丢过来一条告警，如下图，我一看咖啡都不用喝就清醒了，确实晃眼一看有点提神，但好在是未失陷，大概率是一些垃圾文件带的不知道什么年代的前辈下的蛊，一般情况下杀杀毒也就完事了。
但是鼠鼠这边的客户有些难顶，全程我只能接触到态势感知和一台节点防火墙，且防火墙还没有调试策略的权限.....唯一能用的只有封禁恶意IP时塞进黑名单里，以上为背景。
- 研判过程
也没有什么edr什么其他设备的了，那就1，2，3，上数据包！
一开始我同事看这个包的时候先判断为webshell传输解密，以及加上混淆，（因为鼠鼠我最近和他在研究webshell免杀，但是又没来得及对加密流量和特征等，从马后炮视角来看有点草木皆兵了哈），鼠鼠粗粗看一眼也没多想就觉得差不多吧，申请个杀毒就行了，往客户那里一丢就完事，欸，微信发送，成功！
但是，仔细动了动我聪明的小脑袋瓜，好像也不对呀
让我再倒退回去看看态势感知的数据包，这不对呀！是外到内的连接！
（由于涉及到客户IP地址直接截断了，实际方向为客户外网闸->服务器地址）
服务器实际是不出网的，是多台负载+代理的结构，当然，也不排除有些大牛艺高人胆大能把他的马子传进来再二开了工具避开了流量动态检测。
再次回头看数据包，此时距离微信撤回还剩一分钟了！在不赶紧研判出是不是误报就有有一半一半的概率等着甲方阿爸扣绩效了。如下：
这是另一个数据包，由于有多次连接，一开始鼠鼠和同事都是看到了这个encoding，首先判断了是代码编码为base64或者也可能是utf-8后再进行混淆二进制字符（上一个数据包很明显是base64了），但是我们都忽略了一个细节，这里先po上一张鼠鼠自改的冰蝎php马子拿来做对比：
可能很多大佬一开始就看出问题来的，这个数据包是没有执行载体的。且刚才就提到了，这个数据包是从外走到内了，只是不合理的，所有所有的判断都必须推倒。
再次回到数据包，其实关键点在这几个框框里：
这几个是什么呢？我直接上结果吧：
后来和管理员稍微确认了一下服务器用途，实际是一个类似oa的东西，某个板块是用作数据处理的，确实有在线编辑pdf的功能，那一切就明朗了。至于为什么会误报呢，查看了态势感知触发的规则后也大概有了答案，可能也是检测了encoding关键词，以及大量的base64加密内容。（是不是四舍五入鼠鼠和态势感知并肩了？）刚刚好微信撤回时间剩余15秒，撤回！换回客户一个大大的夸赞，今天又是很安全的一天呢！
- 总结
日常研判其实是很细腻很具有变化的事情，像我这样勉强做过一年多安全的黄毛小子（缺锌头发泛黄）总是幻想自己在日常中化作守护大神驻场无敌，抱着这样想法的大概率老是把正常业务或访问当成异常告警就给封了，难免不了老是挨上客户一顿骂；也有些摆子不认真分析就天天误报处理，真出事了卷铺盖都来不及...当然了，今天的例子其实只是提供了一个生动且真实的学习案例，日常不会有那么多无端联想，做研判一定是要精准而迅速的，还是得不断的学习去精进自己滴。（新手上车，大佬们多指教）
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
