【应急响应】没有痕迹该如何进行最优解

应急响应或者技术人员的方法论

在叙述本次应急响应前，先把方法论的前因后果讲解一下，以便可以带着方法论进入问题处置的过程，这样体会可能会更好一点，以便可以帮助到正在提升的我们。

因为技术人员不能只关注技术，对于客户来说世界上只有两种人有价值，一种是能够做事的人，一种是能够解决问题的人，或者两种形态于一身的人（很少）。毕竟系关、项目很复杂，客户/销售想要的可能不是最想的。那么有能力解决问题的人就能够在出现问题的时候创造出价值，从而创造渺小的介入机会。

例如我的起点比较低，只能从最低点开始往上爬，做过IDC机房/单位驻场，分保、系统集成、等保、项目经理、售前、销售（以技术为驱动落地过两个100+的项目，所以一定要相信自己，技术真的可以给公司带来价值，而不是只能体现公司价值，这取决于我们该怎么发挥主观能动性的去做），现在正在做应急、正在学渗透。这一路真不容易，机会也少，很多都是可爱的人愿意相信我愿意给我尝试的机会，我才有涉及的可能，无数次迷茫，但都被下面这个方法论给纠正过来，否则就会是一颗不顶用的螺丝钉。（做的杂，但是很开心，因为我知道前面没有吃的苦，只要我想做，那么这些苦都是必须得还回来的，希望还未入门的你可以少走弯路，出社会即可做自己想做的事，不需要像我这样绕很多路）

因此我深刻体会有一个观点或者方法论非常重要，那就是“任何节点千万不要卡在自己这，一定要往前推进，想尽办法往前推进，如果不行，那你也是尽力了”，适用于学习、售前、售后。项目推进不能卡在销售自己，项目管理实施进度不能卡在项目经理等等，一旦卡住，责任必在自己，因为那是自己的职责。

那么如何套用在应急响应上，例如客户单位发生了安全事件（例如勒索病毒、挂标语这种紧急的突发情况），客户现场：

1.目标主机一定会有日志吗？

2.日志被删了一定有第三方异机备份吗？

3.没有第三方异机备份就一定会有流量回溯吗？

这种情况肯定存在而且非常常见，不可能万事俱备事事如意，不然我们怎么创造价值，那么遇到这种情况该怎么应急响应？一番技术操作后和客户说“因为残留痕迹较少，无法进行攻击溯源，类似于新冠，没有扫安康码留下痕迹，就无法追踪到0号病人”吗？

是的，可以说，客户一般也认可（我以前就这么干，深感不足），因为事实如此，巧妇难为无米之炊。

但是客户单位的业务系统就得带着高危漏洞暴露在互联网：

1.客户领导会怎么想？

2.服务单位的销售会有什么样的担心？会怎么想这名技术，作为技术被销售这么想该怎么办？

3.作为想创造机会的安服公司销售正在想什么？

那肯定想着是怎么拿下这个单位？系关拼不过、产品价格谈不下来，…，靠什么呢，靠的就是这种你搞不定我可以搞定的机会。机会从哪来？机会源于咱们技术人员，这就是技术可以创造价值的能力。那这种情况该怎么带着方法论进入到这个安全事件应急响应过程中呢：

“任何节点千万不要卡在自己这，一定要往前推进，想尽办法往前推进，如果不行，那你也是尽力了”

情况概述

2021年12月12日18:57:30客户单位对互联网开放的致远OA被入侵，文件被加密，后缀为.locked。收到相关通知后随即进场应急。

搜索了一下这个后缀，大部分的结果都是这个病毒都是通过smb纵横传播的。目标主机已禁用网卡断网处置。

入侵检查

指定时间范围内被修改的对象

按照以前文章种叙述的方法，根据案发时间，使用dm:20211212查找了exe、jsp等关键字，在exe关键字中发现异常：

常规检查

根据案发时间查找痕迹再无有用信息，因此常规检查了操作系统。由于工作量大，使用之前文章中的工具进行自动化收集。同样未发现异常，勒索程序并未运行。

检查可攻击范围

由于可用信息较少，因此反向思维推理：

1.从内网横向渗透的可能性：由于仅一台主机被勒索，因此排除该可能性。

2.从互联网纵向渗透：排查互联网网关，发现仅映射业务端口，因此排除操作系统层面被入侵的可能性。

3.因此将检查重点放在应用系统上。

检查攻击痕迹

没找到，后来才发现是致远自己写的java程序，加载的也不是tomcat的配置文件，没有产生日志即不会被第三方异机备份。同时也没有流量回溯设备。

安全设备的检查概述

安全设备中只能看到谁攻击了，但是看不出来谁利用哪个漏洞进来的。因为黑客攻击成功了，意味着黑客绕过了特征库，即不会匹配规则和匹配规则中的记录日志功能。

但是在检查APT过程中发现了异样（安恒还是牛滴呀）：

到这里即会发现，除了一个恶意文件，啥也没有发现，该怎么兑现这个方法论？

“任何节点千万不要卡在自己这，一定要往前推进，想尽办法往前推进，如果不行，那你也是尽力了”

转折点-站在攻击者的角度

同时也算响应了”一切积累都是为了应对此类情况”这句话。

在以往可能受限于能力，可能就收场了，但是现在不一样了，我会信息收集了。

根据关键字进行搜索。

根据信息收集的结果进行测试，发现存在漏洞。

ps：其实哪有这么顺利，版本漏洞这块翻遍了搜索引擎：

致远-OA-A8-htmlofficeservlet-getshell-漏洞
致远OA-A6-search_result.jsp-sql注入漏洞
致远OA-A6-setextno.jsp-sql注入漏洞
致远OA-A6-test.jsp-sql注入漏洞
致远OA-A6-敏感信息泄露一-
致远OA-A6-敏感信息泄露二-
致远OA-A6-重置数据库账号密码漏洞
致远OA-A8-m-后台万能密码
致远OA-A8-m-存在sql语句页面回显功能
致远OA-A8-v5-任意用户密码修改
致远OA-A8-v5-无视验证码撞库
致远OA-A8-任意用户密码修改漏洞
致远OA-A8-未授权访问
致远OA-A8-系统远程命令执行漏洞
致远OA-Session泄漏漏洞
致远OA-帆软报表组件-前台XXE漏洞
致远OA-ajax.d前台未授权任意文件上传
致远OA系统多版本Getshell漏洞复现

沉住心，总结建议该怎么写

因为并不一定是通过这个洞进去的，也有可能是通过其他没有公开但是已在野利用的，因为服务器上并没有痕迹为此做支撑，因此需要建议客户：

1.开启访问日志记录，例如这个洞需要用到的URI就是漏洞指纹，虽然看不到POST数据，但是访问日志中会留下痕迹；

2.检查补丁安装情况，没有公开但是在野利用的，厂商肯定清楚；

3.禁止服务器访问互联网，例如这个漏洞的利用就涉及目标主机是否可以主动外联。

万变不离其宗

场景、事件就和人类指纹类似，不可能一样，那么如何应对不同场景的突发事件，唯有整理出适用于自己的一套方法论作为基础支撑才是最适用的。

IOC

45.76.99.222

8abaa521a014cdbda2afe77042f21947b147197d274bf801de2df55b1e01c904