Sysmon 教學:替 Windows 建立完整的處理程序與網路連線紀錄

⚡ 站長快讀:核心重點

• 文章屬性:教學實戰
• 適用系統:用戶端 Windows 10 以上、伺服器 Windows Server 2016 以上;Windows 11 另有內建版
• 難易度 / 耗時:⭐⭐(看得懂命令提示字元即可)/ 約 30 分鐘
• 核心結論:電腦出事後最缺的不是防毒,是「當時到底發生什麼」的紀錄——Sysmon 補的就是這塊;它有內建版與獨立版兩條路,兩者不能並存,順序搞錯得先移除重來。
• 適用對象:想替自己或小型辦公室電腦留下可回溯活動紀錄的 Windows 進階使用者

📌 快速答案

一句話答案:Sysmon 教學的重點是三個動作——確認要走內建版還是獨立版、安裝服務與驅動程式、套用設定檔,之後活動就會持續寫進獨立事件記錄檔供事後查證。

🧰 開始前的準備

• 系統需求:官方標示 Sysinternals 獨立版執行環境為用戶端 Windows 10 以上、伺服器 Windows Server 2016 以上;另外 Windows 11 已把 Sysmon 做成內建的選用功能,官方要求為「受支援版本的 Windows 11 或更新版本」。
• 權限需求:系統管理員(安裝的是系統服務加驅動程式,一般使用者權限不足)。
• 需要工具:走獨立版請到 Sysmon 官方下載頁(本文查證時的版本為 v15.21,官方發佈日期 2026 年 6 月 17 日,作者 Mark Russinovich 與 Thomas Garnier,壓縮檔約 4.6 MB);走內建版則不需要下載任何檔案。
• 預計耗時:安裝到看見第一筆事件約 10 分鐘;把設定檔調到堪用約再 20 分鐘。
• 難度門檻:全程只用命令提示字元或 PowerShell 加事件檢視器,不需要寫程式;但要有心理準備——Sysmon 只負責記錄,不負責告訴你哪一筆是壞人。官方寫得很白:它不分析事件、不產生警示、也不阻擋任何行為。

🔍 為什麼你需要這個?

半夜網路燈狂閃、防毒說沒事;或是某天發現多了一個奇怪的排程,想回頭查「它是什麼時候、被誰裝進來的」——這時候你會發現一個殘酷的事實:Windows 預設幾乎什麼都沒留下。

工作管理員、TCPView、Process Explorer 都是好工具,但它們有個共同限制:看的是「現在」。程式跑完就消失、連線斷掉就查不到,而攻擊行為往往只存在幾秒鐘。等你察覺不對勁再打開工具,現場早就清乾淨了。

Sysmon 補的正是這一塊。它是一支系統服務加一支驅動程式,裝上去之後跨重開機常駐,把系統活動持續寫進 Windows 事件記錄檔。本文和多數「三步驟裝好」的教學不同,會特別講清楚四件實務上最會踩到的事:

1. Windows 11 有內建版,而且不能和獨立版並存——這是最新、也最容易踩雷的一條:裝過 Sysinternals 版的機器,得先移除才能開內建功能。
2. 預設安裝其實沒有開網路監控——很多人裝完發現「怎麼看不到連線」,不是壞掉,是官方預設就沒開。
3. 和 Windows 內建的 4688 稽核怎麼取捨——內建方案不用裝東西,但要開兩個群組原則,而且微軟自己在文件裡寫明了它的隱私風險。
4. 官方文件對雜湊預設值有兩種寫法——與其猜,不如用一行指令把現行設定倒出來自己看。

🛠️ 實戰步驟

⚠️ 執行前提醒:本節會安裝系統服務與開機啟動的驅動程式,並修改事件記錄檔設定。開始前請先確認電腦已建立系統還原點或可用備份;公司、學校配發的受管控設備,請先取得 IT 授權再操作。

停止條件清單(符合任一,請先停手):不確定自己的 Windows 版本或版次、未完成備份、裝置由公司 MDM 或網域原則管控而你沒有授權、指令輸出與本文描述明顯不符、**Get-Service sysmon* 查得到既有的 Sysmon 服務**(官方明訂內建版不支援與獨立版並存,必須先移除舊的)。

步驟零:先決定走內建版還是獨立版

這是 2026 年才需要做的分岔,很多舊教學沒有。用系統管理員身分開 PowerShell,先確認機器上有沒有跑著的 Sysmon:

