Microsoft says the SCKit worm uses a hijacked ScreenConnect session to reach IT technicians' workstations

Seven steps, seven queries, 27 indicators and no victim count

Microsoft's post on SCKit, dated 13 November 2026 (the page data says published 21:31 UTC and updated 22:07 UTC), numbers 7 steps in its attack chain, prints 7 Microsoft Defender XDR advanced hunting queries and lists 27 indicators in three tables: 5 domains and 2 IP addresses, 18 file hashes (15 SHA-256 and 3 SHA-1) and 2 ScreenConnect client identifiers. The counts are derived: 7 + 18 + 2 = 27. The three SHA-1 rows carry the same three roles as the first three SHA-256 rows, so the post hashes 15 files in all (derived).

The post says Microsoft Threat Intelligence "confirmed ConnectWise's reported activity" and that "the worm targets IT support technician workstations using the hijacked authenticated ScreenConnect Session". The angle of this briefing is that sentence: in the post's account the person doing remote support, and the browser session they use, is a target as well as the customer machine.

What that does not establish. The post prints no count of MSPs, instances, endpoints, technician workstations or downstream devices. It names no actor beyond "a threat actor". It gives no first-activity date of Microsoft's own. It does not say any customer data was taken. And its own caption on the attack-chain figure says the dashed path "describes the toolkit's propagation design, not a confirmed sequence of infections". The way in is also open: the post says "the entry method for the reported campaign remains under investigation". Read the technician-targeting parts as what Microsoft says the toolkit is built to do and what it says it has identified, not as a measured tally.

Whose interests. Microsoft sells Microsoft Defender XDR and Defender for Endpoint, and the queries, alert titles and detection names in the post are those products'. ConnectWise sells ScreenConnect, the product the post says is abused. The post is Microsoft's account of ConnectWise's reported activity and advisory; this site did not open either ConnectWise page that the post lists.

Three roles, and where the post says the attacker works

The post explains ScreenConnect as three parts. Each row below is the post's description, with what the post says the actor does there. The first column is the post's own labels.

The post then separates two attack surfaces and says they must be handled separately: "Extension authentication and client-side file transfer are different attack surfaces". One is a reported entry to the server through its add-ons. The other is the path from a customer endpoint to the technician.

The reported way in, as the post relays it. The post says ConnectWise's advisory describes a reported authentication flaw in RMM+ versions 1.0.31 and 1.0.32: "when no access key was configured, the extension accepted an empty key". In that configuration, per the post, an unauthorized caller "could submit commands to the server's API for delivery to managed endpoints without a normal ScreenConnect user sign-in". The post adds that ConnectWise is investigating extension abuse as a route in and that the entry method for the campaign "remains under investigation". It prints no CVE identifier for the RMM+ flaw. The only identifier it prints is CVE-2026-84869, which it ties to a different path, covered below.

Fix date before write-up date. The post says "The fix for CVE-2026-84869 was released on September 8, 2026". That is 66 days before the post (derived: 22 days left in September, 31 in October and 13 in November). The post says that beginning on 11 November ConnectWise reported an active campaign, two days before the post (derived). The post does not say which entry route, if any, the actor used in a given intrusion, and it says the client-side path "is separate from the server-side access used to deploy SCKit".

The chain, step by step, as the post numbers it

The post's attack-chain section has 7 numbered steps and 8 figures (derived by counting the headings and captions). Steps 1 to 6 run on a customer endpoint; the post says the sequence "establishes a separate remote-access connection and prepares the scripts and RelayTrap component that target a later technician". The table keeps to what the post prints and names each artifact it prints.

Zoom

The part the post leaves quiet. The post does not say how many endpoints reached step 5 or step 6, or whether any technician workstation reached step 7 in the wild rather than in the design. It also prints the request selectors p=1, p=3, p=4, p=5 and p=6 and no p=2 (derived from the five rows of its selector table); the post does not explain the gap.

The technician is the target: two routes the post describes

The post describes two ways SCKit is built to reach a technician, and it keeps them apart.

Route one: RelayTrap, from the endpoint to the technician. RelayTrap is a "malicious replacement for the ScreenConnect client on an affected customer endpoint". It is "designed to reuse the customer endpoint's ScreenConnect connection details in place of its normal client", and "When a technician connects with a vulnerable host client, RelayTrap attempts to deliver the staged batch launcher through that session". The launcher retrieves the same decoder, which the post calls "extending the toolkit's deployment design from the customer device to the technician workstation". The post says ConnectWise states that client 26.6.5 and later block this transfer technique, and that the fix for CVE-2026-84869 was released on 8 September 2026. Because "a cloud-console update does not automatically update those clients", the post tells defenders to verify each technician client's installed version.

