highPhishing

MeshAgent RMM Abuse: A VMware Disguise, a Bulgarian Bullet-Proof Host, and the "traffic-rc" Campaign Targeting Italian IT Staff

PublishedMarch 12, 2026

Threat Actors:ProfileAssessmentattribution)groups)origin)Timeline

phishingsocial-engineeringc2ransomwareexploitdgaaptspearphishing

TL;DR: A weaponized MeshCentral agent was found masquerading as a VMware vSphere Client installer (vmware-viclient-0dfc12e1.exe), delivered via Dropbox and connecting back to a fully operational MeshCentral command-and-control panel at 103.65.230.86 on EuroHoster infrastructure in Bulgaria. The campaign -- internally named "traffic-rc" -- gives the operator full remote desktop, shell access, file transfer, and Intel AMT hardware-level management over compromised machines. The binary is self-signed by a MeshCentral internal CA (MeshCentralRoot-7e2763), the C2 panel is live and internet-facing, and imphash clustering links this sample to at least 10 other MeshAgent abuse campaigns tracked since August 2025. This is not custom malware. It is a legitimate remote management tool, deployed without the target's knowledge, sitting in a blind spot that most endpoint detection products refuse to touch.

Why This Matters More Than Another RAT

Remote Management and Monitoring (RMM) tools occupy a unique position in the threat landscape. They are not malware. They are signed, documented, commercially supported software designed to do exactly what an attacker wants: provide persistent remote access to a system with full administrative capabilities. When a threat actor deploys a custom RAT, every AV engine on the planet is trying to catch it. When a threat actor deploys MeshAgent, Kaspersky shrugs and labels it not-a-virus:HEUR:RemoteAdmin.Win32.MeshAgent.gen. That classification -- "not a virus" -- is technically correct and operationally catastrophic.

MeshCentral is an open-source, full-featured remote management platform. It is used by thousands of legitimate IT shops for helpdesk support, device management, and remote administration. The MeshAgent binary that connects to it is not a trojan -- it is the official agent, compiled from public source code, configured to call back to an attacker-controlled server instead of a corporate IT department. The binary does not need to evade detection because it is not doing anything the operating system considers suspicious. It installs as a Windows service, connects over WebSocket TLS on port 443, and waits for commands. From the perspective of the endpoint, it looks identical to a legitimate IT management agent.

This investigation dissects one such campaign, maps the infrastructure behind it, and provides the detection opportunities that exist in the gaps between what the binary is and what it is being used for.

The Lure: VMware vSphere Client for People Who Don't Check Hashes

The delivery vector is a Dropbox-hosted payload with a filename carefully chosen to exploit trust:

hxxps://www[.]dropbox[.]com/scl/fi/n21z2a7fwawlrk56o9cb9/vmware-viclient-0dfc12e1.exe?rlkey=kjx4biy1xc3qf2mogq57pv80b&st=irspqesm&dl=1

The filename -- vmware-viclient-0dfc12e1.exe -- impersonates the VMware vSphere Client, a tool used almost exclusively by system administrators and infrastructure engineers. This is not a lure designed for the accounting department. The threat actor is specifically targeting people who manage virtualization infrastructure: the exact demographic most likely to have elevated privileges, VPN access, and keys to production environments. If you are going to compromise one person in an organization, an IT admin who routinely downloads tools from the internet is close to the top of the list.

The hex suffix (0dfc12e1) in the filename is a nice touch -- it mimics the kind of build identifiers that legitimate software vendors append to installer filenames. It adds a veneer of authenticity that a simple vmware-installer.exe would lack.

The use of Dropbox for hosting is equally deliberate. Dropbox is a trusted domain. It passes URL reputation filters. It supports direct download links (dl=1 parameter). And it does not require the attacker to maintain their own web infrastructure for the delivery phase. When the link eventually gets reported, Dropbox will take it down -- but by then the campaign has moved on to a fresh link.

Initial reporting tagged the campaign's origin as Italy, consistent with the sample being submitted by Italian threat researcher JAMESWT. The targeting of Italian organizations tracks with the broader pattern: a localized campaign, likely delivered via spearphishing email, aimed at IT personnel in Italian enterprises.

The Binary: Legitimate Code, Illegitimate Purpose

The payload itself is a standard MeshAgent 64-bit executable. There is nothing modified, backdoored, or patched about the binary -- it is the real MeshAgent, compiled from source and configured with an embedded connection profile.

