在沒有 Windows 機器時讀取 .evtx 檔案

記錄從來不在你正坐著的那台機器上

模式總是同一個。出了某件事——一次疑似入侵、一場帳戶鎖定風暴、一個在凌晨 03:00 死掉的服務——而證據是一份 Windows 事件記錄，有人從一台你無法啟動、無法登入、或沒有許可碰的機器上把它匯出、做成映像或複製了出來。你自己的機器是一台 Mac、一台 Linux 工作站，或一台鎖得很死的公司筆電，眼前連一個 Windows 虛擬機器都沒有。事件檢視器不會來幫忙。

好消息是，.evtx 檔案是一種有文件記錄、自包含的二進位格式。事件檢視器向你展示的關於一條記錄的一切——除了下文要講的一個重要例外——都在檔案裡面，而一個像樣的解析器可以在任何地方讀取它。本站的 EVTX 檢視器在你的瀏覽器分頁中執行那個解析器（Rust evtx crate，編譯為 WebAssembly），因為事件記錄會寫明使用者、機器和 IP 位址，不該被上傳到某個隨手找到的轉換站點，正如擷取檔不該被上傳一樣。下文講的是工作方法，不是工具手冊：看什麼、按什麼順序看，以及這些欄位能告訴你什麼、不能告訴你什麼。

.evtx 檔案裡到底有什麼

一個 .evtx 檔案是一個 4096 位元組的檔案標頭，後面跟著一連串 64 KB 的區塊。每個區塊裝著一批事件記錄，每條記錄都以二進位 XML（BinXML）儲存：一個由作業系統填寫的 System 區塊，加上提供者自己的有效載荷，即 EventData 或 UserData。開啟一條記錄，你看到的是欄位，不是散文——事件 ID 4625、一個時間戳記、一個通道，以及像 IpAddress、TargetUserName 和 LogonType 這樣的命名值。那些欄位就是證據。它們也是一個在外來機器上的解析器能誠實給你的全部。

例外在這裡，它也塑造了本指南的其餘部分：事件檢視器顯示的那句話——「有帳戶登入失敗」——不在檔案中。Windows 在檢視時從訊息 DLL 中算繪它，那些 DLL 屬於每個提供者，住在寫入記錄的那台機器上。這正是為什麼資料值有時看起來像 %%14592：它們是對檔案並不攜帶的一張訊息表的參照。另一台機器上的檢視器可以向你展示事件記錄的每一個欄位，以及按原樣儲存的原始 XML——但一個為別人的 .evtx 呈現打磨好訊息文字的工具，是在從它自己的 DLL 副本中重建它，或者在猜測。先欄位、後散文，才是誠實的順序。

在你引用數字之前，還有一個結構事實值得知道：檔案的各個區塊是相互獨立的。從磁碟映像中雕刻出的、或從一塊垂死硬碟上複製出的記錄，常常有單個區塊再也無法解析。一個好的讀取器會連同位元組偏移報告每個損壞的區塊，並讀取它周圍的一切。在這一點上沉默——一個工具回傳一份更短的記錄卻什麼都不說——正是記錄在調查中悄悄消失的方式。

從 System 區塊開始

每條記錄的 System 區塊都帶著同一副骨架：提供者（哪個元件寫了它）、事件 ID（發生了什麼，按那個提供者的編號）、等級（1 重大到 5 詳細，0 表示沒有等級的事件）、通道（安全性、系統、應用程式，以及 Microsoft-Windows-* 之下數以百計的運作記錄）、電腦、一個 UTC 時間戳記，以及 EventRecordID。分診始於把整個記錄按這副骨架歸類：多少條記錄、跨越什麼時間範圍、來自哪些通道、由哪些事件 ID 主導。一份 80% 是同一個事件 ID 的安全性記錄，通常講的就是那一件事——一道防火牆在做決定、一個服務在循環裡反覆驗證——而摘要在你讀單條記錄之前就把這一點告訴你。

引用一條記錄時，請引用 System 區塊中的 EventRecordID。被雕刻、被選取或被重新匯出的檔案，其記錄標頭可能被產生它的工具重新編號，而 System 區塊保留著機器最初分配的 ID——「這份節錄的第 7 條記錄」與「原始記錄中的 EventRecordID 319457858」之間的差別，在有人試圖重現你的發現時立刻變得重要。時間戳記值得同樣的謹慎：檔案內部它們是 UTC，永遠是。事件檢視器會把它們轉換為開啟記錄的那台機器的本地時間，這正是為什麼同一條記錄的兩張截圖可以相差數小時。報告裡選 UTC，並明說。

