A water utility, a telecommunications provider, a regional government body and a university have all been compromised by the Warlock ransomware group, which gained its foothold through unpatched, internet-facing SharePoint servers before harvesting credentials and pushing deeper into each network. The research behind the reporting carries an uncomfortable message: these intrusions owe less to sophisticated tradecraft than to collaboration software that sat exposed long after fixes were published.

How the intrusions worked

According to BleepingComputer's reporting, every incident followed the same grim rhythm. Warlock operators — described in the piece as a financially motivated, China-nexus ransomware-as-a-service operation — obtained initial access by exploiting SharePoint vulnerabilities on unpatched, internet-facing deployments. A webshell was dropped, and the real damage came next: token and credential harvesting that turned a single compromised server into a foothold across the wider Active Directory estate. From there the group moved toward domain compromise, exfiltrated data and prepared double-extortion leaks.

The critical nuance for defenders is timing. Microsoft had patched the most widely abused on-premises SharePoint flaws well before many of these intrusions occurred — the July 2025 out-of-band updates addressed CVE-2025-53770 and CVE-2025-53771, the so-called ToolShell chain, and the published exploitation guidance also flags misconfigured reverse-proxy setups that can quietly neutralise authentication controls. Where patched holes were still open, the decisive variable was patch lag, not attacker brilliance. Target profile matters less than exposure profile: what made these estates attractive was collaboration software reachable from the public internet, not a confirmed strategy to strike any particular sector.

What the attribution does — and does not — say

BleepingComputer's account links Warlock to a China nexus, and that attribution stands as reported. What it does not establish is state direction. The group's monetisation model, leak-site activity and ransomware-as-a-service posture point to a financially driven criminal operation; analysts should treat the origin link and the intent question as separate propositions. Both matter to incident responders, but only the first is evidenced here.

A practical checklist for on-prem SharePoint estates

Large organisations across regulated and infrastructure-heavy sectors still run extensive on-premises SharePoint estates that never completed the move to cloud collaboration. For teams reviewing their own exposure, the pattern from these four intrusions translates into a short, testable list:

  1. Inventory every internet-facing SharePoint instance — on-prem, hybrid, behind a load balancer or reverse proxy. Shadow IT servers are the usual blind spot.
  2. Verify patch status against Microsoft's SharePoint Server advisories (including CVE-2025-53770 and CVE-2025-53771 and the related KB5002741 / KB5002743 updates), not just against the last deployment cycle. Note explicitly whether a fix was applied before the vulnerability was publicly known.
  3. Audit reverse-proxy and WAF configurations for setups that forward requests in ways that bypass or degrade authentication.
  4. Hunt for webshells in SharePoint directories, including .aspx files in /_layouts/ and /_vti_bin/ paths — this is where the intrusion typically becomes visible before token theft begins.
  5. Assume token compromise follows server compromise. Review sign-in logs for unfamiliar sessions, revoke suspect refresh tokens, and check for service principals or applications added outside change control.
  6. Segment SharePoint servers from domain controllers and file shares. Perimeter hygiene and internal segmentation are the same problem, not two.
  7. Rehearse the escalation path: if a SharePoint server fell today, could the team detect webshell activity before domain-wide credential abuse?

The sobering lesson from these four intrusions is that the barrier to entry was low. Every mitigation above is mundane, affordable and well documented — and the cost of deferring any of them keeps getting priced in, one breached water utility at a time.

Source: BleepingComputer

一家水務公用事業公司、一家電訊服務供應商、一個地區政府部門及一所大學，均遭 Warlock 勒索軟件集團入侵。攻擊者先透過未修補、面向互聯網的 SharePoint server 取得初步立足點，其後收割憑證並深入各機構的網絡。相關調查傳達了令人不安的訊息：這些入侵與其說依賴精密手法，不如說源於協作軟件在修補程式公佈後，仍長期暴露於公眾網絡之上。

入侵如何進行

根據 BleepingComputer 的報導，每宗個案都遵循同一套腳本。文中形容 Warlock 是一個主要受財務利益驅動、與中國關聯的勒索軟件即服務（RaaS）運作。他們利用面向互聯網、未修補部署上的 SharePoint 漏洞取得初始存取權限，隨後植入 webshell。真正的破壞在下一階段：收割 token 及憑證，令單一遭入侵的 server 擴展為整個 Active Directory 環境的立足點。從那裡，集團逐步推進至全域入侵、外洩數據，並準備雙重勒索的洩露行動。

對防守者而言，關鍵在於時序。Microsoft 早在多宗入侵發生前，已修補廣遭濫用的本地部署 SharePoint 漏洞——2025 年 7 月的緊急更新涵蓋 CVE-2025-53770 及 CVE-2025-53771（即 ToolShell 攻擊鏈），公開的利用指引亦指出，設定錯誤的 reverse-proxy 設定可令身份驗證機制形同虛設。若修補後的洞口仍然敞開，關鍵因素是修補延誤，而非攻擊者的技術。目標特徵不如暴露特徵重要：令這些環境具吸引力的，是可經公眾網絡存取的協作軟件，而非針對特定行業的確認策略。

歸因說明了什麼——以及沒有說明什麼

BleepingComputer 的分析將 Warlock 與中國關聯起來，該歸因按原報導所述成立。然而，分析並未證實此等入侵受國家層面指令驅動。該集團的變現模式、洩露網站活動及勒索軟件即服務的部署姿態，指向一個由財務利益驅動的犯罪組織；分析人員應將「來源關聯」與「意圖問題」視為兩個獨立命題。兩者對事故回應者同樣重要，但此處有據可查的只有前者。

本地部署 SharePoint 環境的實務檢查清單

受規管及基建密集行業中的大型機構，仍有大量本地部署 SharePoint 環境從未全面遷往雲端協作。對於檢視自身暴露面的團隊而言，這四宗入侵的模式可歸納為以下一份簡短而可測試的清單：

  1. 盤點每一個面向互聯網的 SharePoint 實例 —— 本地部署、混合部署、load balancer 或 reverse-proxy 後方，一律納入。shadow IT 的 server 通常是盲點所在。
  2. 核對修補狀態與 Microsoft SharePoint Server 公告（包括 CVE-2025-53770、CVE-2025-53771 及相關的 KB5002741／KB5002743 更新），而非只對照最近一次部署周期。明確記錄修補是否在漏洞公開前已套用。
  3. 審核 reverse-proxy 及 WAF 設定，找出會繞過或削弱身份驗證機制的轉發設定。
  4. 在 SharePoint 目錄搜尋 webshell，包括 /_layouts/ 及 /_vti_bin/ 路徑下的 .aspx 檔案——入侵活動在 token 竊取展開前，通常先在這裡露出破綻。
  5. 假設 server 遭入侵後，token 必然隨之洩露。 檢視登入紀錄中的陌生 session，撤銷存疑的 refresh token，並檢查是否有 service principal 或應用程式在變更管控之外被新增。
  6. 將 SharePoint server 與 domain controller 及檔案共享分隔開來。 外圍防護與內部區隔是同一個問題，而非兩件事。
  7. 預演升級應變路徑：如果今天有 SharePoint server 失陷，團隊能否在全域憑證遭濫用前偵測到 webshell 活動？

這四宗入侵帶來的警示是：入侵門檻極低。以上每一項緩解措施都平凡、可負擔、且有完整文件記載——然而拖延執行的代價，正隨着一間又一間水務公用事業公司被入侵，逐步被計入成本。

來源：BleepingComputer

新聞來源 / Original News Source