【应急响应】Windows应急响应入门手册

0x01 应急响应概述

  首先我们来了解一下两个概念：应急响应和安全建设，这两者的区别就是应急响应是被动响应、安全建设是主动防御。
  所谓有因才有果，既然是被动的，那么我们在应急响应的时候就得先了解本次安全事件的起因，常见的有：

安全设备告警、数据被勒索加密、数据泄露在网上贩卖、网页被篡改、服务器CPU爆满卡死等。

  在应急响应的时候，你会发现一个非常有用的经验技巧，就是：一旦你能够确定本次安全事件的类型，猜测出攻击者或者恶意代码的攻击思路，然后去验证排查这些猜想，就会加速你的分析过程，而这些从事件起因中就能够获取到一些信息。

---

0x02 应急响应目的

我们在应急响应时大致有以下几个目的：

遏制事件发酵、找到恶意代码、分析入侵路径、整理入侵时间线、分析恶意代码行为以及追踪溯源。

而一般中间的四个为安全人员需要解决的主要任务：

• 找到恶意代码：通过各种动静态分析找到恶意代码、感染文件，进行取样然后清除。
• 分析入侵路径、入侵时间线：结合各类日志以及恶意代码本身，将有关证据进行关联分析，构造证据链，重现攻击过程。
• 分析恶意代码：找到恶意程序的特征，包括行为、释放的文件、网络通信等，从而得到识别、防御和删除该病毒的方法，使得我们的其他机器能够防得住该恶意程序的攻击。
• 解决问题，根除隐患，分析导致事故发生的系统脆弱点，并采取补救措施，恢复系统，使系统正常运行

追踪溯源不太现实，一般只追溯到攻击IP，这部分更多的是根据前面四个部分刻画出来的攻击者画像去搜索相关的威胁情

报。

---

0x03 应急响应流程

  应急事件处理流程一般包括：安全事件报警、安全事件确认、启动应急预案、安全事件处理、撰写安全事件报告、应急工作总结等步骤。
  这个是完整的应急流程，如果是甲方安全人员，一般就是按照这个流程进行应急。而乙方的应急响应，主要是在安全事件处理阶段，也就是应急响应，以及最后的撰写安全事件报告，应急响应第一步要先遏制影响，这个根据安全事件造成的影响大致有以下几种方式：

1. 网站下线（篡改、挂反标）
2. 断网隔离（远控后门、APT）
3. 流量清洗（DOS的进行）
4. 联系运营商（劫持类）

注意：断网隔离不是关机重启，电脑重启将会使内存丢失。
  当然遏制影响一般在我们之前运维人员就会采取相关的措施了，我们负责的是之后进行的安全事件处理以及撰写安全事件报告。我是属于乙方的应急，所以后面都是以乙方安全人员的应急响应来讲，主要的两个阶段：一个是安全事件处理，也就是应急响应：主要工作就是取证、溯源，这个我们后面详细讲。另外一个就是撰写安全事件报告，一般的安全事件报告包括如下内容：

安全事件发生的日期时间
参加人员
事件发现的途径
事件类型
事件涉及的范围
现场记录
事件导致的损失和影响
事件处理的过程
从本次事故中应该吸取的经验和教训

---

0x04 应急响应思路

  整个应急响应都是建立在恶意代码的基础上的，那么我们第一步就是找到恶意代码，针对常见的安全事件，结合工作中应急响应事件分析和解决的方法，总结了常规的入侵排查的检查思路。
检查思路：
  恶意程序需要进行网络通讯，内存中必然有其二进制代码，它要么是进程的 DLL /so模块，通常为了保活，它极可能还有自己的启动项，网络心跳包。
总之，可以归结为如下 4 点要素：网络连接，进程，启动项，内存再加上外部信息，如威胁情报，就可以形成比较完整的证据链。
检查方向：
  找到各种可疑的IP、进程、域名、URL，搜索相关的IOC，然后排查相关特征。

