ConnectWise ScreenConnect Under Active Exploitation: CISA-Confirmed Detection and Remediation Guide

CISA has confirmed what many of us in incident response have been watching build on the ground: a critical-severity vulnerability in ConnectWise ScreenConnect is being actively exploited in the wild. The flaw has been added to the CISA Known Exploited Vulnerabilities (KEV) catalog, which means this is no longer a theoretical risk — exploitation is confirmed, operational, and ongoing.

ScreenConnect sits in one of the most dangerous positions in any environment: it is a remote access and remote support platform with deep, privileged reach into endpoints. When a remote monitoring and management (RMM) tool is compromised or abused, attackers inherit legitimate remote control capabilities that blend into normal administrative traffic. That is exactly why this class of vulnerability is so attractive to both financially motivated groups and ransomware operators — and why ScreenConnect flaws have repeatedly become initial-access vectors in ransomware intrusions and hands-on-keyboard campaigns.

If you operate ScreenConnect — particularly a self-hosted/on-premises instance — you need to treat this as an incident, not a ticket. Patch immediately, hunt for pre-patch compromise, and assume an attacker who reached an unpatched server had the equivalent of a master key to every endpoint the server manages.

Technical Analysis

Affected Products and Exposure

The vulnerability affects ConnectWise ScreenConnect remote access software. Self-hosted (on-premises) ScreenConnect servers carry the greatest exposure because patching is the customer's responsibility, and in every RMM exploitation wave we have worked, a long tail of unpatched on-prem servers persists for weeks after vendor fixes ship. Cloud-hosted instances are patched by ConnectWise on the vendor side, but cloud customers are not off the hook — you still need to verify tenant status with ConnectWise and hunt for abuse of the platform itself, since an exploited RMM control plane means attacker-issued sessions may have occurred before remediation.

Why RMM Exploitation Is So Dangerous

From a defender's perspective, the attack chain for an exploited ScreenConnect server is brutally efficient:

1. Initial access: The attacker exploits the critical flaw against an internet-facing ScreenConnect server. These servers are intentionally exposed — they have to be reachable for remote support sessions — which means scanning and exploitation at internet scale is trivial for motivated actors.
2. Control-plane compromise: Once on the server, the attacker inherits the ability to issue commands to every managed endpoint through the ScreenConnect agent (ScreenConnect.ClientService.exe). No malware needs to touch the endpoint disk — the RMM agent is the payload.
3. Execution on endpoints: Commands execute under the ScreenConnect service context, typically SYSTEM, spawning child processes such as cmd.exe, powershell.exe, or rundll32.exe directly from the agent process tree.
4. Persistence and staging: Attackers deploy secondary tooling — additional RMM agents (AnyDesk, Atera, Splashtop), credential dumpers, and ultimately ransomware or data exfiltration tooling — all riding legitimate remote access channels.

This is the pattern we have seen repeatedly in RMM-driven intrusions: the legitimate tool provides C2, execution, and lateral movement in a single signed, allow-listed binary. Traditional AV is nearly blind to it.

Exploitation Status

• Confirmed active exploitation in the wild, per CISA.
• Listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, which triggers binding remediation deadlines for U.S. federal civilian agencies under BOD 22-01 and serves as the de facto patch-or-mitigate signal for the private sector.
• RMM platforms are a documented favorite of ransomware affiliates and initial access brokers; history with this product family shows exploitation escalates to hands-on-keyboard activity within days of a server's compromise.

Treat any internet-facing ScreenConnect server that was unpatched during the exposure window as potentially compromised until proven otherwise through hunting.

Detection & Response

The highest-fidelity detection surface for ScreenConnect abuse — whether through exploitation or stolen access — is the endpoint process tree. Legitimate technician activity and attacker activity both flow through the same agent, so we hunt for behaviors that technicians rarely perform: the agent spawning reconnaissance commands, scripting engines with encoded content, mass-execution patterns, and secondary tooling installation.

Sigma Rules

The following rules target the process-execution behaviors that distinguish malicious ScreenConnect usage from routine support activity. Tune allow-lists to your environment's known support workflows before deploying at high level.

---
title: ScreenConnect Agent Spawning Suspicious Child Processes
id: 3f8a1c92-7b4e-4d51-9a2c-8e6f5d1b0a47
status: experimental
description: Detects the ScreenConnect client service spawning reconnaissance, scripting, or defense-evasion child processes, consistent with post-exploitation activity through a compromised or abused RMM control plane.
references:
  - https://www.bleepingcomputer.com/news/security/cisa-warns-of-hackers-exploiting-critical-screenconnect-flaw/
  - https://attack.mitre.org/techniques/T1219/
author: Security Arsenal
date: 2026/01/20
tags:
  - attack.execution
  - attack.command_and_control
  - attack.t1219
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\ScreenConnect.ClientService.exe'
      - '\ScreenConnect.Service.exe'
  selection_child_img:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
  selection_child_cli:
    CommandLine|contains:
      - 'whoami'
      - 'net user'
      - 'net localgroup'
      - 'vssadmin delete shadows'
      - 'bcdedit'
      - 'wevtutil'
      - 'FromBase64String'
      - '-enc'
      - '-e '
      - 'downloadstring'
      - 'Invoke-Expression'
      - 'iex'
  condition: selection_parent and (selection_child_img or selection_child_cli)
