内容简介：某云用户网站入侵应急响应
*本文原创作者：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原创奖励计划，未经许可禁止转载
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Ruby on Rails电子商务实战
Christian Hellsten、Jarkko Laine / 曹维远 / 人民邮电出版社 / 2008-4 / 49.00元
《Ruby on Rails电子商务实战》全面讲解了使用Ruby on Rails创建产品级应用程序的过程。书中通过演示构建网上书店的全过程，先后介绍如何使用如TDD的敏捷实践，启动一个项目并建立良好稳定的基础，如何深入Ruby on Rails，实现诸如将应用程序翻译成各种语言对产品进行调试等的普遍需求。其中用到的主要技术包括Ajax、聚合、设置标签和国际化等，还介绍了如何使用ActiveRec......一起来看看 《Ruby on Rails电子商务实战》 这本书的介绍吧!
