本文为整个专题的第四篇，中间跳过了原计划的“内网横向移动攻击模拟（下）”。原因是下与上的类型一致，均为攻击模拟的记录，可分享和讨论的意义不大，只要按照这种模式可以设计出更多的场景。继而，继续编写本专题后续的内容。
'''
01
—
靶场环境分配
靶场搭建在VM虚机中，在红队完成攻击模拟后制作镜像快照，然后导出分发给每一个应急响应小组。
02
—
应急响应时间
每个专题分析一周，各小组一般都是在下班后及利用周末时间进行分析。整个应急过程，加上报告编写及汇报材料准备，平均每个专题花费十天。
03
—
应急响应流程
在真实场景中，应急响应的情况多种多样，比如遇到勒索病毒、挖矿程序、网页篡改、DDOS攻击、CC攻击等，对应的响应流程也会不同。就本专题而言，两次攻击模拟均是由已知漏洞引发，最终目标被植入挖矿程序，故应急响应流程也一致，可归纳为如下：
3.1 概况沟通
在上机动手操作前，有两个事项需要完成。首先是了解被攻击前后的情况，包括在被攻击之后，需要明确：
- 业务的异常表现：是ssh连接不上服务器，显示多余提示如联系外部邮箱进行解密；是通过运维软件，监控到服务器CPU飙升并一直超过90%不下；还是业务某个页面图片或文字被篡改……尽可能的问清楚异常，从而可以迅速判断出具体的攻击类型；
- 已经进行的操作：是否有人做过止血操作，比如关闭服务停应用、拔网线断网、关机，又或是已经有人登录机器并上传了工具扫描……尽可能的了解清楚每个动作，从而区分原有的攻击行为和应急带来的干扰，以及在此基础上继续进行分析；
还包括被攻击之前的以下信息：
- 业务基础环境：业务的IP、所在网段；业务所用的操作系统、数据库、web容器等名称与版本；业务所用的开发框架、开源组件、所用开发语言；对内外开放的端口、业务系统间交互的接口；
- 业务防护水平：业务的系统日志、应用日志、用户操作日志是否有记录；是否有NTA、主机安全、应用安全等设备进行防护；是否进行过安全测试、日常的漏洞扫描与修复；
- 业务变更情况：是否进行过变更，变更的内容是什么；是否由于变更功能引起的业务功能异常而不是攻击；是否由于新增功能导致的攻击事件。
但是在本专题中，主要涉及“业务的异常表现、业务基础环境”，其余部分不适用。
3.2 环境备份
在上机动手操作前，第二个必要项是环境备份，进行镜像克隆或备份是最简单有效的做法。
很多组的同学拿到机器就上手分析，一顿猛如虎，包括看日志、拿着攻击工具做漏洞利用复现以分析攻击思路后，导致有的日志被冲刷了，留下很多自己的操作痕迹。
3.3 上机分析
在分析过程中，需要结合基础环境信息、业务异常情况等，进行大胆假设与小心求证。通常可以采用以下两种方法：
- 按部就班取证分析法：对系统账号登录、数据库、应用（至少包括access、error）等日志进行采集与分析；对系统定时任务、系统账号、历史执行命令记录、异常进程、近期文件变更等进行分析……无论是什么类型的攻击事件，均有一套标准化的采集项与分析流程。这种场景一般是乙方安全公司做应急响应服务时的常规操作，降低了应急难度，提升效率。然而在本专题中，考量或锻炼的就是这些自动化的能力变为手工化，应急同学不能使用现成的自动化工具，只能自己写或使用功能单一的开源工具；
- 从业务异常现象反向分析法：业务系统所在服务器的CPU使用率非常高，那就去查看是哪一个进程或程序占比较大，顺藤摸瓜找到对应用户是否异常、对应程序是否被滥用，再结合基础环境信息去分析被攻击的可能路径，追溯到存在的漏洞，并结合相关日志敲定事实。这种方法需要对漏洞及利用等攻防知识比较了解，假定自己就是攻击人员会如何进行攻击，找对应的日志进行佐证，但同时也要避免先入为主的影响，所有推断要有确凿的支撑。
3.4 横纵向排查
出现异常现象的业务，可能仅是其中一个受害者，在攻击链上处于中间位置。故在真实环境中，需要向前找到攻击者入口点，向后挖掘攻击者占领的最后一座堡垒才算应急结束。在第一个课题中，仅一台windows机器，环境非常单一，不涉及深入排查；在第二个课题中增加了一台Linux机器，并相互攻击，环境稍微复杂点，需要根据IP地址进行溯源分析：
- 谁连接过我：主要指操作系统及其相关服务被连接的源地址，服务包括但不仅限于SSH、RDP、MYSQL、MSSQL、ORACLE、Telnet、FTP、Redis、SMB 、LDAP，被连接情况包括正常连接和异常连接（连续登录失败等暴力破解、异常时间段登录等）；
- 谁访问过我：主要是指应用系统的服务被访问情况，根据各类攻击手法的特征（如sqli：select、’union、into…outfile…）,对应用日志及程序报错日志可以筛选出攻击者的上一跳地址；
- 我连接过谁、我访问过谁：需要依赖于一些工具，如bash历史命令、浏览器记录、ssh远程连接工具、黑客工具扫描或利用后留下的日志等。
3.5 木马后门清理
在梳理出的攻击链路上，沿着可能存在后门之处进行清除。从最开始的web入口处容易产生webshell、cs样本，提升权限用到的exp文件，操作系统的后门账号、影子账号，系统级的rootkit或做持久化的后门文件，都是需要逐一盘点清理的目标。攻击者的思路往往令人意想不到，留下的后门也依旧如此。除了手工排查外还需要：
- 使用专杀工具排查：无论是webshell的查杀工具，如D盾、webshellkiller、河马查杀等；综合型的病毒查杀工具，如各种商业版的AV；还是系统内核级的chkrootkit、rkhunter，均可以全面检查，对手工检查进行补充；
- 借助安全设备排查：在各类安全检查工具的加持下，仍有可能遇到一些高手留下的过XX后门，在静默状态下没有特征不会被发现。若业务被覆盖主机层的hids，网络层的NTA设备，当攻击者远程进行操作时就可能被发现；故在处理被攻击业务时，需要在重新上线后进行值班保障，监测异常；
- 排查潜在风险点位：从攻击角度来看，windows需要排查账号、注册表、启动项、c盘下temp目录、业务系统web目录…；Linux需要排查定时任务、启动项、tmp目录、业务系统web目录、从被攻击开始时间到现在发生变化的文件等，均是风险高的位置；
- 系统重启之后排查：如果被植入内存马，一般在系统重启后就会失效；如果后门没被清除干净，在系统重启后又会新增一些文件、账号或产生外联，这是发现遗漏后门的好时机。
在本专题中，除了第二点使用安全设备排查外，其他均需要进行操作。此外攻击队还在第二次课题模拟中，留下一个彩蛋：在windows桌面上，留下一张名为hackyourown.jpg的图片（实则利用exiftool rce漏洞植入了后门），等待应急响应同学使用exiftool去分析图片，然后上线。
3.6 漏洞修复与加固
业务系统在上线之前，需要将已经被利用的漏洞进行修复与加固。关于漏洞修复有以下几条建议：
- 能选择根除，就尽量不选缓解：根除指从代码或架构上进行彻底解决，不要在外面包很多个安全检测/防护层，说不定哪天就会出现绕过的路子。比如由于未作后缀名校验导致的文件上传漏洞，在前端代码中加入了文件格式校验，但殊不知前端可以使用抓包工具进行绕过，继而产生另一种方式的文件上传漏洞；
- 避免指哪儿打哪儿的修复方式：这里至少有三层意思，若A接口的第一个参数存在sqli，一是需要修复第一个参数；二是需要去源代码层面定位到拼接的地方，排查这个可控传参是否还有其他入口；三是还要排查这个系统的其他功能是否存在sqli漏洞，甚至是其他类型的注入漏洞；
- 避免引入新的安全漏洞或风险：安全人员除了要验证已知漏洞修复情况，还要关注修复方式是否带来新的风险。
看了各组应急响应报告中的修复建议，思路比较固定，基本都分为技术和管理方面。技术方面，推荐的修复方法太干，只传达了意思，需要具体做的人去理解并且较难理解，比如：网站后台和数据库均应该设置强密码、制定定期修改密码的计划；部署服务器安全管理软件，实现从应用层到主机层的纵深防御；管理方面，无外乎就是说开发人员缺少安全编码思维，需要加强培训。
不过这倒是不奇怪，顾及不到业务场景、安全业务场景，这也是甲方非业务安全团队与乙方安全服务中存在的普遍现象。这在专题的总结汇报中，也向参与应急的同学进行说明，有机会还是需要深入了解业务，提出针对性强、有效果、能落地的建议，因为这十分考验安全基本功。
