内容简介：某云用户网站入侵应急响应
*本文原创作者：feiniao，本文属FreeBuf原创奖励计划，未经许可禁止转载
1 情况概述
该案例是前期应急处置的一起因安全问题导致的内网不稳定的情况。写下来，和大家一起讨论应急响应的一些思路及其中间遇到的一些坑，欢迎大牛指点、讨论。
情况是这样的： 某用户发现在网络经常出现内网中断的情况，经其内部分析，初步判定可能为其在云上的一台虚拟服务器 (Linux)异常导致，但是前期对这台虚拟主机进行常规的安全检查与数据包分析，并没有发现其有异常情况。但是用户发现只要这台虚拟主机接入网络就会不定期出现内网中断。该服务器对外只开放 ssh和80。用户为保证其他服务器的安全及可用性，把这台虚拟主机给下线了，但是这台虚拟主机是否存在异常？为什么接入网络会导致中断？在初步分析没有结论的情况下，我方介入协助分析。
2 整体分析
2.1 数据包分析
2.2.1 与183.61.171.154异常交互
我方介入后，根据实际情况，将这台异常虚拟主机全部拷备放到一台暂时没有使用的服务器中，前期考虑可能是发送恶意报文导致某用户内网服务器中断，所以前期采用的方法是对这台虚拟机的流量进行抓取分析，但是在抓取一段时间后，并没发现异常。考虑到可能是不定期发包，因此决定进行长期抓包与系统全面分析的方法进行分析。 下面是我方进行抓包分析情况：
| 抓包情况 | 全量抓取 |
|---|---|
| 抓取日期 | 2016 年 10 月 26 时 16:07 至 2016 年 10 月 28 日 14:35 |
| 抓包总时长 | 1 天 22 小时 27 分钟 |
| 包总大小 | 75.3M |
| 虚拟主机 IP 地址 | 192.168.61.130 |
抓了近两天的数据包，总共包大小为75.3M，从数量上看，包的数量相对较少，应该没有进行大流量攻击行为。继续深入分析数据包:
从数据包中发现有一处报文交互存在可疑，对其深入分析，发现在2016年10月27日13:55:50时这台虚拟主机主动外连183.61.171.154这台主机的5896端口，并下载了一下bc.pl的文件，其源端口为37568，但是由于分析时，该端口已无会话信息，所以无法分析当时是哪个进程。下面是这个过程的情况：
报文交互过程
| 时间 | 2016 年 10 月 27 日 13:55:50 |
|---|---|
| 源 IP | 192.168.61.130 |
| 源端口 | 37568 |
| 目的 IP | 183.61.171.154 |
| 目的端口 | 5896 |
| 下载的文件 | bc.pl |
| 文件类型 | Perl 文件 |
| 安装目录 | /tmp |
| 文件权限 | 644 |
交互信息
文件存放路径
对 bc.pl 文件查看，其源码如下：
bc.pl源码
根源源码分析，其使用有 socket 函数，并定义一些 remoet_ip,remote_port 等关键字，初步判定其为一个用来进行远程控制用的恶意文件的部分文件。但是其文件权限为 644 ，并没有执行的权限，也就是说这个文件只是下载下来，并没有被执行，即使恶意程序自动下载，但是没有赋予相关执行权限，通过外部暂时无法控制这台主机，但是如果恶意程序存在，其同样可以赋予执行权限，然后再通过公网进行控制。但是也不排除黑客执行完这个文件，然后再把权限降低的可能性。
对 183.61.171.154 这个目的 IP 进行分析，发现其存在被僵尸网络控制等情况，这台主机可能并不是真正的原始攻击者，攻击者通过这台主机作为跳板来攻击其他主机。但是我们对这个 IP 的分析，可以证明上面的会话的确存在异常。
对其反向 DNS 解析，分析曾经有哪些域名挂在这个 IP 上，可以看出这个 IP 频繁的更换其对应域名，说明这个 IP 对应的主机可能早已被黑客控制，用来进行黑客行为。下面是其反向 DNS 信息汇总：
继续深入分析，看看183.61.171.154这台主机上是否存在恶意文件，通过下图可以看出183.61.171.154这台主机存在较多恶意脚本。
183.61.171.154存在恶意样本分析
通过上面分析，可以看出 183.61.171.154 这台存在恶意脚本，判断为被黑客控制的机器，黑客使用这台作为跳板来入侵其他设备，因此某用户外连这台主机并下载 bc.pl 这个文件，通过各方面综合分析，判定 bc.pl 是一个用来进行远程控制的恶意文件。
2.2.2 与65.118.123.162异常交互
直接分析 HTTP 数据包，发现除了上面介绍下载的 bc.pl 文件以外，还有大量的 HTTP 请求，请求的内容都为外连一个 pl 文件。
异常交互情况
提取相关信息，汇总如下：
| 源 IP | 192.168.61.130 |
|---|---|
| 源端口 | 较多，不固定 |
| 目的 IP | 65.118.123.162 |
| 目的端口 | 80 |
| 下载文件名称 | mgetemetar.pl |
| 文件类型 | Perl 文件 |
上图可以看出 65.118.123.162 这个 IP 存在被僵尸网络及威胁流量的情况。和上方一样，这个 IP 可能也不是黑客真实的 IP ，黑客控制这台主机，然后再通过 65.118.123.162 这台作为跳板，再入侵其他设备。
继续对65.118.123.162深入分析，反向DNS查看一下，可以看出这台主机位于美国，并且其域名在不断变更。
通过上文，我们可以看出某用户的这台服务器不定期与65.118.123.162这个存在被僵尸网络控制的主机进行交互，并且都是Get 其一个 pl文件。通过对目标主机进行分析，判断该会话为恶意交互，但是因为抓包时，没有及时分析该端口所对应的进程，所以暂时没有办法分析是哪个程序导致。后期如果需要分析，可以进行实时抓包，找到该端口号所对应的进程 ，然后把该进程杀掉即可。
2.2 可疑文件分析
根据上面的分析，发现在 bc.pl 存放在 /tmp 目录下，对这个目录下的分析进行分析，发现几个可疑文件：
直接cat这个文件，可以发现一些很有意思的事情：
1. 直接把主机防火墙关闭
2. 从123.249.7.198:8831上下载 123这个文件
3. 赋予123这个文件 777 的权限
4. 执行123这个文件
这里面可以看到黑客通过这个脚本下载并执行123这个文件，如果存在123这个文件，可以说明 cmd.n 这个文件是有执行的权限的，但是通过上文我们可以看到cmd.n这个文件并没有执行的权限，这可能是黑客相对聪明的地方，执行完以后把这个文件降点权限。一方面可以迷惑分析者，另一方面不会被其他黑客来控制。我们接着来分析，既然黑客下载并执行了 123 这个文件，那么在系统中肯定存在这个文件，我们来查找一下：
查找找到 123 这个文件，在根目录中，直接进根目录中查找分析，发现除了 123 这个文件，还有 1 、 123123 、 1253 这三个文件名非常类似，但是 123 这个文件 cat 不了，直接下载下来，丢到分析平台中分析。
可疑文件
通过杀软平台分析，基本上判定该文档存在病毒：
杀毒分析情况
同样，对其他文件进行查杀，结果如下：
| 文件名 | 文件路径 | 上传时间 | 文件权限 | 创建者 | 是否存在病毒 |
|---|---|---|---|---|---|
| 1 | / | 2016 年 10 月 15 日 9:16 | 755 | root | 是 |
| 123 | / | 2016 年 10 月 29 日 11:54 | 777 | root | 是 |
| 123123 | / | 2016 年 10 月 15 日 9:24 | 755 | root | 是 |
| 1253 | / | 2016 年 10 月 15 日 14:58 | 777 | root | 是 |
运行进程分析
对 10 月 17 号这段时间上传的文件进行导出分析，发现另外一个文件 conf.n ，通过上传时间分析，其也是 10 月 17 日 1 点 25 分上传上去的。在这段时间上传有两个文件，一个为 cmd.n ，另一个为 conf.n ，已分析 cmd.n 为一个异常文件，那么我们推断 conf.n 这个文件肯定也为恶意文件。
这个文件位于 /usr/bin/bsd-port/ 目录下，直接查看这个文件，发现文件做过特殊处理，无法直接查看。直接 google 一下，看是否有相关资料，果然有被这个马搞过的案例。至此，我们已经没有必要继续分析了，基本上可以判定 conf.n 是一个恶意文件。
Linux conf.n 木马
继续看看其他目录是否还有conf.n这个文件，一共找到四处存在，其中两处我们已经分析过了，另外两处做了初步分析，基本上判定也为异常文件，建议直接杀掉。
那么黑客是如何上传这几个恶意脚本的呢？目前根据某用户具体情况，要么是系统，要么是网站。下面我们来对系统和网站进行全面分析。
2.3 系统用户分析
对系统用户进行分析，某用户这台服务器一共存在 39 个账号，对其账号、权限、组等进行分析，初步判定没有账号异常情况。
/etc/passwd文件分析
/etc/shadow文件分析
2.4 webshell分析
系统层面没有问题，那么最大的可能性是网站了。针对网站最大的攻击，主要是通过 webshell 来上传恶意文件。我们首先对 webshell 来进行分析：
使用webshell专杀 工具 对某用户web服务器的内容进行扫描，中间并没有发现存在 webshell, 但是并不能说明某用户的网站没有存在过webshell，有的webshell具有自毁功能，并且通过上面分析，我们可以看到这台服务器已经下载了 bc.pl 这个远程控制脚本，通过这个脚本，黑客已经可以远程控制这台服务器了，根本不需要webshell了，这只是我们的推论，我们需要通过日志分析来验证我们的推论。
2.5 日志分析
下面我们来对日志进行分析，日志包括两部分，一部分为系统日志，另一部分为网站日志：
2.5.1 系统日志
分析 /var/log/secure 文件，发现其系统日志无异常。
2.5.2 对网站扫描
对weblogic的日志进行分析，发现在8月31 号的时候172.17.4.179对这台服务器的web服务进行漏洞扫描。但是因为做了 NAT ，分析到的源IP为内网IP，无法追溯到真实 IP地址。
2.5.3 10月17日日志部分被清除
由于黑客上传那几个恶意文件的时间为10月17日，我们过滤这天的日志来进行全面分析，看看是否从中可以找到蛛丝马迹，但是当我们把时间定格在 1:25分左右的时候我们发现17号的日志很大一部分被清除了。为什么这段时间的日志会被清除？我们不禁想到， 黑客已经在这台服务器上下载了用来进行远程控制的脚本，已经不再需要 webshell 了，同时为了更好的隐藏及保护后续持续控制，黑客把 webshell 给清除。
另外，我们再辅助对系统会话，主机hosts、历史命令进行分析，看看是否还有其他发现。
2.6 系统会话分析
对其正在建立的会话进行分析，我们主要分析基于 TCP 的会话，发现目前存在三组 TCP 会话：
对这三组会话进行分析：
Ø 123.57.150.237
可以看出其程序为123这个程序调用，上文我们已经分析出123为一个病毒文件，因此该会话一定为异常交互。
Ø 208.185.115.120
Ø 165.254.12.197
后面这两组都为clock-applet这个程序发起的，clocl-applet这个程序存在于 /usr/libexec 这个文件夹下面。
对后面两组会话抓包分析，其交互过程如下所示，可以看出它们都是和 weather.noaa.gov/cgi-bin/mgetmetar.pl 这个文件交互，上文我们已经分析到和这个域名的交互情况，可以判断该交互为异常交互。建议把 clock-applet 文件清除。
2.7 主机hosts文件分析
主机 hosts 文件用来静态保存主机 / 域名对应的 IP 情况，默认情况下 DNS 解析时首先查 DNS 缓存，然后再查本地 hosts 文件，最后最进行 DNS 解析。如果 Hosts 文件被篡改，很容易进行 DNS 欺骗攻击。对某用户这台服务器进行分析，并没有发现 hosts 文件存在异常。
2.8 历史命令分析
History 命令集可以反映出当时黑客执行的命令情况，如果 history 从全部保存，可以很好的对入侵进行痕迹分析，对某用户的历史 history 命令进行分析，由于数据被覆盖，所有并没有发现黑客操作的痕迹。
部分 History 历史命令集
3 入侵过程梳理
经过近两周的搭建环境、抓包与分析，基本上梳理清楚此次事件的来龙去脉。对此次事件的整个分析过程如下：
1、2016年10月 17日1点25，黑客上传 conf.n 和cmd.n两个恶意文件
2、黑客执行cmd.n并且下载123这个文件并且执行
3、123创建恶意进程，不断连接一个mgtermetar.pl 文件，但是没有连接成功。
4、本机主动外连并且下载bc.pl文件，这个文件为一个用来进行远程控制的恶意文件。基本上判定该服务器已被黑客控制
但是，黑客是通过什么途径上传cmd.n和conf.n这两个文件的？
上传的途径要么通过系统，要么通过网站。通过对系统日志和系统用户的初步分析，并没有发现异常的情况。我们推断为通过webshell来上传这两个文件的。虽然我们并没有查杀出网站存在 webshell ，但是通过以下证据可以在侧面验证我们的推论：
Ø 对外只有两个途径可以上传，系统和网站
Ø 系统分析，并没发现异常
Ø 发现上传这两个文件当时的web日志被清除
Ø 通过前期日志分析发现存在很多针对网站的扫描行为
Ø 系统已经下载了可用来进行远程控制的脚本，黑客无需再利用webshell，为了更好的隐藏及维持后期控制，把 webshell清除了。
那么，分析至此，但是还存在一个问题：用户反馈的是其内网经常中断，似乎与分析的结论并不吻合。但是考虑到用户的环境为云环境，其带宽、性能资源非常丰富，加上正常情况下，黑客入侵某一台服务器后，大都会进行内网渗透，内网渗透的话可以中间人、扫描等方式，如果人间人或者扫描的话很大可能会导致其内网不稳定。当用户把这台服务器下线后，内网一直正常，正好吻合我们的猜测。
4 总结
1、处理此次事件中间遇到好多坑，如网站日志被黑客删除、没有发现webshell、用户的内网中断现象偶尔出现等都是分析的难点。在应急的过程中经常会遇到这类问题，最多的就是 web 日志只放在服务器上，但是被黑客删除了，这样的话就为我们的分析取证带来很多的难点。在遇到这类问题时，需要想方设法利用现有的资源去分析。
2、严谨推理、大胆猜测。在分析过程中遇到的各个断点的情况，需要根据现有的资源进行大胆猜测。
3、连点成线，我们在分析时可能遇到最多的情况就是解决了一个一个的点，如发现存在webshell、存在可疑账号、存在可疑IP 等，我们需要把这些一个一个的点连成一条线。
4、应急响应不是渗透测试，需要根据现有的信息分析黑客是利用什么漏洞入侵的、入侵的IP、时间、并且入侵之后做了什么等。因此我们在应急响应时不要搞反主次，把应急响应当成渗透测试。
5、应急响应分析不仅仅局限于web这一块，系统这一块同样需要分析。如其账号、连接、进程、安装程序、自启动程序等。
6、善用外部资源，如威胁情报、社工库、开放的沙盒，用好外部资源可能会有意想不到的收获。
7、欢迎大牛指点、讨论。
* 本文原创作者：feiniao，本文属FreeBuf原创奖励计划，未经许可禁止转载
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Machine Learning
Kevin Murphy / The MIT Press / 2012-9-18 / USD 90.00
Today's Web-enabled deluge of electronic data calls for automated methods of data analysis. Machine learning provides these, developing methods that can automatically detect patterns in data and then ......一起来看看 《Machine Learning》 这本书的介绍吧!
