演习前红队暗泉涌动投毒

本章为该系列的第六篇，进入了演习前的厉兵秣马阶段，全部人员都在冲刺着做最后的准备。我们开始组织相关方进行应急响应演练、也在应急响应中心排班布阵，同时发现红队也在努力。接下来将介绍某年的攻防演习前夕，监测到红队在github公开某产品已知漏洞的exp，在依赖包中加入后门，从而进行投毒攻击。回想起来觉得这招真高，明显就是针对安全从业人员布的陷阱，若是红队则可以“黑吃黑”，若是蓝队则可以突破边界...再回忆一下，不禁有点后悔和失望，因为当时没有坚持对开源项目的质疑并深究下去。

01

—

事件描述

          某日下午阿跃IM联系我，同步github上有个项目在开源某产品的漏洞exp（https://github.com/xx/main/mou-RCE.py）。上去看了一下存在漏洞的url及参数，判断为2019年已知的漏洞。观察这个作者有点奇怪，账号刚注册不久、仅有当前这个项目，但是看了代码并没有明显的后门地址，就不了了之。

半夜阿亮在漏洞预警群里发了一个截图，说这个项目是红队投毒项目，fake_useragent-0.1.11包被改为fake_useragant-0.1.11，一运行就会被种上后门。

然而当晚并没有应急，大家都在看稀奇，殊不知内部可能会有人下载并运行脚本（PS：公司X千人具备攻防能力...）。回忆起来，真是有点后怕。

02

—

响应动作

公司内部暂无中招情况。

次日上班时，在内部预警监测群里艾特同事把C2地址禁掉，并在内部排查流量和日志，查看是否有外连记录：

• 网络边界封禁：通常是直接在FW上把C2 deny，但也会有特殊情况，比如最外面是云Waf，那就在最外层进行封禁。随着各级实战演习、公司攻防对抗常态化的开展，封IP作为最常见的动作基本都实现了集中化和自动化，不再繁杂的登陆多种和多个设备。然而其实现，需要逐个去梳理公司生产网、办公网、...、XX网的结构，下发封禁指令至正确的设备，否则会出现很多漏网之鱼；

   

• C2多维查询：依赖于自身网络安全建设的成熟度，主线还是从流量和日志上查询C2的访问或解析记录。流量覆盖全的，直接在NTA设备上看；终端覆盖全的，就在edr控制台上看；系统日志收集全的，就直接搜索日志...当然了，最好的还是把所有日志、告警信息全都汇聚到SOC，直接在SOC上查询；

   

• 终端拉黑样本：此处的样本就是mou-RCE.py，计算下md5，在edr和hids的控制台上下发策略拉黑，可以作为前面动作的补充。不过此类投毒的生命周期比较短，出于谨慎还是有必要执行该操作；

   

• 共享威胁情报：无论是厂商的威胁情报中心，还是企业自建威胁情报，都可以将提取出的C2进行充分利用。现在基本上各类安全产品都接入威胁情报，将该条信息同步（C2地址标记为黑IP或域名），让所有的安全产品拿到黑地址，从而也降低了安全运营本次投毒事件出现漏网之鱼的概率。
   

03

—

处置结果

公司内部暂无中招情况。

幸好，结果是好的。不然一个后半夜的时间，对于攻击队来说足矣。

          

04

—

经验总结

公司内部实际有很多细分领域研究比较深入的团队，针对此类投毒事件，可以进行联动，打通投毒检测-威胁情报-自动化应急处置，提前一体化发现未知威胁和响应：

• 主动组局，将内部优质资源串联：从观察到的现象来看，一般技术大佬或者比较专的技术人员，都不会太主动和别人社交以及向别人寻求资源帮助。联动研究院、威胁情报和内部安全运营，一起拉会讨论。投毒的研究成果不能直接被使用，因为很多库都会有外链行为，有的是拉资源，有的是恶意外链，不能直接直接判毒。故建议其将外联地址过一遍威胁情报，在推送到群里给大家用；

   

• 提出投毒场景的自动化应急响应：在之前的重保就和安全运营同学提过，这部分不难做自动化（获取C2和有毒的库，内部查询进行排查投毒库，边界拉黑C2地址），但一直苦于没有可靠的、固定的信息源，所以一直没做起来。但这实际上是十分普遍的场景，目前响应速度还是不够快速。

     

 

---

 

原文始发于微信公众号（我的安全视界观）：演习前红队暗泉涌动投毒