•   网络连接
•   进程信息
•   系统启动项
•   账号情况
•   日志信息
•   其他

现场分析：
  当发生安全事件时，我们去到现场首先需要先了解一些外部信息：

问题主机/服务器使用人员有谁？
一般使用时间段是什么时候？
是否重启过
查看杀毒软件、防护软件的查杀、隔离、告警日志。（如果有）
各种服务应用如：FTP、SSH、数据库、RDP，是否攻击者开启及是否存在弱口令。
网络中是否有防火墙、行为管理器等防御设备，查看相应告警。

  一些安全人员去到现场后就直奔问题主机去了，然后各种分析，忽略了这些信息，因此列出来做个记录。

---

0x05 取证溯源

  前面分析完思路以及记录需要了解到的一些外部信息，都是为了我们的关键环节取证溯源做准备。当然思路归思路，由于安全漏洞不是存在于特定的场景或应用，Web应用可能存在漏洞、软件程序可能存在漏洞、我们使用的操作系统也可能存在漏洞，因此实际的安全事件，我们需要尽可能的检查到每一个薄弱点。而不是网页篡改就只检查web应用、挖矿木马就只排查恶意程序。
  检查得越多（做好记录），后面整理报告的时候越有用，经常遇到的是应急只有几个小时的，然后没有做好记录回去无法写报告，只能再找客户联系。

5.1 网络连接

  网络连接一般适用于远控后门类的应急事件，这类事件的相同点就是有持续或半持续性的网络连接。一般是找境外IP或不常见端口。有时也会是恶意域名。常用工具：TCPview、火绒剑、DNSquerysniffer、apateDNS、Wireshark
举例：
异常端口（图中工具-TCPview）

异常路径（图中工具-火绒剑）

Dll发起网络连接，本身没有什么异常，但是从这个dll文件的路径，我们还是可以判断出这个dll是有问题的。

域名解析

  网络连接还有一种情况，就是域名解析记录，有时候我们在安全设备上发现的告警，是某一台设备请求了某个域名，而这个域名是已经没有在用的了，也就是说不会解析成功，这个时候我们是看不到又任何的网络连接情况的，那么我们就需要查看本地的域名解析记录，这里我们使用DNSQuerySniffer来查看。

PS：结合火绒剑或者PChunter即可定位到具体进程。

5.2 进程信息

  病毒文件在系统中运行必定依赖于可执行程序，主要有三种模式在系统中运行：

• 病毒本身是exe程序
• 注入到系统程序
• 其他方式

思路：重点检查没有厂商名字、没有签名验证信息、没有描述信息、CPU 或内存资源占用长时间过高的进程。检查可疑进程的属主、路径、参数是否合法。常规的使用命令tasklist
工具：Process Explorer、火绒剑、PChunter
  下面是我之前做的一个测试，用MSF生成的一个后门程序：yu.exe，可以看到，这个进程与正常的进程，少了厂商信息、没有签名、也没有描述信息。通过这些对比，我们就可以快速的筛选出一些的进程，然后再分析这些进程加载了什么dll、使用了什么模块，分析是否存在异常，从而判断该进程是否为一个恶意的进程。

下面就用这几个工具，来讲一下应急响应中我们如何排除一个进程是否是恶意进程。

• 5.2.1 Process Explorer

进程浏览器，列出所有当前活跃的进程、被进程载入的DLL、各种进程属性和整体系统信息。
主要用于：查看进程的签名信息、进程的字符串信息、搜索加载恶意DLL的进程、分析恶意文档、通过属性窗口中的镜像（Image）标签来定位恶意代码在磁盘上的位置。

1. 查看进程加载的dll文件：

  然后有个可以快速判断加载的dll文件是否正常的办法，就是路径。正常的dll文件都是在C:\Windows\System32目录下，当然还有其他几个系统目录，我们要找的就是路径不对，名称可疑的。路径不对可以很直观的看出来，但是有时候路径没错，然后名称是不对的，比如正常的是Kernel32.dll。然后恶意程序把自己的dll文件命名为Kerne132.dll。

