資安研究員 Chaotic Eclipse 在四月初似乎因為對微軟通報漏洞的流程不滿，而公佈了一個可以提權的漏洞 BlueHammer ，根據https://www.ithome.com.tw/news/175055 報導該漏洞已經被微軟登記為CVE-2026–33825 並進行修補，有詳情有興趣的話可以到該研究員的部落格看整個事情的經過

而該研究員於 4/16 又公布了新的提權漏洞 RedSun ，研究員在Github上有提供該漏洞的POC

https://github.com/Nightmare-Eclipse/RedSun/tree/main

該漏洞攻擊原理

該攻擊是利用 Cloud Files API (cldapi.dll)規避了原本 Windows 作業系統 針對高權限的處理程序（例如 SYSTEM）試圖存取一個路徑，且該路徑中包含一個 Reparse Point（重新解析連結）時的檢測，原本當 Defender 等高權程式執行到低權限建立的連結時，且高權限行程沒有明確宣告要跟隨該連結，系統會直接回傳存取被拒

而 Cloud Files API 是 Windows 為了要讓像 OneDrive 等雲端資料能夠像在本機硬碟，實際點擊時才從雲端下載所開發的，與對應的濾驅動程式 cldflt.sys (Cloud Files Mini Filter Driver)一起使用

所以當攻擊者透過呼叫 CfRegisterSyncRoot將惡意目錄註冊為Sync Root後，系統會在惡意目錄中貼上一個特殊的隱藏標籤（IO_REPARSE_TAG_SYNC_ROOT），後續當 Defender 在該目錄要掃描誘餌檔案時，攻擊者利用 Oplock (投機鎖) 卡住 Defender 的讀取請求，創造出 Race Condition 的時間窗，將目錄偷換成指向 System32 的掛載點，當鎖定解除後Defender 看到 Sync Root 標籤，會將處理邏輯直接交給 cldflt.sys，不會直接檢查權限

cldflt.sys 的設計初衷是為了解決雲端同步時複雜的路徑資料處理，在這套 I/O 處理流程中，它錯誤地放寬了對 Reparse Point 的權限檢查。它可能假設既然這是一個合法的 Sync Root 操作，裡面的路徑轉換應該是雲端供應商的正常行為，藉此規避防禦讓攻擊者可以成功將存取點轉移至 System32

該漏洞攻擊過程

攻擊者在一般使用者權限下執行初始惡意程式，該程式會在暫存目錄（例如 %TEMP%\test）下，建立一個名為 TieringEngineService.exe 的誘餌檔案，並寫入病毒特徵碼，此檔名故意與 System32 目錄下受保護的真實系統服務同名，當此行為觸發 Defender 來掃描時，初始惡意程式會立刻對該誘餌檔案發出 FSCTL_REQUEST_BATCH_OPLOCK (批次投機鎖) 指令，強制將 Defender 的讀取與掃描請求暫停 (Pending)

接著，初始惡意程式呼叫 Windows Cloud Files API (CfRegisterSyncRoot)，將該暫存目錄(%TEMP%\test)註冊為一個自訂的雲端同步資料夾，這項操作會對該目錄貼上隱藏的 Sync Root 標籤，迫使系統的 I/O 管理員在後續處理該目錄時，套用雲端過濾驅動程式 (cldflt.sys) 的邏輯分支，從而規避掉系統原本針對惡意重新導向的嚴格防護機制。

趁著 Defender 的執行緒還被 Oplock 卡住，初始惡意程式迅速將原本的 %TEMP%\test 目錄更名移走，並在原地重新建立一個空的 test 目錄，隨後對這個新目錄發出 FSCTL_SET_REPARSE_POINT 控制碼，將它設定為一個指向 \??\C:\Windows\System32 的掛載點 (Mount Point)

當初始惡意程式釋放 Oplock 後，Defender 根據先前的路徑記憶繼續執行隔離操作卻順著 Reparse Point 被重新導向至受保護的 System32 目錄，由於攻擊者事前已透過 CfRegisterSyncRoot 將該目錄註冊為雲端同步資料，當 Defender 以高權限在該目錄內進行操作時，Windows I/O 管理員會將處理邏輯交接給雲端過濾驅動程式 (cldflt.sys)，不正常地放寬了對 Reparse Point 的安全性檢查，導致原本的 Windows 防護暫時失效

趁著 Defender 防護空窗期，RedSun 程式的背景迴圈立刻透過 FILE_SUPERSEDE (強制取代)指令，將自己的惡意 Payload 強制覆寫進合法的系統服務檔中

覆寫完成後，初始惡意程式透過呼叫對應的 COM 物件 (CLSID)，強制系統啟動該服務，此時，Windows 會以 NT AUTHORITY\SYSTEM 的最高權限，執行已經被調包的目標惡意 Payload，取得 SYSTEM 權限的 Payload 啟動後，為了能與當前桌面使用者互動，它會尋找並連回初始惡意程式預先建立好的 Named Pipe (命名管道) 進行跨權限通訊 (IPC)，Payload 透過這個自訂的 Pipe 通道獲取當前使用者的 Session ID，接著複製 SYSTEM 的 Token，並呼叫 CreateProcessAsUser，最終在使用者的桌面上彈出一個具備最高權限的命令提示字元 (cmd.exe)

實際測試

