Microsoft's Threat Intelligence team has published an analysis of SCKit, a toolset that abuses ConnectWise ScreenConnect — the legitimate remote access and support platform widely deployed across managed service providers (MSPs) and enterprise IT environments — to establish unauthorized remote access and specifically target active technician sessions. This is not a vulnerability in ScreenConnect's code; it is the weaponization of a trusted tool against the very people responsible for defending networks.
For SOC teams and IR responders, this campaign represents a particularly dangerous class of threat: living-off-the-land techniques using legitimate remote management and monitoring (RMM) software. Because ScreenConnect is a sanctioned, signed application in most environments where it is deployed, traditional signature-based detection is blind to its abuse. The attacker does not need to drop malware — they simply repurpose what is already trusted.
If your organization uses ScreenConnect, or if your MSP does, this threat directly concerns you. The targeting of technician sessions is especially alarming: adversaries are specifically watching for help desk and IT support personnel to log in, then piggybacking on those elevated sessions to move laterally, deploy payloads, or establish persistence with the technician's own credentials.
Technical Analysis
What Is SCKit?
SCKit is an attacker-assembled toolset designed to abuse ScreenConnect's legitimate functionality. It enables threat actors to:
- Deploy ScreenConnect client instances silently on target endpoints without user consent or awareness, often masquerading as legitimate software or bundling with seemingly benign installers.
- Monitor and hijack active technician sessions — the tool specifically watches for ScreenConnect sessions initiated by IT support staff, then leverages those authenticated sessions to gain access to downstream systems.
- Establish persistent remote access by installing ScreenConnect as a service or via startup persistence, ensuring the attacker retains access even after reboots.
- Blend into legitimate traffic — because ScreenConnect communicates over standard HTTPS (port 443) to ConnectWise cloud infrastructure, the malicious traffic is indistinguishable from legitimate remote support sessions at the network layer without deeper inspection.
Attack Chain
From a defender's perspective, the attack chain follows this pattern:
-
Initial Access: The threat actor gains an initial foothold — typically via phishing, compromised credentials, or exploitation of an exposed service. In some observed cases, the attacker deploys SCKit as a follow-on payload after achieving code execution through another vector.
-
ScreenConnect Client Deployment: SCKit installs or activates a ScreenConnect client instance on the compromised host. This may involve downloading the client from attacker-controlled infrastructure, side-loading it, or reconfiguring an existing legitimate installation to connect to an attacker-controlled ScreenConnect relay.
-
Technician Session Targeting: The critical differentiator — SCKit specifically monitors for active ScreenConnect sessions where a technician is connected. By targeting these sessions, the attacker can observe technician workflows, capture credentials entered during support sessions, and pivot to systems the technician is managing.
-
Lateral Movement and Persistence: With technician-level access, the attacker moves laterally across the environment, deploys additional tooling (ransomware, data exfiltration utilities, or additional RMM instances), and establishes redundant persistence mechanisms.
Why This Is Dangerous
The abuse of legitimate RMM tools like ScreenConnect is a well-documented and growing trend. CISA and the NSA jointly issued guidance on this threat class. ScreenConnect is particularly attractive to attackers because:
- It is signed by ConnectWise and passes application whitelisting checks.
- It communicates over encrypted HTTPS to cloud-hosted relay servers, making network-based detection difficult without TLS inspection or cloud service analysis.
- It is functionally complete — it provides full desktop control, file transfer, command execution, and service management out of the box.
- MSPs and IT departments legitimately deploy it at scale, so its presence on an endpoint is not inherently suspicious.
Exploitation Status
This is confirmed active abuse in the wild. Microsoft's Security Blog describes observed campaigns using SCKit in real intrusions. This is not theoretical. Organizations using ScreenConnect — particularly MSPs and their downstream clients — should treat this as an active threat requiring immediate hunting and hardening.
Detection and Response
The following detection content is designed for SOC analysts actively hunting for SCKit activity and ScreenConnect abuse. These rules and queries focus on the behavioral anomalies that distinguish malicious ScreenConnect usage from legitimate remote support operations.
SIGMA Rules
---
title: ScreenConnect Client Execution from Non-Standard Path
id: 8a2c4f91-3b7d-4e5a-b6c9-2d1e0f3a5b7c
status: experimental
description: Detects ScreenConnect client execution from paths not associated with legitimate installation directories. SCKit deployments often run the client from temp, AppData, or user profile directories to avoid detection.
references:
- https://www.microsoft.com/en-us/security/blog/2026/11/13/sckit-abuses-screenconnect-deploy-remote-access-target-technician-sessions/
- https://attack.mitre.org/techniques/T1219/
author: Security Arsenal
date: 2026/11/13
tags:
- attack.command_and_control
- attack.t1219
logsource:
category: process_creation
product: windows
detection:
selection_img:
Image|contains:
- 'ScreenConnect'
- 'screenconnect'
- 'ConnectWiseControl'
filter_legit:
Image|startswith:
- 'C:\Program Files\ScreenConnect'
- 'C:\Program Files (x86)\ScreenConnect'
- 'C:\Program Files\ConnectWise'
- 'C:\Program Files (x86)\ConnectWise'
- 'C:\ProgramData\ScreenConnect'
condition: selection_img and not filter_legit
falsepositives:
- Custom ScreenConnect deployments in non-standard directories (verify against approved software inventory)
level: high
---
title: ScreenConnect Service Installation via Command Line
id: 3f7b1e92-5c8a-4d6f-a1b3-9e2d4c6f8a0b
status: experimental
description: Detects installation of ScreenConnect as a Windows service using sc.exe, New-Service, or direct registry manipulation. SCKit establishes persistence by registering ScreenConnect as a service.
references:
- https://www.microsoft.com/en-us/security/blog/2026/11/13/sckit-abuses-screenconnect-deploy-remote-access-target-technician-sessions/
- https://attack.mitre.org/techniques/T1543/003/
- https://attack.mitre.org/techniques/T1219/
author: Security Arsenal
date: 2026/11/13
tags:
- attack.persistence
- attack.t1543.003
- attack.command_and_control
- attack.t1219
logsource:
category: process_creation
product: windows
detection:
selection_sc:
Image|endswith:
- '\sc.exe'
- '\powershell.exe'
- '\pwsh.exe'
CommandLine|contains:
- 'ScreenConnect'
- 'screenconnect'
- 'ConnectWiseControl'
selection_reg:
CommandLine|contains:
- 'HKLM\SYSTEM\CurrentControlSet\Services\ScreenConnect'
- 'HKLM\SYSTEM\CurrentControlSet\Services\ConnectWise'
condition: selection_sc or selection_reg
falsepositives:
- Legitimate ScreenConnect installation or update by IT administrators
- MSP deployment scripts
level: medium
---
title: Network Connection to ScreenConnect Relay from Unsigned Process
id: 1e5d3a87-9b2c-4f6e-c8d1-7a3b5e9f0c2d
status: experimental
description: Detects network connections to known ScreenConnect cloud relay domains from processes that are not the signed ScreenConnect client binary. May indicate DLL side-loading or process injection leveraging ScreenConnect infrastructure.
references:
- https://www.microsoft.com/en-us/security/blog/2026/11/13/sckit-abuses-screenconnect-deploy-remote-access-target-technician-sessions/
- https://attack.mitre.org/techniques/T1219/
- https://attack.mitre.org/techniques/T1572/
author: Security Arsenal
date: 2026/11/13
tags:
- attack.command_and_control
- attack.t1219
- attack.t1572
logsource:
category: network_connection
product: windows
detection:
selection_domain:
DestinationHostname|contains:
- 'screenconnect.com'
- 'connectwisecontrol.com'
- 'connectwise.com'
filter_legit:
Image|startswith:
- 'C:\Program Files\ScreenConnect'
- 'C:\Program Files (x86)\ScreenConnect'
- 'C:\Program Files\ConnectWise'
- 'C:\Program Files (x86)\ConnectWise'
condition: selection_domain and not filter_legit
falsepositives:
- Browser access to ScreenConnect admin console
- Legitimate ScreenConnect deployment scripts
level: high
KQL Hunt Query (Microsoft Sentinel / Defender XDR)
The following KQL query hunts across multiple data sources for indicators of SCKit-style ScreenConnect abuse. Run this in Microsoft Sentinel or Defender XDR Advanced Hunting.
// Hunt for ScreenConnect abuse indicators across process, network, and service events
// Designed to identify SCKit-style deployment patterns
// Run against: DeviceProcessEvents, DeviceNetworkEvents, DeviceEvents (Defender XDR)
// Or: SecurityEvent, CommonSecurityLog (Sentinel)
// Query 1: ScreenConnect processes running from suspicious paths
let SuspiciousPaths = dynamic([@"\AppData\", @"\Temp\", @"\tmp\", @"\Users\Public\", @"\ProgramData\Microsoft\", @"\Downloads\", @"\Desktop\"]);
let ScreenConnectKeywords = dynamic(["ScreenConnect", "screenconnect", "ConnectWiseControl", "connectwise"]);
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName has_any (ScreenConnectKeywords)
or ProcessCommandLine has_any (ScreenConnectKeywords)
| extend IsSuspiciousPath = false
| extend IsSuspiciousPath = iif(FolderPath has_any (SuspiciousPaths), true, IsSuspiciousPath)
| where IsSuspiciousPath == true
| project TimeGenerated, DeviceName, FileName, FolderPath, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName,
SHA256, ProcessId
| sort by TimeGenerated desc;
// Query 2: Network connections to ScreenConnect infrastructure from unusual processes
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemoteUrl has_any ("screenconnect", "connectwise")
| where InitiatingProcessFolderPath !has "Program Files"
| project TimeGenerated, DeviceName, InitiatingProcessFileName,
InitiatingProcessFolderPath, InitiatingProcessCommandLine,
RemoteUrl, RemoteIP, RemotePort
| sort by TimeGenerated desc;
// Query 3: New services referencing ScreenConnect installed recently
DeviceEvents
| where TimeGenerated > ago(7d)
| where ActionType == "ServiceInstalled"
| where AdditionalFields has_any ("ScreenConnect", "ConnectWise")
| extend ServiceName = tostring(parse_json(AdditionalFields).ServiceName)
| extend ServiceFileName = tostring(parse_json(AdditionalFields).ServiceFileName)
| project TimeGenerated, DeviceName, ServiceName, ServiceFileName,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by TimeGenerated desc;
Velociraptor VQL Hunt
The following Velociraptor artifact hunts for ScreenConnect client artifacts on endpoints, focusing on non-standard installation paths, persistence mechanisms, and active network connections.
-- SCKit ScreenConnect Abuse Hunt
-- Identifies ScreenConnect binaries in suspicious locations, persistence entries, and active connections
-- Section 1: ScreenConnect processes from non-standard paths
LET suspicious_paths = ["AppData", "Temp", "tmp", "Public", "Downloads", "Desktop", "Roaming"]
SELECT Pid, Name, Exe, CommandLine, Username, CreateTime,
Authenticode.Signed AS IsSigned,
Authenticode.Subject AS SignerSubject
FROM pslist()
WHERE (Name =~ '(?i)screenconnect|connectwise'
OR CommandLine =~ '(?i)screenconnect|connectwise')
AND Exe =~ '(?i)(appdata|temp|tmp|public|downloads|desktop|roaming)'
-- Section 2: ScreenConnect files in suspicious directories
LET file_hits = SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=[
"C:/Users/*/AppData/**/ScreenConnect*",
"C:/Users/*/AppData/**/ConnectWise*",
"C:/Windows/Temp/**/ScreenConnect*",
"C:/Users/Public/**/ScreenConnect*",
"C:/ProgramData/**/ScreenConnect*Client*"
])
SELECT FullPath, Size, Mtime FROM file_hits
-- Section 3: Registry persistence referencing ScreenConnect
SELECT Key.FullPath AS RegKey, Key.Name AS ValueName,
Key.Data AS ValueData
FROM glob(
globs=[
"HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/ScreenConnect*/**",
"HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Run/ScreenConnect*",
"HKEY_CURRENT_USER/SOFTWARE/Microsoft/Windows/CurrentVersion/Run/ScreenConnect*"
],
accessor="registry"
)
-- Section 4: Active connections to ScreenConnect cloud infrastructure
SELECT Pid, Name, LocalAddress, LocalPort, RemoteAddress, RemotePort, Status
FROM netstat()
WHERE Status = 'ESTABLISHED'
AND Name =~ '(?i)screenconnect|connectwise'
Remediation Script
The following PowerShell script audits endpoints for unauthorized ScreenConnect installations, identifies non-standard deployments, and provides remediation options.
# SCKit ScreenConnect Abuse - Audit and Remediation Script
# Run with administrative privileges on target endpoints or via GPO/Intune
# Author: Security Arsenal
# Date: 2026-11-13
Write-Host "=== ScreenConnect Abuse Audit ===" -ForegroundColor Cyan
Write-Host "Scanning for unauthorized ScreenConnect installations..." -ForegroundColor Cyan
# Define approved installation paths (customize for your environment)
$approvedPaths = @(
"C:\Program Files\ScreenConnect*",
"C:\Program Files (x86)\ScreenConnect*",
"C:\Program Files\ConnectWise*",
"C:\Program Files (x86)\ConnectWise*",
"C:\ProgramData\ScreenConnect*"
)
# Define suspicious paths where SCKit commonly deploys
$suspiciousPaths = @(
"C:\Users\*\AppData\Local\Temp\*ScreenConnect*",
"C:\Users\*\AppData\Roaming\*ScreenConnect*",
"C:\Users\Public\*ScreenConnect*",
"C:\Windows\Temp\*ScreenConnect*",
"C:\Users\*\Downloads\*ScreenConnect*",
"C:\Users\*\Desktop\*ScreenConnect*"
)
$findings = @()
# Check 1: Find ScreenConnect processes from non-standard paths
Write-Host "`n[1] Checking running ScreenConnect processes..." -ForegroundColor Yellow
$scProcesses = Get-Process | Where-Object { $_.ProcessName -match "ScreenConnect|ConnectWise" }
foreach ($proc in $scProcesses) {
$procPath = $proc.Path
$isApproved = $false
foreach ($approved in $approvedPaths) {
if ($procPath -like $approved) { $isApproved = $true; break }
}
if (-not $isApproved) {
Write-Host " [ALERT] ScreenConnect process from non-standard path: $($procPath)" -ForegroundColor Red
Write-Host " PID: $($proc.Id) | Started: $($proc.StartTime)" -ForegroundColor Red
$findings += @{Type="SuspiciousProcess"; Path=$procPath; PID=$proc.Id; Action="Review and terminate if unauthorized"}
} else {
Write-Host " [OK] ScreenConnect process from approved path: $($procPath)" -ForegroundColor Green
}
}
# Check 2: Find ScreenConnect files in suspicious locations
Write-Host "`n[2] Checking for ScreenConnect files in suspicious locations..." -ForegroundColor Yellow
foreach ($susPath in $suspiciousPaths) {
$files = Get-Item -Path $susPath -ErrorAction SilentlyContinue
foreach ($file in $files) {
Write-Host " [ALERT] ScreenConnect file in suspicious location: $($file.FullName)" -ForegroundColor Red
Write-Host " Created: $($file.CreationTime) | Modified: $($file.LastWriteTime)" -ForegroundColor Red
$findings += @{Type="SuspiciousFile"; Path=$file.FullName; Created=$file.CreationTime; Action="Quarantine and investigate"}
}
}
# Check 3: Check for ScreenConnect services
Write-Host "`n[3] Checking for ScreenConnect services..." -ForegroundColor Yellow
$scServices = Get-Service | Where-Object { $_.Name -match "ScreenConnect|ConnectWise" -or $_.DisplayName -match "ScreenConnect|ConnectWise" }
foreach ($svc in $scServices) {
$svcPath = (Get-CimInstance -ClassName Win32_Service -Filter "Name='$($svc.Name)'" -ErrorAction SilentlyContinue).PathName
Write-Host " [INFO] Service: $($svc.DisplayName) | Status: $($svc.Status) | Path: $($svcPath)" -ForegroundColor $(if($svc.Status -eq 'Running'){'Yellow'}else{'Gray'})
$findings += @{Type="Service"; Name=$svc.Name; DisplayName=$svc.DisplayName; Status=$svc.Status; Path=$svcPath; Action="Verify against approved software inventory"}
}
# Check 4: Check registry run keys for ScreenConnect persistence
Write-Host "`n[4] Checking registry persistence mechanisms..." -ForegroundColor Yellow
$runKeys = @(
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
"HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce",
"HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
)
foreach ($key in $runKeys) {
$entries = Get-ItemProperty -Path $key -ErrorAction SilentlyContinue
if ($entries) {
$entries.PSObject.Properties | Where-Object { $_.Value -match "ScreenConnect|ConnectWise" } | ForEach-Object {
Write-Host " [ALERT] Registry persistence found: $($key)\$($_.Name) = $($_.Value)" -ForegroundColor Red
$findings += @{Type="Persistence"; Key=$key; Name=$_.Name; Value=$_.Value; Action="Remove if unauthorized"}
}
}
}
# Check 5: Check for ScreenConnect network connections
Write-Host "`n[5] Checking active ScreenConnect network connections..." -ForegroundColor Yellow
$scConns = Get-NetTCPConnection -State Established -ErrorAction SilentlyContinue | Where-Object {
$proc = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
$proc.ProcessName -match "ScreenConnect|ConnectWise"
}
foreach ($conn in $scConns) {
$procName = (Get-Process -Id $conn.OwningProcess).ProcessName
Write-Host " [INFO] Active connection: $($procName) (PID:$($conn.OwningProcess)) -> $($conn.RemoteAddress):$($conn.RemotePort)" -ForegroundColor Yellow
}
# Summary
Write-Host "`n=== AUDIT SUMMARY ===" -ForegroundColor Cyan
if ($findings.Count -eq 0) {
Write-Host "No unauthorized ScreenConnect indicators detected." -ForegroundColor Green
} else {
Write-Host "$($findings.Count) item(s) require investigation:" -ForegroundColor Red
foreach ($f in $findings) {
Write-Host " [$($f.Type)] $($f.Action)" -ForegroundColor Yellow
}
}
# Optional: Remove unauthorized ScreenConnect (uncomment with caution)
# To stop and remove unauthorized ScreenConnect services:
# Get-Service | Where-Object { $_.Name -match "ScreenConnect|ConnectWise" } | Stop-Service -Force
# Get-Service | Where-Object { $_.Name -match "ScreenConnect|ConnectWise" } | Set-Service -StartupType Disabled
Write-Host "`n=== Recommended Actions ===" -ForegroundColor Cyan
Write-Host "1. Cross-reference all ScreenConnect installations against your approved software inventory"
Write-Host "2. Verify ScreenConnect relay URLs are pointing to your organization's approved instance"
Write-Host "3. Review ScreenConnect admin console for unauthorized access or session logs"
Write-Host "4. Check with your MSP to confirm their ScreenConnect deployment is secured and audited"
Write-Host "5. Deploy the Sigma rules and KQL queries from this guidance to your SIEM/EDR"
Remediation
Immediate Actions (Next 24 Hours)
-
Inventory all ScreenConnect deployments across your environment. Know exactly which endpoints have ScreenConnect installed, which version, which relay/instance they connect to, and who authorized the installation. Any ScreenConnect installation not in your approved software inventory is a finding until proven otherwise.
-
Verify relay/instance configuration: ScreenConnect clients connect to a configurable relay server. SCKit-style attacks redirect the client to an attacker-controlled relay. Verify that all ScreenConnect instances point to your organization's approved ConnectWise cloud instance or on-premises server.
-
Review ScreenConnect admin console: Check for unauthorized host client deployments, unexpected session logs, unfamiliar technician accounts, and sessions initiated outside of normal support hours.
-
Engage your MSP: If you consume IT support through an MSP, contact them immediately. Ask specifically: Are they aware of the SCKit campaign? Have they audited their ScreenConnect instance? Have they implemented the mitigations below? Your MSP's ScreenConnect instance is a potential attack vector into your environment.
Short-Term Hardening (Next 7 Days)
-
Implement application control: Use Windows Defender Application Control (WDAC), AppLocker, or your EDR's application control to restrict ScreenConnect execution to approved paths and signed binaries only. Block ScreenConnect execution from user-writable directories.
-
Enable ScreenConnect session auditing: Ensure all ScreenConnect sessions are logged with full audit trails. Enable alerts for sessions initiated outside of business hours or from unexpected source IPs.
-
Deploy the detection content above: Implement the Sigma rules in your SIEM, run the KQL hunt queries in Sentinel/Defender XDR, and execute the Velociraptor artifact across your fleet.
-
Restrict ScreenConnect network access: Where possible, implement firewall rules or DNS filtering to only allow connections to your approved ScreenConnect relay domains/IPs. Block outbound connections to unknown ScreenConnect instances.
Long-Term Strategic Actions
-
Establish RMM governance: Create a formal policy for approved remote access tools. Maintain an approved software list, require change control for RMM deployments, and conduct regular audits.
-
Implement zero-trust principles for remote support: Require MFA for all technician sessions, implement just-in-time access for remote support, and monitor for session anomalies using UEBA capabilities.
-
Educate technicians: Your help desk and IT support staff are the primary targets of this campaign. Train them to recognize signs of session hijacking, unexpected ScreenConnect prompts, and unusual behavior during remote sessions.
CISA Guidance
CISA and NSA have published joint guidance on defending against RMM abuse: CISA Guide to Securing Remote Access Software. Review and implement the recommendations in this guidance as they directly apply to this threat class.
Vendor Advisory
Refer to the official Microsoft Security Blog post for the latest indicators and recommendations: SCKit Abuses ScreenConnect — Microsoft Security Blog
Conclusion
The SCKit campaign is a stark reminder that the tools we trust most — the ones our IT teams depend on daily — are also the tools attackers covet most. ScreenConnect abuse is not new, but the specific targeting of technician sessions represents an escalation in adversary tradecraft. Attackers are not just using RMM tools for access; they are actively hunting the defenders.
For SOC teams: the detection content in this post is designed to be deployed today. Hunt first, ask questions second. For CISOs and IT leadership: your RMM governance (or lack thereof) is now a front-line security control. If you cannot account for every ScreenConnect instance in your environment, you have a gap that an attacker may already be exploiting.
The MSP ecosystem amplifies this risk. A single compromised ScreenConnect instance at your MSP can cascade into hundreds of downstream client environments. Do not assume your service providers are immune — verify.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.