Get-Service sysmon*

官方的判準很簡單:這條指令不該回傳任何結果;有結果就表示已經裝了獨立版,要先移除才能繼續走內建版路線。

• Windows 11 用戶 → 建議走內建版。官方說明它「以原生 Windows 功能的方式運作」,啟用是兩個步驟、缺一不可。第一步先開啟選用功能:

Enable-WindowsOptionalFeature -Online -FeatureName Sysmon

第二步才是真正安裝(官方文件把這一步和上一步並列在同一節,漏掉的話事件記錄檔會是空的):

sysmon -i

想一開始就帶設定檔的話,官方也接受 sysmon -i C:\Sysmon\sysmonconfig.xml 這種寫法。

• Windows 10、Windows Server,或需要指定版本的人 → 走 Sysinternals 獨立版(下一步)。

無論哪一條路,Sysmon 預設都是停用的,一定要明確安裝並設定才會產生事件——這是官方原話。

步驟一:下載並用預設值先裝起來(獨立版)

先到官方下載頁取得壓縮檔並解壓縮,建議放在一個好記的路徑,例如 C:\Tools\Sysmon。壓縮檔內含數個執行檔,官方頁面並未逐一說明各檔對應哪種架構;官方「Usage」段以 sysmon64 為例、「Examples」段則寫成 sysmon,本文統一採用 sysmon64。

用系統管理員身分開啟命令提示字元,切換到該資料夾後執行安裝:

sysmon64 -accepteula -i

-i 是安裝服務與驅動程式,-accepteula 是自動接受授權條款——不加這個參數會跳出互動式視窗要你按同意。官方明確寫著:安裝與移除都不需要重新開機。

這裡有個關鍵細節要先講:官方「Examples」段把這條指令的行為寫成「以預設值安裝(處理程序映像檔以 SHA1 雜湊、且不做網路監控)」。也就是說,你現在裝好的 Sysmon,Event ID 3 網路連線事件是關著的。這不是 bug,是預設。

步驟二:確認事件真的有進來

打開事件檢視器(Win + R 輸入 eventvwr.msc),依序展開:

應用程式及服務記錄檔 → Microsoft → Windows → Sysmon → Operational

官方文件對這個路徑的原文是 Applications and Services Logs/Microsoft/Windows/Sysmon/Operational;Vista 之前的舊系統才會寫進 System 記錄檔。官方針對內建版給的驗收判準是:看得到 Process Create、Network Connect、File Create 之類的事件,就代表已經啟用並套用了現行設定——獨立版的判斷邏輯相同,但要注意獨立版預設不開網路連線,所以這句舉例裡的 Network Connect 在預設安裝下不會出現。

你應該會立刻看到一批 Event ID 1(Process creation,處理程序建立),每一筆都帶完整命令列與父處理程序資訊。映像檔雜湊會不會出現,取決於現行的 HashAlgorithms 設定(原因見步驟三那個官方文件自相矛盾的坑),請以 sysmon64 -c 倒出的結果為準。另外請注意兩件事:

• 事件時間戳記是 UTC 標準時間,不是台灣時間。看到時間對不上不要慌,自己加八小時。
• 服務啟停會記成 Event ID 4,設定被改會記成 Event ID 16,這兩種事件官方明訂無法被過濾規則排除。

不想開圖形介面的話,用內建的 wevtutil 也可以直接撈。通道名稱請一律以 wevtutil el 實際列出的為準——官方 Sysmon 文件只給事件檢視器的樹狀路徑,沒有載明 wevtutil 用的通道字串,自己列一次最保險:

wevtutil qe Microsoft-Windows-Sysmon/Operational /c:5 /rd:true /f:text

/c:5 是只取五筆,/rd:true 是最新的排前面,/f:text 是輸出純文字。

步驟三:換上設定檔,把該開的事件打開

預設設定的問題是「開太少又記太雜」:網路連線沒開,但每一支程式的建立都照單全收。實務上要靠設定檔來決定記什麼、不記什麼。官方也把設定檔講得很直白:它決定哪些事件被記錄、哪些被過濾掉,內容通常包含啟用的事件類型、include 與 exclude 過濾規則,以及雜湊演算法與中繼資料選項。

設定檔是一份 XML,以下是節錄自官方範例的片段:

