舊版WinGUp會先從 notepad-plus-plus.org 下載一個 XML 描述檔，裡面包含新版本的下載連結，WinGUp 會依照該連結下載安裝程式，但下載後並未強制檢查該安裝程式的數位簽章（Digital Signature）與憑證（Certificate）
系統盲目信任了 XML 描述檔所提供的資訊。如果攻擊者能竄改 XML 內容，WinGUp 就會直接下載並執行攻擊者指定的惡意程式
一旦下載了偽造的 AutoUpdater.exe 或 update.exe，它就會在系統中執行
漏洞分類 CWE-494 (Download of Code Without Integrity Check)
CVSS 評分： 7.5 HIGH
修補建議 針對 CVE-2025–15556 Notepad++已經提供修復版本，確保環境内的 Notepad++ 已升級至 v8.8.9 或更新的版本（目前已有 v8.9.2）。
詳細資訊可以參考 Notepad++的網站說明 https://notepad-plus-plus.org/news/v889-released/
雖然 Notepad++ 官方在 2025 年 12 月釋出了 v8.8.9 修復了 WinGUp 的更新驗證漏洞，且Notepad++ 的開發者在2026 年 2 月 2 日發表聲明，表示這是因為 2025 年 6 月至 9 月期間發生的供應鏈層級攻擊事件，但根據卡巴斯基的研究報告，駭客對 Notepad++ 內部的未授權存取，實際上從 2025 年 6 月一直持續到 12 月底
關於該次供應鍊攻擊的技術細節可以查看卡巴斯基的研究報告
IOCs
以下指標來自卡巴斯基的公開報告與技術分析
惡意 Notepad++ 更新檔派送 URL
- http://45.76.155[.]202/update/update.exe
- http://45.32.144[.]255/update/update.exe
- http://95.179.213[.]0/update/update.exe
- http://95.179.213[.]0/update/install.exe
- http://95.179.213[.]0/update/AutoUpdater.exe
接收受害系統資訊回傳 URL
Metasploit Downloader 派送 Cobalt Strike Beacon 之中繼 URL
- https://45.77.31[.]210/users/admin
- https://cdncheck.it[.]com/users/admin
- https://safe-dns.it[.]com/help/Get-Start
由惡意 Notepad++ 更新程式植入之 Cobalt Strike Beacon C2 URL
- https://45.77.31[.]210/api/update/v1
- https://45.77.31[.]210/api/FileUpload/submit
- https://cdncheck.it[.]com/api/update/v1
- https://cdncheck.it[.]com/api/Metadata/submit
- https://cdncheck.it[.]com/api/getInfo/v1
- https://cdncheck.it[.]com/api/FileUpload/submit
- https://safe-dns.it[.]com/resolve
- https://safe-dns.it[.]com/dns-query
LAB 測試
為了在地端驗證這個 CVE，本次測試採用 MitM (中間人攻擊) 架構，透過區域網路劫持與憑證偽造，來「模擬」官方伺服器遭入侵、流量被惡意引導的情境
免責聲明/Disclaimer:
本文僅供資安教育與防禦研究使用，所有實驗皆於封閉合法測試環境中進行，作者不對任何未經授權之利用行為負責。本文亦不提供任何可執行檔案、腳本或下載連結。
本實驗共包含三台虛擬主機：
- 受害主機 (Windows 10/11)：
192.168.1.10(安裝存在漏洞的舊版 Notepad++) - 模擬遭滲透的官方伺服器 (REMnux)：
192.168.1.104(利用 MitM 手法攔截流量、偽造 HTTPS 並派發惡意更新檔) - C2 監聽伺服器 (Kali Linux)：
192.168.1.19(負責接收 Payload 觸發後的反彈 Shell)
階段一：流量劫持 (模擬基礎設施遭駭)
在真實攻擊中，駭客直接控制了更新檔的位置，在 Lab 中，我們透過修改受害主機的本機 DNS 解析來模擬這個「流量被導向惡意節點」的結果
以系統管理員身分修改 C:\Windows\System32\drivers\etc\hosts
階段二：在 REMnux 產生偽造的 SSL 憑證
真實的攻擊者因為控制了官方伺服器，自然擁有合法的 SSL 憑證。但我們的 REMnux 是一台偽造的伺服器，為了繞過 Windows Schannel 嚴格的 HTTPS 憑證檢查（避免跳出 SEC_E_UNTRUSTED_ROOT 錯誤），我們必須在 Lab 中建立一套偽造的 PKI (公開金鑰基礎建設) 信任鏈
將 Fake CA 匯入 Windows 受害機的「本機電腦 -> 受信任的根憑證授權單位」
搜尋 Windows 的「網際網路選項」，切換到「內容」標籤，點擊「清除 SSL 狀態」
在 Windows 上點擊該憑證檔案，點選「安裝憑證」
存放位置選擇 「本機電腦」
關鍵步驟：選擇「將所有憑證放入以下的存放區」，點擊「瀏覽」，然後選擇 「受信任的根憑證授權單位」 (Trusted Root Certification Authorities)
階段三：模擬替換更新檔的惡意程式
使用 REMNUX 下載惡意程式 (稍後讓使用者點擊更新時實際執行的惡意程式)
REMNUX 開啟網頁服務 (模擬 Notepadd++實際下載的站點)
惡意程式的聆聽端
階段四：執行 Notepad++ 安裝/更新
Windows 下載尚未更新漏洞版本的 notepad++
點擊? 中的更新 Notepad++
點擊好
REMNUX 收到檔案請求
點擊是，繼續安裝
這時候惡意程式就直接執行了
總結
攻擊者利用了使用者對知名軟體的信任，透過竄改官方伺服器上的更新描述檔，將更新路徑導向惡意檔案。由於軟體本身的更新機制缺乏完善的完整性檢查 (Integrity Check)，導致使用者在不知情的情況下，主動下載並執行了後門程式。
防禦與應對建議：
- 立即修補： 盡快將環境內的 Notepad++ 更新至 v8.8.9 以上版本
- 主動獵捕 (Threat Hunting)： 藍隊人員可利用 Rapid7 及卡巴斯基提供的 IOCs 清單，透過企業內的 NDR 尋找比對可疑的流量，或利用 EDR 檢查端點是否有
gup.exe產生的異常子程序，確保內部環境未遭滲透
到這邊本次的測試就結束了，謝謝大家