2. 查看进程中的字符串信息：

  有时候进程的网络通讯是间歇性的，所以有可能在我们查看的时候他是正常的，而到了特定的时间他才会执行相应的网络请求。这个时候我们可以看一下这个进程的字符串信息，在字符串信息中，我们有时候可以看到进程调用的Windows API函数和一些IP、URL，或者一些命令行的提示信息，通过看到的一些api函数，来猜测这个进程的功能：比如写入注册表、遍历文件目录、创建进程等。

• 5.2.2 PChunter

这个是一个比较底层的工具，可以看到进程启动的参数。
用得比较多的是用于查找隐藏的文件和目录。

• 5.2.3 火绒剑

  这里利用火绒剑查看这个svchost加载的dll文件，可以看到有两个异常的dll文件，虽然有公司名和描述，但是这个描述额、、有点随意，而且查这两个dll文件的路径，在Windows的tmep文件夹下，那么我们也可以猜测这两个dll文件是恶意的dll文件。

实验测试：进程注入

  以MSF生成的后门程序为例，使用MSF进程注入功能，利用migrate命令将后门注入到其他进程：

TCPView检测网络连接，根据可疑进程名和可疑网络连接可以定位到meterpreter后门进程：

但是查找对应的PID找不到相应的进程：

这个时候可以使用PCHunter，这个比较底层的工具。查找对应网络连接可以直接查到对应进程路径：

加载后，你可以开始搜索Meterpreter使用的关键指标，如ws2_32.dll和metsrv.dll。ws2_32.dll是用于处理网络连接的Window Sockets Library，而metsrv.dll是默认的Meterpreter服务。这两个dll是用于网络连接的，而everything这个进程是没有网络连接的，但是却调用了这两个dll文件，那么就有问题了。
  针对MSF的后门，这里再推荐一款工具：Meterpreter_Payload_Detection.exe，可自行在GitHub上搜索下载。
  利用Meterpreter_Payload_Detection.exe检测工具，通过扫描内存检测Meterpreter无法检测的有效负载。缺点就是运行时间比较久。

5.3 启动项

思路：检查启动项、计划任务、服务
这个我一般就检查三个地方：
1.【开始】>【所有程序】>【启动】:

2. 计算机管理:

3. gpedit.msc:

检查启动项这里推荐使用Autorun这款工具，上面的检查项都可以用这个工具查看到，只是一些启动项的路径还是需要大家熟悉一下，因此还是讲一遍：

可以看到，利用这个工具，我们能直观的看到启动项执行的命令、启动的脚本、参数等。

0x06 需要取证的点

1、系统日志、网站访问日志（搜索log文件）、本地用户情况（是否有隐藏、克隆用户）。
2、保存系统当前信息：

systeminfo >c:\Temp\sysinfo.txt
netstat -ano >c:\Temp\net.txt
tasklist >c:\Temp\task.txt
net user >c:\Temp\user.txt
xcopy %systemroot%\system32\winevt\logs\*  C:\Temp\eventlog

3、使用Process Monitor、Autorun、Tcpview等工具，保存记录文件。PClog和Process Explorer选择性保存。
可在现场简单检查，把可疑的程序打包回来分析。
4、检查webshell结果（最好能把网站整个文件夹拷贝回来）。
因为jsp后门删除了还会有.class缓存保留，命名方式为_xx__jsp.class，可恢复。
5、系统内存、镜像
Readline、DumpIt（这两个都是适用于低内存系统）,电脑重启将会使内存丢失。
将以上几个需要取证的数据打包回来事后分析。
☆注意：所有软件都必须以管理员身份运行。
最终，我们在一次应急响应中需要拷贝回来取证的有如下文件（包括但不限于）：

日志如果被删，建议整个文件夹拷贝回来。

笨鸟先飞早入林，笨人勤学早成材。

转载请注明出处：
撰写人：fox-yu  http://www.cnblogs.com/fox-yu/