Nezha RMM and a suspicious vmtools.exe SOCKS5 proxy

During review of an endpoint with Nezha Chinese RMM present, the first useful pivot was not the RMM by itself. It was an authentication mismatch that made the active network connections worth examining.

That mismatch appeared while reviewing Windows Security 4624 Logon Type 3 events on peripheral systems for signs of lateral movement. The events did show lateral movement, but they also carried adversary hostname spill in the Workstation field. The workstation name did not line up cleanly with the source network address observed for the logon.

This matters because, when a user authenticates via NTLM, the client hostname is carried in the NTLM authentication payload, while the source network address comes from the underlying transport connection. Those two values are usually expected to describe the same originating system or at least a coherent access path.

That relationship breaks down when an adversary authenticates through a tunnel, proxy, or similar relay. The hostname in the NTLM material can still point at the legitimate machine, but the source IP address reflects the tunnel endpoint or transport path. That mismatch is a useful signal: it can unintentionally disclose that access is being relayed rather than coming directly from the host implied by the authentication payload.

That is what pushed the investigation toward live network state. The interesting thread became the combination of an unexpected service, odd file placement, and network activity from a process that was trying to look familiar.

Initial service context

The Nezha component was installed as a fake spooler-adjacent service:

• Service name: spool
• Display name: Windows Spooler
• Hash: 01b4324edf07cbe003c5f70a6564d7f0a669a8a0a2dff7a4c44f5795bcbd274f
• Image path: C:\WINDOWS\System32\spool\drivers\x64\svchost.exe
• Config path: C:\WINDOWS\System32\spool\V4Dirs\print.yml

Those paths are not legitimate Windows spooler locations for this service context. The placement appears selected to blend into spooler-adjacent filesystem noise while keeping the Nezha agent and configuration under attacker-controlled naming.

I am intentionally redacting the contents of print.yml. Nezha deployments commonly expose a web dashboard or control panel: the official installation guide describes a dashboard server with public internet access and an exposed port, and the Servers area is where connected Agents are managed.¹² In this case, navigating to the exposed Nezha panel allowed direct identification of the host that had the malicious RMM installed. Publishing the configuration would make that pivot easier to repeat.

Follow-on proxy activity

From there, active network connections led to a process named vmtools.exe:

C:\Program Files\VMware\VMware Tools\tools\vmtools.exe

That path is not where the legitimate VMware vmtools.exe normally lives. The binary was a renamed Node runtime, not the VMware utility. It was used to execute update.txt, which allowed new configurations to be pushed to the SOCKS5 proxy. Persistence for update.txt was provided by a scheduled task named Vmware Tools.

The proxy payload itself was present as upgrade.txt, with persistence provided by a separate scheduled task named Vmware Update.

Artifact summary

The key files tied the service, runtime, proxy, and collection behavior together:

File	Role	SHA-256
svchost.exe	Nezha agent staged under fake spooler path	01b4324edf07cbe003c5f70a6564d7f0a669a8a0a2dff7a4c44f5795bcbd274f
vmtools.exe	Renamed Node runtime	63c259c81e5d472b5f11c8d506070130cb04a1ecf84b80377a34ed6ec9048088
update.txt	Configuration update logic for the SOCKS5 proxy; persisted by scheduled task Vmware Tools	eb3375707bc308dbff16c214f416c46efe50a1fc76f480d097fdfe6038f1dd8a
upgrade.txt	SOCKS5 proxy payload; persisted by scheduled task Vmware Update	eb3375707bc308dbff16c214f416c46efe50a1fc76f480d097fdfe6038f1dd8a
cl.txt	PowerShell collection script	9a0239f1d3ecfeacef40c8862b2b8e382b81de3ef26a1aacc217a19285b0ccd8

The collection script, cl.txt, established PowerShell modules for host and account enumeration, including registry items, display names, services, processes, hostnames, and related system context. It was heavily commented and had traits consistent with LLM-generated code.

Representative comments from the collection script:

# Saved credentials from Credential Manager (cmdkey /list).
# These are the per-user creds that get auto-supplied to RDP/SMB/HTTP targets.
# Targets that don't match anything visible to the user are a strong audit signal:
# leftover creds from old servers, sneaky persistence, or accounts that bypass SSO.
# We never extract passwords

Taken together, the activity was not legitimate VMware tooling or ordinary server monitoring. Nezha provided the RMM foothold under a fake spooler service, while the mislabeled vmtools.exe Node runtime and VMware-themed scheduled tasks operated and maintained a SOCKS5 proxy implant.

Lessons learned

The NTLM hostname/source-IP relationship is a useful tunnel detection clue. In a 4624 Logon Type 3 event, the Workstation value can preserve the client hostname from the NTLM exchange, while the source network address reflects the actual transport path. When those values describe different realities, it is worth asking whether the authentication came through a tunnel, proxy, or relay.

That distinction mattered here because Nezha RMM alone did not explain the lateral movement pattern. A legitimate RMM session might explain remote access to the host, but it would not neatly explain adversary hostname spill in lateral authentication events on peripheral systems. The mismatch made the implant and relay hypothesis more plausible than treating the activity as normal RMM-driven administration.

The file paths also carried signal. svchost.exe under C:\WINDOWS\System32\spool\drivers\x64\ and print.yml under C:\WINDOWS\System32\spool\V4Dirs\ were chosen to look spooler-adjacent without matching legitimate service context. Likewise, vmtools.exe under C:\Program Files\VMware\VMware Tools\tools\ borrowed a trusted VMware name while living in the wrong place and executing non-VMware payloads.

Finally, active network connections were the connective tissue. The authentication mismatch explained why network state deserved attention; the connections tied that suspicion to the mislabeled vmtools.exe process; and the artifacts behind that process showed the SOCKS5 proxy, configuration updater, and scheduled task persistence.

Footnotes

1. Nezha’s dashboard installation guide describes a server with public internet access and an exposed dashboard port. See: Installing the Dashboard. ↩

2. Nezha’s Servers documentation describes the Servers area as the place where Agents are managed. See: Servers. ↩