基于Windows日志分析的终端安全研究

李春强 夏伟

摘 要：网络安全已经上升到关系国家主权战略问题，受到广泛的重视。近年越来越多的新型攻击方式不断涌现，对于这些无法防范的安全威胁，经过正确配置和记录的系统日志便发挥出其价值。尤其对于大型企业，其系统日志是冗杂且数量庞大，完整性也经常遭到人为的破坏。论文介绍了Windows操作系统的日志结构，利用已有的日志分析辅助工具和批量处理工具，讨论如何更高效地利用系统日志完成安全事件的溯源，并查找系统未知漏洞以进行修补，最终给出系统日志分析的基本模型。

关键词：日志分析；终端安全； 企业内网安全

中图分类号：TP393.08 文献标识码：A

Abstract： Network security has risen to the relationship between national sovereignty strategic issues， and has been widely attention. Recently more and more completely new attacking methods appeared on the network. The event log is getting valuable because we cant defend those threats. But the event log of a system is redundant and in a large amount， especially for enterprise. And the integrality of the log is always destroyed factitiously. This passage will introduce the struct of Windows event log and discuss about how to originate the source of the security accident and find vulnerabilities to repair. Finally， will give out basic model of system log analysis.

Key words： event log analysis； terminal security； corporation intranet security

1 引言

内网安全是企业信息安全的重要组成部分，而日志审计也是安全审计中最为核心的一部分，日志审计中很大一部分比重是终端日志审计。然而，Windows操作系統的日志结构复杂，对其进行统一且合理的自动化分析成为终端安全的重点和难点，本文提出一种分析方式，可以有效地整理和分析Windows日志。

2 日志分析工具现状

已经有研究团队开发出了自动化的日志分析工具。这些工具不限于针对Windows系统的日志分析，主流针对的是中间件，如Apache、Nginx、Tomcat等Web中间件，它们可以很方便地得出其中的可疑事件或入侵事件，如XSS攻击、SQL注入等。对于Windows日志分析较为知名的有软件Event Log Analyzer、Splunk等。

2.1 Event Log Analyzer

一款综合了日志收集与分析、合法性检查（信息系统安全性是否符合标准）的日志分析工具，能够对日志趋势进行绘图，可统计所有分级事件的数目，它以报表的形式反馈用户重点关注的内容，不限于Windows日志，也包含Linux/Unix系统和中间件日志。

2.2 Splunk

依赖SPL（搜索处理语言）进行数据搜索的一款日志分析软件，用户使用SPL来生成自己需要的报表，它支持大量第三方插件，目前其APP商店中有300多款辅助日志分析的插件，且都是开箱即用的，功能十分丰富，可自由定制。Splunk也对软件使用和如何编写插件提供了丰富的文档。

3 Windows操作系统日志结构

3.1日志文件分布和格式

微软从Windows Vista开始使用EVTX格式记录日志，可以使用事件查看器将其导出为多种格式（XML、CSV、TXT等），推荐XML格式。XML格式导出的内容不包括事件查看器对事件的解析文本。而TXT格式则是将所有事件的解析文本全部保存。Windows系统大部分日志保存在%SystemRoot%＼winevt＼Logs中，用户可自行导出到任何位置，除此之外，系统中仍有一部分日志以纯文本形式（.log）存放在零散的位置，由于系统清理软件可能定期删除它们，其存在不稳定。但我们不能忽视其在日志安全性审计中的价值。如C：＼Windows＼Logs＼CBS＼CBS.log，该文件记录了系统实用工具SFC（System File Check系统完整性检查工具）的运行日志。部分病毒会修改或删除关键的系统文件，SFC检查时会在日志中记录相关信息。

3.2 日志内容和分类

