Threat Analysis: SCKit Worm and GSocket Abuse, Your MSP's Remote Access Tools Are Becoming Attack Infrastructure

Threats & Attacks

Threat Analysis: SCKit Worm and GSocket Abuse, Your MSP's Remote Access Tools Are Becoming Attack Infrastructure

This is your Daily Threat Analysis for the 12th of November 2026.

Two stories today, and they are connected by a thread that matters specifically to UK small and medium businesses: the tools your managed service provider uses to look after your systems are being turned into attack infrastructure. Not hypothetically. Right now.


The SCKit Worm: 48 Organisations Hit Through a ScreenConnect Plugin Flaw

On the 11th of November 2026, researchers at Huntress published analysis of an active operation they have named SCKit. Attackers exploited a vulnerability in third-party plugins for ConnectWise ScreenConnect, one of the most widely deployed remote management platforms in the UK managed services sector, and used it to spread a worm across 288 hosts belonging to 48 separate organisations in a single campaign.

The operation ran in two stages. First, the worm spread laterally from already-infected endpoints to technician workstations by stealing session cookies. Once a technician workstation was compromised, the attackers used the access and credentials available there to push attacker-controlled ScreenConnect clients outward to other managed endpoints. The second stage involved deploying the SCKit toolkit itself, which installs rogue ScreenConnect clients and session cookie relay infrastructure across the victim environment.

In response, ConnectWise disabled five third-party extensions as a precautionary measure across approximately 400 environments. That is a reasonable containment step. What ConnectWise has not been able to confirm, as of publication today, is the initial access vector, how the attackers first got into the plugin infrastructure to begin the chain.

That detail matters. The advisory tells you what happened. What it does not tell you is whether the initial access vector has been closed, or whether additional environments remain exposed through plugins that were not among the five disabled.

What This Means for UK SMBs

ScreenConnect is pervasive in the UK MSP market. If your IT provider uses it, and there is a reasonable chance they do, your endpoints were potentially reachable through this chain, depending on what plugins your provider had installed and whether those were among the affected extensions.

The worm-like propagation mechanism is what makes this serious. This was not a targeted intrusion against a single organisation. It spread automatically, jumping from one MSP-managed environment to another using the legitimate session infrastructure. From an attacker’s perspective, compromising one MSP technician workstation gave them reach into dozens of unrelated client businesses simultaneously.

If your IT provider tells you this does not affect you because you are too small, ask them how many of the 48 organisations hit in this single operation thought the same thing.

What To Ask Your Provider

Contact your IT provider today and ask the following:

  • Which ScreenConnect plugins were active in your environment, and which have been disabled in the last 48 hours?
  • Were any of the five ConnectWise-disabled extensions present in your managed environment?
  • Has your provider conducted a review of active ScreenConnect client instances to identify any that were not authorised by their team?
  • Are there indicators of session cookie relay processes on any managed endpoints?

If your provider cannot answer these questions with confidence and evidence, escalate. The NCSC’s guidance on supply chain security is clear that you have a right to understand the security posture of the services managing your infrastructure. The fact that this needs saying in 2026 is, as usual, instructive.


GSocket: Patching Your Server Is Not Enough

Separately, but on the same day, Microsoft’s threat intelligence team published research on a significant and growing trend: multiple threat actor groups are deploying GSocket, a legitimate open-source remote access relay tool, on compromised Linux servers specifically to maintain access after vulnerabilities are patched.

The numbers from Microsoft’s analysis: GSocket deployment by threat actors increased by 356.2% between March and August 2026. The primary targets are web applications and hosting environments. Education and research sectors account for 30.7% of affected organisations in the data, but hosting-dependent businesses across all sectors are exposed.

GSocket works by tunnelling connections through a relay network, bypassing firewall rules and NAT configurations. Because it is legitimate open-source software, it does not trigger the same detection responses as purpose-built malware. It blends in. That is precisely why threat actors are using it.

The operational logic here is straightforward and worth understanding clearly. An attacker finds a vulnerability in a web application running on your Linux server, a PHP application, a content management system, a customer portal. They exploit it and gain access. You or your provider discover the breach, patch the vulnerability, and believe the incident is resolved. But if the attacker installed GSocket before you discovered them, they still have a tunnel into your server. The remediation did not evict them. It just closed the door they came in through.

