一次云上病毒事件的应急响应——阿云的阿里云安全技术实践（1）

[TOC]

一点惆怅

自打从老东家辞职后，阿云加入了一个新兴的互联网企业。新、老公司运维模式完全不一样，这里没有 IDC 机房，也没有传统的防火墙，更没有天天“救火”的匆忙。作为一名信息安全工程师，阿云的日常工作就是保障公司租用的阿里云基础设施和云上业务系统的安全。

似乎云平台解决了所有的安全问题，阿云已经好几个月没有和黑客正面对抗了。这让他有些惆怅，心生倦怠，他甚至怀念起了以往与“黑产”正面厮杀的场景。

重燃烈火

“防狼”的日子一天天过去，到了秋季，准确地说是2018年9月31日——一个平淡得不能再平淡的上午。正在浏览vipread.com（不是广告）的阿云，看到任务栏弹出一则钉钉消息：“安骑士主机异常事件：木马程序”。久不高速运转的脑神经，突然一阵抽搐。3秒钟过后，阿云的脑回路重新激活。“来活了！”阿云朝身边的其他战友喊道，脸上似乎带着些快意。

阿云再次喊道：“开发环境，192.168.0.3可能中木马了，赶紧给看下！”

负责主机安全事件的余老师因为临时被叫去参加一个会议无法立即协助，好在组织内部分工明确也协作有序，替补人员大鹏哥立即响应：“我登上阿里云控制台了，正在看！”

“svchost.exe，系统进程么？会不会是安骑士误报啊？”大鹏哥淡淡地说。话音刚落又是一条消息：“安骑士主机异常事件：DDoS木马”，还是192.168.0.3。紧接着又是一梭钉钉消息！

192.168.0.4,192.168.4.4,192.168.4.10,10.0.3.19都有告警，看来不是误报，是沦陷！

阿云的额头开始冒汗，老司机这回要翻车了？

稳住，我们能行！

阿云所在的团队总共五个人，当时能参与事件响应的只有三个人：阿云、大鹏哥和小明。

此时，团队已经兵分三路开工了。

大鹏哥和各个系统的维护人员比较熟悉，第一时间联系到相关责任人，对阿里云上的多台服务器的用途和状态立即做了确认，之后配置安全组规则快速执行了网络隔离。
小明早已开始通过外部威胁情报渠道，查询本次安全事件背后的关联信息。
远在会议室开会的余老师开上了小差，和一些重要部门的同学就服务器近期访问情况进行讨论并启动日志分析。
阿云自己则开始快速查询日志，进行事件关联性分析。

工作在争分夺秒地开展，时间在缓慢地流逝，办公室里突然安静了许多。接下来还会不会有更多的服务器沦陷？没人敢说，也不看敢想……

初现端倪

通过查询微步威胁情报，小明发现目标文件已经被多款杀毒软件识别为恶意软件。看来这是真中招，不是误报。

大鹏哥这边也有发现！结合阿里云安骑士告警，再登录受感染服务器查询，大鹏哥发现服务器上有个可疑的文件目录：C:\Windows\SpeechsTracing\Microsoft\。通过互联网搜索，发现已经有相关安全报告涉及到这个未知文件和目录，可能和虚拟货币“挖矿”有关。参考FreeBuf《【安全研究】关于挖矿蠕虫Wannamine2.0的研究分析》，病毒大概逻辑是这样的：

扫描同网段存活的445端口，并启动程序逐个发起攻击。
攻击阶段一：启动svchost.exe > stage1.txt（c:\windows\SpeechsTracing\Microsoft\svchost.exe ）执行端口扫描
攻击阶段二：启动spoolsv.exe >stage2.txt（c:\windows\SpeechsTracing\Microsoft\spoolsv.exe ）执行漏洞攻击

现在，阿云的团队至少知道这些服务器中的是什么招。受感染主机均已经被隔离，局势暂时有所缓解，但阿云还有几个问题没有解决：

还有哪些主机被攻击过？（漏报）
有没有被攻击但没有被告警的主机？（漏报）
病毒最初是从哪里进入服务器的？（怎么死的）

