1. 日誌分析

1.1. 要調查安全問題，通常需要查看來自不同供應商和不同設備的多種日誌

1.2. 一旦瞭解瞭如何讀取日誌，在多個供應商產品的日誌之間切換就會變得更容

1.3. 許多工具可以自動執行日誌聚合，例如SIEM（Security Information Event Management，安全信息和事件管理）解決方案

1.4. 很多時候這不是數量的問題而是質量的問題

1.5. 確保你擁有能夠智能地採集和處理數據的工具，當需要進行手動調查時，你只需關注它已經過濾的內容

1.6. 在網絡安全中沒有萬能的策略

1.7. 基礎知識非常重要，因為它將幫助你快速吸收新的挑戰經驗，並應用安全原則來補救威脅

2. 數據關聯

2.1. 大多數組織將使用某種SIEM解決方案將其所有日誌集中到一個位置，並使用自定義查詢語言在整個日誌中進行搜索

2.2. 需要知道如何在不同的事件、日誌和工件中穿梭，以執行更深入的調查

2.3. 從SIEM獲得的數據有助於發現威脅、威脅行為者，以及縮小受威脅系統的範圍

• 2.3.1. 需要找到根本原因並根除威脅

2.4. 每次執行數據分析時，重要的是要考慮如何將難解之謎的各部分結合起來

2.5. 工作方式

• 2.5.1. 調查人員開始檢查操作系統日誌中的危害跡象

• 2.5.2. 在此通信期間，發起了從外部網站到內部Web服務器的回調(callback)，那麼需要查看Web服務器日誌文件

• 2.5.3. 調查人員通過檢查此Web服務器中的IIS日誌來繼續數據關聯過程

2.6. 訪問哪些日誌、查找哪些信息，以及最重要的，如何在情景中查看所有這些數據，都存在一個邏輯

3. Windows日誌

3.1. 在Windows操作系統中，最與安全相關的日誌可以通過事件查看器訪問

3.2. Windows\System32\winevt\Logs獲取單個文件

3.3. 操作系統中的日誌分析不一定侷限於操作系統提供的日誌信息，尤其是在Windows中

3.4. 在Windows 10中，還可以使用OneDrive日誌(C:\Users\＜USERNAME＞\AppData\Local\Microsoft\OneDrive\logs)

3.5. 要解析Windows預讀文件，Windows-Prefetch-Parser的Python腳本

3.6. Windows存儲用户模式崩潰轉儲文件的位置

• 3.6.1. C:\Users\＜username＞\AppData\Local\CrashDumps

• 3.6.2. 崩潰轉儲文件是可用於識別系統中潛在惡意軟件的重要資料

• 3.6.3. 在轉儲文件中暴露的一種常見攻擊類型是代碼注入攻擊

• 3.6.3.1. 惡意軟件主要使用此技術來訪問數據，並隱藏自己或阻止被移除

• 3.6.3.2. 合法軟件開發人員有時可能出於非惡意原因使用代碼注入技術

• 3.6.4. WinDbg

• 3.6.4.1. 需要適當的技能來瀏覽轉儲文件以確定崩潰的根本原因

• 3.6.5. 即時在線崩潰分析

• 3.6.5.1. osronline

• 3.6.6. 將此日誌（崩潰發生的當天）與事件查看器中提供的其他信息（安全和應用程序日誌）相關聯，以驗證是否正在運行可能已獲得此應用程序訪問權限的可疑進程

• 3.6.6.1. 需要執行數據關聯以獲得有關特定事件及其罪魁禍首的更多有形信息

4. Linux日誌

4.1. auth.log

• 4.1.1. 位於/var/log下

• 4.1.2. 包含所有與身份驗證相關的事件

• 4.1.3. 注意調用root用户的事件，這主要是因為該用户不應該以如此高的頻率使用

• 4.1.4. RedHat和CentOS將在/var/log/secure中存儲類似的信息

4.2. 如果只想檢查失敗的登錄嘗試，請使用var/log/faillog中的日誌