falsepositives:
  - Legitimate remote support sessions where technicians run scripts or system commands through ScreenConnect
level: high
---
title: ScreenConnect Spawning Shadow Copy Deletion or Backup Tampering
id: 9c2d7e41-1f6a-4b38-a5d9-4c8b2e7f3a05
status: experimental
description: Detects ScreenConnect agent process trees executing ransomware precursor behaviors including shadow copy deletion, boot configuration tampering, and recovery disabling.
references:
  - https://www.bleepingcomputer.com/news/security/cisa-warns-of-hackers-exploiting-critical-screenconnect-flaw/
  - https://attack.mitre.org/techniques/T1490/
author: Security Arsenal
date: 2026/01/20
tags:
  - attack.impact
  - attack.t1490
  - attack.t1219
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|contains: 'ScreenConnect'
  selection_impact:
    CommandLine|contains:
      - 'vssadmin delete shadows'
      - 'vssadmin Delete Shadows'
      - 'wmic shadowcopy delete'
      - 'bcdedit /set'
      - 'recoveryenabled no'
      - 'wbadmin delete catalog'
  condition: selection_parent and selection_impact
falsepositives:
  - Rare; backup maintenance is not normally driven through an RMM agent
level: critical
---
title: ScreenConnect Agent Installing Secondary Remote Access Tooling
id: 5b1e9f38-4d2c-4a76-b8e1-2f6a9c3d8e52
status: experimental
description: Detects ScreenConnect-spawned processes downloading or installing secondary RMM or remote access tooling, a common persistence and redundancy technique following RMM compromise.
references:
  - https://www.bleepingcomputer.com/news/security/cisa-warns-of-hackers-exploiting-critical-screenconnect-flaw/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/01/20
tags:
  - attack.persistence
  - attack.command_and_control
  - attack.t1219
  - attack.t1105
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|contains: 'ScreenConnect'
  selection_tools:
    CommandLine|contains:
      - 'anydesk'
      - 'atera'
      - 'splashtop'
      - 'teamviewer'
      - 'logmein'
      - 'rustdesk'
      - 'ngrok'
      - 'cloudflared'
      - 'msiexec'
      - '.msi'
  condition: selection_parent and selection_tools
falsepositives:
  - Managed service providers legitimately deploying or migrating RMM tooling through ScreenConnect sessions
level: high

KQL — Microsoft Sentinel / Defender

This query hunts across Defender for Endpoint telemetry for ScreenConnect agent process trees exhibiting post-exploitation behavior. Run it over at least 14 days, and extend to 30+ days if your server was exposed during the pre-patch window.

let Lookback = 14d;
let SuspiciousCommands = dynamic(["whoami", "net user", "net localgroup", "vssadmin", "bcdedit",
    "wevtutil", "FromBase64String", "downloadstring", "Invoke-Expression", "nltest",
    "quser", "tasklist", "ipconfig /all", "systeminfo", "wmic shadowcopy",
    "anydesk", "atera", "splashtop", "rustdesk", "ngrok", "cloudflared"]);
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName has "ScreenConnect"
    or InitiatingProcessCommandLine has "ScreenConnect"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe",
    "mshta.exe", "rundll32.exe", "regsvr32.exe", "msiexec.exe", "vssadmin.exe", "bcdedit.exe")
    or ProcessCommandLine has_any (SuspiciousCommands)
| project TimeGenerated, DeviceName, AccountName,
    ParentProcess = InitiatingProcessFileName, ParentCommandLine = InitiatingProcessCommandLine,
    ChildProcess = FileName, ProcessCommandLine, SHA256, ReportId
| sort by TimeGenerated desc

A companion query for network-level hunting in Sentinel — useful for identifying endpoints communicating with ScreenConnect relay infrastructure you do not recognize, or new outbound tunnels from endpoints where ScreenConnect should not exist:

let Lookback = 14d;
DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName has "ScreenConnect"
| where RemoteUrl has "screenconnect.com" or RemotePort in (8040, 8041, 443)
| summarize Connections = count(), DistinctRemoteIPs = dcount(RemoteIP),
    FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DeviceName, RemoteUrl, RemoteIP, RemotePort
| sort by FirstSeen asc

Investigate any ScreenConnect agent first seen after the disclosure date, any instance on a device where the tool was never deployed by your team, and any connection to a ScreenConnect relay domain not belonging to your own instance.

Velociraptor VQL

For endpoint triage at scale — particularly across fleets managed by an on-prem ScreenConnect server that was exposed — this artifact enumerates live ScreenConnect process trees and their network connections:

-- Hunt: ScreenConnect agent processes, child processes, and active connections
-- Deploy as a hunt across all endpoints previously managed by an exposed server
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)screenconnect'
   OR Exe =~ '(?i)screenconnect'
   OR Name =~ '(?i)screenconnect'

