官方提供了一个splunk- instance，用于指引安全事件排查
一、主页界面
search&report应用的界面，splunk应用功能非常强大，都是splunk官方或一些安全厂商为了让自身安全产品的日志适配splunk所开发出来的工具集。
比如checkpoint开了一个checkpoint app for splunk，利用此app就能快速导入并解析checkpoint安全产品的日志并形成安全告警。
二、登录官方实例后的界面
左上角可以选择各种app,对于刚安装的splunk，当然最主要是上面的search&report应用，内置了核心功能，这里的dataset是官方给这个实例安装的应用，选择安全数据集应用可以看到splunk准备了两个事件案例，
案例1收集了两个ids产品产生的安全日志，主要是检测到了webshell，nessus、nmap以及红队zuo做的其他事。模拟一般的web安全事件，但是数据源已无法使用，即没有日志了。
案例2收集sysmon（进程日志）、windows日志、网络流、ids、fortigate防火墙日志，模拟入侵windows主机后实施勒索病毒攻击行为，这是非常完整的日志链。此案例还可以用
三、前情提要
1、根据此数据集提示，windows窗口能看到勒索信，明显中了勒索病毒，勒索病毒的特征是带有cerber标识，并找到了相关信息。
2、那么此时的问题是：
他是怎么进来的？渗透到哪个层面了。拿到root了？（深度，当然这里被干爆了）
只有这台主机中招吗，影响了多少主机？（广度）
病毒木马识别与清除？（主机排查）
要怎么做补救？（防御加固）
3、理清常见的攻击思路来进行溯源分析。
安全分析主要利用各种网络设备、网络安全软硬件，主机安全软硬件产生的日志还原黑客攻击链。
根据不同的设备角色，常见攻击入口有：
如desktop，钓鱼邮件、带毒的可移动介质等
如服务器，看服务器角色，如web服务器常见于web攻击、ssh等。
以web攻击为例，首先往往是黑客的主机与受害主机建立http链接（ip：port）。网络方面，涉及到网络流日志，边界的安全防护设备的检测日志以及ids入侵检测的日志。
流量进入到主机，我们知道，所谓连接，本质上就是两台主机之间端口所在进程的通信。比如80端口，那就是能发起http请求的客户端进程与httpd进程的通信。
当黑客通过sql注入也好，文件上传漏洞入侵httpd成功拿到shell后，实际上就是获得了httpd进程的属主账户在主机上的shell权限。接下来他可能进行外链，还是进一步提权，或是横向移动，都是以httpd进程属主身份操作的，sysmon就可以监控这些进程的行为。
拿下跳板服务器后，开始内网漫游，内网协议主要是arp发现、网络扫描、SMB、SSH、3389等
4、由上图看到有很多日志源类型（sourcetype）。主要有以下类别：
suricata：IDS检测日志
stream网络流日志：tcp、snmp、smb、sip、mapi、ldap、ip、icmp、http、dns、dhcp
nessus：扫描器日志
iis：http日志
Fortigate日志：utm（安全日志）、traffic（流量日志）、event（自身系统日志）
windows日志：sysmon进程监控、注册表、系统、安全、应用
源类型是splunk用来标识不同的日志来源的。splunk内置了很多源类型，比如windows的，linux的。而Fortigate没有内置，但是厂商开发了app提供了解析正则表达式，也可以通过安装app进行日志规范化。
比如公司总部和子公司都用了fortigate的防火墙，他们都通过514端口推送安全日志到slunk平台，那么假设这么多台fortigate防火墙的安全日志源类型都归类到fgt_utm，此时通过splunk搜索框，就能搜索出所有的fortigate的安全日志，就能一次性统筹查看公司整体网络边界防火墙的各种安全数据
#如何分辨是哪一台防火墙的日志呢#其实在发送给splunk那一刻，splunk对其进行索引，就记录下源主机ip，存到host字段中#如果不加host筛选，或者host=*，那就搜索所有的安全日志sourcetype = fgt_utm host=*复制
四、正式开始
1、从受害主机开始调查
我们只知道受害主机名是we8105desk，这里并没有使用指定字段搜索，也就是模糊搜索相关字符串
index是botsv1，index是一个重要的过滤条件，基本所有的搜索都是从它开始的。比如该公司存在多个分部，广州、北京、上海等等，那么通常会为各个分部建立一个index，那么当index=guangzhou时，就会快速搜索广州到广州的数据，而不是搜索全部，加快搜索速度
#这个案例的index是botsv1index=botsv1 we8105desk复制
2、查找we8105desk主机信息
index=botsv1 we8105desk sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational | stats count by src_ip | eventstats sum(count) as perc | eval percentage=round(count*100/perc,2) | fields - perc | sort - count复制
通过查找sysmon的操作日志并根据源地址进行统计出现次数并排序，得知绝大多数ip是192.168.250.100，此IP很可能就是受害主机的IP地址
同时通过sysmon里的src_host字段值出现的we8105desk.waynecorpinc.local次数与ip出现次数大致相同可以进行确认
3、USB取证
由于是台desktop，不太可能开放了web或其他服务被人打进来，注意力放在windows自身的日志，会不会是从usb可移动介质引起的安全事件呢。有时，我们需要知道哪些 USB 设备连接到到该计算机。
注册表是 Windows 中的一个数据库，用于存储操作系统、硬件设备、软件程序和用户偏好设置的设置。每当我们将 USB 驱动器插入计算机时，都会创建一个名为“USBSTOR”的注册表项。此注册表项存储有关该 USB 设备的信息，操作系统需要知道的任何信息都可以在此注册表项中找到
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR
USBSTOR 里可以获得已连接到此计算机的所有 USB 设备的列表。
单击列表中的任何一个设备，然后单击右侧的子项。您将找到一个名为“friendlyname”的条目。就在这个条目的前面，你可以很容易地看到这是什么类型的 USB 设备。
4、使用splunk进行模糊搜索friendlyname，找到了两条json格式的日志
#指定index，指定了数据源是注册表日志index=botsv1 sourcetype=winregistry friendlyname复制
json格式日志非常不直观，splunk做了解析，并把解析到的字段展示在左边的字段选择区，我们对这两个事件的相关进行列出，可以看到确实与该主机相关
#使用管道符将数据传递给table 命令，table是制表命令，后面跟想要的字段index=botsv1 sourcetype=winregistry friendlyname | table host object data复制
此时查到了usb设备名
5、U盘插入计算机，恶意文件执行命令，会创建进程。找出异常文件、可疑命令和可疑进程
index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational host=we8105desk复制
发现很多的C盘路径的命令，U盘盘符肯定不是C盘，所以排除C盘开头的，只看到一个D盘，使用模糊搜索D盘的相关指令，找出了执行奇怪命令，比如打开了121214.tmp、20429.vbs
index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational host=we8105desk "d:\\" | reverse | fields *复制
精确搜索D盘插入时，由D盘开始打开了啥文件并执行，可以看到是用word程序打开了文件，然后就被执行了这一堆奇怪代码，明显是U盘存在带毒的word文档
index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational host=we8105desk (CommandLine="*d:\\*" OR ParentCommandLine="*d:\\*")| table _time CommandLine ParentCommandLine| sort _time复制
通过查找进程日志，也可以找到这个奇怪命令，在sysmon的操作日志中，EventCode值为1代表进程创建
index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational *.exe CommandLine=* host=we8105desk EventCode=1| eval length=len(CommandLine)| table CommandLine length| sort - length复制
6、查看操作日志找出这个主机有没有进行横向扩散
发现和192.168.250.20、192.168.2.50这两个IP地址的连接数远远高于其他IP
index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational host=we8105desk src=we8105desk.waynecorpinc.local| stats count by dest_ip | sort - count复制
查找注册表日志，模糊搜索fileshare发现和192.168.250.20存在文件共享
index=botsv1 sourcetype=winregistry host=we8105desk fileshare复制
对192.168.250.20进行主机名识别，同时搜索该主机源主机和目的主机时出现次数最多的主机名，得到主机名是we9041srv.waynecorpinc.local，从主机名得知这是一台服务器
index=botsv1 sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" 192.168.250.20 | stats count by src_host | eventstats sum(count) as perc | eval percentage=round(count*100/perc,2) | fields - perc | sort - countindex=botsv1 sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" 192.168.250.20 | stats count by dest_host | eventstats sum(count) as perc | eval percentage=round(count*100/perc,2) | fields - perc | sort - count复制
7、查找主机是否进行外链，DNS的A记录能帮到我们，DNS的A记录是指向DNS发起解析请求，解析某个FQDN的IP地址。
index=botsv1 sourcetype=stream:DNS src=192.168.250.100 record_type=A复制
发现DNS查询记录有很多Microsoft的主机地址，他不太可能搞我们，排除掉，同时排除内部地址，查询wpad、isatap是正常，都排除，只剩下了三个域名，其中两个很奇怪，先连接了solidaritedeproximite.org、后连接cerberhhyed5frqa.xmfir0.win，同时 发现是向192.168.250.20发起的DNS请求，目的地址很可能是DNS服务器
8、通过查询安全厂商信息，得知该恶意软件会进行http外链下载恶意文件，于是排查http连接情况
查询流日志确实发现了相关URL
#stats 是统计命令，stats count是统计搭配，如果写成stats count by dest url#那么dest和url组成了很多种唯一值，往往是dest相同，url不同。会出现很多条#使用values就是讲多值字段合并到一个格子形成1对多的关系index=botsv1 sourcetype=stream:http src=192.168.250.100| stats count values(url) by dest复制
查询suricata IDS的日志也发现相似结果
index=botsv1 sourcetype=suricata src=192.168.250.100 url=*| stats count values(url) by dest复制
查询微步，相关URL确实是勒索软件
查询utm的日志，发现192.168.250.100连接到相关地址进行下载mhtr.jpg文件，action是allowed，也就是没有阻挡
index=botsv1 sourcetype=fgt_utm src=192.168.250.100 mhtr.jpg| table _time src dest msg url action复制
继续在utm排查192.168.250.100的后续行为，共有9640个事件，
index=botsv1 sourcetype=fgt_utm src=192.168.250.100复制
从app字段中看到9231个都跟Cerber.Botnet有关，明显是下载了jpg文件后被控了
index=botsv1 sourcetype=fgt_utm src=192.168.250.100 app="Cerber.Botnet" | reverse复制
9、那么受害主机上有哪些恶意进程呢，以及进程之间怎么调用的
排查一下刚才提到的12114.tmp，查看下这个文件究竟怎么来的，做了啥还是排查sysmon的日志，模糊搜索，找出父进程子进程的ID以及命令
index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational 121214.tmp CommandLine=*| table CommandLine ProcessId ParentProcessId ParentCommandLine| reverse
可以看到是由20429.vbs打开121214.tmp，这个文件居然会执行命令，调用了osk.exe，还做了计划任务管理
那么20429.vbs被谁调用过呢，就是那戳很复杂的命令来的
而osk.exe则是做了更多事情，以及写下了勒索信
10、排查文件被加密情况
查看sysmon日志里的event种类有多少，有1、2、3、5、6、7
index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational host=we8105desk|stats count by EventCode复制
涉及文件操作的只有2和7,7是图像加载，重点是2，文件创建时间，当文件创建时间被进程显式修改时，会注册更改文件创建时间事件。此事件有助于跟踪文件的实际创建时间。攻击者可能会更改后门的文件创建时间，使其看起来像是随操作系统一起安装的。请注意，许多进程会合法地更改文件的创建时间；它不一定表示恶意活动。
发现1179个文件更改事件中大部分都跟osk.exe和121214.tmp有关，看来这些文件都被加密了。
index=botsv1 sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational host=we8105desk EventCode=2复制
排查文件服务器的文件是否被远程加密，排查步骤同理。
五、事后总结与补救
1、总结：
用户（或某人）将受感染的 USB 驱动器插入 Bob Smith 的工作站
Word 文档产生了一个可疑进程，该进程产生了其他进程
调用 FQDN 和 IP 地址后下载文件
文件加密在本地磁盘和共享上开始
重定向到带有加密通知的外部站点
用户（或某人）将受感染的 USB 驱动器插入 Bob Smith 的工作站
Word 文档产生了一个可疑进程，该进程产生了其他进程
调用 FQDN 和 IP 地址后下载文件
文件加密在本地磁盘和共享上开始
重定向到带有加密通知的外部站点
2、补救
修改相关安全设备的防护规则
查找在线解密网站尝试找找有没有密钥，没有就只能格盘重装了
等等。。。
3、splunk是一个很牛逼的平台，取决于数据源的数量以及多层次的丰富度，他能非常友好的让用户将数据导进来，并智能解析，通过不同的字段进行标识每一个事件。同时还需要熟悉各种网络安全设备，安全工具的使用，了解不同受害角色可能存在的被攻击路线，完善其被攻击链。