該實際測試於4/19，但發現在 4/18 微軟已將該支 PoC 程式 (RedSun.exe) 標記為已知威脅，由於該測試必須開啟 RealTime Protection ，藉由誘騙防毒引擎進行掃描來觸發漏洞，測試過程需透過設定特定排除目錄來允許 PoC 運行，雖然本次測試在最後的提權階段並未成功彈出 SYSTEM 權限的命令提示字元 ，經分析，其失敗主因是 Defender 對目標檔案下達了等待刪除 (DELETE PENDING)標記，導致 Windows 核心拒絕載入該處理序，但依然能透過此次測試的 Procmon 遙測紀錄，完整檢視並驗證該攻擊如何成功繞過Windows的IO防護

沒有成功提權，但還是可以從該次測試檢視關於該攻擊對於系統產生的實際行為

檢視 hash 與作者 github 一致 sha256:57a70c383feb9af60b64ab6768a1ca1b3f7394b8c5ffdbfafc8e988d63935120

實際執行 RedSun.exe

可以發現在 16:52:23 RedSun.exe 在%TEMP%中建立了TieringEngineService.exe

同時間 Windows Defender 偵測到TieringEngineService.exe含有惡意程式碼

也觀察到RedSun.exe在執行時載入cldapi.dll

16:52:43 RedSun.exe 對TieringEngineService.exe檔案發出 FSCTL_REQUEST_BATCH_OPLOCK (批次投機鎖) 請求

接著 MsMpEng.exe 對TieringEngineService.exe檔案的 CreateFile 的結果變成 CANNOTBREAK OPLOCK ( Defender 被鎖住)

在 Defender 被 Oplock 鎖住時，RedSun.exe (PID 5672) 對 %TEMP%\RS-{8CFC8DAC-08E7–4588-A751–7592ED40B873}這個目錄更名為 %TEMP%\RS-{8CFC8DAC-08E7–4588-A751–7592ED40B873}.TEMP2 移走

然後在原地重新建立一個空的 %TEMP%\RS-{8CFC8DAC-08E7–4588-A751–7592ED40B873} 目錄

接著RedSun.exe (PID 5672) 對 %TEMP%\RS-{8CFC8DAC-08E7–4588-A751–7592ED40B873} 這個目錄送出了 FSCTL_SET_REPARSE_POINT (設定重新解析點) 控制碼，而且回傳值是 SUCCESS

因為 Cloud API 的狀態混淆，Windows 的防禦失敗，RedSun 成功對原本的系統服務檔C:\Windows\System32\TieringEngineService.exe 發出了 CreateFile 請求，並帶有 Disposition: Supersede 參數，此參數為若檔案存在則強制完全取代，該操作成功執行 (SUCCESS)，標誌著合法的系統服務檔在此微秒被實體摧毀，目標路徑僅留下一個合法的空檔案控制代碼 (Handle)

在檔案遭摧毀後，RedSun.exe 立刻對同一個空檔案發出 SetEndOfFileInformationFile 控制碼， 日誌顯示其將檔案的 EndOfFile (檔案結尾) 屬性設定為 156,160 位元組，此步驟為 Windows 複製檔案的標準底層行為，目的是在寫入資料前，先向檔案系統 (NTFS) 索取連續且足夠的磁碟區塊，以容納即將到來的惡意負載

後續RedSun.exe (PID 5672) 對自己的原始執行檔路徑 C:\BypassZone\RedSun.exe 發動了連續的 ReadFile (讀取檔案) 請求，仔細計算其讀取的位元組長度 (Length)：第一段讀取了 131,072 bytes，緊接著第二段讀取了 25,088 bytes，兩者相加的總和剛好是 156,160 bytes，與上個階段目標檔預先分配的空間大小 (156,160) 完全一致

如 Procmon 紀錄所示，Defender 原本的是針對 %TEMP% 目錄下的病毒誘餌執行隔離與刪除，但因為攻擊程式精準掌握了 Oplock 釋放的時間窗，並透過 FSCTL_SET_REPARSE_POINT 將目錄重新導向至 C:\Windows\System32，導致 Defender 挾帶其高權限，將操作直接執行在受 Windows核心I/O保護的系統服務檔案 TieringEngineService.exe 上

雖然攻擊程式成功利用路徑導向與 Cloud API 混淆完成了實體檔案的寫入，但 Defender 在後續處理中對該路徑下達了延遲刪除標記，在 Windows 核心機制中，帶有 DELETE PENDING 標籤的檔案會被 Process Manager 拒絕載入記憶體，因此，當攻擊程式最後試圖透過 COM 物件呼叫並以 SYSTEM 權限啟動該 Payload 時，系統直接拒絕執行

本次測試 SYSTEM 提權攻擊因為防毒軟體的干擾而失敗，但透過的雜湊值 (Hash) 比對結果，確認了任意檔案寫入階段成功

原本位於 C:\BypassZone\RedSun.exe 的惡意 Payload，其 SHA256 雜湊值 (57a70c383feb9af60b64ab6768a1ca1b3f7394b8c5ffdbfafc8e988d63935120) 與系統核心目錄下的 C:\Windows\System32\TieringEngineService.exe 完全一致。

這證明了攻擊程式成功利用了 Windows Cloud Files API (cldapi.dll) 產生的狀態混淆，在目錄被重新導向的瞬間，系統 I/O 管理員將針對該路徑的寫入請求誤判為合法的雲端同步行為，從而讓惡意程式得以無視 Windows核心I/O的嚴格權限防護，直接用自身的惡意二進位碼覆寫了合法的系統服務檔

沒有成功跳出S YSTEM 權限 cmd

本次的測試到這邊就結束了，比較意外的是該次測試是下午，但在晚上21點，想再測試時已經無法將惡意檔案寫入 System32 中了，懷疑 Defender 的掃描引擎可能又修正了偵測機制