<Sysmon schemaversion="4.82">
  <HashAlgorithms>*</HashAlgorithms>
  <EventFiltering>
    <DriverLoad onmatch="exclude">
      <Signature condition="contains">microsoft</Signature>
      <Signature condition="contains">windows</Signature>
    </DriverLoad>
    <NetworkConnect onmatch="include">
      <DestinationPort>443</DestinationPort>
      <DestinationPort>80</DestinationPort>
    </NetworkConnect>
    <NetworkConnect onmatch="exclude">
      <Image condition="end with">iexplore.exe</Image>
    </NetworkConnect>
  </EventFiltering>
</Sysmon>

讀懂它只要抓住四個規則,這是整個 Sysmon 最需要理解的部分:

• onmatch="include"= 只記錄符合的;onmatch="exclude"= 除了符合的都記錄。同一個事件可以同時給兩組——上面那份範例就是這樣寫的:先用 include 收下往 443 與 80 埠的連線,再用 exclude 把路徑結尾是 iexplore.exe 的排掉,因為exclude 的優先權高於 include。
• 同一個欄位名稱寫多條 = OR;不同欄位名稱寫在一起 = AND。這條最常被搞錯。
• 條件關鍵字官方列了一整排,常用的有 is、is any、contains、contains any、excludes、begin with、end with、image(可只比對檔名,lsass.exe 就能對上完整路徑)、less than、more than,而且全部不分大小寫。
• 想知道是哪一條規則命中,就給規則加 name 屬性——官方原話是「讓 Sysmon 回報是哪一條規則命中而產生此事件」,事件中會帶出對應的規則名稱。

把設定檔存成 sysmon-config.xml,套用時執行:

sysmon64 -c C:\Tools\Sysmon\sysmon-config.xml

官方說明設定會立即生效,不需要重新啟動。-c 除了套用設定,不帶任何參數時會把目前生效的設定倒出來——這就是解決前面那個「預設到底有沒有雜湊」疑問的方法:

sysmon64 -c

💡 為什麼要這樣做? 官方文件在這一點上有內部不一致:「Examples」段說預設以 SHA1 雜湊,但「Configuration Entries」表格裡 HashAlgorithms 的 Default 卻標成 None。與其相信任何一邊(包括本文),直接倒出你這台機器的現行設定最準。這也是 Sysmon 設計上很體貼的一點:現行設定隨時可查,不用翻登錄檔。

不想自己從零寫規則的話,微軟官方的 Windows 文件本身就列了三份社群資源當作範例來源:SwiftOnSecurity/sysmon-config(官方描述為「高品質的預設 Sysmon 事件設定」)、olafhartong/sysmon-modular(模組化、涵蓋 MITRE ATT&CK)、以及 trustedsec/SysmonCommunityGuide。官方同時提醒:過度嚴格或未經最佳化的設定可能產生極高的事件量,大規模部署前務必先審閱與測試。

另外,schemaversion 這個屬性和 Sysmon 執行檔版本是各自獨立的,舊設定檔才能被新版解析(所以你會看到官方不同文件的範例分別標 4.82 與 4.90——兩個數值都出自官方範例,但官方並未載明哪一個對應你手上的執行檔)。要查你這版支援到哪個 schema,用官方給的這條:

sysmon64 -? config

步驟四:先開這幾種事件就夠用

官方的事件過濾表列到 ID 29,但其中 4 與 16 的標籤欄標示為 n/a(無法被過濾),所以真正可用規則控制的是 27 個;另外還有不在表內的錯誤事件 255。全部開下去只會把記錄檔灌爆。以「一般人想查清楚電腦到底在幹嘛」的目標來說,優先序大致是:

⚠️ 官方文件只對 Event ID 3 與 7 明文寫了「disabled by default」,其餘事件的預設狀態文件並未載明,網路上的說法也彼此矛盾。不要相信任何二手表格(包括這一張的推測欄位)——用 sysmon64 -c 把你這台機器的現行設定倒出來,那才是唯一準確的答案。

另外幾個值得知道的:Event ID 10(ProcessAccess)官方直言它的用途是偵測「讀取 lsass.exe 記憶體以竊取憑證」這類手法,但也警告開了會產生大量記錄,一定要搭配排除規則;Event ID 7(Image loaded)官方說明需另行以 -l 啟用,而且「監控所有模組載入會產生非常可觀的記錄量」;Event ID 22(DNS 查詢)的遙測是 Windows 8.1 才加入的,Windows 7 以前沒有;Event ID 15(FileCreateStreamHash)則專門記錄具名檔案串流的建立,官方舉的例子正是瀏覽器下載檔案時附加的 Zone.Identifier「網路標記」串流——換句話說,它盯的就是 NTFS 交替資料串流(ADS),對這個機制不熟的話,文末延伸閱讀那篇可以先補。