Attribute	Value
SHA-256	`cc5533276e0298b981c7d0ca3a8ee6a502af679ad8ce124044d70b002fb0893c`
MD5	`fa39ee1b3739d14c844ba1a92fb17e57`
SHA-1	`4b63dedced43ead47897983525726d2c1017ea16`
imphash	`fb0a8b4a81655f744a37af985e009476`
File Size	3,482,304 bytes (3.3 MB)
File Type	PE32+ executable (console) x86-64, 7 sections
Compile Time	2025-03-07 02:57:17 UTC
PDB Path	`C:\MeshAgent\MeshAgent\Release\MeshService64.pdb`
Delivery Name	`vmware-viclient-0dfc12e1.exe`

The compile timestamp -- March 7, 2025 -- predates the campaign's first public sighting by exactly one year. This could indicate a pre-built agent that sat in the operator's toolkit for months, or it could be a manipulated PE timestamp. Either way, the binary is not freshly compiled for this campaign.

Extracted Configuration

The agent's embedded configuration tells us everything about where it calls home and what capabilities the operator has:

Config Field	Value
MeshServer	`wss://103[.]65[.]230[.]86:443/agent.ashx`
MeshName	`traffic-rc`
MeshType	2 (Full agent)
MeshID	`0xFAB8CE6473F538F47B3D8F37730F42FD...`
ServerID	`9ADC89F71F57C9B1B1A996BAB44469ED...`

The MeshName field is the campaign identifier: traffic-rc. The naming convention -- traffic followed by a suffix -- suggests a traffic distribution or redirect operation. This is consistent with initial access broker (IAB) activity, where the operator's goal is not to conduct the final-stage attack themselves but to sell access to compromised machines in bulk. The "rc" suffix could denote a sub-campaign, a geographic region, or simply a version tag.

MeshType=2 is the critical detail. MeshCentral supports three agent types:

Type 1: Minimal agent (basic info collection only)
Type 2: Full agent (KVM, terminal, file transfer, process management)
Type 3: Recovery agent (Intel AMT only)

Type 2 gives the operator everything. Remote desktop with keyboard and mouse control. An interactive command shell. Bidirectional file transfer. Process and service management. Hardware inventory. And because the MPS (Management Presence Server) is active on port 4433, the operator also has Intel AMT capabilities -- hardware-level management that persists even if the operating system is reinstalled.

Detection Coverage: The "Not-a-Virus" Problem

Vendor detection tells the story of why RMM abuse works:

Vendor	Detection
Kaspersky	`not-a-virus:HEUR:RemoteAdmin.Win32.MeshAgent.gen`
ClamAV	`SecuriteInfo.com.Program.MeshAgent.3.UNOFFICIAL`
ReversingLabs	7/36 scanners (19%)
Spamhaus HBL	Suspicious
Triage Sandbox	Score 10/10 (malicious)
ANY.RUN	Malicious activity

Seven out of thirty-six scanners. Nineteen percent detection rate. Kaspersky -- one of the most aggressive engines in the industry -- explicitly labels it "not a virus." This is the fundamental challenge of RMM abuse: the binary is doing exactly what it was designed to do. The malicious intent exists in the deployment context, not in the code, and that distinction is one that signature-based detection cannot bridge.

The sandbox platforms (Triage, ANY.RUN) correctly flag the behavior as malicious because they observe the full execution chain -- the WebSocket callback to a non-corporate server, the service installation without user interaction, the full capabilities being activated. But sandboxes are not deployed on every endpoint. The agents that are deployed on every endpoint are the ones calling it "not a virus."

The Attack Chain

[DELIVERY]                 [SOCIAL ENGINEERING]          [INSTALLATION]              [C2]                    [POST-COMPROMISE]

Dropbox shared     --->    VMware vSphere         --->   MeshAgent installs   --->   wss://103.65.230.86    --->   Full Remote
file link                  Client disguise               as Windows service          :443/agent.ashx               Control:
(trusted domain,           (vmware-viclient-             (MeshType=2,                (MeshCentral panel,           - KVM desktop
direct download)           0dfc12e1.exe)                 persists across             encrypted WebSocket)          - Shell access
                           Targets: IT admins            reboots)                                                  - File transfer
                                                                                     Intel AMT MPS on             - Process mgmt
                                                                                     port 4433                    - HW inventory
                                                                                     (hardware-level              - AMT control
                                                                                     persistence)

