Back to Intelligence

3BB Intrusion: Attacker Abused MeshCentral RMM for Root Access and Subscriber Credential Theft — Detection and Response Guide

SA
Security Arsenal Team
September 15, 2026
13 min read

The Short Version: Why This Matters to You

Threat intelligence firm Hunt.io has disclosed that an attacker maintained persistent, interactive control inside the network of 3BB — one of Thailand's largest broadband providers — using MeshCentral, a legitimate, open-source remote monitoring and management (RMM) platform. The attacker wasn't burning a zero-day. They were living off a tool that most EDR products treat as benign, operating with root-equivalent access, and positioning to harvest subscriber credentials. Hunt.io uncovered the intrusion by examining an internet-exposed attacker server containing the operator's tooling and a target list.

If you run a SOC, manage an enterprise network, or provide managed services, this is the pattern you should internalize: RMM abuse is the modern persistence mechanism of choice. No exploit to patch, no malware signature to catch — just a signed, legitimate remote access binary doing exactly what it was designed to do, for the wrong operator. Any organization not explicitly inventorying and allow-listing RMM tooling is exposed to this exact tradecraft today.

Technical Analysis

What Happened at 3BB

Based on Hunt.io's findings:

  • An attacker established and maintained remote control of internal machines within 3BB's infrastructure using MeshCentral, a web-based remote management platform that provides full desktop control, file transfer, terminal access, and remote command execution.
  • The attacker obtained root access on internal systems — indicating either compromised administrative credentials, privilege escalation after initial foothold, or direct access to management interfaces that should never have been reachable.
  • The operator's infrastructure was left exposed on the internet, allowing Hunt.io analysts to enumerate the attacker's own tooling and a list of targets — a classic operational security failure by the threat actor, and a reminder that attacker infrastructure is itself an intelligence goldmine.
  • The apparent objective was subscriber credential theft — consistent with targeting an ISP, where harvested credentials enable account takeover, resale on criminal markets, phishing infrastructure, and downstream compromise of customers.

Why MeshCentral (and RMM Abuse Generally) Is So Dangerous

MeshCentral is architecturally identical to commercial RMM platforms (ConnectWise ScreenConnect, AnyDesk, TeamViewer, Splashtop, Atera, TacticalRMM — all of which have been abused in confirmed campaigns). From a defender's perspective, the threat model has several compounding properties:

  1. Signed, legitimate binaries. meshagent.exe (Windows) and the meshagent binary (Linux) are not malware. Hash-based blocklists and signature AV are useless.
  2. Outbound-only C2. The MeshCentral agent initiates connections to its management server (default TCP/443), bypassing most inbound firewall rules and blending with normal HTTPS egress.
  3. Full capability set out of the box. Interactive desktop, remote shell (root/SYSTEM context if installed as a service/root daemon), file transfer, and tunneling — everything an intruder needs, pre-built.
  4. Self-hosted infrastructure. An attacker can stand up their own MeshCentral server on commodity VPS infrastructure (as happened here — and the server was left internet-facing), meaning there is no vendor telemetry to subpoena and no shared IOC feed.
  5. Service persistence. The agent installs as a Windows service (Mesh Agent) or a Linux systemd/init service, surviving reboots and running in privileged context.

Attack Chain (Reconstructed)

  1. Initial access into 3BB's network (vector not publicly confirmed — common ISP entry points include exposed management interfaces, compromised credentials, or vulnerable edge services).
  2. Deployment of the MeshCentral agent on internal machines, installed with root/SYSTEM privileges.
  3. Persistent interactive access via the attacker's self-hosted MeshCentral server over outbound HTTPS.
  4. Credential access operations targeting subscriber data — likely involving database access, memory scraping, or file system enumeration on subscriber-management systems.
  5. OPSEC failure: attacker tooling server left internet-accessible, leading to discovery by Hunt.io.

Exploitation Status

No CVE is associated with this campaign — this is abuse of legitimate functionality, not a software vulnerability. There is nothing to patch in MeshCentral itself. The exploitation status is confirmed active, in-the-wild intrusion against a production telecommunications provider. Organizations should treat unauthorized RMM presence as a high-severity incident by default, not a policy violation.

