Your MSP's Console Went Dark Overnight: What To Hunt Downstream Of The N-central Able2Shell Disclosure

On 9 November N-able took its hosted N-central platform offline and asked on-premises customers to shut their servers down, after a researcher published proof-of-concept code for 33 alleged zero-day flaws in the product. If your IT is run by a managed service provider, there is a fair chance N-central is the tool they use to patch, script and remote into your machines. N-able says it has seen no exploitation. That is good news, but it isn't evidence about your estate. This post covers what to check on your side of the RMM.

What happened

A set of exploit chains, which the researcher calls "Able2Shell", was published on GitHub with Python proof-of-concept scripts. According to Huntress, the 33 flaws form at least four chains: three lead to remote code execution on the N-central server and one to root. They were tested against N-central Appliance 2026.4.0.31 and "likely earlier versions as well". The Hacker News lists the bug classes: credential disclosure, arbitrary file writes, directory traversal, XSS, XXE injection and RCE. Among the chains are support-token theft and execution of unsigned packages.

N-able said it was "temporarily taking our Hosted N-central environment offline" as a precaution. It also told on-premises customers to take their servers offline until a hotfix ships, and gave no release date. As of 15:15 UTC on 9 November it had seen no active exploitation. Field Effect points out that the claims are unverified and no CVE identifiers have been assigned yet.

This product has been here before. In September, N-central CVE-2026-86218, a pre-authentication RCE rated CVSS 10.0, was exploited in the wild, and earlier in 2026 exploitation of N-central flaws led to unauthorised scripts and tools being pushed to managed machines. With public PoC code now available, it would be unwise to assume nobody used it before the servers went dark.

Why this matters if you are the customer, not the MSP

An RMM server is trusted by design. Its agent runs as SYSTEM on every managed endpoint and server, and it can deploy software, run scripts and open remote sessions. Its activity looks like normal IT administration because that is what it is for. If someone controls the server, they control every agent connected to it, across every client the MSP manages. Our RMM explainer covers why attackers like these tools.

Most mid-market organisations can't see inside their provider's N-central console. You can, however, see what arrived on your own machines. That is where the hunt below looks.

What to hunt

The queries below use Microsoft Defender XDR advanced hunting tables, which you can also run in Sentinel. They are starting points to tune. Agent install paths and process names vary by version and by which N-central components your provider deploys, so check a known-good machine first and adjust the path filters. Huntress suggests reviewing from 8 November. We'd go back at least to 1 October, given the September exploitation.

1. What the RMM agent launched

// Child processes of the N-central / N-able agent stack. Confirm paths on a known-good host first.
let RmmPaths = dynamic(["\\N-able Technologies\\", "\\Windows Agent\\", "\\BeAnywhere Support Express\\"]);
DeviceProcessEvents
| where Timestamp > ago(40d)
| where InitiatingProcessFolderPath has_any (RmmPaths)
| where FileName in~ ("powershell.exe","pwsh.exe","cmd.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","msiexec.exe","certutil.exe","bitsadmin.exe","curl.exe")
| summarize Runs = count(), Devices = dcount(DeviceId), FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
            Example = any(ProcessCommandLine) by InitiatingProcessFileName, FileName, CmdHash = hash_sha256(ProcessCommandLine)
| order by Devices desc, FirstSeen desc

Your provider runs the same maintenance scripts week after week, so a command line that appears for the first time, on many devices in a short window, deserves attention. Look in particular for encoded PowerShell, downloads from unfamiliar hosts, and new remote-access or tunnelling tools.

2. New software and services pushed through the agent

DeviceEvents
| where Timestamp > ago(40d)
| where ActionType == "ServiceInstalled"
| extend ServiceName = tostring(parse_json(AdditionalFields).ServiceName),
         ServicePath = tostring(parse_json(AdditionalFields).ServiceFileName)
| where InitiatingProcessFolderPath has_any ("\\N-able Technologies\\", "\\Windows Agent\\")
   or InitiatingProcessParentFileName in~ ("agent.exe")
| summarize Devices = dcount(DeviceId), FirstSeen = min(Timestamp) by ServiceName, ServicePath
| order by FirstSeen desc

A second remote-access tool appearing alongside the RMM is the pattern seen in earlier RMM compromises. Attackers add their own access so they don't lose it when the provider fixes the server.

3. New local admins and accounts on managed machines

DeviceEvents
| where Timestamp > ago(40d)
| where ActionType in ("UserAccountCreated", "UserAccountAddedToLocalGroup")
| extend Group = tostring(parse_json(AdditionalFields).GroupName)
| where ActionType == "UserAccountCreated" or Group in~ ("Administrators", "Remote Desktop Users")
| project Timestamp, DeviceName, ActionType, AccountName, Group,
          InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessAccountName
| order by Timestamp desc

Do the same in Active Directory if the agent runs on domain controllers. Event IDs 4720, 4728, 4732 and 4756 in SecurityEvent cover account creation and changes to privileged groups.

4. Remote sessions outside your provider's normal hours

DeviceNetworkEvents
| where Timestamp > ago(40d)
| where InitiatingProcessFolderPath has_any ("\\N-able Technologies\\", "\\BeAnywhere Support Express\\")
| where RemoteIPType == "Public"
| summarize Connections = count(), Devices = dcount(DeviceId) by RemoteIP, RemoteUrl, bin(Timestamp, 1h)
| extend HourUtc = hourofday(Timestamp)
| where HourUtc < 6 or HourUtc > 20
| order by Timestamp desc

Agent check-ins happen around the clock, so expect noise. What you're looking for is a new destination, or a spike in remote-control traffic at times when your provider's engineers aren't working.

What to do this week

1. Ask your provider four questions. Do you use N-central, and is it hosted or on-premises? Was our server offline from 9 November? Have you reviewed logins, admin accounts and script runs on it since 8 November? When the hotfix lands, how will you confirm the server is clean before reconnecting it?
2. Know what is running in the gap. With the RMM offline, patching and scripted maintenance have stopped. Microsoft's November security updates are released today. Agree how critical updates will be applied in the meantime.
3. Watch for the reconnect. When the server returns, the agents will catch up on queued jobs. Run query 1 again for the first 48 hours after restoration.
4. Rotate what the RMM could see. Field Effect recommends rotating N-central admin, service and integration credentials if misuse is found. Also list the domain admin, hypervisor and backup credentials stored in the RMM's credential vault. These are often forgotten.
5. Treat RMM agents as Tier 0. Anything that runs code as SYSTEM on your domain controllers is as privileged as a domain admin, and its supply chain needs the same level of attention. Our post on what access your provider holds in your tenant covers the Microsoft 365 side of the same question.

How a managed SOC helps

The hard part of an RMM incident is telling your provider's normal work from someone else's activity on the same channel. That takes endpoint telemetry from every managed device, a baseline of what the provider usually does, and analysts who will check a new script on a Sunday night instead of assuming it is routine. Wizard Cyber has run Microsoft Sentinel since 2019. Our SOCs are staffed 24/7, and on the managed service senior analyst sign-off is the default. If you want an independent view of whether anything came through your RMM channel before the shutdown, a compromise assessment answers that question.

Want a second pair of eyes on what your RMM has been doing? Talk to our team.