The elegance of this chain is its simplicity. There is no multi-stage loader. No shellcode injection. No process hollowing. No obfuscation layers to peel back. The operator downloads a legitimate binary, configures it with their server address, renames it to something an IT admin would trust, and uploads it to Dropbox. The entire "malware development" process probably took less than five minutes.

Infrastructure Analysis: EuroHoster and the Bulgarian Connection

The C2 Server

Attribute	Value
IP Address	`103[.]65[.]230[.]86`
ASN	AS207728
Provider	EuroHoster Ltd. (Bulgaria)
Reverse DNS	`vps38367.hosted-by-eurohoster.org`
Open Ports	22 (SSH), 80 (HTTP redirect), 443 (MeshCentral Panel), 4433 (MPS)
Status	LIVE at time of investigation

The MeshCentral panel is fully operational and internet-facing on port 443. HTTP on port 80 redirects to HTTPS. The operator has disabled the default account creation page -- a minimal OPSEC step that prevents researchers from creating accounts on the panel, but one that still leaves the login page exposed. Port 4433 hosts the Intel AMT Management Presence Server, confirming this is a full-featured MeshCentral deployment, not a stripped-down agent relay.

EuroHoster: A Familiar Name in Threat Reports

Attribute	Value
Organization	EUROHOSTER Ltd.
Country	Bulgaria (Burgas)
ASNs	AS207728, AS59729
Contact	Andrii Balytskyi
Abuse Contact	`abuse@eurohoster.org`
IP Ranges	30+ /24 prefixes across multiple allocations
Datacenter Names	"Greenhouse" (BG), "NewJersey", "Telepoint" (Sofia)

EuroHoster is a hosting provider that occupies the gray zone between legitimate infrastructure and bulletproof hosting. They have abuse contacts, they respond to some reports, and they host plenty of legitimate customers. But their IP space also appears with notable frequency in threat intelligence feeds. The combination of Bulgarian jurisdiction, relatively permissive acceptable use policies, and low-cost VPS offerings makes them attractive to operators who need infrastructure that will stay online long enough to run a campaign.

The provider operates across at least two ASNs with more than 30 /24 prefixes -- a significant amount of address space. The contact name (Andrii Balytskyi) and the Ukrainian-sounding name combined with Bulgarian registration suggests the kind of cross-border hosting operation common in Eastern European datacenter markets.

TLS Certificate Forensics

The certificates on this server are a goldmine for pivoting and tracking.

Port 443 -- MeshCentral Web Panel:

Field	Value
Subject	`CN=103.65.230.86`
Issuer	`CN=MeshCentralRoot-7e2763, O=unknown, C=unknown`
Serial	`15371419960 (0x394354138)`
Validity	2017-12-31 to 2049-12-30
Key	RSA 3072-bit
SANs	`IP:103.65.230.86, DNS:103.65.230.86, DNS:localhost, IP:127.0.0.1`
SHA-256 Fingerprint	`44:92:05:1A:7F:79:7B:9D:F7:77:33:FE:8B:75:44:56:...`

Port 4433 -- Intel AMT MPS:

Field	Value
Subject	`CN=103.65.230.86`
Issuer	`CN=MeshCentralRoot-7e2763, O=unknown, C=unknown`
SHA-256 Fingerprint	`1F:F1:87:1A:BB:2D:59:58:06:62:41:D2:AF:E3:4C:56:...`

Authenticode Code Signing:

Field	Value
Subject	`CN=103.65.230.86-4a1e19`
Issuer	`CN=MeshCentralRoot-7e2763, O=unknown, C=unknown`
Serial	`161155201032 (0x2585993808)`
Thumbprint (SHA-256)	`32cf1229d221bf0d6a467076112066ea3d42c696f05ed50b856832e6d484e4fc`

Several things stand out. First, the root CA identifier MeshCentralRoot-7e2763 is unique to this MeshCentral installation. Every MeshCentral deployment generates its own root CA with a random suffix. That suffix -- 7e2763 -- becomes a high-fidelity fingerprint for tracking this specific operator's infrastructure. If this CA appears on a different IP address tomorrow, it is the same operator who moved servers.

