Research

SCKit Waits on the Customer's Machine for Your Technician to Connect. Update Every ScreenConnect Host Client to 26.6.5.9742 or Later, and Hunt for RelayTrap Before Anyone Opens a Session

Patrick Duggan · · 7 min read

SCKit Waits on the Customer's Machine for Your Technician to Connect. Update Every ScreenConnect Host Client to 26.6.5.9742 or Later, and Hunt for RelayTrap Before Anyone Opens a Session

If your technicians use ScreenConnect, update the Host client on every technician workstation to build 26.6.5.9742 or later today, and do not open an interactive session to any customer machine you have not first checked for a scheduled task named TrapWatch, a folder named C:\ProgramData\RelayTrap, or a Run-key value named RelayTrapLiteAlert. That is the new fact since our post last night: the toolkit behind this week's rogue ScreenConnect campaign, which researchers now call SCKit, is built to attack in the reverse direction, from an infected customer device back to the technician who connects to it. Blackpoint Cyber's Adversary Pursuit Group recovered and decrypted it, and Huntress published its own analysis the same day. The credit for this research is theirs.

This follows our first post on the campaign, which has the extension guidance and the network indicators: https://www.dugganusa.com/post/screenconnect-msp-rogue-clients-huntress

What to do, in order

  1. Patch the technician side. CVE-2026-84869 is a flaw in the ScreenConnect client that lets a remote side push and run a file through an active session "without authorization or Host confirmation." Blackpoint says it affects builds earlier than 26.6.5.9742 and recommends updating Host and Guest clients to 26.6.5.9742 or later and reinstalling Host clients as ConnectWise advises. The CVE record lists "All versions prior to 26.6.5" as affected. If your technicians run an older Host client, this is the hole SCKit's trap is aimed at.
  2. Check before you connect. On any endpoint you suspect, look from your EDR or another tool outside ScreenConnect for the TrapWatch scheduled task (it runs as SYSTEM), the RelayTrap folder, the RelayTrapLiteAlert Run key, a file named RelayTrap.cs, temporary scripts named k followed by 32 hex characters and .ps1, and Microsoft Defender exclusions added for msiexec.exe and powershell.exe. Blackpoint also suggests looking for ScreenConnect event ID 201 in session context and PowerShell connections to ns.mo7sen.dev.
  3. If a technician already connected to a suspect machine, review that technician's workstation for unexpected execution and for access to browser cookie stores, end their ScreenConnect web sessions from a clean device, and rotate the credentials involved. SCKit's second stage hunts for the .ASPXAUTH session cookie so it can act as the technician without a password.
  4. Inventory your Access clients. List every installed ScreenConnect Access client and compare its relay address against the servers you actually run. The two rogue client IDs in this campaign are 2588ef5c15954b10 and ed630cc2c873b091.
  5. Review Run Command and Shared Toolbox. The worm's spreading step uploads a payload to the Shared Toolbox and pushes it to every session the stolen identity can reach. Look for Toolbox items and commands you did not create, sent to many endpoints at once.
  6. Do the steps from last night too. Disable the third-party extensions ConnectWise named, preserve logs, and block the network indicators. They are in our earlier post and still apply.

What is confirmed

  • The reverse direction is real in the code. Blackpoint describes a TrapWatch task that finds a legitimate ScreenConnect Guest service and replaces it with a process that compiles RelayTrap.cs on the endpoint. The replacement reconnects with the original Guest's parameters, so the technician sees an ordinary session. When the technician's Host joins, it sends a file-transfer-and-run request toward the Host. The configured payload is Run-Lateral-Full.bat. Blackpoint notes the recovered code "does not check the Host version first," so it tries this even against a patched Host.
  • The patched client held in Blackpoint's test. Blackpoint reproduced the attempt against a current client: "The malicious Guest queued the transfer, but the Host never requested or executed the payload." And: "The vendor's 26.6.5 client fix remained effective in this test." Blackpoint told The Hacker News it had "no evidence of successful exploitation and no evidence of a bypass at this time."
  • Nobody has seen the worm step work. Huntress: "To date we have not observed a successful jump from an infected endpoint to a technician workstation or from that workstation to other endpoints," and "The console-takeover attempt failed in every recovered host log we have checked so far." That is Huntress's view across its own customers' recovered logs, not across every MSP.
  • The CVE dates, from the records. The CVE record was published Tuesday, September 8, 2026, CVSS 3.1 score 9.9, and says "ScreenConnect servers are not impacted." CISA added CVE-2026-84869 to its Known Exploited Vulnerabilities catalog on Friday, September 11, with a federal due date of Monday, September 14. CISA's ransomware-use field reads "Unknown." Huntress writes that ConnectWise shipped the fix after a Huntress response to "similar worm-like activity" in September, and The Hacker News reports the flaw was earlier used to deliver a cryptocurrency miner.
  • It is the same campaign as last night's, on the evidence Blackpoint published. Blackpoint says SCKit's staging paths, client IDs, relay addresses, file names and overlapping file hashes "match indicators published during the active MSP investigation, including those documented by Huntress." The values line up with what we listed last night: 185.99.255.28, the two client IDs, sckit-run.bat, TrapWatch.ps1 and ToolboxRelayUploader.exe. Five of Blackpoint's nine file hashes also appear in Huntress's list. Huntress, in turn, credits Blackpoint with first flagging cdn007-digitaldownloads.com. Huntress's updated count is at least 288 endpoints across 48 organizations, all of them Huntress customers, so the real total is at least that.

