要確保 SharePointServer 儲存庫的安全性，必須在其內建的防毒功能之上疊加多層控制措施；因為該防毒功能僅在檔案上傳或下載時，使用單一掃描引擎對每個檔案進行一次掃描。Multiscanning、CDR（內容解除武裝與重建）、DLP（資料外洩防護）以及持續重新掃描，才能填補那些讓惡意軟體和勒索軟體得以潛伏的漏洞。
關鍵要點
- SharePointServer內建防毒功能（VSAPI 或 AMSI）僅 在檔案上傳或下載時， 使用單一掃描引擎 對每個檔案進行掃描。 它絕不會重新掃描已儲存的檔案。
- 一個在首日被評定為「乾淨」的檔案，其評定結果將永久有效；因此，當簽名檔和偵測模型不斷改進之際，惡意軟體和勒索軟體便能隱匿其中而不被察覺。
- 版本歷史紀錄加劇了資料外洩的風險：每份保留的副本都與當前檔案一樣，存在未經掃描的靜態資料風險。
- 2025 年 7 月發生的ToolShell/Warlock 攻擊事件顯示，攻擊者植入了網路殼層檔案，而單引擎的特定時間點掃描本就無法偵測此類檔案。
- 要彌補這項漏洞，需要一套多層次的控制機制。該機制在原生掃描功能之外，還增加了多重掃描、CDR（內容無害化與重建）、DLP（資料外洩防護）以及持續重新掃描等功能。
- MetaDefender Security™ 是OPSWAT企業級資料保護平台，運用 Metascan™ Multiscanning™、Deep CDR™ 技術以及 Proactive DLP™，對新上傳的檔案及現有靜態儲存的檔案進行檢查。
當本地部署的 SharePoint 使用者和管理員上傳檔案時，該檔案會透過第三方防毒軟體或相容於 AMSI 的掃描引擎（例如 Microsoft Defender）進行掃描。若檔案通過初步掃描，即被視為已處理完畢。一次清理，永久安全。正是基於這種假設，惡意軟體和勒索軟體的有效載荷才能在儲存庫中隱匿存在而不被偵測，有時甚至長達數年之久。
微軟也直接指出：SharePoint 的惡意軟體防護功能雖能將損害降至最低，但並不能作為唯一的防禦手段。
對於 BFSI（銀行、金融服務與保險）、醫療保健、政府部門，以及 OT（營運技術）或關鍵基礎設施環境而言，面臨風險的資料包括合規申報文件、病患紀錄、案件檔案及工程文件。這些資料全都存放在一個年復一年不斷擴增的資料庫中，卻無人回頭重新檢視其中已有的內容。
以下內容主要涵蓋三點：SharePoint 防毒掃描的實際運作方式、其未能涵蓋的範圍，以及一套分層且有效的 SharePoint 檔案儲存庫安全機制應具備的樣貌。
SharePoint 原生掃描功能未能涵蓋的範圍
微軟直截了當地警告使用者，SharePoint 的內建防毒功能雖然可能包含病毒，但並非旨在作為防禦惡意軟體的唯一防線。其中有三個具體的盲點值得探討。
已處於靜態狀態的資料
偵測結果很快就會過時。由於偵測引擎並非定期觸發，因此檔案的判定結果僅反映單一引擎在掃描該檔案時所能識別的內容。
版本歷史
啟用版本歷史紀錄功能的 SharePoint 資料庫會將每個儲存的版本保留為檔案的獨立副本。根據組織的版本控制政策，單一檔案隨時間推移可能會累積數百個歷史版本。
微軟關於版本歷史的文件中，並未提及針對儲存版本執行的惡意軟體掃描。
因此，存放在資料庫中的每個歷史版本，都與當前版本具有相同的靜態暴露風險。在更新頻率較高的資料庫中，這種暴露風險會隨時間累積。同一份（受感染）檔案可能累積數百個未掃描的版本。風險會隨著版本歷史的深度呈指數級增長。
未知或零日威脅
零日漏洞會像正常檔案一樣通過掃描，原因很簡單，就是目前還沒有任何掃描引擎能偵測到它。而且由於 SharePoint 不會在之後重新掃描現有內容，因此一個在第一天通過掃描的零日漏洞檔案，即使在第二百天時，即使廠商已發布能偵測到該漏洞的簽名更新，也不會再次被檢查。
未知威脅也是基於相同的邏輯。由於沒有附帶簽名，靜態分析（即防毒引擎所進行的分析）便無法偵測到該威脅。
註：這些屬於功能範圍上的缺口，而非缺陷。SharePointServer原生防毒功能是為了在特定的互動點進行「特定時間點」檢查而設計的，並非為了針對不斷擴增且具有版本控制的儲存庫，在不斷演變的威脅環境下進行持續性的重新驗證。
2025 年 7 月，微軟披露了一系列影響本地部署 SharePointServer 的未經身份驗證遠端程式碼執行漏洞鏈，目前正被積極利用：CVE-2025-49706、CVE-2025-49704，其後又新增了CVE-2025-53770和CVE-2025-53771。 此漏洞利用無需憑證或登入即可成功運作。
隨後微軟針對此漏洞發布了修補程式，而這套漏洞利用鏈也因此獲得了名稱：ToolShell。
根據《Infosecurity Magazine》引述 Eye Security 的分析，在 41 個國家的 145 個組織中，共發現 396 台遭入侵的系統。政府部門受創最重，佔已確認感染案例的 30%，其中光是美國就佔總數的 31%。 此外，Shadowserver 基金會報告指出，即使在導致數百家組織遭受攻擊的漏洞公開後，仍有超過 10,700 個 SharePoint 實例處於暴露狀態，任何運行相同漏洞利用鏈的人都能存取。Storm-2603 作為該漏洞利用背後的組織之一，將此漏洞轉化為 Warlock 勒索軟體的有效載荷。
一旦入侵成功，Storm-2603 便利用竊取的憑證及合法的管理員工具，在系統間進行橫向移動。由於此舉仰賴本應存在於系統中的工具，因此並未觸發任何警報。Storm-2603 安裝了 Web Shell，並竊取了重要資料。即使在漏洞修補後，他們仍能維持存取權限，因為攻擊者早已竊取了用於偽造有效認證憑證所需的金鑰。
ToolShell 是基於四個串聯在一起的 CVE 漏洞所建構，且從一開始就內建了繞過修補程式的機制。CVE-2025-53770 和 -53771 的存在，正是因為原本針對 CVE-2025-49704 和 -49706 的修補措施可以被繞過。
真正重要的是，攻擊者在短短幾週內，針對同一目標，兩度以比修補週期更快的速度進行了適應。
諸如單一防毒軟體僅對檔案進行一次掃描、並比對單一供應商簽章這類靜態防護機制，從一開始就並非為了偵測伺服器端的漏洞利用鏈而設計。而且，當攻擊者在修補程式發布後，帶著能繞過該修補程式的手段再次發動攻擊時，這些機制也無力抵禦。
ToolShell 展現了當前針對 SharePoint 伺服器所發動的攻擊已達到何等高超的程度。沒有理由認為這會是最後一次發生此類攻擊。存放在這些伺服器上的資料，究竟是受到能與時俱進的防護機制所保護，還是僅靠一次掃描就草草了事？
公平地說，ToolShell 並非一個瞞過上傳掃描的惡意文件。但攻擊者植入的 Web Shell（spinstall0.aspx 及其更名的變體）呢？那確實是一個檔案。它就存放在伺服器上，而它是否被標記為可疑，最終取決於先前提到的相同限制：僅使用單一掃描引擎、僅檢查一次，且僅在單一時間點進行檢查。
這就是將此事件與更廣泛的論點聯繫起來的機制。修補程式專門用於封堵 ToolShell 的漏洞鏈。對於已經存放在儲存庫中、尚未經過掃描的下一個檔案，修補程式則毫無作用。
MetaDefender™Storage Security 解決方案如何Storage Security 這些要求
MetaDefender™Storage Security OPSWAT企業資料保護平台，旨在透過 Metascan™Multiscanning、Deep CDR™ 技術及 Proactive DLP™，保護部署於本地端、混合式及雲原生儲存環境中的檔案，同時掃描新上傳的檔案以及現有靜態儲存的內容。
對於 SharePoint 使用者而言，該平台既能解決內容處於靜態狀態的問題，也能克服僅依賴單一偵測引擎所帶來的限制。具體運作方式如下：
- 透過Metascan™Multiscanning技術，運用 30 多個反惡意軟體引擎進行掃描；若某個供應商漏檢了某項威脅，仍有另外 29 次機會被其他引擎偵測到。
- Deep CDR™ 技術可消除偵測盲點；Deep CDR™ 技術會將檔案拆解並重新建構為安全的結構，對於隱藏在生產力檔案中的零日威脅及未知威脅特別有效。無論是否偵測到威脅，系統都會對檔案進行拆解處理。
- Proactive DLP™ 技術透過識別、封鎖及遮蔽檔案中的敏感或機密資料，以降低資料外洩的風險。對於受 PCI DSS、PHI 或 CUI 規範所管制的 BFSI、醫療保健及政府環境而言，這是一項建基於惡意軟體防護與稽核追蹤之上的合規控制措施。
MetaDefender Storage Security中的多種掃描選項
MetaDefender Storage Security 與 SharePoint 的原生模型有根本性的差異Storage Security 對儲存庫中現有內容進行即時、排程及隨需掃描。即時防護能在數秒內保護新上傳的檔案，而排程與隨需掃描則確保現有檔案及歷史版本持續受到保護。
常見問題
1. SharePointServer 會自動Server 檔案以檢查是否含有惡意軟體嗎？
是的，但僅限於特定時機。SharePointServer 透過 VSAPI 或基於 AMSI 的文件防毒功能，利用單一引擎在文件上傳、下載及線上編輯時進行掃描。它不會自動重新掃描已儲存於資料庫中的檔案。
2. 惡意軟體是否可能隱匿於 SharePointServer 中而不被偵測到？
是的。SharePointServer原生防毒整合功能（VSAPI 或 AMSI）會在上傳或下載時，使用該時刻單一防毒引擎的簽名檔來掃描檔案。檔案之後不會再次掃描，因此當防毒引擎的簽名檔尚未更新時，原本是乾淨的檔案，或是單純未被識別的檔案，可能會無限期地保留在資料庫中。
3. SharePointServer 會Server 已經儲存的檔案嗎？
不。原生掃描是基於事件的，由上傳或下載活動觸發。它不會依照定期排程對現有內容進行掃描，包括透過版本歷史記錄保留的舊版檔案。
4. 攻擊者如何利用 SharePoint 散佈惡意軟體，而不僅是儲存惡意軟體？
攻擊者可利用 SharePoint 的共享與同步功能——例如外部連結或訪客連結、已同步的資料庫，或是遭入侵且載有釣魚文件與惡意連結的網站——將已預先存放於儲存庫中的檔案傳送給其他使用者及終端裝置。
5. SharePoint Online（Microsoft 365）是否也受到相同的漏洞及 ToolShell 的影響？
不。ToolShell 漏洞利用Server 影響本地部署的 SharePointServer ；SharePoint Online 並未受到影響。本文所討論的「靜態資料」及「單引擎掃描」限制，同樣適用於本地部署的Server 。
6. 什麼是 ToolShell？修補程式能否完全解決這個問題？
ToolShell 是一組鏈式漏洞利用（CVE-2025-49704、CVE-2025-49706、CVE-2025-53770、CVE-2025-53771），可讓攻擊者在本地部署的 SharePointServer 上進行未經身份驗證的遠端程式碼執行。 雖然安裝修補程式可修復這些漏洞，但由於攻擊者已竊取機器金鑰，組織還必須輪替金鑰，並搜尋已植入的 Web Shell。
7. 為何在套用修補程式後需要輪替 ASP.NET 機器金鑰？
竊取您系統金鑰的攻擊者，即使您已套用修補程式，仍可偽造有效的驗證憑證。CISA 的建議是：先輪替金鑰、套用更新、再次輪替金鑰，並使用 iisreset.exe 重新啟動 IIS，如此一來，修補程式才能真正將攻擊者驅逐出系統。
8. 啟用 AMSI 能否保護 SharePoint 免受 ToolShell 的侵害？
AMSI 請求過濾整合功能（自 2023 年 9 月更新起預設啟用，建議在「完整模式」下運作）會檢查傳入的請求，並能阻擋未經身份驗證的 ToolShell 攻擊。此功能與基於 AMSI 的文件防毒功能不同，後者會在檔案上傳和下載時掃描檔案內容。
