基于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.