Route two: the browser session. The toolkit looks for cookies named .ASPXAUTH, in a section the post heads "6. Browser access targets authenticated ScreenConnect sessions". The post's description of what a stolen cookie is for is that the distribution component is "designed to combine an authentication cookie with the required anti-forgery and access tokens, enumerate accessible sessions, upload a payload using ToolboxRelayUploader.exe, and queue execution through the Shared Toolbox". It adds that the workflow removes the uploaded Toolbox item afterwards, and that "The account's permissions determine which additional sessions and devices the distribution workflow can reach". The post does not say which route it means by "hijacked authenticated ScreenConnect Session" in its opening; this site reads it as this cookie route, which is an inference.

This site's inference, labelled as such. A technician account that can see many customers' sessions is a wider door than any one customer endpoint, and the post says reach follows the account's permissions. The post prints no example of how many sessions a typical account reaches, so the size of that door is not stated. The post also does not say whether route two works without route one, that is, whether the toolkit reaches a technician workstation by any route other than a connection to an endpoint that carries RelayTrap, or how many technician workstations received the launcher.

Labels that stand in for a clean machine

The post's headline warning is one sentence: "Removing an unauthorized client alone does not remove the toolkit's persistence or invalidate exposed web sessions". Five comforting actions each leave something behind, in the post's own words.

Zoom

The post's guidance for the removal itself is blunt about the kit's own script: "Do not use a cleanup script recovered from the kit as a remediation tool". It also says to "Verify the complete state before restoring connectivity" and, where that cannot be done, to "Rebuild devices when integrity cannot be established".

What the post states, and what it does not

What a hunt team can copy from Microsoft's post

Everything in this section is copied from Microsoft's post. Where the post prints an indicator, it prints it defanged, and so does this site. Do not open, resolve or fetch any of these; they are for matching in logs. Each block says in words whose it is and what a defender does with it. Nothing here was written or altered by this site except the plain-text introductions.

Network indicators. Microsoft's table lists 5 domains and 2 IP addresses with a role for each. A defender searches DNS, proxy, firewall and EDR network logs for them and, per the post, reviews the full destination and the initiating process, because an approved remote-support server can sit close to an unapproved one.

File hashes. The post lists 15 SHA-256 hashes and 3 SHA-1 hashes, and warns that "The watcher compiles RelayTrap against local client libraries, and embedded configuration changes script hashes". A defender matches these against file events and treats a miss as inconclusive: the post says to use file and process behaviour to investigate other builds. The SHA-1 rows are printed for the query that follows; the post says SHA-256 is usually unpopulated in DeviceFileEvents.

Client identifiers. Two identifiers are labelled "Unauthorized ScreenConnect client identifier". The post does not say where on a device the identifier is read. This site's suggestion: compare the clients installed on managed devices with these two. The post's own advice is to validate each client's enrolled instance and relay destination before removing it.

Paths, names and strings. These are the file paths, registry value, task markers and request strings the post names in its text. They are matching strings, not instructions. A defender searches command lines, file events and the registry for them, and inspects any scheduled task whose definition mentions them.

C:\Windows\Temp\sc.msi
/Bin/ScreenConnect.ClientSetup.msi
c=Exploited<N>
ns[.]mo7sen[.]dev/EadF.php?p=4
-Mode full
BATPATH
SCKIT_SELF
%TEMP%\SCKitBundle
%TEMP%\SCKit\trapkit\payload
%TEMP%\k<32-hex>.ps1
C:\ProgramData\RelayTrap
RelayTrapLiteAlert
-PollSeconds 10
ToolboxRelayUploader.exe
RelayTrap.cs
RelayTrap.exe
trapbins
TrapWatch
.ASPXAUTH
-NoReArm

Request selectors. The post says the scripts use these values of p at the decoder's server path to request components. They help a defender read a proxy log: a request for one of these on a host that is not on the approved list is worth a look.

Microsoft Defender for Endpoint alert titles. The post lists alert titles by tactic, and separate Microsoft Defender Antivirus detection names (including the Tikise, RelayPersist, SCRelayTrap and ScreenConnect families, not repeated here). A defender checks whether those alerts fired in the period and reads them with the device timeline and the ScreenConnect audit records, as the post advises.

The seven advanced hunting queries. Microsoft prints seven queries for Microsoft Defender XDR advanced hunting. They are reproduced exactly: this site did not write or change any query. The post says "Each query below runs independently and uses a 14-day lookback" and to adjust the range to the investigation window and retention. One difference inside the post: the last query, for the generated PowerShell file name, uses a 30-day lookback in its own text. The first query holds the campaign domain names and addresses. The post prints them undefanged inside the query; this site shows them defanged with [.] and nothing else changed, so refang them before running the query in Defender. None of them should be opened.