其中第三个问题最为重要，也是阿云的口头禅：“‘不知道是怎么死的’往往最可怕！”

事件回溯

为了搞清楚到底还有哪些主机被攻击或沦陷，阿云团队开始了事件日志回溯工作，主要是如下思路：

通过阿里云【态势感知】|【主机进程快照】，找到运行过svchost.exe或spoolsv.exe的主机
通过阿里云【态势感知】|【网络连接日志】和【网络会话日志】，找到所有445端口连接或被连接的行为
登录所有已经沦陷主机，查询c:\\windows\\SpeechsTracing\\Microsoft\\目录下的stage1.txt和stage2.txt，确认曾经被扫描或攻击的日志。

通过阿里云控制台进入【态势感知】|【更多功能】|【日志检索】，可快速查找网络连接信息和网络会话信息。

如下图所示，通过查询可以发现主机192.168.0.3的确有过连接192.168.0.4TCP 445端口的记录。

基于上述统计信息，统计出病毒爆发前后1小时内所有445访问行为，阿云所在安全团队拿到了病毒在内网进行端口扫描的所有记录。为了进一步佐证攻击事实，大鹏哥登录多台服务器，逐个确认 stage1.txt和 stage2.txt，看是否有攻击程序遗留的记录。果然在192.168.0.3服务器上发现了 stage2.txt中保留的攻击192.168.0.4的记录。同时，在192.168.0.4服务器上也找到了同样的攻击程序和文件目录。

通过态势感知后台查询安骑士进程快照信息，可以获悉到哪些主机曾经执行过恶意进程，从而判断具体哪些主机已经沦陷。

攻击还原

结合上一环节使用的阿里云态势感和安骑士日志，阿云所在的安全团队掌握了充足的信息。经过一番梳理，基本可以确定：

哪些主机连接过 TCP 445端口
哪些主机被连接过 TCP 445端口或在 stage2.txt中出现过（被扫描和攻击过）
哪些主机执行过恶意进程（已沦陷）
哪些主机在 stage1.txt中出现，但是在 stage2.txt中未出现（开放端口，但攻击失败）

当年追踪羊毛党推荐关系链时用过的工具Graphviz再次派上用场。阿云将主机访问信息输入到绘图工具 Graphviz 中，得到下面的访问或攻击关系图。

其中红色实线表示成功攻击，棕色表示发起过攻击但未成功（来源于 stage2.txt），黑色虚线表示至少发起过端口扫描的连接尝试（态势感知日志和 stage1.txt）。

未完的故事

至此，阿云所在的安全团队算是搞清楚了本次病毒事件的基本时间序列。从安骑士的告警信息来看，本次病毒攻击事件几乎没有误报和漏报。阿云心中多个疑惑都已解开，唯独还有一个问题没想明白：“第一台服务器192.168.0.3是如何感染病毒的？”

是啊，病毒是怎么进的云服务器？这真是个头疼的问题，阿云想了很久，没有答案，头痛的厉害，醒来了……“唔，做梦吗？”

想知道这个问题的答案吗？关注我，且听下回分解~

附：Graphviz 绘图源码

digraph G {edge[style = "dotted" color="brown"] "192.168.0.3"->"192.168.0.6""192.168.0.4"->"192.168.0.201""192.168.4.4"->"192.168.4.227""192.168.4.19"->"192.168.4.227"edge[style = "solid" color="red"]"192.168.0.4" -> "192.168.4.4""192.168.0.4" -> "192.168.4.19""192.168.0.3" -> "192.168.0.4""192.168.4.4" -> "10.0.3.19"edge[style = "dotted" color="black"]        "192.168.0.4" -> "192.168.0.7""192.168.0.4" -> "192.168.0.13""192.168.0.4" -> "192.168.0.109""10.0.3.19"->"10.0.3.1\n10.0.3.2\n10.0.3.7\n..."}

首发于 VSRC 公众号：https://mp.weixin.qq.com/s/fVXr-mTx1lob03vVzI7Bpw