Second, the validity period (2017-12-31 to 2049-12-30) is the MeshCentral default -- a 32-year certificate. The "Not Before" date of December 31, 2017 does not mean the server was set up in 2017; it is a hardcoded default in the MeshCentral certificate generation code. But the operator did not bother changing it, which tells us they deployed a stock MeshCentral installation without customizing the PKI parameters.

Third, the code signing certificate embeds the IP address in the Common Name (103.65.230.86-4a1e19). This is another MeshCentral default behavior -- the platform generates Authenticode certificates using the server's IP or hostname. It means the binary itself contains a breadcrumb pointing directly at the C2 server, readable by anyone who checks the digital signature properties.

The operator is using the MeshCentral internal CA for everything -- TLS, MPS, and code signing. No commercial certificates. No Let's Encrypt. This is simultaneously lazy OPSEC (self-signed certificates are trivially fingerprinted) and a deliberate choice (no certificate authority has a record of their identity).

Neighborhood Analysis: What Else Lives on 103.65.230.0/24

Scanning the /24 block reveals the kind of mixed-use infrastructure typical of permissive hosting providers:

IP	Hostname	Services	Notes
.81	vps39700.hosted-by-eurohoster.org	RDP (3389), WinRM (5985)	Windows VPS -- open RDP is a red flag
.85	vps40721.hosted-by-eurohoster.org	SSH (22)	Linux VPS
.86	vps38367.hosted-by-eurohoster.org	SSH, HTTP, HTTPS, MPS	Our target -- MeshCentral C2
.88	vps38328.hosted-by-eurohoster.org	SSH, HTTPS	Serves certificate for Apple `sb.music.apple.com`
.89	vps38341.hosted-by-eurohoster.org	HTTPS	Serves Let's Encrypt certificate for `RT.com`
.90	vps38333.hosted-by-eurohoster.org	Full mail stack	Mail server
.93-.95	`*.modifyhomeappliances.com`	SSH, HTTP, MySQL	Suspicious DGA-like subdomains

The neighbors at .88 and .89 are particularly interesting. One is presenting a TLS certificate for Apple's music streaming infrastructure (sb.music.apple.com), and the other is impersonating Russian state media (RT.com) with a Let's Encrypt certificate. Certificate impersonation at this scale -- on adjacent IPs in the same /24 -- suggests the hosting provider's block is being used for man-in-the-middle infrastructure, phishing, or SSL interception operations. We cannot attribute these to the same operator running the MeshCentral panel, but the neighborhood context reinforces that this IP range is not a normal hosting environment.

The .93-.95 range running modifyhomeappliances.com with exposed MySQL ports has the hallmarks of a compromised or purpose-built phishing/scam domain. The name reads like it was generated to sound vaguely legitimate without meaning anything specific.

What Was Found vs. What Was Known

This investigation began with a tweet from threat researcher g0njxa and a ThreatFox submission from DonPasci. Here is what our analysis added:

Aspect	Prior Public Reporting	Breakglass Intelligence Findings
C2 Server	IP `103.65.230.86` identified	Full MeshCentral panel mapped: login page, MPS endpoint, WebRelay. Four ports enumerated (22, 80, 443, 4433)
Delivery	Not specified	Dropbox URL with VMware vSphere Client social engineering identified and documented
Configuration	Not extracted	Full MeshAgent config recovered: MeshID, ServerID, MeshName "traffic-rc", MeshType=2
Infrastructure	Single IP address	EuroHoster AS207728 profiled, 30+ /24 prefixes mapped, adjacent IP analysis revealing cert impersonation activity
Certificate	Tagged as "signed"	Self-signed CA chain fully documented: MeshCentralRoot-7e2763, code signing thumbprint, TLS fingerprints for both ports
Related Campaigns	Not linked	Same-imphash sample cluster identified: 10 campaigns, including commercial cert variant ("MICOMPUTER SUPPORT"), dating to Aug 2025
ThreatFox Context	Reported 12 hours prior	Cross-referenced with 4 other MeshAgent C2 servers tracked since Oct 2025

The gap between "an IP was reported" and "the infrastructure is fully characterized" is where actionable intelligence lives. Knowing an IP is malicious lets you block it. Knowing the CA fingerprint lets you detect the operator's next server. Knowing the campaign name lets you correlate future samples. Knowing the hosting provider's patterns lets you pre-emptively monitor their IP space.