Connections to campaign infrastructure. Searches network events for the listed domains and addresses. A defender reviews the full destination, the initiating process and the approved remote-support infrastructure for each match.

DeviceNetworkEvents
| where Timestamp > ago(14d)
| where RemoteUrl has_any (
    "ns[.]mo7sen[.]dev", "sc[.]payproofkit[.]com",
    "newnewnew[.]gotdns[.]org", "soxnewwork[.]homedns[.]org",
    "cdn007-digitaldownloads[.]com")
    or RemoteIP in ("185[.]99[.]255[.]28", "155[.]94[.]150[.]39")
| project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP,
    InitiatingProcessFileName, InitiatingProcessCommandLine, ReportId

Toolkit command lines and cookie-query activity. Searches process command lines for the toolkit's distinctive names, a staging path, the installer marker and the cookie name. This site's reading: a match on the cookie name in a command line is worth treating as urgent on a technician workstation.

DeviceProcessEvents
| where Timestamp > ago(14d)
| where ProcessCommandLine contains "/EadF.php"
    or ProcessCommandLine contains "SCKit"
    or ProcessCommandLine contains "RelayTrap"
    or ProcessCommandLine contains "Panel-Lateral"
    or ProcessCommandLine contains "ToolboxRelayUploader"
    or ProcessCommandLine contains ".ASPXAUTH"
    or ProcessCommandLine contains "c=Exploited"
| project Timestamp, DeviceId, DeviceName, FileName,
    ProcessCommandLine, InitiatingProcessFileName, ReportId

Known installer, archive and uploader files. Matches file events for the sc.msi package, the staged ZIP and the uploader by SHA-1. The post says to combine hash matches with command-line and persistence findings.

DeviceFileEvents
| where Timestamp > ago(14d)
| where SHA1 in~ (
    "0be01e7bd69cfdd222645d49bb5ad9961372fef2",
    "3f81c9c874a896c46e4bccea2fad2eaa3d9f2054",
    "13ce33b19daee3963f7e15d461b191c38f6bc0d3")
| project Timestamp, DeviceId, DeviceName, FileName, FolderPath,
    SHA1, InitiatingProcessFileName, ReportId

Registry values referencing RelayTrap. Finds writes to the RelayTrapLiteAlert value or any value whose data contains RelayTrap. A defender reviews the registry key, the value data and the initiating process.

DeviceRegistryEvents
| where Timestamp > ago(14d)
| where ActionType == "RegistryValueSet"
| where RegistryValueName =~ "RelayTrapLiteAlert"
    or RegistryValueData contains "RelayTrap"
| project Timestamp, DeviceId, DeviceName, RegistryKey,
    RegistryValueName, RegistryValueData,
    InitiatingProcessFileName, ReportId

RelayTrap scheduled-task events. Finds scheduled-task events mentioning RelayTrap or TrapWatch. The post says to inspect the task definition for its triggers, executable and arguments.

DeviceEvents
| where Timestamp > ago(14d)
| where ActionType contains "ScheduledTask"
| where AdditionalFields contains "RelayTrap"
    or AdditionalFields contains "TrapWatch"
| project Timestamp, DeviceId, DeviceName, ActionType,
    AdditionalFields, InitiatingProcessFileName, ReportId

Defender Antivirus path-exclusion writes. Finds writes to the Defender exclusions paths. The post says to review changes naming Windows Temp, ConnectWiseControl_, CWInstall_ or RelayTrap and to verify their authorization and effective policy.

DeviceRegistryEvents
| where Timestamp > ago(14d)
| where ActionType == "RegistryValueSet"
| where RegistryKey contains @"\Windows Defender\Exclusions\Paths"
| project Timestamp, DeviceId, DeviceName, RegistryKey,
    RegistryValueName, RegistryValueData,
    InitiatingProcessFileName, ReportId

Generated PowerShell loader files. Looks for temporary files named k followed by 32 hexadecimal characters and .ps1, which the post says can reveal staged payloads independently of known hashes or infrastructure.

DeviceFileEvents
| where Timestamp > ago(30d)
| where FileName matches regex @"(?i)^k[0-9a-f]{32}\.ps1$"
| project Timestamp, DeviceId, DeviceName,
ActionType, FileName, FolderPath, SHA256,
InitiatingProcessFileName

What to do, in order

The question the post leaves open

If removing the unauthorized client leaves a scheduled task, a Run value and live web sessions, and Microsoft prints no count of technician workstations that received the launcher, how does an MSP show a customer that the machine its staff sign in from is clean, and who checks?

Key facts