What is not known

  • How the attackers got the first foothold. Huntress believes it came through the RMM+ extension: in versions 1.0.31 and 1.0.32, "if an administrator had never configured the extension's access key, RMM+ would accept a blank one." Blackpoint "found no technical link between those extensions and SCKit's RelayTrap execution request" and calls their role in first access "a separate, unresolved question." Those two statements do not contradict each other (one is about entry, the other about the trap), but neither is a confirmed root cause.
  • Whether CVE-2026-84869 was exploited successfully in this campaign. The trap is built around the transfer the CVE describes. Huntress's post mentions the CVE only as background and does not say it was used on November 11. Blackpoint saw no successful exploitation.
  • What Huntress means by "affected" versions. Huntress's key takeaways say "The most current versions of the remote monitoring and management (RMM) software, 26.6.6.9747 and 26.7.6.9783, are affected." Read beside Blackpoint's test, the likeliest reading is that the campaign (rogue clients pushed by Run Command, and the trap itself) works on current versions, while the reverse file execution is blocked by the client fix. Neither company has said that in those words, so we are not stating it as fact. Patch, and still hunt.
  • Who is behind it. No actor has been named.

Why this one matters

The standard response to a suspicious endpoint is to connect to it and look. SCKit is written to punish exactly that habit: the infected machine waits for a technician, because the technician holds the keys to every other customer. The client fix stopped it in Blackpoint's lab. The defensive habit ConnectWise, Huntress and Blackpoint all repeat is the one that does not depend on a patch: investigate a suspect machine with a tool the attacker does not control.

How we know, and what we did

  • Sources read. Blackpoint's write-up, read in full through a fetch tool (a direct download was blocked by its Cloudflare challenge), including its indicator table, which we read twice and compared value by value. Huntress's SCKit post, read the same way. The CVE record from the CVE Program and the CISA KEV JSON, read directly. BleepingComputer and The Hacker News were used as leads; both trace to Blackpoint and Huntress, so this is two research sources, not four.
  • Our feed. The network indicators (185.99.255.28, 155.94.150.39, sc.payproofkit.com, cdn007-digitaldownloads.com, soxnewwork.homedns.org, newnewnew.gotdns.org, ns.mo7sen.dev) were already in our public feed from last night under the source manual-batch-screenconnect-msp-2026-11, so we did not add them twice. None of Blackpoint's file hashes was in our corpus before today. We added eight of them as SHA-256 hashes, malware family SCKit, confidence 80, under the source manual-batch-sckit: Stage0Loader.ps1, SilentForceInstall-WithUninstall.ps1, the p=4 decoder, the p=3 decoded bundle, RelayTrap.cs, TrapWatch.ps1, Panel-Lateral-free.ps1 and ToolboxRelayUploader.exe. These are Blackpoint's indicators, cited, not our observations. Huntress warns that hashes are weak here because the scripts are rebuilt with different embedded values per victim, so treat a hash miss as meaning nothing and hunt by the artifacts above.
  • Left out on purpose. Blackpoint's ninth hash is for ScreenConnect.ClientSetup.msi, an installer package built by ScreenConnect software carrying the attacker's configuration. We kept it out of a blocklist and suggest hunting by the rogue client IDs instead. Nothing under screenconnect.com or connectwise.com is in the feed.
  • Our edge. CVE-2026-84869 is a client-to-client transfer inside a ScreenConnect session, which our edge cannot see, and we do not run ScreenConnect. As a narrow check, we searched our own edge blocks, edge canaries and origin honeypot since October 12 for any request containing "screenconnect" or the staging path EadF.php: zero matches across 354,002 block events, 56,314 canary records and 809 origin captures. We have no ScreenConnect decoy, so that zero says nobody probed our websites for it on paths we log, nothing more. We did not find a dedicated earlier post of ours on CVE-2026-84869; it was mentioned in passing in a September roundup of KEV additions.

This is still a moving incident. Treat the above as roughly 95% right today and check the vendor pages before acting on anything that has changed.

Sources

  • Blackpoint Cyber, Sam Decker and Nevan Beal, SCKit research, November 11, 2026 (primary): https://blackpointcyber.com/blog/screenconnect-attack-sckit/
  • Huntress, SCKit and rogue ScreenConnect post, November 11, 2026, updated the same day (primary): https://www.huntress.com/blog/sckit-worm-rogue-screenconnect
  • CVE-2026-84869 record (CVE Program): https://www.cve.org/CVERecord?id=CVE-2026-84869
  • ConnectWise security bulletin cited by CISA: https://www.connectwise.com/company/trust/security-bulletins/2026-09-08-screenconnect-bulletin
  • CISA Known Exploited Vulnerabilities catalog (JSON): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
  • BleepingComputer, "New worm-like SCKit malware targets MSPs in ScreenConnect attacks," November 12, 2026: https://www.bleepingcomputer.com/news/security/new-worm-like-sckit-malware-targets-msps-in-screenconnect-attacks/
  • The Hacker News, SCKit coverage, November 2026: https://thehackernews.com/2026/11/sckit-malware-targets-screenconnect.html
  • Our earlier post on this campaign: https://www.dugganusa.com/post/screenconnect-msp-rogue-clients-huntress

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register