The imphash fb0a8b4a81655f744a37af985e009476 -- a hash of the binary's import address table -- provides a reliable clustering mechanism for MeshAgent samples compiled from the same source tree. It links our sample to a growing roster of abuse campaigns:

First Seen	File Name	C2 Server	Code Signing	Campaign
2026-03-10	MeshAgent.exe	103[.]65[.]230[.]86	Self-signed (7e2763)	traffic-rc
2026-03-03	b47f2b7b...bin	flancer[.]micomputer[.]support	MICOMPUTER SUPPORT (GoGetSSL)	alg
2026-02-06	1.exe	meshcentral[.]casenova[.]co	Self-signed (912409)	unknown
2026-02-03	meshagent64-GA.exe	mesh[.]acs[.]nz	Self-signed (08167f)	unknown
2026-02-03	meshagent64-Jobcorp.exe	mesh[.]acs[.]nz	Self-signed (08167f)	unknown
2026-01-15	exe.exe	meshcentral[.]girydsfsggvb[.]com	Self-signed (8334e4)	unknown
2025-12-26	SecuriteInfo...	saihou[.]duckdns[.]org	Self-signed (d636bc)	unknown
2025-10-31	ututu.exe	kids[.]redroomclub[.]online	Self-signed (82b21b)	unknown
2025-08-13	mesh.exe	192[.]227[.]153[.]89	Self-signed (5633da)	unknown
2025-08-13	Meshi.exe	65[.]108[.]211[.]181	Self-signed (405893)	unknown

Ten distinct campaigns in seven months. Every single one uses its own MeshCentral root CA (different suffix on each MeshCentralRoot-XXXXXX), meaning each is a separate deployment -- but they are all compiled from the same codebase, producing the same import table hash. This is the MeshAgent abuse ecosystem in miniature: a shared open-source tool, used by unrelated operators, each spinning up their own server, each virtually invisible to endpoint detection.

The "alg" campaign (March 3, 2026) is especially noteworthy. Unlike every other sample in the cluster, this one uses a commercial code signing certificate issued to "MICOMPUTER SUPPORT" through GoGetSSL. A commercially signed MeshAgent binary will pass even stricter endpoint controls that block unsigned executables. The operator behind "alg" either purchased the certificate themselves or obtained it through a compromised or fraudulent certificate request -- both of which represent a step up in sophistication and investment compared to the self-signed majority.

ThreatFox Tracked MeshAgent Infrastructure

The broader threat intelligence community has been tracking MeshAgent C2 infrastructure through abuse.ch's ThreatFox platform:

IOC	First Seen	Reporter
`103[.]65[.]230[.]86:443`	2026-03-09	DonPasci
`alienmesh[.]servehttp[.]com`	2026-02-09	abuse_ch
`meshcentral[.]girydsfsggvb[.]com`	2026-01-15	DonPasci
`45[.]93[.]95[.]199:444`	2025-11-29	juroots
`kids[.]redroomclub[.]online:443`	2025-10-31	juroots

Five distinct MeshAgent C2 servers reported in the last five months. The reporting cadence is accelerating -- two in the last 60 days alone. This is consistent with a broader industry trend: CISA, the FBI, and multiple national CERTs have issued advisories throughout 2025-2026 about the increasing abuse of legitimate RMM tools, with MeshAgent, AnyDesk, and ScreenConnect leading the pack.

Threat Actor Assessment

Attribute	Assessment
Attribution Confidence	LOW -- insufficient evidence for specific actor identification
Campaign Name	"traffic-rc" -- suggests traffic distribution / redirect operations
Likely Motivation	Financial -- initial access brokering or direct data theft / ransomware precursor
Target Profile	IT administrators and infrastructure engineers (VMware vSphere lure)
Target Geography	Italy (based on reporter and origin tagging)
OPSEC Level	Moderate -- disabled panel registration, but uses self-signed certs with embedded IP, stock MeshCentral deployment

The campaign name "traffic-rc" is the strongest behavioral indicator we have. In cybercrime ecosystems, "traffic" typically refers to traffic distribution systems (TDS) -- platforms that route compromised user sessions to different monetization endpoints based on geography, device type, or value. An operator running a campaign called "traffic-rc" is likely building an inventory of remote access footholds that can be sold, rented, or leveraged for downstream operations. This fits the initial access broker model: compromise machines through RMM tool deployment, maintain persistent access, and sell that access to ransomware operators, data exfiltration groups, or espionage teams.

