Rogue ScreenConnect Clients Found on 288 Endpoints as ConnectWise Disables Five Integrations
At least 288 endpoints across 48 organizations have been found running rogue ScreenConnect clients, prompting ConnectWise to disable five third-party extensions in partner environments as a precaution, according to The Hacker News.
In an advisory posted on its site, ConnectWise said there is no evidence that the incident involves a compromise of its infrastructure or a vulnerability in the ScreenConnect software. The company described its initial assessment as suggesting the activity may involve other factors, and has not yet published a root cause, an initial access vector, or the names of the five extensions it disabled. That assessment should be treated as provisional until a fuller report lands.
Why the numbers matter more than the individual hits
The headline figures point to coordination rather than scattered misconfiguration. For managed service providers, the arithmetic is more troubling than the raw endpoint count: a single abused ScreenConnect server typically fans out into dozens of downstream customer networks, so one compromised MSP management plane can translate into broad third-party exposure. The 48-organisation figure suggests attackers were working through a common set of entry points rather than exploiting a flaw in each target individually.
Rogue clients are difficult to spot precisely because they are legitimate. They are signed ScreenConnect binaries, commonly allowlisted in endpoint tooling, and structurally indistinguishable from routine remote-support traffic. Signature-based alerting will not catch them. Detection depends on deliberate, inventory-driven auditing — which is why a same-day sweep is the first action any team should take.
A practical checklist for ScreenConnect operators
1. Rogue client sweep. Enumerate every client registered against your ScreenConnect server and reconcile the list against your asset inventory. Anything that cannot be tied to a known device, owner, and support ticket is a candidate for isolation. Scrutinise connection origins and timestamps, including activity that predates the advisory.
2. Integration review. Identify which of the five disabled third-party extensions — still unnamed by ConnectWise — are deployed in your environment, and map what breaks if they stay offline. These extensions sit at the junction to ticketing, credential, and automation systems, which makes them the most plausible lateral-movement path into an MSP's core tooling. Confirm approval provenance before requesting restoration.
3. Credential rotation. Treat admin accounts, server-authenticated accounts, and integration shared secrets as exposed. Rotate them, and enforce multi-factor authentication on the ScreenConnect management interface if it is not already mandatory.
4. Session and auth log review. Pull logs across the pre-advisory period as well as the current window. Look for sessions initiated from unfamiliar geographies, off-hours connections, and accounts that authenticated but produced no corresponding ticket activity.
5. Brief front-line staff. Support technicians are often the first to see an unexpected session. Give them a short, concrete briefing on recognising and escalating unexplained access.
Governance, not patching
Because ConnectWise reports no product flaw, patch management alone does not address this incident. The durable questions are operational: how integrations are approved into a privileged RMM environment, how that tooling is monitored for unrecognised clients, and how quickly an endpoint that should not exist can be detected and removed.
For Hong Kong IT teams and MSPs running ScreenConnect, the advisory is a prompt to run the audit now rather than wait for the vendor's final report. ConnectWise has yet to publish the extension names and full root cause; teams should revisit their assessment when that material is released.
288 個端點發現未經授權的 ScreenConnect 客戶端，ConnectWise 暫停五項整合功能
據 The Hacker News 報導，至少 48 家機構共 288 個端點被發現正在運行未經授權的 ScreenConnect 客戶端，促使 ConnectWise 作為預防措施，在合作夥伴環境中暫停五項第三方擴充功能。
ConnectWise 在官方網站發表通告稱，目前沒有證據顯示事件涉及其基礎設施被入侵或 ScreenConnect 軟件存在漏洞。該公司表示初步評估顯示相關活動可能涉及其他因素，尚未公布根本原因、初始入侵途徑，以及被暫停的五項擴充功能名稱。在更完整的報告出台之前，該評估應視為臨時性結論。
為何整體數字比個別事件更值得關注
頭條數字反映的是協同行動，而非零散的配置失誤。對 Managed Service Provider（MSP）而言，計算下來的結果比端點總數更令人擔憂：一台被濫用的 ScreenConnect 伺服器通常會蔓延至數十個下游客戶網絡，換言之，一個被入侵的 MSP 管理平台可能造成廣泛的第三方暴露風險。48 家機構這個數字顯示，攻擊者是透過一組共同的入口點逐一入侵，而非針對每個目標個別利用漏洞。
未經授權的客戶端難以察覺，恰恰因為它們表面上是合法的：它們是經過簽名的 ScreenConnect 二進制檔案，通常已被端點工具列入允許清單，在結構上與常規遠端支援流量無異。基於簽名的警報機制無法捕捉到它們。偵測有賴於有系統、以資產清單為基礎的審核——這正是任何團隊都應在通告發出當日立即執行全面掃描的原因。
ScreenConnect 管理員實用清單
1. 未經授權的客戶端掃描。 列舉所有在您的 ScreenConnect 伺服器註冊的客戶端，並將名單與資產清單逐一核對。任何無法對應到已知設備、負責人及支援工單的項目，都應考慮隔離處理。仔細檢查連線來源及時間戳記，包括早於通告發布前的活動。
2. 整合功能檢視。 確認被暫停的五項第三方擴充功能——ConnectWise 尚未公布名稱——哪些已部署在您的環境中，並評估若持續離線會影響哪些功能。這些擴充功能位於工單系統、憑證系統及自動化系統的交匯處，因此最可能成為入侵 MSP 核心工具的橫向移動路徑。在申請恢復前，務必確認其審批來源。
3. 憑證輪換。 將管理員帳戶、伺服器驗證帳戶及整合共享密鑰視為已暴露，全部進行輪換，並在 ScreenConnect 管理界面強制實施 multi-factor authentication（MFA），若尚未列為強制要求的話。
4. session 及驗證日誌審查。 調取通告發布前一段時期及當前時段的日誌，留意從陌生地理位置發起的 session、非辦公時間的連線，以及已通過驗證但沒有相應工單活動的帳戶。
5. 向前線員工簡報。 支援技術人員往往是最先發現異常 session 的人。為他們提供簡短而具體的指引，說明如何識別及上報無法解釋的存取行為。
重點在於治理，而非套用修補程式
由於 ConnectWise 表示產品本身沒有缺陷，單靠修補程式管理無法解決這次事件。長遠而言，關鍵問題在於營運層面：整合功能如何獲批進入權限極高的 RMM 環境、如何監控該工具以發現未經識別的客戶端，以及如何迅速偵測並移除不應存在的端點。
對於香港正在使用 ScreenConnect 的 IT 團隊及 MSP 而言，這份通告是立即展開審核的提示，不應等待供應商的最終報告。ConnectWise 至今尚未公布擴充功能名稱及完整根本原因；相關資料發布後，團隊應重新評估形勢。