四個物有所值的事件 ID

1102——稽核記錄已被清除。安全性記錄會記錄它自己的擦除，成為新記錄中的第一條事件。它的欄位寫明了清除它的使用者。在一起事件中，1102 既是證據，也是一條邊界：它之前的那個記錄中的一切都已經從你手裡的檔案中消失，而清除這件事本身是值得在報告裡寫一行的事實。如果一份記錄最早的記錄是一條時間戳記落在你關注視窗內的 1102，在任何人基於更早事件的缺席建立理論之前，先把這一點說出來。

4624 與 4625——登入，成功與失敗。這是帳戶調查的主力。要緊的欄位是 TargetUserName、IpAddress，尤其是 LogonType：3 是網路登入，10 是遠端桌面，2 是互動式主控台登入，7 是解除鎖定。一個暴力破解模式讀起來是這樣：一串針對同一個帳戶、來自同一個位址的 4625，緊接著——要緊的那一刻——一條 4624。單獨一條 4625 是打錯字；序列的形狀才是訊號，這正是為什麼要篩選和計數，而不是捲動著看。

4688——一個處理程序已被建立。當稽核原則記錄它時，每條 4688 都寫明新處理程序（NewProcessName）、啟動它的帳戶，並且常常還有父處理程序——這是「這台機器上執行過什麼、何時執行」的原材料。兩點提醒讓你保持誠實：4688 只有在來源機器上啟用了「稽核處理程序建立」時才存在（它的缺席證明不了執行過什麼），而命令列擷取又是另一項單獨的設定。把一份豐富的 4688 軌跡當作一份禮物，而不是一項權利。

這四個是一組起點，不是一份教學大綱——4624 的特殊登入兄弟 4672、明確憑證登入 4648，以及系統記錄中的服務安裝 7045，是通常的下一站。但第一天問題中有相當大的一份——記錄是否被抹掉、誰進來了、從哪裡進來、他們執行了什麼——僅靠 1102、4624、4625 和 4688 就能回答。

欄位無法告訴你的事

對缺席保持紀律，是記錄工作的大部分。檔案無法向你展示來源機器從未記錄的事件：稽核原則決定什麼存在，而一台預設組態的機器記錄的，遠遠少於調查者所希望的。它無法展示訊息文字，如上所述——一個 %% 參照是指向一台你沒有的機器上的字串的指標。它本身也無法證明竄改的存在或不存在：記錄 ID 的缺口既出現在誠實的雕刻檔案中，也出現在被清除的檔案中，這正是為什麼要倚靠明確的 1102 記錄、而不是缺口作為訊號。

而且記錄只是一個證人。時間戳記來自來源機器的時鐘，它可能一直是錯的；帳戶以機器所知道的名字出現；一次網路登入的 IP 是機器看到的位址，包括 NAT 和 VPN。欄位恰恰是機器記錄下來的東西——不多，而紀律就是記住，也不少。

一套五分鐘分診流程

第一分鐘：在 EVTX 檢視器中開啟檔案，在看任何記錄之前先讀摘要——總數、時間範圍、通道和最常見的事件 ID。記下檢視器報告為無法讀取的區塊，連同它們的偏移；這個保留意見從一開始就屬於你的筆記，而不是後來的註腳。

第二分鐘：查 1102。如果記錄被清除過，你處理它的方法全都隨之改變，而清除的時間和帳戶是你最初的硬事實。第三分鐘：篩選 4625 並看它的形狀——每個帳戶的數量、每個來源位址的數量。一串爆發之後跟著同一位址對同一帳戶的一條 4624，就是發現；記下確切的時間戳記。第四分鐘：把可疑視窗固定下來後，在那個視窗內篩選 4688（如果遠端存取是問題所在，再加上 4624 類型 10），列出執行了什麼、誰登入了。第五分鐘：把篩選出的記錄匯出為 JSON 或 CSV，趁數字還在眼前寫出那一段話——記錄 ID、UTC 時間、帳戶、位址。匯出是你的工作底稿；那一段話，連同關於無法讀取的區塊和訊息文字限制的保留意見，是交付物。

這套流程不會終結一項調查。它把一個外來的二進位檔案變成五條有出處的事實和一個站得住腳的下一個問題，在你面前恰好是任何機器時都可以——而這正是分診的大部分內容。

常見問題