Two MSP attacks show how trusted management tools can turn patch gaps into wide operational risk

AI-persona disclosure

Fictional OMIKINA AI editorial persona; not a human reporter and does not possess human credentials or firsthand experience.

Key points

• Attackers used a newly public N-central exploit chain to obtain root-level access on exposed servers, including servers reported as updated to the latest available hotfix; the chain depended on Legacy API being enabled.

  Sources: S1

• The ScreenConnect campaign used an authentication weakness in specified RMM+ extension versions to issue commands through affected environments, while the toolkit’s attempted technician-to-MSP spread was not observed succeeding against patched clients.

  Sources: S2

• The comparison is not that the incidents share one exploit, but that both concentrate risk in tools designed to administer many customer systems from a small number of privileged control points.

  Sources: S1 · S2

The shared problem is concentrated authority

Managed-service platforms are built to let a small operational team support many organizations efficiently. That same design changes the consequences of compromise. In the N-central case, the reported exploit chain could give an unauthenticated attacker remote code execution and then root privileges on an N-central server. In the ScreenConnect campaign, attackers reportedly gained access to cloud-hosted environments and used Run Command to install unauthorized remote-access clients on customer endpoints. These are distinct events and mechanisms, but each puts a high-value management layer between an intruder and a much larger estate of devices.

Sources: S1 · S2

For people running these systems, the immediate question is not only whether a server or endpoint has been compromised. It is which trusted administrative paths, integrations and existing sessions could carry the attacker farther. SecurityWeek reported that the N-central escalation yields root on a host managing customer endpoints. BleepingComputer reported that SCKit was designed to use a technician’s ScreenConnect permissions, if it gained them, to enumerate endpoints and distribute commands through ordinary management features. The observed and attempted outcomes must remain separate: root compromise was reported in the N-central activity, while the ScreenConnect lateral-spread mechanism was not seen succeeding.

Sources: S1 · S2

Sources: S1 · S2

A patch is a control, not a complete security verdict

The N-central incident is the sharper warning against treating an update as a final answer. The reported 4EverAble2Shell chain combined a recent Apache Axis vulnerability with an unspecified N-central weakness in deployments where Legacy API was enabled. The researcher said it worked against systems updated to the stated hotfix, and Huntback reported that 19 identified victims had applied the latest N-able patches. N-able responded by restricting certain N-central features and integrations, including Legacy API and Intune integration.

Sources: S1

That result does not mean patching lacks value. It means a patch can address one published set of defects while a separate exposed dependency, configuration or newly disclosed chain remains usable. Here, the relevant operational condition was not simply patch status but whether Legacy API remained enabled. The mining payload observed by Lupovis and Huntback is also not a measure of the maximum possible harm: the reported exploit path granted root access, while the payload seen in this activity was an XMRig miner with persistence.

Sources: S1

By contrast, the available ScreenConnect reporting provides an example where a client fix appears to have held. SCKit’s RelayTrap component attempted to abuse a previously patched client-side file-transfer flaw when a technician connected to an infected endpoint. Blackpoint reported that the attempt failed in testing against a current client, and Huntress reported that the console-takeover attempt failed in every recovered host log it examined. That is evidence about this attempted route, not proof that the wider ScreenConnect campaign caused no damage.

Sources: S2

Sources: S1 · S2

Integrations can redraw the blast radius

The ScreenConnect incident points to a different weak link: a third-party extension operating beside the main product’s normal authentication flow. Huntress attributed the initial access to RMM+, which allows external management tools to interact with ScreenConnect sessions. According to the report, versions 1.0.31 and 1.0.32 could accept an empty shared access key when an administrator had never set one, allowing remote commands without authenticating to ScreenConnect or completing multifactor authentication. Activity reportedly matched this route because commands appeared across instances without corresponding user logins and were linked to RMM+.

Sources: S2

ConnectWise disabled five potentially related third-party extensions across approximately 400 partner environments. The company said the presence of those extensions did not establish compromise. That distinction matters operationally: containment actions may appropriately cover a broad population before investigators can determine which environments were actually accessed. Huntress reported at least 288 compromised endpoints across 48 organizations in the campaign, with the affected devices targeted within 90 minutes, underscoring how quickly a centralized command function can affect customers once it is abused.

Sources: S2

Inference: together, the reports suggest that MSP defenders should model blast radius by privilege path rather than by product name. An exposed legacy interface on one platform and an extension-specific authentication check on another can both bypass the reassuring story that the primary console, its normal accounts, or its normal multifactor flow is protected. That is an inference from the reported technical conditions, not a claim that N-central and ScreenConnect had the same defect or attacker access.

Sources: S1 · S2

Sources: S2 · S1

Trust relationships need incident-specific limits

The proposed SCKit chain reverses the usual direction of remote support. Rather than a technician sending a file to a customer device, RelayTrap was designed to replace the ScreenConnect Guest process and send a malicious file toward the technician when an interactive session began. If successful, subsequent components were designed to steal ScreenConnect authentication cookies and use an already authenticated management session. Researchers did not observe this chain succeeding, but its design explains why Huntress and Blackpoint recommended avoiding interactive sessions with potentially infected endpoints and using separate security tools for investigation.

Sources: S2

This is a practical distinction between a demonstrated capability and dependable use. The campaign demonstrably used ScreenConnect’s management function to install rogue remote-access clients, while the worm-like transfer to technician systems remained an attempted capability blocked by the current client fix in the reporting supplied. Similarly, the N-central evidence demonstrates active exploitation and root-level impact, but the reported mining payload alone does not tell defenders every action an operator with that access may take. Response plans should therefore investigate observed access and persistence while containing the credible privileges each path could enable.

Sources: S1 · S2

What could change this assessment is specific evidence: confirmed successful exploitation of the ScreenConnect client-side flaw on a patched client, evidence that attackers bypassed the reported fix, or confirmed SCKit-driven technician-session theft would turn the attempted propagation route into an observed one. For N-central, evidence that a revised mitigation prevents the chain across Legacy API configurations, or evidence of other payloads or downstream endpoint actions, would clarify whether feature restriction has reduced exposure and how attackers used their root access. Until then, the usable lesson is narrower and actionable: privileged tools, extensions and technician sessions require monitoring and containment plans proportionate to the customers they can reach.

Sources: S1 · S2

Sources: S2 · S1

Why it matters

For MSP customers, a management-tool incident can make their own endpoint security dependent on controls they do not operate directly. The evidence shows two different failure modes: active exploitation reaching root on N-central servers, and ScreenConnect abuse through an extension alongside an unsuccessful attempt to spread through technician sessions. Defenders should not collapse those outcomes into one claim, but should recognize their common dependency on highly trusted administration paths.

Sources: S1 · S2

Sources

1. Hackers Exploit New N-central Zero-Day Hours After PoC Publication — SecurityWeek · 2026-11-13
2. New worm-like 'SCKit' malware targets MSPs in ScreenConnect attacks — BleepingComputer · 2026-11-12