记一次Windows下的应急过程一、概述在一个夜黑风高的夜

一、概述
在一个夜黑风高的夜晚，正在酣眠突然手机响起，电话那头传来了同事焦急的声音。某用户服务器被入侵了，需要进行调查取证，但是关键数据已经被运维人员删除，需要我们协助处理一下……
作为一个经验的（上了年纪的）安服工程师，接到这个电话后就在也睡不着了，数据被删除了，明天我去现场能干什么？带着这个问题我翻开了被尘封在角落里N年的一遍关于数据恢复的书《数据恢复技术深度揭秘》，已知条件为：目的服务器是WindowsServer2008被删除文件名为：shell.jsp带着这几个问题，重点看了windows系统相关书数据恢复内容如GPT磁盘分区等。以上内容并非工作需要或者想真正获取到什么东西，而是为了自己在没有找到任何线索的时候能够给出一个专业的答复而准备的答案（换句话说其实就是吹牛先打下的草稿）
二、检查到了现场发现基本确定了下面几条信息：
1.公网某个系统存在struts2漏洞，且漏洞监控人员发现已经有人对该漏洞进行利用，上传了名为shell1.jsp的后门文件。
2.通报的后门文件已被运维人员删除（在接到通报后的第一时间被运维人员删除）
3.由于内部原因必须找到被删除的后门文件
==================分割线===============
在这里我思考的第一个问题是，监控人员可以通过一个Struts漏洞就可以发现攻击者上传的后门？而且还提供了连接的截图。。闪过这个念头我得出的第一个想法是系统应该不止一个后门，因为运维人员在进行恶意文件删除的时候肯定只是删除的通知中给出的文件。
相对此处，便拿出万能的D盾，先扫一波，由于当时开发运维不再现场，应用目录用户无法确定，因此我就指定整个D盘为扫描对象，结果确让人意外，可疑文件找到很多，后门文件找到两个，其中一个是已经被开发人员删除了的文件，临时保存在回收站。

文章图片
查看shell后门文件后发现基本都是一些种后门的操作，部分内容如下：

文章图片

文章图片

文章图片

文章图片
查看对应的后门文件路径后果然发现st.exe后门文件
通过在线沙箱分析st后门结果如下：

文章图片
程序回连地址如下：

文章图片
基本可以确定目标站点是一台僵尸主机。

文章图片
文件内容如下：

文章图片

文章图片
文件丢入沙箱分析结果如下：

文章图片
程序使用地址如下：

文章图片
【记一次Windows下的应急过程】矿池地址如下：

文章图片
完全确定服务器沦陷，且被人种下挖矿程序。在服务器端查找对应内容如下：
攻击者在服务建立用户

文章图片
服务器系统目录下发现子系统文件夹，且目录下众多恶意文件不在一一分析。

文章图片
服务排查过程中发现系统服务中已存在挖矿软件启用服务

文章图片

文章图片
分析过程中发现一个值得思考的问题：

文章图片
如果不良攻击者使用了你编写的webshell攻击了服务器，对方报警后通过webshell备注的作者信息溯源到了你，你是否承担责任呢？