How to Audit an RMM Console After a Vendor Zero-Day

When a remote monitoring and management vendor ships an emergency fix for a flaw that was exploited before the patchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program. existed, applying the hotfixHotfix🛡️An out-of-cycle software update that addresses a specific urgent defect, usually a security flaw, on an existing release line without waiting for the next scheduled version. Hotfixes are typically numbered and cumulative on that line, but each covers only the issues named in its notes, so a later one may be required. is the easy part. The harder question is whether someone was already inside, and if so, what they left behind. This guide walks through that audit for an RMM console, using the September 2026 N-able N-central zero-dayZero-Day🛡️A security vulnerability that is exploited or publicly disclosed before the software vendor can release a patch, giving developers 'zero days' to fix it. CVE-2026-86218 as the working example. The steps generalise to any platform in the category.

The premise is important: Huntress's patient zero in this incident was a fully patched N-central server at the time it was compromised. Patching after the fact does not tell you whether the window was already used.

Step 1: Establish the exposure window

Before looking at logs, decide what period you are auditing. Bound it by:

• The earliest date exploitation is known to have started. For N-central, Huntress observed activity in early August against the earlier authentication bypasses (CVE-2026-18556 and CVE-2026-18577) and a new intrusion on 4 September against a server that had every fix then available.
• The date your server actually reached the fixed build (2026.3.1.14 for Hotfix 4). Verify the build number in the console. Do not rely on a patch job that reported success.
• Whether the console was reachable from the internet during that window. If it was behind a VPN or allowlist the whole time, the audit is still worth doing but the prior is much lower.

If you cannot answer the middle question because logs have rotated, note that now. Huntress could not identify which CVE was used in its case for exactly this reason. Extend retention before the next advisory, not after.

Step 2: Audit user accounts and roles

The first thing the N-central intruders did after gaining access was create their own administrative accounts. Export the full user list and check:

• Accounts created inside the exposure window. Every one needs an owner who can vouch for it.
• Email domains that do not belong to your organisation. Huntress found accounts with addresses ending in `.invalid`, an obvious tell that only shows up if someone looks.
• Role changes, especially anyone promoted to an administrative role, and changes to security settings such as MFA enforcement or session timeouts.
• Vendor or support accounts. Some malicious sessions in the N-central case were associated with the vendor's `mspsupport` support account name. A session under that name from an unfamiliar address is not automatically benign.
• Service accounts and API keys. An attacker who wants to survive account cleanup will mint an API credential that nobody reviews.

Disable rather than delete suspicious accounts until the investigation is done; you may need the audit trail attached to them.

Step 3: Review remote-control sessions

RMM platforms log interactive sessions because technicians bill for them. That log is now your best evidence. In N-central the feature is called Take Control; Huntress points to the UI and remote-access logs, the `envoy_proxy_HTTPS.log` file and the `ncentraldms` syslog stream on the server side.

Look for:

• Sessions into domain controllers, file servers, backup servers or hypervisorHypervisor🌐Software that creates and manages virtual machines by allocating physical hardware resources among multiple guest operating systems. VMware ESXi is a Type 1 (bare-metal) hypervisor. hosts. These were the intruders' priority targets, and they are rarely the target of a routine support session.
• Sessions at hours when your team was not working, or from source addresses you do not recognise. Consumer VPN exit nodes (NordVPN, Mullvad and Tzulo appear in the Huntress indicator list) are a strong signal in an MSP context, where technicians normally connect from known offices.
• Sessions that do not correspond to a ticket. Cross-reference against your PSA or ticketing system for the window.

On the endpoint side, the remote-control agent writes its own logs. For N-central, Huntress cites Windows Application event IDs 4102, 8192 and 8193 and the `GetSupportService_N-Central` log directory under `ProgramData`. Endpoint logs survive a console wipe, so they are useful even if the server's history is gone.

Step 4: Review what was pushed to endpoints

The console's job is to run things on endpoints, and that is what the attacker used it for. Pull the history of script executions, software deployments, scheduled tasks and automation policies for the window. Anything you did not author is evidence. Pay particular attention to:

• New scripts or edited existing scripts, especially ones that download from an external URL.
• Deployment jobs targeting many endpoints at once, or targeting only high-value machines.
• New scheduled tasks or automation policies that would re-run on a timer. This is how an attacker keeps a foothold after their accounts are removed.

Where the platform supports it, export the actual script contents rather than just the job names.

Step 5: Hunt for persistence on endpoints

In both N-central waves the intruders installed Cloudflare tunnels, which give an operator a persistent inbound path to an endpoint that does not depend on the RMM console at all. That means cleaning the console is not enough.

Across the managed fleet, search for:

• Tunnel binaries and services (the Cloudflare tunnelCloudflare Tunnel🛡️A Cloudflare service in which a lightweight client on a host opens an outbound connection to Cloudflare's edge so the host can be reached from the internet without inbound firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. rules. Legitimate for publishing internal services, it is also abused by intruders as a persistent backdoor that survives console cleanup, as seen in the N-central intrusions. client is commonly deployed as a service), and any other unexpected remote-access tool.
• Outbound connections to the tunnel and dynamic-DNS domains in the vendor and researcher indicator lists. Huntress published Synology dynamic-DNS hostnames and a specific tunnel account identifier.
• New local administrator accounts on endpoints, particularly on the domain controllers and file servers that were session targets.

This is the step where your EDR and DNS logs do the work the RMM console cannot.

Step 6: Decide whether to rebuild

If you find any of the above, the console is compromised and the safest path is a rebuild from a known-good image with credentials rotated, followed by treating each client network the intruders reached as a separate incident. The Post-Compromise Checklist for Self-Hosted Services covers that process.

If you find nothing but your logs did not cover the whole window, you have an absence of evidence, not evidence of absence. Say so explicitly in your incident notes, extend retention, and keep the hunting queries running for the next several weeks.

Step 7: Close the exposure

Finally, fix the condition that made the audit necessary. Put the console behind a VPN or an IP allowlist, enforce MFA on every account, and set up an alert for new administrative accounts and for remote sessions into tier-zero hosts. Why RMM Platforms Are the Highest-Value Target on an MSP Network explains why these controls matterMatter🏠A new universal smart home standard backed by Apple, Google, and Amazon for cross-platform compatibility. more here than on any other server you run.

Then expect to do this again. N-able needed four hotfixes in five weeks; the odds that this was the last are not good. Why One Hotfix Is Rarely Enough: Planning for Incomplete Patches explains how to plan for that.