主流针对Windows日志的研究从事件ID入手，然而对于Windows日志而言事件ID并非事件的唯一标识，有时具有相同事件ID的事件却显然从分类上没有关联，对于Windows中的日志，应当从三方面进行分类：事件频道、事件源、事件ID。事件频道即事件查看器中列举出的每一个事件容器，每个频道对应着一个EVTX文件，里面记录若干不同事件源、不同事件ID的事件。事件源即产生此事件的组件，事件源内事件的ID是唯一的。事件源不一定来自系统组件，其他应用程序也可以将事件记录到系统日志中。事件ID即一个事件源内部的事件标识（事件源内唯一），可在此范围内依据此ID对筛选事件，此处应当指出：Windows系统中事件的ID并非一成不变，相同的事件在不同版本系统中可能存在差异。事件查看器的Windows日志文件夹中列出了几个重要的事件频道Application、Setup、System、Security、Forwarded Event。Forwarded Event在未设置事件转发时一般为空。Setup主要负责记录系统安装补丁包的情况，将一个频道的事件导出为XML格式后，可以观察到：一个事件就是一个Event元素，其下包含两个子元素System、Event Data（个别情况除外）。System中部分元素及其含义对照如表1所示。

3.3日志事件源及ID号

Application中需要重点关注的事件[1]，如表2所示。

Security频道中的事件需要重点关注的事件[2]，如表3所示。

System频道中需要重点关注的事件[1]，如表4所示。

表格说明1[3]：此事件记录了文件筛选器的注册过程。文件筛选器主要用于过滤对文件读写的操作，杀毒软件依赖此功能拦截病毒和木马。它具有一定的时序，操作系统使用系统栈存储每个文件系统筛选器的实例，其中杀毒软件的筛选器实例应当在栈中较高的位置以监视整个文件系统。高度较低的几个常见文件筛选器是（从高到低）：Storqosoft、Wcifs、CldFlt，FileCrypt、Luafv、Npsvctrig、Wof、FileInfo。

4 Windows日志过滤和分析

Windows每天都要产生很多不同类型的日志，当日志来源于运行了几周甚至几个月的终端，就必须对日志进行“清洗”以除去那些对安全性分析无关的事件。

4.1事件冗余度和低频事件

Windows中几乎所有事件都具有一定冗余度，对于一个事件本身而言，在不分析时序关系时可以不关心System中的数据，只要对比EventData便可知两个事件是否相同。将这些事件依据ID分类，就能得到在给定的事件集中各个类型事件的冗余度了，现将日志的冗余度定义为日志的R属性。在Python中利用xml.dom解析包很容易對导出为XML的事件集进行分析并计算其冗余度，对于冗余度本身，设定一定比例标识，如表5所示。

“$”的数目越多，冗余的程度越大。最终得到形式如同图1的事件冗余度信息。

注：ID为事件ID， SUM（Types）是事件md5值的取值数目。SUM（Events）是此ID下总计的事件数。P是事件源名称，T为任务类型（System元素中的Task字段的值），最后的数字是哈希值为该值的事件数目。

Note： ID=Event ID， SUM（Types） = counts of md5 values. SUM（EVENTS） = count of event with this ID。P=Event source，T=Task type. The number at the last is total of this type of event.

从结果我们可以看出，Windows中很多事件的冗余度都是相当大的。在系统日志中，System频道事件ID为7016的事件，冗余度达到了100%，事件重复了超过8000次。对于这样的事件，如果和相同事件源中其他事件没有时序关系，它们显然不具备任何分析价值。

另外，若所有终端都处在相同的网络环境下，它们中高频事件的种类和比例应当类似。除此之外可以直接从事件的来源入手，如那些来源于Windows Search的事件显然没有研究的价值。如果一个事件源中不同ID的事件具有时序关系，在事件查看器中依据来源筛选事件时，一定有十分明显的时序关系，如图1所示。