步驟五:把記錄檔調大,並定期匯出

若保留模式為 false(多數通道的常見設定),事件記錄檔滿了就會覆蓋最舊的紀錄,等於你的可回溯期被檔案大小決定;實際值以你這台機器為準,用 wevtutil 先看現況:

wevtutil gl Microsoft-Windows-Sysmon/Operational

要調整大小,用 sl 搭配 /ms:(單位是位元組)。官方說明:最小值為 1048576 位元組(1024 KB),而且檔案一律是 64 KB 的倍數,填進去的值會被四捨五入。例如設成 512 MB:

wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:536870912

想長期保存就定期匯出成 .evtx:

wevtutil epl Microsoft-Windows-Sysmon/Operational C:\Logs\sysmon-20260825.evtx

wevtutil sl 還有兩個參數值得知道:/rt:true 是「滿了就保留舊事件、丟掉新事件」,/rt:false 則是「新事件覆蓋最舊的」;/ab:true 是滿了自動備份,但官方註明使用 /ab:true 時 /rt 也必須設為 true。

🔬 底層機制:Sysmon 到底攔在哪一層?

這一段是 Sysmon 和一般「記錄工具」的分水嶺,也是它為什麼看得到別人看不到的東西。

第一,它有一支驅動程式,而且是 boot-start driver。 官方寫得很直接:驅動程式以開機啟動方式安裝,以便從開機非常早期就開始擷取活動,那段時間服務還沒起來,事件會先累著、等服務啟動再寫進事件記錄檔。這也是官方敢說「可以捕捉到即使是精密核心模式惡意程式所做的活動」的依據。相對地,任何跑在使用者模式的監控程式,都得等系統起來才有機會看。

第二,服務以受保護處理程序(protected process)執行。 官方說明這麼做是為了「阻擋大範圍的使用者模式互動」——白話講,就是讓一般權限的程式沒辦法隨便去戳 Sysmon 服務。這是防竄改設計,不是效能設計。

第三,ProcessGUID 解決了 PID 重用問題。 Windows 的 PID 是會被回收再用的,同一個 4712 今天是瀏覽器、明天可能是別的東西,事後拼時間軸時就會對錯。官方說明 Sysmon 在處理程序建立事件裡放了一個跨網域唯一的 ProcessGUID,另外每筆事件還帶 session GUID 用來關聯同一個登入工作階段。這是「事後追查」和「即時觀察」在資料結構上的根本差別。

第四,也是最重要的認知——這件事官方分寫在兩份文件裡:Sysinternals 下載頁寫的是「不分析它產生的事件」與「不會試圖對攻擊者隱藏自己」;Windows 的「Sysmon 做什麼、不做什麼」一節寫的則是「不分析事件、不產生警示」與「不阻擋或阻止行為」。合起來看就是四件事:不分析、不警示、不阻擋、不隱藏。 換句話說,它是一台品質很好的行車記錄器,不是保全。真正的分析要靠你自己讀、或送進 Windows Event Collection、SIEM 之類的收集端。攻擊者只要有系統管理員權限,一樣看得到 Sysmon 裝在這裡。

那 Windows 內建的 4688 稽核呢?

Windows 本身就有處理程序建立稽核(安全性記錄檔 Event ID 4688),不用裝任何東西,但要開兩個原則,而且預設兩個都是「未設定」:

• Audit Process Creation(位置:電腦設定 → 原則 → Windows 設定 → 安全性設定 → 進階稽核原則設定 → 詳細追蹤),這個開了才會有 4688。
• Include command line in process creation events(位置:系統管理範本 → 系統 → 稽核處理程序建立),這個開了 4688 才會帶命令列。

微軟在這份文件裡放了一段很少人引用、但很關鍵的警語:啟用命令列稽核後,命令列資訊會以純文字寫進安全性記錄檔,任何有權限讀取安全性事件的使用者,都能讀到所有成功建立處理程序的命令列引數;而命令列引數可能包含密碼或使用者資料等敏感或私人資訊。

這句話的實務意義是:內建方案不是「免費的 Sysmon」,它把敏感字串寫進一個相對多人讀得到的記錄檔。要澄清一個常見誤解:4688 這條線並非完全沒有雜湊——同一份更新會把可執行檔的 SHA1/2 雜湊寫進 AppLocker 事件記錄檔(Applications and Services Logs\Microsoft\Windows\AppLocker),只是雜湊跟 4688 不在同一個記錄檔裡,查起來要跨兩處。真正拿不到的是 ProcessGUID、網路連線與 DNS 事件。另一方面,內建方案也有它的優勢——不額外安裝非內建(non-inbox)的核心驅動、不新增攻擊面、群組原則就能大規模部署。

還有一個實務細節容易忽略:使用進階稽核原則時,要確認它不會被基本稽核原則覆蓋。微軟文件指出,設定被覆寫時系統會記錄 Event 4719,而避免衝突的做法是啟用「稽核:強制稽核原則子類別設定覆寫稽核原則類別設定」。

🔙 萬一翻車:回退步驟

情境一:事件太多,記錄檔一天就被灌爆

先確認是哪一種事件在洗版(通常是 Event ID 7 Image loaded 或 10 ProcessAccess),回到設定檔用 exclude 規則把已知正常的來源排掉,再重新套用:

sysmon64 -c C:\Tools\Sysmon\sysmon-config.xml

覺得設定改壞了、想回到官方預設,官方提供了這條:

sysmon64 -c --

情境二:安裝後系統或某個程式明顯異常

先確認異常時間點是否與安裝時間吻合,並到 Sysmon 記錄檔查有沒有 Event ID 255(Error)——官方說明這是 Sysmon 內部發生錯誤時產生的事件,可能出現在系統負載過高、某些工作無法完成,或安全性與完整性條件未達成時。若確定與 Sysmon 相關,直接走情境三移除即可,不需要重新開機。

情境三:要完全移除

sysmon64 -u

若安裝不完整導致移除失敗,官方提供強制參數:

sysmon64 -u force

官方明訂 -u force 的行為是「即使部分元件未安裝也繼續執行移除」。移除後別忘了三件收尾:①先把還要留存的事件用 wevtutil epl 匯出;②用 Get-Service sysmon* 確認服務真的不見了(要改走 Windows 11 內建版的話,這一步是官方要求的前置檢查);③如果你有啟用檔案封存功能,磁碟根目錄可能留有封存資料夾(ArchiveDirectory 預設名稱為 Sysmon,官方說明該目錄受 System ACL 保護),請確認是否還需要保留。

💡 總結:進階玩法與底層邏輯

站長我把 Sysmon 定位成「Windows 上最划算的一次性投資」——設定一次,之後每次出事都少花好幾個小時。但有三個心態要先擺正:

第一,它是記錄器,不是防護。 不分析、不警示、不阻擋、不隱藏這四點,分別出自 Sysinternals 下載頁與 Windows 官方文件。裝了 Sysmon 不會讓你更安全,它只讓你在事情發生後查得出來。真正的防護還是 Windows 安全性中心、更新、以及不亂裝東西。

第二,設定檔才是本體。 執行檔版本(本文查證時獨立版為 v15.21)其實不太會影響你的日常使用,schemaversion 與規則寫法才是。官方特別說明 schema 版本與執行檔版本互相獨立,就是為了讓舊設定檔還能被新版解析——這是一個對長期維運很友善的設計。

第三,先窄後寬。 這是站長的個人建議、不是官方指引:先只開 Event ID 1 觀察一週,確認記錄檔成長速度可接受,再加 3(網路連線)與 22(DNS),最後才考慮 11、13。官方那句 Important 講的是事件量——未經最佳化的設定可能產生極高事件量、大規模部署前先審閱與測試——它並沒有替任何導入順序背書。反過來一次全開,結果通常是三天後把整個服務移除。

想再往下走,官方也提供 Sysmon for Linux 的 GitHub 專案,同一套事件模型可以延伸到 Linux 主機;而多台機器的情境,官方明講下一步就是把事件轉送到集中收集或 SIEM。

證據等級聲明:本文為官方文件與權威技術來源交叉查證所寫成(E3),非站長實機實測;文中所有版本號、事件 ID、參數與預設值均以查證日的微軟官方文件為準。你的環境若與本文描述不符,請以 sysmon64 -c 倒出的現行設定為準。

❓ 常見問題

Q:Sysmon 會不會拖慢電腦?