The choice of EuroHoster in Bulgaria is consistent with Eastern European cybercrime infrastructure patterns. Bulgarian hosting offers EU-adjacent connectivity, relatively slow law enforcement cooperation for international requests, and a datacenter ecosystem that caters to cost-conscious operators who do not want to answer too many questions.

Operator Timeline

Date	Event
2017-12-31	MeshCentral CA certificate "Not Before" date (default value)
2025-03-07	MeshAgent binary compiled (PE timestamp)
2026-03-09	C2 IP reported to ThreatFox by DonPasci
2026-03-09	ANY.RUN sandbox analysis of Dropbox-delivered payload
2026-03-10	JAMESWT_WT submits sample to MalwareBazaar (origin: Italy)
2026-03-10	Breakglass Intelligence investigation and infrastructure mapping

The gap between compile time (March 2025) and first sighting (March 2026) is notable. Either the binary was pre-compiled and shelved, the PE timestamp is falsified, or the operator has been using this agent for up to a year without it appearing in public threat feeds. Given the detection rate problem discussed earlier, the third option is entirely plausible -- a MeshAgent binary that Kaspersky calls "not a virus" could run on endpoints for months without triggering an alert.

MITRE ATT&CK Mapping

Tactic	Technique	ID	Implementation
Resource Development	Acquire Infrastructure: VPS	T1583.003	EuroHoster VPS in Bulgaria
Resource Development	Stage Capabilities: Upload Malware	T1608.001	Dropbox-hosted payload
Initial Access	Phishing: Spearphishing Link	T1566.002	Dropbox link to fake VMware installer
Execution	User Execution: Malicious File	T1204.002	Victim runs "VMware vSphere Client"
Persistence	Create/Modify System Process: Windows Service	T1543.003	MeshAgent installs as persistent service
Command and Control	Application Layer Protocol: Web Protocols	T1071.001	WebSocket over HTTPS (port 443)
Command and Control	Remote Access Software	T1219	MeshCentral / MeshAgent (legitimate RMM)
Command and Control	Encrypted Channel: Asymmetric Crypto	T1573.002	TLS with self-signed MeshCentral CA
Command and Control	Ingress Tool Transfer	T1105	File transfer via MeshAgent
Collection	Screen Capture	T1113	MeshAgent KVM capability
Discovery	System Information Discovery	T1082	Hardware inventory via MeshAgent

The critical technique here is T1219 -- Remote Access Software. This is the MITRE classification that captures the entire RMM abuse pattern. The other techniques describe how the agent was delivered and what it does -- but T1219 describes why it works. Legitimate remote access software is trusted by design. Detecting its abuse requires context that most security tools do not have: who authorized this installation?

Indicators of Compromise

Network Indicators

# C2 IP (defanged)
103[.]65[.]230[.]86
103[.]65[.]230[.]86:443
103[.]65[.]230[.]86:4433

# C2 WebSocket endpoint
wss://103[.]65[.]230[.]86:443/agent.ashx

# Reverse DNS
vps38367.hosted-by-eurohoster.org

# Delivery URL (defanged)
hxxps://www[.]dropbox[.]com/scl/fi/n21z2a7fwawlrk56o9cb9/vmware-viclient-0dfc12e1.exe?rlkey=kjx4biy1xc3qf2mogq57pv80b&st=irspqesm&dl=1

File Indicators

# MeshAgent binary (traffic-rc campaign)
SHA256: cc5533276e0298b981c7d0ca3a8ee6a502af679ad8ce124044d70b002fb0893c
MD5:    fa39ee1b3739d14c844ba1a92fb17e57
SHA1:   4b63dedced43ead47897983525726d2c1017ea16
imphash: fb0a8b4a81655f744a37af985e009476
ssdeep: 49152:adZEy2B6vflQf6X8uZQoy3vR6QVQy5Z+bm4M/HMFvfGW0/7Z7Ib3jxw5bB:iHvfGfZvZj1/N/z/owJB

# Delivery filename
vmware-viclient-0dfc12e1.exe

Certificate Indicators

# MeshCentral Root CA (unique per deployment -- high-fidelity fingerprint)
Issuer CN: MeshCentralRoot-7e2763
Serial:    0x3227975495

# Code Signing Certificate
Subject CN: 103.65.230.86-4a1e19
Thumbprint: 32cf1229d221bf0d6a467076112066ea3d42c696f05ed50b856832e6d484e4fc

# TLS Certificate Fingerprint (port 443)
SHA256: 44:92:05:1A:7F:79:7B:9D:F7:77:33:FE:8B:75:44:56:12:0E:5E:67:84:AD:A9:97:DE:78:89:EF:29:2F:6A:5F

# TLS Certificate Fingerprint (port 4433 -- MPS)
SHA256: 1F:F1:87:1A:BB:2D:59:58:06:62:41:D2:AF:E3:4C:56:FD:EE:2A:22:61:99:98:45:63:13:AE:80:8E:0D:48:C9

Behavioral Indicators

# MeshAgent configuration strings (searchable in binary)
MeshName=traffic-rc
MeshType=2
MeshID=0xFAB8CE6473F538F47B3D8F37730F42FD030FA216F474BD84FBA30D991FCBB9462827D92FB62C02E8981CE6E87971AD5B
ServerID=9ADC89F71F57C9B1B1A996BAB44469EDC388F346469963AD3337C9CA95C3345B04A79E8087D44FBA3473AA3C15CFB221

# PDB path (build artifact)
C:\MeshAgent\MeshAgent\Release\MeshService64.pdb

# WebSocket connection pattern
GET /agent.ashx HTTP/1.1
Upgrade: websocket
Connection: Upgrade

Detection Engineering

The Core Problem

You cannot write a YARA rule that says "this MeshAgent is unauthorized." The binary is legitimate. The challenge is detecting deployment context -- was this agent installed by IT, or by a threat actor? The detection opportunities exist at the infrastructure layer (certificate fingerprints, C2 addresses) and the behavioral layer (unexpected MeshAgent services, WebSocket connections to non-corporate IPs).

YARA Rules

rule MeshAgent_TrafficRC_Campaign {
    meta:
        author = "GHOST (Breakglass Intelligence)"
        description = "Detects MeshAgent binary configured for traffic-rc campaign"
        date = "2026-03-10"
        tlp = "WHITE"
        hash = "cc5533276e0298b981c7d0ca3a8ee6a502af679ad8ce124044d70b002fb0893c"
    strings:
        $meshserver = "MeshServer=wss://103.65.230.86" ascii
        $meshname = "MeshName=traffic-rc" ascii
        $meshid = "MeshID=0xFAB8CE6473F538F47B3D8F37" ascii
        $serverid = "ServerID=9ADC89F71F57C9B1B1A996BAB44469ED" ascii
        $ca = "MeshCentralRoot-7e2763" ascii
        $copyright = "MeshCentral MeshAgent" ascii wide
        $agent_ashx = "/agent.ashx" ascii
    condition:
        uint16(0) == 0x5A4D and filesize > 3MB and filesize < 5MB and
        ($meshserver or $meshname) and ($copyright and $agent_ashx)
}

rule MeshAgent_Generic_Abuse {
    meta:
        author = "GHOST (Breakglass Intelligence)"
        description = "Generic detection for weaponized MeshAgent with embedded C2 config"
        date = "2026-03-10"
        tlp = "WHITE"
    strings:
        $mc1 = "MeshServer=wss://" ascii
        $mc2 = "MeshName=" ascii
        $mc3 = "MeshID=0x" ascii
        $mc4 = "MeshType=" ascii
        $mc5 = "ServerID=" ascii
        $copyright = "MeshCentral MeshAgent" ascii wide
        $agent = "/agent.ashx" ascii
    condition:
        uint16(0) == 0x5A4D and filesize > 2MB and filesize < 6MB and
        $copyright and $agent and 3 of ($mc*)
}

The first rule catches this specific campaign. The second rule catches any MeshAgent binary with an embedded configuration -- useful for organizations that have no legitimate MeshCentral deployment and want to flag the presence of the tool entirely.

Suricata Rules

# Direct C2 IP match
alert tls any any -> 103.65.230.86 443 (msg:"BREAKGLASS MeshAgent C2 traffic-rc TLS"; flow:to_server,established; sid:2026031001; rev:1;)

# MeshAgent WebSocket handshake (generic -- catches any MeshAgent connecting to any server)
alert http any any -> any any (msg:"BREAKGLASS MeshAgent WebSocket agent.ashx"; flow:to_server,established; content:"GET"; http.method; content:"/agent.ashx"; http.uri; content:"Upgrade"; http.header; content:"websocket"; http.header; sid:2026031002; rev:1;)

