DΛΣMӨП

// HackTricks · Network Services

MeshCentral

MeshCentral

Overview

MeshCentral is a self-hosted remote monitoring / device management platform that mixes an admin web UI with agent-facing WebSocket endpoints. During a pentest, treat it as both a web target and an RMM control plane: a single browser-side bug in the dashboard can become fleet-wide command execution because the product already exposes legitimate remote execution features.

Relevant endpoints from the public exploit chain:[1]

  • Admin UI: https://<target>/
  • Agent channel: wss://<target>/agent.ashx
  • Admin control channel: wss://<target>/control.ashx

If you identify MeshCentral, review the generic XSS and WebSocket Attacks pages, then test how agent-controlled metadata reaches the UI and how the UI talks to privileged WebSocket APIs.

High-value attack surface

1. Agent-submitted metadata rendered in the admin UI

Do not limit testing to normal dashboard users. MeshCentral agents submit host metadata that is later rendered to administrators, so fields such as device name, OS description, volume labels, sensor names, or similar agent-fed attributes should be treated as stored XSS candidates.[2]

In the published 2026 chain, a rogue/compromised agent injected HTML/JS into osdesc inside the coreinfo message. When an admin opened the device details panel, the payload executed in the admin origin.[1][2]

Agent impersonation from a low-privileged host

If you compromise a managed endpoint, check whether local users can read MeshCentral enrollment material. In the public advisory chain, low-privileged Windows users could read MeshAgent.msh and MeshAgent.db, which exposed enough data to impersonate the enrolled node:[3]

  • Server URL / WebSocket endpoint
  • MeshID / ServerID / NodeID
  • Agent certificate and private key material

Typical extraction flow:[3]

uv run extract_agent_identity.py /path/to/MeshCentral/ -o client.json
uv run rogue_agent.py -s mesh.lab.local --identity client.json

This is a useful pattern beyond MeshCentral: whenever an RMM/MDM agent stores tenant identifiers, node identity, or client certificates/keys in locally readable files, a local foothold may be enough to re-register or impersonate the device remotely.

MeshCentral agent authentication flow

When emulating a MeshAgent, the public PoC used the following handshake against /agent.ashx:[3]

  1. Connect and recover the TLS certificate hash.
  2. Send Cmd 1 with a nonce and cert hash.
  3. Send Cmd 4 to trust the server / skip its signature validation.
  4. Receive server Cmd 1 nonce.
  5. Send Cmd 2 with the agent certificate and RSA-SHA384 signature.
  6. Send Cmd 3 with agent info / metadata.
  7. Wait for Cmd 4 to confirm authentication.

Once authenticated, an attacker-controlled agent can update metadata fields that later reach the UI.

Stored XSS -> privileged WebSocket API abuse

The important escalation is not the alert box. The key trick is that same-origin JavaScript executing in the MeshCentral admin console can open the privileged WebSocket API with the victim admin session automatically attached by the browser.[1]

Minimal browser primitive:[1]

const ws = new WebSocket(location.origin.replace(/^http/, 'ws') + '/control.ashx')

From there, the published chain waited for serverinfo, enumerated nodes, and then used the built-in remote execution action:[1]

ws.send(JSON.stringify({action:'nodes',responseid:'poc'}))
ws.send(JSON.stringify({
  action:'runcommands',
  nodeids:[nodeId],
  type:0,
  cmds:'whoami > C:\\pwned.txt',
  runAsUser:0,
  responseid:'rce-'+nodeId
}))

Important fields:[1]

  • action:'nodes': enumerate devices visible to the admin session
  • action:'runcommands': dispatch remote commands through the management plane
  • type:0: cmd / shell
  • type:2: PowerShell
  • runAsUser:0: request execution as SYSTEM/root

This is the general RMM/MDM lesson: stored XSS in a management console is often equivalent to authenticated API abuse and remote code execution because the platform already exposes privileged operator actions.[1]

Pentest checklist

  • Fingerprint MeshCentral and inspect both /agent.ashx and /control.ashx traffic.
  • Test whether agent-controlled fields are reflected in device details, sharing dialogs, file-browser metadata, or permission dialogs.
  • On a compromised endpoint, check ACLs on MeshAgent.msh and MeshAgent.db.
  • If the browser UI uses WebSockets, capture the JSON actions and replay them after achieving XSS.
  • Check whether remote execution features allow SYSTEM/root execution (runAsUser:0).
  • Review command history/logs for suspicious runcommands, broad node enumeration, or the same command sent to many devices.

Mitigation / detection notes

  • Upgrade MeshCentral to 1.1.60 or later. Publicly documented affected versions are below 1.1.60.[2][4]
  • Defenders should review MeshCentral logs for:[1]
    • unexpected runcommands
    • suspicious runAsUser:0
    • one admin session enumerating many nodes immediately before command dispatch
    • demo artifacts such as whoami > C:\\pwned.txt

References