5. 防火牆日誌

5.1. 防火牆日誌的格式因供應商而異，但是無論使用哪種平台，都會有一些核心字段

• 5.1.1. 誰發起的通信（源IP）​？

• 5.1.2. 該通信的目的地（目的地IP）在哪裏？

• 5.1.3. 哪種類型的應用程序正在嘗試到達目的地（傳輸協議和端口）​？

• 5.1.4. 防火牆是允許還是拒絕該連接？

5.2. Check Point和NetScreen防火牆日誌之間的一個重要區別是它們記錄有關傳輸協議的信息的方式

5.3. 通過利用iptables將Linux計算機用作防火牆

• 5.3.1. iptables.log

5.4. 如果需要查看Windows防火牆，請查看C:\Windows\System32\LogFiles\Firewall處的pfirewall.log日誌文件

5.5. 防火牆日誌是收集有關傳入和傳出流量信息的好地方

6. Web服務器日誌

6.1. Web服務器日誌也可以提供有關用户活動的有價值的見解

6.2. 特別注意具有與SQL數據庫交互的Web應用程序的Web服務器

6.3. IIS Web服務器日誌文件位於\WINDOWS\system32\LogFiles\W3SVC1，它是可以使用記事本打開的.log文件

• 6.3.1. 使用Excel或Microsoft Log Parser打開此文件並執行基本查詢

• 6.3.2. 在查看IIS日誌時，請密切注意cs-uri-query和sc-status字段

• 6.3.3. 如果使用Log Parser，則可以針對日誌文件執行查詢，以快速確定系統是否遭受SQL注入攻擊

6.4. Apache日誌文件

• 6.4.1. 訪問日誌文件位於/var/log/apache2/access.log

• 6.4.2. 格式也非常易於閲讀

• 6.4.2.1. 在Linux中使用cat命令

• 6.4.2.2. 使用apache-scalp工具

7. AWS日誌

7.1. 如果資源位於AWS(Amazon Web Services)上，並且需要審核平台的整體活動，則需要啓用AWS CloudTrail

• 7.1.1. 啓用此功能後，AWS賬户中發生的所有活動都將記錄在CloudTrail事件中

• 7.1.2. 事件是可搜索的，並在AWS賬户中保留90天

7.2. 如果使用Microsoft Sentinel作為SIEM平台，則可以使用Microsoft Sentinel的AWS Data Connector將以下日誌以流的方式傳輸到Microsoft Sentinel工作區

• 7.2.1. Amazon Virtual Private Cloud(VPC)—產生的VPC流量日誌

• 7.2.2. Amazon GuardDuty—威脅檢測發現的安全日誌

• 7.2.3. AWS CloudTrail—記錄和監控服務生成的管理和數據事件日誌

7.3. 使用Log Analytics KQL(Kusto Query Language)調查AWS CloudTrail日誌

8. Azure Activity日誌

8.1. Microsoft Azure還具有平台日誌記錄功能，能夠可視化Azure中發生的訂閲級別事件

• 8.1.1. 從Azure資源管理器(Azure Resource Manager，ARM)操作數據到服務運行狀況事件更新

• 8.1.2. 日誌也會存儲90天，並且默認啓用此日誌

8.2. 如果使用Microsoft Sentinel作為SIEM平台，則可以使用原生Azure Activity日誌連接器從Azure平台接收數據

8.3. 使用Log Analytics KQL調查Azure Activity日誌

9. Google Cloud Platform日誌

9.1. 谷歌雲平台(Google Cloud Platform，GCP)是重要參與者

9.2. 問題

• 9.2.1. 誰做了什麼？

• 9.2.2. 什麼時候完成的？

• 9.2.3. 在哪裏完成的？

9.3. 使用Microsoft Sentinel，你可以獲取GCP身份和訪問管理(Identity and Access Management，IAM)日誌，它可以用來查看管理活動（審核日誌）​，其中包括管理寫(admin write)操作，以及數據訪問(data access)審核日誌，其中包括管理讀(admin read)操作