-- Hunt: Suspicious child processes spawned under the ScreenConnect agent
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Ppid IN (
    SELECT Pid FROM pslist() WHERE Name =~ '(?i)screenconnect'
)
AND Name =~ '(?i)(cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|msiexec|vssadmin|bcdedit)'

-- Hunt: Active network connections from ScreenConnect processes to identify relay endpoints
SELECT Pid, Name, RemoteIP, RemotePort, Status
FROM netstat()
WHERE Name =~ '(?i)screenconnect'
  AND Status =~ 'ESTABLISHED'

Correlate the relay IPs returned by the third query against your organization's known ScreenConnect instance. Any agent reporting to infrastructure you do not control is an unauthorized RMM foothold — isolate that endpoint immediately.

Remediation and Verification Script

Use this PowerShell script on on-prem ScreenConnect servers and managed endpoints to verify version posture, identify the agent footprint, and surface suspicious services or recently created persistence artifacts:

# ScreenConnect compromise assessment - run elevated on servers and endpoints
# 1. Identify installed ScreenConnect components and versions
Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*,
  HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* -ErrorAction SilentlyContinue |
  Where-Object { $_.DisplayName -match 'ScreenConnect|ConnectWise' } |
  Select-Object DisplayName, DisplayVersion, InstallDate, Publisher | Format-Table -AutoSize

# 2. Enumerate ScreenConnect services and their binary paths - flag anything outside the expected install dir
Get-CimInstance Win32_Service |
  Where-Object { $_.Name -match 'ScreenConnect|ConnectWise' -or $_.PathName -match 'ScreenConnect' } |
  Select-Object Name, State, StartMode, PathName | Format-List

# 3. Flag suspicious services created recently (potential attacker persistence via RMM)
$Cutoff = (Get-Date).AddDays(-30)
Get-CimInstance Win32_Service | Where-Object {
  $_.PathName -match 'Temp|AppData|ProgramData|Users\\Public'
} | Select-Object Name, State, PathName | Format-List

# 4. Review recently created local accounts (common post-exploitation action)
Get-LocalUser | Where-Object { $_.PasswordLastSet -gt $Cutoff -or $_.LastLogon -gt $Cutoff } |
  Select-Object Name, Enabled, LastLogon, PasswordLastSet | Format-Table -AutoSize

# 5. Pull recent ScreenConnect-related process launches from the Security log for triage
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4688; StartTime = $Cutoff } -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'ScreenConnect' } |
  Select-Object TimeCreated, Message -First 50 | Format-List

For on-prem servers specifically, verify the server build directly against ConnectWise's security bulletin for this flaw — do not rely on the admin console's self-reported status alone, and confirm the upgrade actually completed and services restarted cleanly.

Remediation

Work through this in order. The sequence matters: patch first to close the door, then hunt to determine whether someone already walked through it.

1. Patch immediately. On-premises/self-hosted customers: upgrade to the fixed ScreenConnect build specified in the official ConnectWise security bulletin at https://www.connectwise.com/company/trust/security-bulletins. Verify the running server version post-upgrade — do not assume the installer succeeded. Cloud customers: confirm with ConnectWise that your instance is patched and request any available session/audit logs for the exposure window.
2. Check the CISA KEV catalog at https://www.cisa.gov/known-exploited-vulnerabilities-catalog for this vulnerability's entry and its remediation due date. Federal civilian agencies are bound to that deadline under BOD 22-01; private organizations should treat the same date as their own SLA.
3. Hunt before you trust. A patched server tells you nothing about what happened while it was vulnerable. Pull ScreenConnect server session logs (connections, file transfers, command executions), and run the endpoint detections above across every managed endpoint — not just the server. Look for: sessions outside business hours, sessions from unfamiliar source IPs, file transfer events, and the deployment of secondary RMM tools.
4. Audit RMM inventory broadly. Establish an authoritative allow-list of remote access tools in your environment. Any RMM binary outside that list — ScreenConnect instances you didn't deploy, plus AnyDesk, Atera, Splashtop, RustDesk, and similar — should be treated as an intrusion indicator until explained. Attackers routinely install redundant access immediately after compromising a primary RMM.
5. Reduce the attack surface. Restrict access to the ScreenConnect administration and relay interfaces to known IP ranges or VPN-only paths where operationally feasible. Enforce MFA on all technician accounts. Review and minimize the number of endpoints the server manages and the privilege level of agent deployments.
6. Rotate credentials if compromise is suspected. If hunting reveals unauthorized sessions, treat all credentials reachable from managed endpoints as exposed: rotate domain admin and service account credentials, invalidate tokens, and review authentication logs for follow-on access. A compromised RMM server is a credential-theft event by default.
7. Segment and monitor outbound RMM traffic. Alert on endpoints initiating connections to ScreenConnect (or any RMM) infrastructure that is not your own instance. This single control catches both unauthorized agent installs and control-plane hijacking.

If you find evidence of unauthorized sessions or secondary tooling, escalate to a full IR engagement — do not attempt to clean an RMM compromise in place. The attacker may hold persistence mechanisms you cannot see from the endpoint alone, including access to the ScreenConnect server's own backend database and stored session credentials.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub