什麼是 WDAC 操縱攻擊以及如何防禦？

操縱攻擊 Windows Defender的 應用程式控制（WDAC）已經變成一種非常嚴重的 靜默防禦，例如 EDR 和 Microsoft Defender 在企業環境中。這種趨勢並非科幻小說：研究人員已經觀察到威脅組織如何改變程式碼完整性，以阻止驅動程式和安全服務從 開機.

除了標題之外，了解它們的工作原理以及它們會留下哪些信號，是確保 SOC 和響應團隊不被蒙在鼓裡的關鍵。在本分析中，我們將重點放在 WDAC處理技術、實用指標和緩解措施，而且在 WDAC 的合法使用中（例如，在 HoloLens 2 或 Windows 管理中心），以及它與無文件威脅和濫用的關係 PowerShell的 和 LOLBins。

什麼是 WDAC 操縱攻擊？

WDAC 是 Windows 應用程式控制技術，可限制哪些二進位檔案、腳本、MSI 安裝程式甚至 核心級程式碼 被授權運行。本質上，它使用允許列表方法，根據簽名、發布者、哈希、路徑、目錄等建立程式碼完整性策略。

攻擊者已經學會了扭轉這種邏輯：當他們獲得足夠的權限時，他們會改變或部署 WDAC 策略來 專門阻止安全組件 (驅動程序 以及 EDR 二進位（包括 Microsoft Defender），在使用額外的有效載荷之前降低可見性和防禦響應能力。

發生了什麼以及它們如何運作

觀察到的技術涉及修改程式碼完整性策略，以便它們不會被載入。 保全服務和司機 在啟動過程中。最常見的罪魁禍首是 SiPolicy.p7b 策略文件，Windows 將其位於「C:\\Windows\\System32\\CodeIntegrity\\」。

透過更改該文件或強制使用替代策略，攻擊者可以針對已知的 EDR 路線和驅動程式（例如，CrowdStrike、SentinelOne、Symantec、Tanium）以及 EDR 本身引入阻止規則。 Microsoft Defender 終結點Microsoft Defender Endpoint這大大降低了防禦標準，為以較低的被發現機率行動提供了機會。

除了更改文件之外，還有一些註冊表訊號值得關注。特別是，Windows DeviceGuard 中「ConfigCIPolicyFilePath」和「DeployConfigCIPolicy」鍵的變更可能表明 未經授權部署 WDAC 策略 或將其用於惡意目的。

另一種常見的操作路線是使用誘餌：人們觀察到一些看似無害的文件（例如所謂的“PDF”），但實際上 旨在強制執行惡意策略的 WDAC 二進位文件 默默地實現持久性和防禦的逐步失效。

從克魯格計劃到 DreamDemon 威脅

這一演變凸顯了從用 .NET 編寫的概念驗證 Krueger 到更成熟的 DreamDemon 系列的飛躍，該系列重新實現了 在 C++ 中提高效率和彈性雖然 Krueger 證明了可行性，但 DreamDemon 在現實環境中自動化並強化了 WDAC 策略修改技術。

DreamDemon 的目標很明確：修改 WDAC 以防止載入 來自多個供應商的服務和驅動程式 安全性，包括 Microsoft Defender 生態系統。停用感測器後，攻擊者可以減少摩擦，從而降低被發現的可能性，執行額外的有效載荷、橫向移動或洩漏資料。

需要注意的指標和跡象

在與此活動相關的遙測資料中，SHA-256 雜湊值已被共享，安全團隊可以將其用作搜尋點和操作情報。以下是兩個範例 相關 IoC 連結：

• 90937b3a64cc834088a0628fda9ce5bd2855bedfc76b7a63f698784c41da4677
• a795b79f1d821b8ea7b21c7fb95d140512aaef5a186da49b9c68d8a3ed545a89

除了 IoC 之外，監控「程式碼完整性」和 DeviceGuard 事件並設定警報也是一個好主意 對“ConfigCIPolicyFilePath”和“DeployConfigCIPolicy”的更改在變更過程之外或非典型時間偵測 WDAC 策略部署是一個危險訊號。

還值得關注的是附件或 下載 實際適用的所謂文件 惡意 WDAC 策略這種模式適合尋求持久性和沈默防禦的活動，為勒索軟體等更大的威脅鋪平道路。

對公司和政府的影響

如果攻擊者成功阻止 EDR 和 Defender 的加載，環境就會陷入一種操作的昏暗狀態：可見性降低，關聯性和響應能力被削弱，並且 橫向移動、滲透和加密對 SOC 來說，這確實是遊戲規則的改變者。

克魯格跳到 DreamDemon 表明，對抗 WDAC 的技術已經成熟並工業化。因此，它在今天至關重要。 提高可觀察性 透過端點信任鏈、儀器程式碼完整性遙測以及彌補策略管理差距。

建議和緩解措施

在預防層面，第一步是加強對 WDAC 和 Defender 的變更控制，並了解如何 屏蔽視窗. 在應用任何 SiPolicy.p7b 或補充政策並保護部署管道，以便只使用可信任來源。

• 限制管理員權限並要求對安全任務和策略部署進行 MFA，減少濫用的表面。 特權憑證.
• 審核並警告 DeviceGuard 修改（尤其是“ConfigCIPolicyFilePath”和“DeployConfigCIPolicy”）和代碼完整性事件。
• 在所有端點上啟用並驗證 Microsoft Defender 篡改保護 避免局部操縱.
• 強化 EDR/AV：控制允許清單、阻止未簽署的驅動程式以及重複規則審查。
• 優先考慮 Windows 和應用程式更新：修補程式和偵測可提高抵禦 新興技術.
• 使用者訓練：對意外的附件和假定的 PDF 要特別小心；請務必驗證來源。

HoloLens 2 上的 WDAC：應用程式控制，不會與資訊亭模式混淆

在 HoloLens 上，WDAC 允許您阻止 應用程式啟動. 與資訊亭模式（隱藏 應用程序 但允許您啟動它們），使用 WDAC，您可以查看它們但不能運行它們。此外，一個設備可以擁有多個 WDAC 策略，如果它們匹配， 最嚴格的限制.

許多管理員會使用 PowerShell 和 Microsoft Intune 來建立規則。通常，第一步是使用類似「Get-AppxPackage -name *name*」的命令來定位應用程式套件。例如，對於 Edge，運行“Get-AppxPackage -name *edge*”可能會返回 各種結果，您可以在該清單中找到確切的名稱。

如果套件名稱不明顯，建議使用不同的近似值重複查詢，直到 找到鏈條 正確。一旦識別，對應的規則將會加入到策略（newPolicy.xml）中或透過精靈新增。

對於 HoloLens 2 上預先安裝的常用應用，以下是 套件系列名稱 通常包含在規則中（代表性摘錄）：

應用	包系列名稱
3D 檢視器	Microsoft.Microsoft3DViewer_8wekyb3d8bbwe
App安裝程序	Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
日曆/郵件	microsoft.windowscommunicationsapps_8wekyb3d8bbwe
相機	HoloCamera_cw5n1h2txyewy
反饋中心	Microsoft.WindowsFeedbackHub_8wekyb3d8bbwe
微軟商店	Microsoft.WindowsStore_8wekyb3d8bbwe
影視	Microsoft.ZuneVideo_8wekyb3d8bbwe
OneDrive	microsoft.microsoftskydrive_8wekyb3d8bbwe
FOTOS	Microsoft.Windows.Photos_8wekyb3d8bbwe
組態	HolographicSystemSettings_cw5n1h2txyewy

如果你想阻止新的 微軟邊緣 具體來說，可以透過檔案名稱新增拒絕規則，例如： <Deny FriendlyName='C:\\Data\\Programs FileRule' PackageVersion='65535.65535.65535.65535' FileName='msedge.exe' />. 該指令 將阻止執行 指示的二進位。

如果您沒有列出該應用程式，Device Portal 是一個有用的資源。連接 HoloLens 2，前往“視圖”>“應用程式”，選擇該應用程式，然後找到 PackageRelativeID。複製“!”之前的內容以獲取 包系列名稱 您可以在 WDAC 中使用它。

Windows Admin Center 與 WDAC 應用程式環境

WDAC 還可以限制腳本並在 PowerShell 中啟用 ConstrainedLanguage，這會影響 Windows管理中心 （WAC）。當您使用 WDAC 連線至伺服器或群組時，WAC 會在「概覽」頁面上顯示狀態，例如 PowerShell 語言是否處於受限模式。

關鍵要求：主機上的標準安裝、主機和管理節點上的本機管理員權限、正確的網路配置（WinRM HTTP 5985、HTTPS 5986）以及透過 TCP 連接埠 445 的 SMB 存取。建議 WAC 和節點位於同一網路上。 同一網域或具有信任，特別是用於身份驗證和管理。

關於策略，需要考慮以下常見情況。情況 1：只有託管節點套用 WDAC；您只​​需在節點原則中授權 Microsoft 簽署者即可。情況 2：WAC 主機和節點都套用 WDAC；您必須 包括其他簽署人 （例如，Microsoft 第三方應用程式元件和.NET）在 WAC 主機上。

簽署者規則範例（可以使用精靈或 PowerShell 生成，然後進行審查）： <Signer Name='Microsoft Code Signing PCA 2011'><CertRoot Type='TBS' Value='F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E' /><CertPublisher Value='Microsoft Corporation' /></Signer>對於案例2，他也補充： <Signer Name='Microsoft Code Signing PCA 2011'><CertRoot Type='TBS' Value='F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E' /><CertPublisher Value='Microsoft 3rd Party Application Component' /></Signer> y <Signer Name='Microsoft Code Signing PCA 2011'><CertRoot Type='TBS' Value='F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E' /><CertPublisher Value='.NET' /></Signer>.

如果您使用的 WAC 版本低於 2410，則可能不需要「.NET」規則，但您可能需要在 WAC 主機上設定特定的檔案或雜湊規則。例如，允許 WiX 函式庫： <FileRules><Allow FriendlyName='WiX wixca.dll' Hash='9DE61721326D8E88636F9633AA37FCB885A4BABE' /><Allow FriendlyName='WiX wixca.dll' Hash='B216DFA814FC856FA7078381291C78036CEF0A05' /><Allow FriendlyName='WiX wixca.dll' Hash='233F5E43325615710CA1AA580250530E06339DEF861811073912E8A16B058C69' /><Allow FriendlyName='WiX wixca.dll 2' Hash='EB4CB5FF520717038ADADCC5E1EF8F7C24B27A90' /><Allow FriendlyName='WiX wixca.dll 2' Hash='6C65DD86130241850B2D808C24EC740A4C509D9C' /><Allow FriendlyName='WiX firewall.dll' Hash='2F0903D4B21A0231ADD1B4CD02E25C7C4974DA84' /><Allow FriendlyName='WiX firewall.dll' Hash='868635E434C14B65AD7D7A9AE1F4047965740786' /><Allow FriendlyName='WiX firewall.dll' Hash='5C29B8255ACE0CD94C066C528C8AD04F0F45EBA12FCF94DA7B9CA1B64AD4288B' /></FileRules>。 這個 方便安裝和模組 WAC 需要的。

關於 PowerShell 執行策略，預設設定通常就足夠了。如果您要更改它，請將“LocalMachine”範圍設為“RemoteSigned”，以允許載入已簽署的腳本。僅在以下情況下進行更改： 至關重要 並記錄風險。

已知問題和故障排除

應用 WDAC 存在一些限制。例如，不支援在 Azure Local 上部署 Azure Kubernetes 服務以及透過 WAC 橋接 Azure Arc 資源。 在具有 WDAC 的環境中受支援單一伺服器 RBAC 和一些憑證工具操作也有限制。

如果 WAC 顯示“模組未找到”或“連線失敗”，請檢查“Microsoft.SME.*”模組是否已傳輸至節點（“%PROGRAMFILES%\\WindowsPowerShell\\Modules”目錄）。如果沒有，請重試連線。此外，請驗證 WAC 主機是否有權訪問 TCP 連接埠 445 節點的 SMB 通訊。

無檔案惡意軟體、PowerShell 和 LOLBins：WDAC 濫用的完美環境

El 惡意軟件 無檔案攻擊無需將持久性檔案寫入磁碟即可造成破壞：它會在記憶體中運行所有內容或濫用內建工具，因此很難被偵測到。一些備受矚目的案例包括： 2016 年民主黨全國委員會的承諾以及活動（例如，由拉撒路組織發起）已觀察到 Word 在 Windows 和 macOS 上使用 LOLBins 在記憶體中執行程式碼。

常見的無文件攻擊類型包括惡意文件和腳本、濫用 Living Off the Land Binaries (LOLBins) 以及記憶體注入技術。內存易失性高，因此攻擊者通常會尋求 持久性機制 以在重啟後繼續生存。

PowerShell 和 WMI/CIM 是最受歡迎的。 PowerShell 非常強大且靈活，如果輸入不受控制，提示注入可能會被利用，導致遠端執行、資料外洩或 權限提升. WMI 提供了一個管理和訂閱層，也可以利用其實現持久性和移動性。

攻擊者用於腳本的工具包括「powershell.exe」、「wscript.exe」、「cscript.exe」、「cmd.exe」或「mshta.exe」。此外，攻擊者也會濫用本機二進位文件，例如“regsvr32.exe”、“rundll32.exe”、“certutil.exe”、“schtasks.exe”、“bitsadmin.exe”、“wmic.exe”、“cmstp.exe”、“msbuild.exe”、“cnet.exe”、“execurl”、“ 命令列運行工具 來自 Defender 本身。它們的組合可用於下載、執行、規避 UAC、橫向移動或嘗試繞過 WDAC 等控制。

在記憶體注入中，諸如「VirtualAllocEx」和「WriteProcessMemory」之類的 API 呼叫允許一個進程將程式碼寫入另一個進程。對於混淆，PowerShell 中提供了諸如 Invoke-Obfuscation 或 Invoke-DOSfuscation 之類的框架。 Linux 存在的 混淆工具 用於 bash（例如 Bashfuscator、SHC 等）。

緩解措施：不要開啟可疑附件，強化 RDP，啟用進階 PowerShell 日誌記錄（模組、 腳本 阻止、轉錄）、審核 WMI 中是否存在奇怪的訂閱、在適用時透過策略停用 Office 宏，並依靠分層安全性 網路和記憶體偵測，此外還要保持軟體更新。

現實場景：WDAC 阻止合法應用程式（學校案例）

一個常見的問題：IT 團隊想要阻止瀏覽器 手提 並且應用程式沒有「正確」安裝，但在審核模式下部署測試策略時，您會看到 合法的教育軟體 看起來像是違規行為，如果強制執行該策略，它將被阻止。即使您新增了允許規則（例如，允許「C:\\Math」中的所有檔案），事件檢視器也會顯示封鎖。

發生了什麼：WDAC 在設計上是一種允許列表技術，並且 規則優先級 是否相關（通常拒絕策略有效）。此外，如果有多個策略，則以限制性最強的策略為準。因此，如果存在另一個限制性更強的策略層，或者可信來源尚未完善，則允許規則可能會被忽略。

WDAC 能否只在拒絕清單模式下使用，讓其他所有流量都通過？這不是 WDAC 的原生方法，從長遠來看， 難以維持為了更有效地控制啟動，請使用審核模式，透過事件產生庫存，透過發布者規則（如果可用）、雜湊或非發布者應用程式的目錄進行細化，並評估其他策略或使用託管安裝程式/Intune 建立信任。

如果應用程式沒有發布者或簽名標識符，請考慮使用補償控制（嚴格的 ACL、變更控制）的每個資料夾規則，儘管理想的做法是遷移到 簽名規則 和目錄。另外，請檢查嚮導中是否包含對您的場景過於嚴格的模板；有時，從較為寬鬆的基礎開始，然後反覆收緊，有助於防止生產中斷。

PowerShell 中的提示注入攻擊及其與 WDAC 的關係

提示注入攻擊操縱輸入或上下文以誘導解釋器執行 命令 惡意。在 PowerShell 中，這可能導致遠端執行、資料外洩或服務帳戶洩露，如果 WDAC 已被 先前已中和.

最佳實踐：最小特權原則、專用帳戶和 JEA（Just Enough Administration，恰好足夠的管理）；避免使用“Invoke-Expression”，構造類型化參數，使用白名單驗證和清理輸入，要求腳本簽名，啟用 AMSI 和高級日誌記錄，並使用 AppLocker 或 WDAC 限制執行在架構上，分離環境，隔離關鍵流程、網路控制以及與 SIEM 整合的集中審計。

在 CI/CD 管線中加入 SAST、程式碼審查和以注入為導向的滲透測試。自動化驗證，阻止不符合策略的部署。有專門的公司提供以下服務： 設計防禦、強化、AppLocker/WDAC 配置、與 SIEM 整合的高級日誌記錄和自動響應，以及可視化風險的商業智慧。

由此可見，WDAC 既是攻擊目標，也是盟友：當攻擊者操縱它來壓制感測器時，組織就會失去可見性；如果管理得當，它就會成為一道堅實的屏障。關鍵在於強化信任鏈（簽章和驗證策略），監控 SiPolicy.p7b 和 DeviceGuard，強化 Defender 和 EDR，改善 PowerShell 安全，以及 減少攻擊面 對抗無文件和 LOLBins，依靠遙測和嚴格的變更控制。