Detection & Response

The detection strategy for RMM abuse rests on three pillars: (1) process/service execution of RMM agents that aren't on your approved inventory, (2) network egress to RMM management servers (especially non-corporate MeshCentral instances), and (3) persistence artifacts (services, systemd units) created by agent installation. The single most effective control is a definitive allow-list: if MeshCentral is not an approved tool in your environment, any execution is malicious. If it is approved, detection pivots to unauthorized server endpoints.

SIGMA Rules

YAML
---
title: MeshCentral Agent Execution or Installation
description: Detects execution of the MeshCentral remote management agent or its installer. MeshCentral is a legitimate open-source RMM tool confirmed abused in the 3BB ISP intrusion for persistent root-level access. Any execution in environments where MeshCentral is not an approved tool should be treated as high-fidelity malicious.
references:
  - https://thehackernews.com/2026/09/3bb-attacker-used-meshcentral-backdoor.html
  - https://attack.mitre.org/techniques/T1219/
author: Security Arsenal
date: 2026/09/15
status: experimental
id: 3f7a2c91-5e4d-4b8a-9c1f-6d8e2a4b7c10
tags:
  - attack.command_and_control
  - attack.t1219
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\meshagent.exe'
      - '\MeshAgent.exe'
      - '\MeshCentral.exe'
  selection_cli:
    CommandLine|contains:
      - 'meshagent'
      - 'meshcentral'
      - 'MeshCentralServer'
  condition: 1 of selection_*
falsepositives:
  - Environments where MeshCentral is an approved, inventoried RMM platform — in those environments, tune to fire only on agents connecting to non-corporate server FQDNs
level: high
---
title: MeshCentral Agent Windows Service Persistence
description: Detects creation of the MeshCentral agent Windows service, which provides SYSTEM-level persistence and is the standard installation path for both legitimate deployments and intruder-abused agents as observed in the 3BB breach.
references:
  - https://thehackernews.com/2026/09/3bb-attacker-used-meshcentral-backdoor.html
  - https://attack.mitre.org/techniques/T1219/
  - https://attack.mitre.org/techniques/T1543_003/
author: Security Arsenal
date: 2026/09/15
status: experimental
id: 8b1e4d62-7a3c-4f5e-b2d9-1c6a8e3f5d21
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1543.003
  - attack.t1219
logsource:
  category: service_installation
  product: windows
detection:
  selection:
    ServiceName|contains:
      - 'Mesh Agent'
      - 'meshagent'
    ImagePath|contains:
      - 'meshagent'
      - 'meshcentral'
  condition: selection
falsepositives:
  - Approved MeshCentral deployments — maintain a strict approved-server inventory and alert on any installation outside the sanctioned rollout
level: high
---
title: MeshCentral Agent Network Connection to Non-Corporate Server
description: Detects outbound connections from the MeshCentral agent. In environments where MeshCentral is sanctioned, connections to any destination other than the corporate MeshCentral server indicate a rogue agent deployment, matching the tradecraft used against 3BB where the attacker operated a self-hosted internet-facing server.
references:
  - https://thehackernews.com/2026/09/3bb-attacker-used-meshcentral-backdoor.html
  - https://attack.mitre.org/techniques/T1219/
author: Security Arsenal
date: 2026/09/15
status: experimental
id: c5d2f7a4-9b6e-4c1d-a8f3-2e7b9d4c6a58
tags:
  - attack.command_and_control
  - attack.t1219
  - attack.t1071.001
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    Image|endswith:
      - '\meshagent.exe'
      - '\MeshAgent.exe'
  filter_approved:
    DestinationHostname|contains:
      - 'meshcentral.yourdomain.com'
      - 'rmm.yourdomain.com'
  condition: selection and not filter_approved
falsepositives:
  - None expected if the approved-server filter is accurate — any MeshCentral agent beaconing to an unknown server is unauthorized by definition
level: critical

Tuning note: Replace the placeholder FQDNs in the third rule with your actual approved RMM server hostnames. If your organization does not use MeshCentral at all, delete the filter — every connection is critical-severity.

KQL Hunt (Microsoft Sentinel / Defender)

This query hunts across process execution, service installation, and network telemetry for MeshCentral artifacts. It covers both the agent binary and the characteristic service names, and is designed for environments where MeshCentral is not an approved tool (adjust the exclusion list otherwise):

KQL — Microsoft Sentinel / Defender
let ApprovedRmmServers = dynamic(["meshcentral.yourdomain.com", "rmm.yourdomain.com"]);
let MeshProcesses = dynamic(["meshagent.exe", "MeshAgent.exe", "MeshCentral.exe", "MeshCentralServer.exe"]);
union isfuzzy=true
(DeviceProcessEvents
| where FileName has_any (MeshProcesses)
   or ProcessCommandLine has_any ("meshagent", "meshcentral")
| extend SignalType = "ProcessExecution"
| project TimeGenerated, SignalType, DeviceName, AccountName, FileName, ProcessCommandLine, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine),
(DeviceNetworkEvents
| where InitiatingProcessFileName has_any (MeshProcesses)
| extend SignalType = "NetworkEgress"
| where not(RemoteUrl has_any (ApprovedRmmServers))
| project TimeGenerated, SignalType, DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort, RemoteUrl),
(SecurityEvent
| where EventID == 7045
| where ServiceName has_any ("Mesh Agent", "meshagent") or ServiceFileName has_any ("meshagent", "meshcentral")
| extend SignalType = "ServiceInstall"
| project TimeGenerated, SignalType, Computer, ServiceName, ServiceFileName, ServiceAccount, ServiceStartType)
| order by TimeGenerated desc

For Linux estates forwarding Syslog/CEF into Sentinel, also hunt for the agent's systemd footprint and outbound TLS connections:

KQL — Microsoft Sentinel / Defender
Syslog
| where Facility =~ "daemon" or SourceIP has_any ("your_meshcentral_server_ip_placeholder")
| where SyslogMessage has_any ("meshagent", "meshcentral")
   or ProcessName has_any ("meshagent", "meshcentral")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, SeverityLevel
| order by TimeGenerated desc

Velociraptor VQL Hunt

This artifact sweeps endpoints for the three observable pillars of a MeshCentral deployment: running processes, on-disk binaries (including renamed copies in common staging paths), and active network connections from agent processes:

VQL — Velociraptor
-- Hunt for rogue MeshCentral RMM agent artifacts (process, disk, network)
-- Context: 3BB intrusion — attacker used MeshCentral for persistent root access

SELECT * FROM {
  -- 1. Running processes matching MeshCentral agent indicators
  SELECT "process" AS ArtifactType,
         Pid, Name, Exe AS Path, CommandLine AS Detail,
         Username AS Account
  FROM pslist()
  WHERE Name =~ '(?i)mesh(agent|central)'
     OR CommandLine =~ '(?i)mesh(agent|central)'
     OR Exe =~ '(?i)mesh(agent|central)'
} UNION {
  -- 2. On-disk binaries in common installation / staging locations
  SELECT "file" AS ArtifactType,
         NULL AS Pid, NULL AS Name,
         FullPath AS Path,
         format("size=%v mtime=%v", Size, Mtime) AS Detail,
         NULL AS Account
  FROM glob(globs=[
    'C:/Program Files/Mesh Agent/**',
    'C:/Program Files (x86)/Mesh Agent/**',
    'C:/ProgramData/**/meshagent*.exe',
    'C:/Users/Public/**/meshagent*.exe',
    'C:/Windows/Temp/**/meshagent*.exe',
    '/usr/local/**/meshagent*',
    '/opt/**/meshagent*',
    '/tmp/**/meshagent*'
  ])
} UNION {
  -- 3. Active network connections from agent processes (default MeshCentral TCP/443 C2)
  SELECT "netstat" AS ArtifactType,
         Pid, Name,
         format("%v:%v -> %v:%v", Laddr.IP, Laddr.Port, Raddr.IP, Raddr.Port) AS Path,
         Status AS Detail, NULL AS Account
  FROM netstat()
  WHERE Name =~ '(?i)mesh(agent|central)'
     OR (Raddr.Port = 443 AND Status =~ 'ESTAB'
         AND Laddr.IP !~ '^(127\.|10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)')
}

Deploy this as a hunt across your fleet. Any hit in an environment without sanctioned MeshCentral is an incident trigger, not a tuning exercise.

Remediation / Verification Script (PowerShell)

Run this across Windows endpoints (via your EDR, GPO scheduled task, or RMM-of-record) to enumerate MeshCentral presence and optionally remove unauthorized agents. Validate against your approved inventory before enabling the removal block.

PowerShell
# Requires -RunAsAdministrator
# Rogue MeshCentral RMM detection and eradication — Security Arsenal IR toolkit
# Set $ApprovedMeshServers to your sanctioned MeshCentral FQDN(s); empty = none approved

$ApprovedMeshServers = @()  # e.g. @("meshcentral.yourdomain.com")
$Evidence = [System.Collections.Generic.List[object]]::new()

# --- 1. Enumerate MeshCentral services ---
$services = Get-CimInstance Win32_Service | Where-Object {
    $_.Name -match 'mesh(agent|central)' -or $_.PathName -match 'mesh(agent|central)'
}
foreach ($svc in $services) {
    $Evidence.Add([pscustomobject]@{
        Type = 'Service'; Name = $svc.Name; Path = $svc.PathName
        State = $svc.State; StartMode = $svc.StartMode
    })
}

# --- 2. Enumerate running processes ---
$procs = Get-Process | Where-Object { $_.Name -match 'mesh(agent|central)' }
foreach ($p in $procs) {
    $Evidence.Add([pscustomobject]@{
        Type = 'Process'; Name = $p.Name; Path = $p.Path
        State = 'Running'; StartMode = $null
    })
}

# --- 3. Check common on-disk locations ---
$paths = @(
    "$env:ProgramFiles\Mesh Agent",
    "${env:ProgramFiles(x86)}\Mesh Agent",
    "$env:ProgramData",
    "$env:PUBLIC",
    "$env:TEMP"
)
foreach ($base in $paths) {
    if (Test-Path $base) {
        Get-ChildItem -Path $base -Recurse -Filter 'mesh*agent*.exe' -ErrorAction SilentlyContinue |
            ForEach-Object {
                $Evidence.Add([pscustomobject]@{
                    Type = 'File'; Name = $_.Name; Path = $_.FullName
                    State = "Size=$($_.Length)"; StartMode = $_.LastWriteTime
                })
            }
    }
}

# --- 4. Report ---
if ($Evidence.Count -eq 0) {
    Write-Output "[+] $env:COMPUTERNAME : No MeshCentral artifacts found."
} else {
    Write-Output "[!] $env:COMPUTERNAME : $($Evidence.Count) MeshCentral artifact(s) detected:"
    $Evidence | Format-Table -AutoSize
    $Evidence | Export-Csv -NoTypeInformation -Path "$env:TEMP\mesh_hunt_$env:COMPUTERNAME.csv"

    # --- 5. OPTIONAL eradication — uncomment ONLY after IR scoping is complete ---
    # WARNING: Stop evidence collection first (memory capture, triage image) if this is an active incident.
    # foreach ($svc in $services) {
    #     Stop-Service -Name $svc.Name -Force -ErrorAction SilentlyContinue
    #     & sc.exe delete $svc.Name | Out-Null
    # }
    # foreach ($p in $procs) { Stop-Process -Id $p.Id -Force -ErrorAction SilentlyContinue }
    # foreach ($f in ($Evidence | Where-Object Type -eq 'File')) { Remove-Item $f.Path -Force -ErrorAction SilentlyContinue }
}

For Linux hosts, the equivalent verification sweep:

Bash / Shell
#!/usr/bin/env bash
# Rogue MeshCentral agent sweep — run as root, log centrally
echo "=== MeshCentral hunt: $(hostname) $(date -u) ==="

# Running processes and listening/established connections
ps aux | grep -i '[m]eshagent\|[m]eshcentral'
ss -tlnp | grep -i mesh
ss -tnp state established | grep -i mesh

# Systemd persistence
systemctl list-units --type=service | grep -i mesh
systemctl list-unit-files | grep -i mesh
find /etc/systemd /usr/lib/systemd /lib/systemd -iname '*mesh*' 2>/dev/null

# On-disk binaries in common install/staging paths
find /usr/local /opt /tmp /var/tmp /home -iname 'meshagent*' -o -iname 'meshcentral*' 2>/dev/null

# Cron-based persistence
grep -ri mesh /etc/cron* /var/spool/cron 2>/dev/null

Remediation

There is no patch for this threat — the fix is governance, inventory, and eradication. Execute in this order:

1. Immediate (24 hours)

  • Inventory every RMM tool in your environment. Pull installed-software lists (Windows: Get-CimInstance Win32_Product / registry uninstall keys; Linux: package managers + filesystem sweep) and network egress telemetry. Cross-reference against a written approved-tool list. Anything unapproved is treated as an active intrusion until proven otherwise.
  • Block unauthorized RMM at the egress layer. Deny outbound TCP/443 (and RMM-specific ports) to known RMM vendor domains and uncategorized VPS providers where feasible. At minimum, alert on egress to MeshCentral server endpoints not on your allow-list.
  • If MeshCentral artifacts are found unexpectedly: isolate the host, capture volatile evidence (memory, network connections, logged-on sessions) before removal, and initiate your IR process. Assume credential compromise — the 3BB operator's objective was subscriber credentials, and any host under an attacker's RMM control should have all credentials that touched it rotated.

2. Short-term (1–2 weeks)

  • Enforce application control. Deploy WDAC/AppLocker (Windows) and consider fapolicyd (Linux) rules that permit only allow-listed RMM binaries. Signed-binary abuse means you must control which signed tools can run, not just whether they run.
  • Audit privileged access paths. Root access at 3BB implies management interfaces, jump hosts, or credential stores were reachable by the attacker. Enforce MFA on all administrative interfaces, segment management networks, and verify that ISP-style infrastructure (RADIUS, subscriber databases, provisioning systems) is not reachable from general-purpose segments.
  • Deploy the detections above into your SIEM and validate them with a controlled MeshCentral test deployment in a lab segment.

3. Strategic (30–90 days)

  • Stand up a formal RMM governance policy: approved tool, approved server FQDNs, approved installer hashes, change-controlled deployment. This converts future rogue deployments from 'plausibly benign' to 'high-fidelity alert.'
  • Protect the credential stores attackers actually want. If you operate subscriber/customer credential databases, verify hashing algorithms (bcrypt/argon2/PBKDF2 — not unsalted MD5/SHA1), audit query access, and deploy DLP or database activity monitoring on those tables.
  • Threat-hunt quarterly for RMM artifacts as a standing hypothesis, using the VQL/KQL hunts above as scheduled jobs.
  • Monitor for your own exposure. Hunt.io found this intrusion by examining attacker infrastructure left open on the internet. Subscribe to threat-intelligence reporting on your sector and ensure your own external attack surface is continuously inventoried — if the attacker could leave a server exposed, so can you.

A Note for ISPs and Managed Service Providers

If you operate infrastructure similar to 3BB's, your risk is compounded: a single RMM foothold can cascade to thousands of downstream customers. Subscriber credential theft from a broadband provider feeds credential-stuffing campaigns against banking, email, and corporate SSO at national scale. Treat RMM governance and subscriber-database segmentation as tier-one controls, not hygiene items.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

sigma-rulekql-detectionthreat-huntingdetection-engineeringsiem-detectionmeshcentral3bb-breachrmm-abusecredential-theftisp-security

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.

Book a SOC AssessmentSee AlertMonitor in Action