N-able confirmed this week that threat actors are actively exploiting a new set of vulnerabilities in its N-central remote monitoring and management (RMM) platform — flaws the research community is tracking as 4EverAble2Shell and Agent2Shell. The confirmed impact so far: 21 compromised N-central servers, and 19 of them were already running Hotfix 2. Read that again. Organizations that believed they had applied the relevant interim mitigation were still breached.
N-able's response has been to restrict certain N-central features and integrations while remediation is completed — a significant move that tells you two things: first, the attack surface involved is broad enough that a surgical patch wasn't immediately viable, and second, the vendor considers the exploitation risk serious enough to degrade product functionality for its entire customer base.
If you are an MSP, an MSSP, or an enterprise running N-central — particularly an on-premises instance — this is not a "patch next maintenance window" situation. N-central is a tier-zero management plane: it holds credentials, pushes scripts and software to every managed endpoint, and is trusted by every agent in your fleet. A compromise of the N-central server is functionally a compromise of every customer and endpoint it touches. That is precisely why RMM platforms have become a preferred initial access and lateral movement vector for both financially motivated actors and ransomware affiliates.
This post breaks down what we know, how to hunt for compromise in your environment today, and the concrete steps you need to take.
Technical Analysis
What Is Affected
- Product: N-able N-central (RMM platform), with on-premises/hosted deployments at greatest risk
- Flaw set: Publicly disclosed vulnerabilities tracked as 4EverAble2Shell and Agent2Shell
- Confirmed impact: 21 servers infected in the wild; 19 of those were running Hotfix 2, indicating the hotfix did not fully close the exploitation path or that compromise predated its application and persisted
- Vendor response: N-able is actively restricting certain N-central features and integrations as an interim protective measure while full remediation is developed and deployed
The naming convention — 2Shell — is telling. Both flaw chains reportedly terminate in command execution on the N-central server: one via a persistent/durable path ("4EverAble"), and one via the agent component ("Agent2Shell"). An agent-side code execution path is the nightmare scenario for an RMM platform, because it converts a server compromise into fleet-wide downstream compromise of managed endpoints.
Why RMM Exploitation Is a Force Multiplier
From an attacker's perspective, N-central is the perfect target:
- Implicit trust. Endpoints execute whatever the RMM tells them to run. Deploying ransomware or a loader through a compromised RMM bypasses most endpoint controls because the activity is signed, expected, and administratively normal.
- Credential density. RMM servers store or broker credentials, API keys, and integration tokens for PSA tools, backup platforms, and cloud tenants.
- MSP blast radius. One compromised N-central server can mean dozens of downstream customer environments — the classic supply-chain amplification pattern we've seen repeatedly with RMM and MSP tooling intrusions.
- Egress is expected. N-central servers legitimately talk to the internet and to thousands of endpoints. C2 traffic hides in plain sight.
Exploitation Status
- Active in-the-wild exploitation: CONFIRMED — 21 servers already infected
- Patch/hotfix evasion or pre-hotfix persistence: CONFIRMED — 19 of 21 victims were running Hotfix 2
- Vendor feature restrictions in effect — expect degraded functionality in some integrations while N-able completes remediation
Treat every N-central server as potentially compromised until you have validated otherwise. If your server was internet-reachable at any point during the disclosure window, assume it was enumerated.
Detection & Response
The highest-fidelity detection opportunities for this class of attack are: (1) the N-central web application or service processes spawning shells or script interpreters, (2) unexpected files — particularly web-accessible scripts — dropped under N-central installation and web directories, and (3) anomalous outbound connections from the N-central server to infrastructure that isn't N-able's.
SIGMA Rules
---
title: N-central Server Process Spawning Shell or Script Interpreter
id: 4a2b8c1d-7e5f-4c3a-9d2e-8f1a6b3c5d7e
status: experimental
description: Detects N-central application or web server processes spawning command shells or script interpreters, consistent with post-exploitation activity following RCE flaws such as 4EverAble2Shell and Agent2Shell.
references:
- https://thehackernews.com/2026/11/hackers-exploit-n-central-flaws-to.html
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/11/06
tags:
- attack.execution
- attack.t1059
- attack.t1190
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|contains:
- '\\N-able\\'
- '\\N-central\\'
- '\\ncentral\\'
- '\\jboss\\'
- '\\tomcat\\'
- '\\apache\\'
- 'java.exe'
- 'javaw.exe'
- 'httpd.exe'
selection_child:
Image|endswith:
- '\\cmd.exe'
- '\\powershell.exe'
- '\\pwsh.exe'
- '\\wscript.exe'
- '\\cscript.exe'
- '\\mshta.exe'
- '\\rundll32.exe'
- '\\certutil.exe'
- '\\bitsadmin.exe'
- '\\wmic.exe'
condition: selection_parent and selection_child
falsepositives:
- Legitimate N-central automation and script deployment jobs - correlate with scheduled tasks in the N-central console and change windows
level: high
---
title: Webshell or Script Dropped in N-central Web Directory
id: 6c3d9e2f-8a4b-4d5c-b1e3-9f2a7c4d6e8f
status: experimental
description: Detects creation of script or executable files in N-central web-accessible directories, a common persistence and webshell staging behavior following exploitation of RMM web interfaces.
references:
- https://thehackernews.com/2026/11/hackers-exploit-n-central-flaws-to.html
- https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/11/06
tags:
- attack.persistence
- attack.t1505.003
logsource:
category: file_event
product: windows
detection:
selection_path:
TargetFilename|contains:
- '\\N-central\\'
- '\\ncentral\\'
- '\\webapps\\'
- '\\wwwroot\\'
- '\\htdocs\\'
selection_ext:
TargetFilename|endswith:
- '.jsp'
- '.jspx'
- '.asp'
- '.aspx'
- '.php'
- '.war'
- '.exe'
- '.dll'
- '.ps1'
- '.bat'
condition: selection_path and selection_ext
falsepositives:
- Legitimate N-central updates and hotfix deployments - validate against vendor release windows and file signatures
level: high
---
title: Suspicious Outbound Connection from N-central Server Process
id: 8e5f1a3c-2b6d-4e7f-a3c5-1d9b4e6f8a2c
status: experimental
description: Detects uncommon outbound network connections initiated by shell or scripting processes on an N-central server, potentially indicating C2 or data staging after RCE exploitation.
references:
- https://thehackernews.com/2026/11/hackers-exploit-n-central-flaws-to.html
- https://attack.mitre.org/techniques/T1071/001/
author: Security Arsenal
date: 2026/11/06
tags:
- attack.command_and_control
- attack.t1071.001
logsource:
category: network_connection
product: windows
detection:
selection:
Image|endswith:
- '\\cmd.exe'
- '\\powershell.exe'
- '\\pwsh.exe'
- '\\mshta.exe'
- '\\rundll32.exe'
- '\\certutil.exe'
- '\\curl.exe'
- '\\wget.exe'
DestinationPort:
- 80
- 443
- 8080
- 8443
filter_local:
DestinationIp|startswith:
- '10.'
- '172.16.'
- '192.168.'
condition: selection and not filter_local
falsepositives:
- Administrative tooling and vendor support sessions - baseline and allowlist known management activity
level: medium
Analyst note on tuning: The first rule keys off parent/child process lineage, which is the single most reliable signal for web-application RCE. Tune the parent image list to match your actual N-central installation paths (confirm whether your deployment uses JBoss, Tomcat, or Apache components) before deploying broadly.
KQL — Microsoft Sentinel / Defender
This query hunts for shell and scripting child processes spawned by N-central server components, joined with recent file drops in web directories — the two strongest post-exploitation signals for this campaign.
// Hunt: N-central server processes spawning shells or script interpreters
// Deploy against Defender MDE data; adjust path filters for your installation
let suspiciousChildren = dynamic(["cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","certutil.exe","bitsadmin.exe","wmic.exe","curl.exe"]);
let ncentralParents = dynamic(["java.exe","javaw.exe","httpd.exe","tomcat.exe","jboss.exe","w3wp.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where FileName in~ (suspiciousChildren)
| where InitiatingProcessFileName in~ (ncentralParents)
or InitiatingProcessFolderPath has_any ("N-central", "ncentral", "N-able")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine,
AccountName, SHA256
| join kind=leftouter (
DeviceFileEvents
| where TimeGenerated > ago(14d)
| where FolderPath has_any ("webapps", "wwwroot", "N-central", "ncentral")
| where FileName endswith_cs ".jsp" or FileName endswith_cs ".aspx"
or FileName endswith_cs ".php" or FileName endswith_cs ".ps1"
| project FileTime=TimeGenerated, DeviceName, DroppedFile=FileName,
DropPath=FolderPath, DroppedBy=InitiatingProcessFileName
) on DeviceName
| order by TimeGenerated desc
If you ingest N-central server syslog or firewall logs into Sentinel, layer this with an egress check:
// Hunt: Rare outbound destinations from N-central servers
// Assumes firewall/NSG flow logs ingested via CommonSecurityLog
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where SourceHostName has "ncentral" or Computer has "ncentral"
| where DeviceAction == "Allowed" or isempty(DeviceAction)
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by DestinationIP, DestinationPort, ApplicationProtocol
| where ConnectionCount < 50 // surface rare/new egress, not steady-state vendor traffic
| order by FirstSeen asc
Velociraptor VQL
Use this artifact to triage a suspected N-central server: enumerate shell/script processes with web-service lineage and inventory recently created scripts in web-accessible paths.
-- N-central compromise triage: shell lineage + web directory file drops
LET processes = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(cmd|powershell|pwsh|mshta|rundll32|certutil|wscript|cscript)'
LET webdrops = SELECT FullPath AS FilePath, Mtime, Size
FROM glob(globs=[
'C:\\**\\N-central\\**\\*.jsp',
'C:\\**\\ncentral\\**\\*.jsp',
'C:\\**\\webapps\\**\\*.jsp',
'C:\\**\\webapps\\**\\*.war',
'C:\\**\\wwwroot\\**\\*.aspx'
])
WHERE Mtime > now() - 1209600 -- last 14 days
SELECT * FROM processes
UNION ALL
SELECT NULL AS Pid, NULL AS Ppid, 'FILE_DROP' AS Name,
FilePath AS CommandLine, NULL AS Exe, NULL AS Username,
Mtime AS CreateTime
FROM webdrops
Follow up on any hits by collecting the file (for webshells, pull the full content — they are usually small) and reviewing N-central's application logs for the request that wrote it.
Verification and Hardening Script
Run this on each on-premises N-central server to confirm hotfix/update state, inventory potential webshell artifacts, and check for unexpected local accounts and scheduled persistence.
# N-central post-exploitation verification script - run elevated on the N-central server
$report = @()
# 1. Identify N-central installation paths
$installPaths = @("C:\Program Files (x86)\N-able", "C:\Program Files\N-able", "C:\N-central") |
Where-Object { Test-Path $_ }
# 2. Hunt for script/webshell files modified in the last 14 days under install and web roots
$webRoots = $installPaths + @("C:\inetpub\wwwroot") | Where-Object { Test-Path $_ }
foreach ($root in $webRoots) {
$report += Get-ChildItem -Path $root -Recurse -ErrorAction SilentlyContinue |
Where-Object { $_.Extension -in '.jsp','.jspx','.war','.aspx','.asp','.php','.ps1','.bat','.exe' `
-and $_.LastWriteTime -gt (Get-Date).AddDays(-14) } |
Select-Object FullName, LastWriteTime, Length
}
# 3. Flag shell processes parented by java/web service processes (live state snapshot)
$report += Get-CimInstance Win32_Process |
Where-Object { $_.Name -match 'cmd|powershell|mshta|rundll32|certutil' } |
ForEach-Object {
$parent = Get-CimInstance Win32_Process -Filter "ProcessId=$($_.ParentProcessId)" -ErrorAction SilentlyContinue
if ($parent -and $parent.Name -match 'java|httpd|tomcat|jboss|w3wp') {
[PSCustomObject]@{ FullName = "$($parent.Name) -> $($_.Name)"; LastWriteTime = $_.CreationDate; Length = $_.CommandLine }
}
}
# 4. Review recently created local accounts and scheduled tasks (persistence check)
Get-LocalUser | Where-Object { $_.PasswordLastSet -gt (Get-Date).AddDays(-30) } |
Select-Object Name, Enabled, PasswordLastSet
Get-ScheduledTask | Where-Object { $_.Date -gt (Get-Date).AddDays(-30) } |
Select-Object TaskName, TaskPath, Date
# 5. Export findings
$report | Format-List
$report | Export-Csv -Path "C:\ncentral_triage_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
Write-Host "[+] Triage complete. Review output, then confirm installed version/hotfix against N-able's current advisory before returning the server to service."
Remediation
Given that 19 of the 21 compromised servers were already running Hotfix 2, do not treat hotfix application as proof of safety. Follow this sequence:
- Apply N-able's current remediation immediately. Pull the latest guidance directly from the N-able security advisory and N-central release notes — do not rely on Hotfix 2 as your terminal state. Verify the exact installed build against the build N-able currently lists as remediated. If N-able's feature restrictions are available to enforce on your instance, enable them rather than waiting for them to be pushed.
- Hunt before you patch — and after. Run the detections above against at least 30 days of retained telemetry. If exploitation occurred before patching, the patch does not evict the attacker. Webshells, added local accounts, new scheduled tasks, and rogue agent configurations all survive patching.
- Restrict network exposure of the N-central console. The management UI should never be broadly internet-exposed. Place it behind a VPN, ZTNA gateway, or IP allowlist. Restrict agent-to-server and server-to-internet egress to required N-able endpoints only.
- Rotate credentials on any server you cannot conclusively clear. This includes N-central admin accounts, integrated PSA/API credentials, domain or service accounts used by the platform, and any downstream customer credentials brokered through the tool. Assume credential theft on any compromised RMM.
- Review recent N-central-driven actions. Audit scripts pushed, software deployed, and agent policy changes over the exposure window across all managed endpoints — the agent-side path ("Agent2Shell") means downstream endpoints are in scope, not just the server.
- If you find evidence of compromise, treat it as an IR engagement, not a patching ticket. Preserve the server image and logs before rebuilding. Given the MSP blast radius, assess downstream customer notification obligations early — contractual and, depending on data involved, regulatory.
- Monitor N-able's communications daily until the vendor declares remediation complete. The feature-restriction posture tells you the situation is still evolving; expect updated builds and revised guidance.
The Bigger Lesson
This incident is the latest proof point in a pattern every defender should have internalized by now: RMM platforms are critical infrastructure and must be threat-modeled as such. They are internet-facing, they hold the keys to every endpoint, and attackers know that MSPs often cannot take them offline quickly. Inventory your RMM exposure, monitor it like you monitor your domain controllers, and have a pre-built IR runbook for "our management plane is compromised" — because the 19 organizations running Hotfix 2 almost certainly thought they had already handled this.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.