记一次险象环生的应急响应经历

**前言：** 在近期的一次攻防演练中，发生了危险的应急反应。整体体验记录如下。 \r

\r

\r

\r

###0x01 第一战\r

\r

18:13 收到EDR告警，检测到Webshell。隔离Webshell并按照工作流程发起紧急响应：\r

\r

* 分析团队：分析日志定位入侵原因，制定并实施止血方案\r

* 响应组：检查主机和应用程序中是否存在其他尚未发现的后门\r

\r

18:26 判断风险已基本消除，应急响应结果：\r

\r

* 定位Web入侵入口，启动WAF规则止血，同步推进开发修复漏洞\r

* 发现另一个未检测到的webshell 并将其删除\r

*阻止所有可疑的攻击IP\r

\r

PS：这个入侵时间是非常微不足道的。正值所有开发者都在吃饭的时候，应急响应效率受到很大影响\r

\r

###0x02 左右支撑\r

\r

18:32 再次收到EDR警报，表示正在执行可疑命令。再次响应警报。分析结论：\r

\r

* 攻击团队正在从服务器中拖拽代码并搜索AK，导致该行为触发警报\r

* 入侵原因尚未确定。可能是通过其他未知漏洞或者过去遗留下来的webshell/rootkit重新进入的。目前，攻击小队已经感知到我们发现了它。如果我们删除人肉发现的webshell，对方也会植入新的webshell，继续收集信息\r

* 在无法定位入侵原因的前提下与业务部门进行沟通。业务部门无法接受暂时下线业务、关闭主机的风险\r

* 响应陷入僵局，存在攻击团队随时从代码中分析出新漏洞或拖走业务数据的风险\r

\r

###0x03 绝地反击\r

\r

18:37 经过综合研判，没有办法阻止攻击队伍再次进入。我们只能尝试利用目前处于试用阶段的拟态防御功能，将攻击方的后门热迁移到蜜罐环境中，看看能否有效欺骗攻击方，为分析入侵原因、止血赢得时间\r

\r

* 随后发现攻击团队尚未发现Webshell执行环境已被替换，仍在继续窃取蜜罐中的业务代码，成功获得了更多的响应时间\r

\r

\r

* 同时，拟态蜜罐检测到攻击方可能使用蚁剑Webshell管理工具，有一定概率可以反击并反向控制其机器\r

###0x04 前途光明\r

\r

18:39发出反指令，2分钟后成功收到攻击方的炮弹，并开始遍历攻击方的机器寻找有效信息\r

\r

* 分析发现攻击团队确实使用了rootkit来持久控制机器，并且有多个未被发现的webshell可供使用，同时还有备用RCE用于进一步入侵\r

* 将相应后门热迁移至拟态蜜罐，并通过WAF拦截相应漏洞后，成功完成应急响应\r

\r

###0x05 事后回顾\r

\r

1、应急响应的关键是争取尽可能多的响应时间。 WAF的快速止血和基于拟态防御的主动欺骗是更有效的赢得时间的方法；\r

2、在选择主动对抗攻击团队时，一定要谨慎，确保最终有效的止血方式（比如这次业务拒绝关闭/下线，我们就会很被动），否则很有可能黑客察觉到自己暴露，隐藏自己不被我们察觉。第一波止血后，黑客的Webshell就没有被我们检测到。如果黑客因为信息收集活动过多而没有再次被我们发现的话，这次很有可能整个集团都会垮掉。 \r

\r

===============================================\r

\r

以上为用户真实试用案例。文中提到的拟态防御主动欺骗能力可以通过以下渠道申请试用：【长汀百川云平台】(https://stack.chaitin.com/tool/detail?id=45)