# MeshCentralRoot-7e2763 certificate in TLS handshake
alert tls any any -> any any (msg:"BREAKGLASS MeshCentralRoot-7e2763 Cert"; flow:to_server,established; tls.cert_issuer; content:"MeshCentralRoot-7e2763"; sid:2026031003; rev:1;)

The second Suricata rule -- matching /agent.ashx in a WebSocket upgrade request -- is the most broadly useful. Every MeshAgent binary, regardless of which server it connects to, uses this endpoint path. If your organization does not use MeshCentral, this signature should never fire in normal operations.

Hunting Queries

For organizations running EDR with process telemetry:

Unauthorized MeshAgent services: Search for Windows services with MeshAgent in the binary path or service name that were not deployed by IT
WebSocket connections to /agent.ashx: Any outbound HTTPS connection where the URI path contains /agent.ashx to a non-corporate IP
MeshCentral CA in certificate stores: Search for certificates issued by any MeshCentralRoot-* CA in machine certificate stores
Dropbox direct downloads of executables: Proxy log entries matching dropbox.com/scl/fi/*/...exe?*dl=1 -- Dropbox direct download links for executable files

Recommended Actions

Immediate (24-48 hours)

Block 103[.]65[.]230[.]86 on all firewalls and proxy servers
Search endpoint and proxy logs for connections to 103.65.230.86:443 and :4433
Search web proxy logs for the Dropbox delivery URL
Deploy the YARA rules above to endpoint detection platforms
Check for MeshAgent Windows service installations on all endpoints

Short-term (1-2 weeks)

Deploy Suricata rules at the network perimeter
Hunt for imphash fb0a8b4a81655f744a37af985e009476 across endpoint telemetry
Report the Dropbox URL to Dropbox Trust and Safety for takedown
Monitor EuroHoster IP ranges (AS207728) for new MeshCentral deployments

Medium-term (1-3 months)

Implement an RMM tool allowlist policy -- enumerate every remote management tool authorized in your environment, and block everything else via application control
Deploy certificate-based detection for self-signed MeshCentral CAs (MeshCentralRoot-*) at the network perimeter
Add /agent.ashx WebSocket detection to your network monitoring baseline
Review your organization's exposure to legitimate-tool-abuse attacks across all common RMM platforms (MeshCentral, AnyDesk, ScreenConnect, RustDesk, Splashtop)

The Bigger Picture

This investigation documents one campaign by one operator using one legitimate tool. But it represents a structural problem in defensive security that is not going away. The industry has spent decades building detection systems optimized for catching malicious code. RMM abuse sidesteps that entire paradigm by using legitimate code for malicious purposes.

The detection gap is not a bug -- it is a feature of how we designed security products. When Kaspersky labels MeshAgent "not a virus," it is making a correct technical assessment. The virus is not in the binary. The virus is in the intent. And until our detection systems can reason about intent -- about who installed a tool and why -- the "traffic-rc" operators of the world will continue to find that a trusted binary and a Dropbox link are all they need.

Twenty-five MeshAgent abuse samples on MalwareBazaar since August 2025. Ten campaigns sharing a single imphash. Five C2 servers tracked on ThreatFox in five months. The trend line is clear. The question is not whether RMM abuse will increase -- it is whether your detection stack is designed to catch it.

References

g0njxa original reporting: https://x.com/g0njxa/status/2031034087801012435
CAPE Sandbox analysis: https://www.capesandbox.com/analysis/56924/
ANY.RUN sandbox: https://app.any.run/tasks/e0937ead-4392-49ac-bc41-a8de525a28ad
Triage sandbox: https://tria.ge/reports/260310-mebp5ags2t/
MalwareBazaar sample: https://bazaar.abuse.ch/sample/cc5533276e0298b981c7d0ca3a8ee6a502af679ad8ce124044d70b002fb0893c/
ThreatFox IOC: https://threatfox.abuse.ch/ioc/1762475/

Published by Breakglass Intelligence. Investigation conducted 2026-03-10. 1 legitimate tool weaponized. 1 live C2 panel mapped. 10 related campaigns clustered. 7/36 AV engines noticed. Classification: TLP:CLEAR