图1中4624、4627、4672的时序关系是很明显的，对于不明显的我们可以借助Python解析已导出的XML格式事件来分析。对于高频事件，我们应当予以过滤，而对于低频事件，我们应当予以重视。相对于安全事件，系统产生的日常运行日志中只有很少的一部分包含我们需要关心的安全事件。实际上绝大多数入侵事件、病毒感染等都不那么容易触发系统事件，所以低频的事件更能反馈安全问题。部分低频事件甚至能指出入侵者以何种方式入侵系统，通过分析这类事件，我们可以亡羊补牢。除了Windows日志文件夹中四个最重要的频道，应用程序和服务日志在必要的时候也应予以关注。

4.2 实例：从日志看出入侵事件

部分安全事件在日志中是能够反映出来的，但不能过度依赖Windows自身记录的日志去追踪所有安全事件，这是不现实的。

4.2.1 Wannacry勒索病毒侵入系统后的日志特征

Wannacry是2017年5月12日爆发的利用Windows系统445端口传播的蠕虫，它利用MS17-010漏洞在全球范围内肆虐，入侵系统后加密用户数据，必须交付一定的赎金才能解锁文件。一般情况下，Wannacry病毒入侵系统后，没有明显的特征事件可以指出病毒何时入侵，虽然在日志中没有明显的踪迹可循，但不意味着它在日志中永远不会留下踪迹。在某种极端的情况下，病毒在C：＼Windows＼下释放的病毒程序tasksche.exe会出现软件并行配置不正确的情况，此时在Application频道会记录此事件，事件源为Side by Side。

4.2.2 Hydra暴力破解远程桌面服务用户名和密码

Windows远程桌面服务可以帮助系统管理员远程登录计算机，只要提供正确的用户名和密码就可以成功登录并执行任意操作。如果登录用户使用了弱口令，使用Kali下提供的密码爆破软件Hydra即可对登录密码进行爆破。证了此过程：靶机为Windows 7，用户名为test，密码为123456。尝试的用户名为：a，b，…… r，s，test，尝试的密码为：1，12，123，…，123456。在暴力破解用户名和登录密码成功后，在事件查看器＼应用程序和服务日志＼Microsoft＼Windows＼TerminalServices-RemoteConnectionManager＼Operational下我们可以很明显的看到每一次爆破行为尝试的用户名。

4.3 日志分析方法

鉴于Windows日志分析的特殊性，这里给出日志分析的一般模型以供参考。

实质上，对于Windows系统日志的分析就在特征库匹配和无关事件的索引上，但由于Windows日志的特殊性，很难做到所有日志都使用自动化分析工具分析，对于部分日志仍需人工分析。

5 使用Sysmon追踪入侵行为

Windows事件记录在真正的入侵行为发生后作用有限，无法溯源攻击行为发生的过程。对此，需要更全面的日志记录工具。

5.1 Sysmon简介

Sysmon是Wininternals公司提供的免费系统调试工具集Sysinternals中的一个命令行工具，用户给定XML格式的过滤规则文件后，便可以根据此规则收集系统中发生的事件。目前Sysmon最新的版本为v8.0，使用自己的驱动程序来保证对事件的完整收集，如表7所示[4]。

安装Sysmon服务时，使用命令：sysmon.exe -i -accepteula C：＼SysmonConfig.xml

服务安装后Sysmon会将日志记录在应用程序和服务日志＼Microsoft＼Windows＼Sysmon文件夹中。更新配置文件时使用此命令：sysmon.exe -c C：＼SysmonConfig.xml。

如图给出配置文件的一般形式[5]，如图3所示。

合理地构造此XML文件，可以让Sysmon在不影响系统性能的前提下记录最有用的日志从而在源头实现了对日志的“清洗”。这里给出一个建议的过滤规则：此过滤规则由安全团队SwiftOnSecurity总结得到，可以在此基础上进行修改以适应安装了不同类型应用的系统：

https：//github.com/SwiftOnSecurity/sysmon-config/blob/master/sysmonconfig-export.xml[3] 。