官方文件沒有給出量化的效能數字,所以任何具體百分比都不要輕信。但文件本身給了三個明確的「會很吃資源」的警訊:Event ID 7(Image loaded)監控所有模組載入「會產生非常可觀的記錄量」;Event ID 10(ProcessAccess)在有診斷工具反覆查詢處理程序狀態時「可能產生大量記錄」;Windows 文件則直接以 Important 標註「過度嚴格或未經最佳化的設定可能產生極高的事件量」。實務上的結論很清楚:效能問題幾乎都是設定檔開太寬造成的,不是 Sysmon 本身。

Q:Windows 11 的內建 Sysmon 和 Sysinternals 下載的版本可以一起裝嗎?

不行。官方明訂內建 Sysmon 不支援與獨立版並存,啟用內建功能前必須先用 Get-Service sysmon* 確認查不到既有服務,查得到就得先把獨立版移除。這是本文寫作時最容易踩到的一個坑——舊教學多半只講獨立版。

Q:裝了 Sysmon 還需要防毒軟體嗎?

需要,而且兩者不是同一件事。官方明白寫著 Sysmon 不阻擋行為(唯一的例外是 Event ID 27 FileBlockExecutable 與 28 FileBlockShredding 這兩個會實際阻擋的功能)。它不會判斷善惡、不會隔離檔案、不會通知你。把它當成防毒的替代品是最危險的誤解。

Q:我沒有網域環境,個人電腦裝這個有意義嗎?

有,但用途不同。個人機的價值主要在事後查證:哪個程式在什麼時候連了哪個網域(Event ID 3 與 22)、某支可疑執行檔是什麼時候被寫進來的(Event ID 11)、開機啟動項是被誰改的(Event ID 12/13)。搭配事件檢視器讀當機紀錄的基本功,自己就能把時間軸拼出來。

Q:這個方法在舊版 Windows 也適用嗎?

Sysinternals 獨立版官方標示的執行環境是用戶端 Windows 10 以上、伺服器 Windows Server 2016 以上,更舊的系統不在支援範圍;內建版則要求受支援版本的 Windows 11 或更新版本。另外要注意單一事件的相容性:Event ID 22(DNS 查詢)的底層遙測是 Windows 8.1 才加入的,Windows 7 以前沒有這個事件;而事件寫入位置在 Vista 以前的系統是 System 記錄檔而非獨立的 Sysmon 通道。

🔗 延伸閱讀

• Autoruns 教學:揪出藏在 Windows 開機啟動項裡的東西——Sysmon 的 Event ID 11/12/13 會告訴你「啟動項被改了」,Autoruns 則讓你當場看見改成什麼。
• Process Monitor 過濾與開機記錄教學——同樣來自 Sysinternals,適合需要更細顆粒度(單一檔案、單一登錄檔鍵值)的短時間深挖。
• ProcDump 教學:抓出應用程式沒回應與當機瞬間的記憶體傾印檔——當 Sysmon 告訴你哪支程式有問題,下一步就是抓它的傾印檔。
• NTFS 交替資料串流(ADS)是什麼——步驟四提到的 Event ID 15 就是專門盯 ADS 與 Zone.Identifier 網路標記的,先懂 ADS 才看得懂那個事件在報什麼。

📎 參考資料來源

📖 第一級|廠商官方:

• Sysmon v15.21 – Sysinternals(Microsoft Learn) — 2026-08-25 查證
• Enable and configure Sysmon in Windows(Microsoft Learn) — 2026-08-25 查證
• Command line process auditing(Microsoft Learn) — 2026-08-25 查證(⚠️ 該頁自載聲明:由微軟客服支援工程師撰寫、以 Windows Server 2012 R2 為背景、未經一般編輯流程;本文引用的是其中的群組原則官方描述文字)
• wevtutil 指令參考(Microsoft Learn) — 2026-08-25 查證
• SysmonForLinux(microsoft/SysmonForLinux,GitHub) — 2026-08-25 查證

📖 社群維護專案(非微軟發佈,但由微軟官方文件列為範例資源):

• SwiftOnSecurity/sysmon-config — 2026-08-25 查證
• olafhartong/sysmon-modular — 2026-08-25 查證
• trustedsec/SysmonCommunityGuide — 2026-08-25 查證

⚠️ 本文核心事實以第一級為準,社群專案僅供設定檔起手式參考,套用前請自行審閱內容。

📅 本文查證戳記:2026-08-25 依據 Sysmon v15.21 與 Microsoft Learn 官方文件撰寫,非實機實測。

若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。