This is covered by CVE-2026-43284, though the GSocket tool itself is not the vulnerability, it is the persistence mechanism installed after exploitation of other vulnerabilities.

Why This Is Particularly Relevant to Businesses Running Web Hosting or CMS Platforms

UK SMBs running their own web infrastructure, whether that is a WordPress site on a VPS, a customer-facing application, or any Linux-based server managed by a third-party hosting or IT provider, should treat this as a prompt to verify their environment.

The education and research sector weighting in the data is likely a function of those organisations running more exposed web infrastructure with longer patch cycles. But the technique is not sector-specific. Any Linux server with a web-facing application is a potential target.

Microsoft’s research also notes that GSocket use increased substantially through the period studied, which suggests that word of its effectiveness has spread across multiple threat actor communities. This is not one group’s tactic. It is becoming standard practice.

Verification Steps

If you manage or are responsible for Linux-based server infrastructure, the following checks are warranted:

  • Look for unexpected processes associated with GSocket (gs-netcat, gsnc, gs-sftp or similar). GSocket binaries can be renamed, so look for unusual processes making outbound connections on port 443 or similar commonly-allowed ports.
  • Review cron jobs and systemd unit files for entries that were not explicitly created by your team. GSocket is typically installed with persistence mechanisms to survive reboots.
  • Check for unexpected outbound connections to relay infrastructure. GSocket by design routes through external relay servers, traffic analysis should show this.
  • If you have suffered any web application compromise in the past 12 months and did not conduct a full post-incident forensic review, treat your server as potentially still compromised until proven otherwise.

If your hosting provider manages your Linux infrastructure on your behalf, ask them specifically whether they have assessed GSocket indicators across managed environments in light of today’s Microsoft research.


The Connecting Thread

These two stories are not coincidentally appearing on the same day. They reflect a consistent operational logic: attackers are focusing effort on the legitimate tools and infrastructure that sit between you and your IT provider, because those tools have privileged access to your systems and are often less scrutinised than the endpoints themselves.

ScreenConnect manages your endpoints. GSocket persists on your servers after the initial incident is supposedly resolved. In both cases, the attack surface is the management layer, not the user-facing systems your security controls are typically oriented toward.

The NCSC published guidance on supply chain and managed service provider security that is directly relevant here. The fact that MSP-targeting attacks of this nature are still generating incident reports at this scale tells you everything about how seriously that guidance has been absorbed at the operational level.


If this briefing is useful to you, follow the show wherever you listen so tomorrow’s analysis lands automatically, and if you know someone running an MSP-dependent business who needs the heads-up today, pass this along. The SCKit story in particular is moving quickly.


Sources

SourceTitleURL
HuntressSCKit Worm Installs Rogue ScreenConnect Clients and Session Cookie Relays Across Hundreds of Endpointshttps://www.huntress.com/blog/sckit-worm-rogue-screenconnect
The RegisterHackers exploiting ScreenConnect plugin flaw to spread malware across hundreds of PCshttps://www.theregister.com/security/2026/11/12/hackers-exploiting-screenconnect-plugin-flaw-to-spread-malware-across-hundreds-of-pcs/5309361
Microsoft Security BlogGlobal Socket: How Threat Actors Are Weaponizing GSocket for Stealthy C2https://www.microsoft.com/en-us/security/blog/2026/11/11/global-socket-how-threat-actors-weaponizing-gsocket-stealthy-c2
BleepingComputerHackers plant GSocket on Linux servers for persistent accesshttps://www.bleepingcomputer.com/news/security/hackers-plant-gsocket-on-linux-servers-for-persistent-access/
AlienVault OTXSCKit Worm threat intelligence pulse (CVE-2026-84869)https://www.huntress.com/blog/sckit-worm-rogue-screenconnect
AlienVault OTXGSocket C2 abuse intelligence pulse (CVE-2026-43284)https://www.microsoft.com/en-us/security/blog/2026/11/11/global-socket-how-threat-actors-weaponizing-gsocket-stealthy-c2

Filed under

  • msp-security
  • remote-access
  • smb-security
  • supply-chain-risk
  • incident-response
  • vendor-risk
  • uk-business