5.2 实例：使用Sysmon追踪对系统的攻击行为

5.2.1 Sysmon追踪利用MS17-010漏洞的攻击行为

在靶机为Windows 7并且配置了Sysmon的情况下，使用Metasploit利用MS17-010漏洞攻击靶机445端口后，Sysmon记录下了事件。

（1）攻击者连接靶机的445、135端口。

（2）攻击者发起大量到445端口的连接。

（3）被注入的线程以NT AUTHOITY＼SYSTEM权限启动应用，如果后渗透部分是回弹shell，则会启动cmd.exe。

（4）攻击结束后，445端口最后一个链接指向攻击者metasploit回弹窗口。

以上是攻击行为和正常的文件共享不同，正常的行为中，共享双方先使用llmnr（链路本地多播名称解析）协议获取双方的IP地址，通常文件传输时只有一次445端口的连接。

从Sysmon记录的日志来看，甚至能追踪到攻击者的IP地址（Kali系统），如图4所示。

从图4中可以看出，Sysmon记录的信息相当全面，甚至有对连接端口协议的解析，借助这些信息，甚至可以溯源得到未知的攻击手段。

5.2.2 Sysmon追蹤利用MS17-11882漏洞的攻击行为

此漏洞属于Office办公软件系列漏洞，同样在靶机为Windows 7并且配置了Sysmon的情况下，使用Metasploit攻击靶机后，Sysmon记录下了事件。

（1）用户打开Word文档，由explorer.exe创建了WinWord.exe进程。

（2）由svchost.exe -k DcomLaunch创建EQNEDT32.EXE -Embedding进程。

（3）由EQNEDT32.EXE -Embedding进程创建mshta.exe进程（关键，EQUEDT32.EXE中存在远程任意代码执行漏洞）。

（4）mshta.exe创建hta文件，后与攻击者137端口进行一次通信并创建两个PowerShell隐藏进程。

（5）第二个Powershell进程和攻击者住进程进行一次通信，目的端口为攻击者msfconsole的回弹窗口，并创建cmd.exe进程。

同样，根据Sysmon记录下的相关信息，我们仍然可以很轻松的溯源得到攻击者的IP地址，如图5所示。

除此之外，设想如果此漏洞属于未知威胁，从Sysmon记录下进程建时命令行的信息甚至可以得到入侵行为更具体的信息。

在成功获得系统Shell后，还可以记录入侵者的进一步行为，如图7所示。

6 结束语

对于Windows操作系统日志审计的自动化仍然需要很多工作去做，随着Windows系统的更新和升级，本方案也需要随之做出相关调整和改变，希望本文引出更多针对Windows操作系统日志分析的研究。

参考文献

[1] “The Top 10 Windows Event ID's Used To Catch Hackers In The Act”， Michael Gough， 2016-4-20.

[2] The top 10 Windows logs event IDs used. Michael Gough， 2016-4-22.

[3] https：//docs.microsoft.com/zh-cn/windows-hardware/drivers/ifs/index， 2018/11/18.

[4] “RSA Conference 2017 How to Go from Responding to Hunting with Sysinternals Sysmon”， Mark Russinovich， 2017-2-13.

[5] “RSA Conference 2016 Tracking Hackers on Your Network with Sysinternals Sysmon”， Mark Russinovich， 2016-2-29.

[6] 史春涛.基于Windows平台的日志分析系统的设计与实现[D]. 2010.

[7] 潘建华.基于Windows平台的电子信息挖掘分析系统的设计与实现[D].厦门大学， 2009.

[8] 鲍一丹.基于Windows平台的日志提取与分析[D].吉林大学， 2008.

[9] 王锡强.基于日志的网络安全审计系统的设计与实现[D].山东大学， 2007.

[10] 李承.基于防火墙日志的网络安全审计系统研究与实现[J].计算机工程， 2002， 28（6）：17-19.