应急响应的基本流程二

应急响应大致可以分为五个部分，其基本流程包括收集信息、判断类型、深入分析、清理处置、产出报告。       

收集信息：收集客户信息和中毒主机信息，包括样本。

判断类型：判断是否是安全事件，何种安全事件，勒索、挖矿、断网、DoS等等。

深入分析：日志分析、进程分析、启动项分析、样本分析。

清理处置：直接杀掉进程，删除文件，打补丁，抑或是修复文件。

产出报告：整理并输出完整的安全事件报告。

勒索和挖矿事件，可以占比50%以上，而且这两种安全事件业务特征极其鲜明，因此可以单独提流程出来处置。

信息收集表

取证要素：取证并非毫无头绪的，病毒本身必然有网络行为，内存必然有其二进制代码，它要么是单独的进程模块，要么是进程的dll/so模块，通常，为了保活，它极可能还有自己的启动项、网络心跳包。

总之，可以归结为如下4点要素：流量、内存、模块、启动项。

流量分析可以使用Wireshark，主要分析下当前主机访问了哪些域名、URL、服务，或者有哪些外网IP在访问本地主机的哪些端口、服务和目录，又使用了何种协议等等。

例如，使用Wireshark观察到，主机访问了sjb555.3322.org这种动态域名，即可粗略猜测这是一个C&C服务器（如何判断一个域名是可疑域名，可以参考后文）。

有时候，可以根据网络协议来直接过滤分析流量。譬如，目前IRC协议已经很少被使用了，但利用IRC建立僵尸网络通道的现象仍比较普遍。使用Wireshark，直接在过滤条件里输入“irc”，回车看是否有相关流量。

如下图，刚好看到有相关的IRC协议流量，这便是可疑的。

Wireshark执行下“Follow TCP Stream”操作，查看到当前Botnet主机正在加入一个IRC频道。另外，也可以从目的IP下手，可查到这是一个恶意IRC僵尸网络服务器。

网络流量这块，如果具体到对应建立的连接，也可使用TCPView工具进行查看。如下，我们使用TCPView查到了2条连接：

chenyu-57068a53.localdomain.2671-> 170.178.191.191:6667

chenyu-57068a53.localdomain.2674-> amsterdam.nl.eu.undernet.org.6667

当我们分析病毒进程遇到困难的时候，其内存便是我们查找问题的最后一道防线。

以某Linux服务器应急事件为例子，如下图，我们找到三个病毒进程[ksoftirqd/7]的父子关系，可以看到，11275拉起了11276和11277，但11275是1号进程拉起来的，即init是其父进程。

这意味着，实际的父进程（原始病毒文件）在当前状态下是追查不到的了。

进程树已经追踪不到父进程了，能下手的地方不多。如反汇编[ksoftirqd/7]对应的病毒文件，则对于一次应急响应事件来说，时间是仓促的（不够）。但简单这样想，即不管病毒文件做了何种混淆、何种加壳，在最终运行于内存之上的代码上，终归是原始代码，至少堆栈就有不少信息。

Linux环境下dump内存，可以使用系统自带的gdb，键入命令 gdb attach 11275，attach到病毒进程11275，在gdb环境下，使用dump binary memory file start_addr end_addr将11275有效内存空间dump下来。

譬如：file为输出文件，可以指定为 11275.dump，start_addr是起始地址，end_addr是终止地址，例 dump binary memory /tmp/11275.dump 0x13838000 0x13839000 （这里仅仅只是举例，实际地址在gdb中获取）

对于内存文件11275.dump，采用命令 strings -n8 11275.dump，获取长度8及以上的字符串内容，我们发现有如下一行：

/etc/security/ntps.conf

这是在病毒运行内存里面发现的，要么是病毒配置文件，要么是原始病毒文件。

我们 cd /etc/security 并使用 ls -al查看内容如下：

可以看到，ntps.conf并非一个配置文件，它是可执行的（使用file命令可以知道这是个ELF可执行文件），文件修改时间应该是伪造的。 

本文始发于微信公众号（盾山实验室）：应急响应的基本流程二