N4D Mesh Controller: New infrastructure, a UPX-packed agent labeled "go-titan," and how to hunt for it

N4D Mesh Controller is an active Linux malware campaign that turns exposed Model Context Protocol (MCP) servers, and a wide range of other internet-facing services, into entry points for credential theft, lateral movement, persistence, and command and control (C2). Public reporting by researcher German Fernandez first documented the campaign's exploitation framework in June 2026. New isolated-execution analysis by Datadog Security Research paints a clearer picture of the malware campaign's current tactics, including a newer loader-to-agent chain, rotated infrastructure, exact persistence artifacts, and direct runtime evidence that the current agent enumerates MCP tools, invokes a command-execution tool, and reports the result to its controller.

Overview

Researcher German Fernandez first documented N4D, reporting a generic MCP exploitation framework, eight polymorphic agent modules, more than 30 service-specific exploitation modules, automated attack-chain planning, and dedicated targeting of AI and LLM infrastructure. Datadog Security Research later obtained and executed a sample submitted after that initial reporting. The sample contacted a new IP address, 209.99.186.235, and retrieved a second-stage agent identifying itself as 33.8-go-titan, which installed several overlapping Linux persistence mechanisms.

This new sample doesn't represent a new campaign. It confirms that N4D's operators are still active, still evolving their delivery infrastructure, and still worth hunting.

What happened

MCP servers can expose high-impact capabilities—including command execution, file access, database queries, and cloud administration—through a single, uniform protocol. N4D turns that uniformity into an attacker advantage: Instead of needing a distinct exploit for every MCP implementation, its scanner initializes a session, requests tools/list, classifies the returned tools, and invokes anything that looks dangerous (most notably execute_command) through tools/call.

This automation changes the threat model for a publicly reachable MCP server. An unauthenticated server that intentionally exposes a command execution tool doesn't need a memory corruption bug or a CVE to be compromised; the dangerous capability is already there, and N4D supplies automated discovery and abuse.

From that foothold, N4D broadens access through an unusually large, conventional exploitation library. The recovered Go binary contains paths for databases, caches, container platforms, application servers, and AI infrastructure, including Ray Dashboard and LightLLM. An operator can use one exposed MCP server as a beachhead and keep scanning or exploiting adjacent services from the compromised host.

The observed attack flow proceeds as follows:

1. Discover exposed services. Scanner probes MCP endpoints and common infrastructure ports. Older scanner artifacts identify the MCP client as n4d-vps; the current Go agent uses the shorter name n. Both negotiate protocol version 2024-11-05 and request tools/list.
2. Classify dangerous capabilities. Tool names associated with command execution, file access, and database queries are selected for invocation.
3. Deliver the agent. Shell scripts and loaders use curl or wget to retrieve an architecture-specific agent from cdnorigin.net, 209.99.186.73, or the newly observed 209.99.186.235. The newer loader tries both /api/agent/full?arch= and the legacy /api/agent/binary?arch=.
4. Establish control. The agent communicates with controller API paths, including /api/register, /api/beacon, /api/task/, /api/result/, and /api/pty, authenticated with custom X-Mesh-Auth and X-Operator-Key headers.
5. Expand access. The agent contains service-specific abuse paths for PostgreSQL, MySQL, Redis, Docker, Kubernetes, Nacos, Jenkins, Ray, LightLLM, and other platforms, including recovered functions named deployRayDashboard and deployLightLLM.
6. Persist and conceal. Observed mechanisms include hidden cron entries, shell-profile modification, watchdog scripts, systemd units, SSH key installation, execution from memory-backed directories, and process names that mimic Linux kernel workers.
7. Add a secondary channel. The agent can launch Cloudflare Quick Tunnels and report the assigned *.trycloudflare.com hostname back to its controller.

What we found

Sample analysis

At a publication-time refresh on July 29, 2026, the associated VirusTotal collection held 27 artifacts: 21 ELF binaries, five POSIX shell scripts, and one file of unknown type. Eighteen of the ELF files were UPX-packed. Antivirus detections across the set ranged from 0 to 29 engines, a wide enough spread that behavioral and campaign-specific artifacts are more useful for tracking than any detection-count threshold.

The same refresh found an enabled four-rule VirusTotal Livehunt ruleset covering loaders, unobfuscated agents, delivery scripts, and MCP autodeployment behavior. Its newest notifications were repeated behavior matches on the known packed agent (fc4109f5dd1d30b65dd60e57dc639ac1d313bfa5241e36e61fbc4aabc1cda482) and static matches on two known unobfuscated collection files (3435cc9d4a255bfb4cfb09f2390c29b888f70a43345cfaaecf46c55bc89b814d and ab435e3e24cfb3a37c1f564209869fe53c8fe95bc9161d0d373fbc1c551b2c29). These were new analyses of previously submitted files, not newly submitted campaign samples. They validate the rules but do not, by themselves, establish new campaign activity.

We inspected five representative files: an unpacked Go build, a packed ELF with the collection's highest detection count, and three downloader/watchdog scripts.

The unpacked x86-64 Go sample (3435cc9d4a255bfb4cfb09f2390c29b888f70a43345cfaaecf46c55bc89b814d) exposes extensive implementation detail through static strings and symbols:

• MCP operations: initialize, tools/list, tools/call, execute_query, and command-execution classification logic
• Agent control: X-Mesh-Auth, .trycloudflare.com, /api/pty, and the registration/tasking/result API paths
• AI infrastructure targeting: main.deployLightLLM and main.deployRayDashboard
• Persistence and execution: /etc/cron.d/.syscheck, /etc/profile.d/sys_alias.sh, /root/.ssh/authorized_keys, /dev/shm/.n4d, and kernel-worker-style process names
• Service exploitation: PostgreSQL COPY TO PROGRAM, MySQL outfile/event execution, Redis configuration abuse, Docker socket access, Kubernetes APIs, Nacos, and Jenkins

The shell samples show a compact, repeatable delivery pattern: Check a lock file or running process, map the host architecture, download to /tmp/.agent or /tmp/.n4d, chmod +x, and detach with setsid. One watchdog re-downloads the payload every 30 seconds if /tmp/.agent is missing. Another tries both the TLS-fronted domain and the raw IP. A third computes an architecture value but requests the amd64 payload regardless, a sign of uneven quality across generated or operator-maintained variants.

Isolated execution of the newer loader

We executed a newer x86-64 loader in disposable microVMs, using QEMU user-mode emulation with host-level syscall denial for runtime network connections. The password-protected archive was 77fe750d6b94b32e80e25aecb2ae7c435f0b45cfca25969dbee4dc22967b1302; its ELF payload was 0d5f67b6d35e609e1d5eac0afd981147ea8df7da2f192ae59ac0bab7e48cc1de. The statically linked Go loader used module path n4d-agent/loader and embedded both cdnorigin.net and 209.99.186.235.

The loader tried four endpoint combinations across ports 80 and 8443, using both the current /api/agent/full?arch=amd64 path and the legacy /api/agent/binary?arch=amd64. It wrote /etc/cron.d/.sys-health on a three-minute schedule and staged /tmp/.sys-health-monitor.tmp.

To capture the next stage without giving the loader unrestricted network access, we retrieved the exact observed URL from a separate disposable VM: http://209.99.186.235:8443/api/agent/full?arch=amd64 returned a 7,321,596-byte UPX-packed ELF (fc4109f5dd1d30b65dd60e57dc639ac1d313bfa5241e36e61fbc4aabc1cda482). Unpacked with UPX 5.1.1, it grew to 19,202,174 bytes (c422621ef824b627d74906f8d75ed8f990f4d6c708a0d263f219f9d9dd435174), a Go binary that was also garble-obfuscated, with damaged or removed symbol metadata.

The agent identified itself in its debug log as 33.8-go-titan, using node authentication key n4d-2ff16c75b1d2. We denied every outbound connection before egress and let the agent run for 120 seconds. In that window, it made 22,831 connection attempts across 742 destination IPs, 15,833 IP/port pairs, and 37 destination ports, targeting SSH, databases, container APIs, Kubernetes, caches, and application servers. This is direct runtime evidence that the delivered agent performs broad, multi-service scanning rather than only maintaining C2.

The denied run also constrains how those targets were chosen: Scanning started without receiving controller tasking. Destinations clustered into contiguous address ranges, while the unobfuscated oracle exposes scanCIDR and scanLateral functions, as well as /24 construction artifacts. Together, that evidence supports autonomous, on-host expansion of CIDR seeds rather than 742 individually hardcoded targets. We have not recovered the seed selection algorithm from the garble-obfuscated 33.8 build, so whether those prefixes were built in or generated locally, and why the agent selected those particular public ranges, remain unresolved.

The same run surfaced the current controller API surface: POST /api/register, GET /api/task/{node}, POST /api/result/{node}, POST /api/intel, GET /api/endpoints, and three /api/update/ endpoints, all issued via an embedded Go HTTP client so they never appear as curl or wget command lines.

Observed persistence included /etc/cron.d/.s, /etc/cron.d/.sys-health, /etc/profile.d/.sys_alias.sh, /etc/systemd/system/sys-resource.service, /tmp/.wd, /var/tmp/.wd, /usr/local/bin/.sys-health-monitor, and an appended shell startup command. It also installed the following SSH public key into /root/.ssh/authorized_keys:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJKH4g/SD6c00i5PzlWWkwXJwIHEac+nlAjg6WeOHUq3 root@ubuntu

The agent also attempted to download cloudflared from GitHub and retained logic to launch a Quick Tunnel to a local port. Generic Quick Tunnel activity is not an N4D indicator on its own, as legitimate use is common, but temporary-path execution combined with other campaign artifacts provides the needed context.

Offline replay against deterministic services

Connection denial established the agent's scanning breadth, but it could not show what happens after a service answers. We therefore built an offline replay lab. The sample runs in a network namespace connected only to a recorder namespace. The recorder has no default route or external interface, drops forwarding, captures original packets with tcpdump, transparently redirects TCP through mitmproxy, and sends HTTP, TLS, and WebSocket requests to deterministic aiohttp fixtures. The controller fixture registers a synthetic node but always returns an empty task queue. The MCP fixture advertises one inert execute_command tool and never executes the supplied argument. Samples and generated captures remain outside Git.

An inert probe validated DNS, HTTP, TLS, WebSocket, PCAP, flow, syscall, and filesystem capture before malware execution. That validation also exposed an instrumentation failure: Wrapping QEMU in host strace set a nonzero TracerPid, which the debug agent read from /proc/self/status before exiting. Removing the host tracer while retaining QEMU's guest-side syscall trace allowed the same build to remain active until the containment timeout. Dynamic-analysis instrumentation can change the behavior it is intended to measure, so the lab records the execution mode with every run.

We compared the unobfuscated 14.10-go-titan oracle with the supplied packed 33.8-go-titan sample. The supplied archive (94ae566e27b176698958b4b9c216a0a2b0ac7ce11d7d81417c8add081fd3cc9c) contained only the expected packed ELF (fc4109f5dd1d30b65dd60e57dc639ac1d313bfa5241e36e61fbc4aabc1cda482). VirusTotal independently relates that file to extracted payload c422621ef824b627d74906f8d75ed8f990f4d6c708a0d263f219f9d9dd435174.

The request totals are not campaign scan rates. The fixture deliberately accepted every configured controller and synthetic MCP endpoint, amplifying concurrent loops and tool calls. They do establish code-path reachability. Most importantly, the packed current build did not merely contain generic MCP strings: It completed initialize → tools/list → tools/call, selected execute_command, attempted id, and exfiltrated the structured result. It also wrote /tmp/.n4d_autodeploy_debug, providing a second source of ground truth for each MCP initialization and tool-list operation.

The two result flags describe different stages. error:false records that the JSON-RPC tool call itself succeeded. exec_verified:false is implant-side validation, not controller confirmation: The agent placed it in the outbound /api/intel request before receiving a response. In this run, the fixture returned the literal text fixture: execution disabled, which did not resemble a real id result. We did not recover the exact verification predicate from the obfuscated build.

The AI service findings require a stricter confidence boundary. The replay dynamically confirmed current probes for Ollama, ComfyUI, and Stable Diffusion WebUI, but it did not observe exploitation of those products. The debug build reached Ray's version probe, while its /run deployment path remains a static capability. LightLLM /pd_register, Marimo /terminal/ws, Jupyter, FastGPT, and the two-stage Nginx UI chain were not reached in the bounded replay. Because the controller returned an empty task queue, the replay could not exercise modules that require operator tasking. Nor can it distinguish build-version changes from response gating, fixture fidelity, or timing. The functions and protocol artifacts remain high-confidence static findings from the debug build, supported by the original research and these advisories:

• LightLLM PD-mode unsafe deserialization, CVE-2026-26220, covers unauthenticated binary WebSocket data passed to pickle.loads() in versions through 1.1.0.
• Ray job submission, CVE-2023-48022, covers remote code execution through the job API in Ray 2.6.3 and 2.8.0. Ray's documented position is that the service was intended for a controlled network, and token authentication became available in Ray 2.52.0.
• Marimo's unauthenticated terminal WebSocket, CVE-2026-39987, affects versions before 0.23.0 and is in CISA's Known Exploited Vulnerabilities catalog.
• Nginx UI's unauthenticated backup disclosure, CVE-2026-27944, and unauthenticated MCP endpoint, CVE-2026-33032, match the debug build's backup and MCP-chain artifacts. We did not dynamically reproduce that chain.

The current build's runtime behavior is both broader and narrower than its static inventory suggests. It operationalises generic MCP tool abuse and adds probes for locally deployed generative-AI services, while several older CVE-specific modules did not execute during the bounded replay. We cannot yet attribute that difference to module removal or a deliberate behavioral shift; build changes, autonomous scanner prioritisation, response gating, timing, and operator tasking remain plausible explanations. The distinction is the main contribution beyond the original report: It separates code retained in an oracle build from behavior exercised by the packed agent delivered in July 2026.

The current controller surface included POST /api/register, GET /api/task/{node}, GET /api/beacon, POST /api/intel, and POST /api/deployed. Authentication used X-Mesh-Auth, and the first intelligence report attempted to collect AWS, Google Cloud, and Azure metadata, environment values, sensitive files, and SSH keys.

Detection opportunities

Defenders can correlate campaign-specific indicators with behaviors that stay useful even after infrastructure or file hashes rotate. Here's an overview of what to look for:

MCP server telemetry

• An MCP initialize request followed by tools/list from client name n4d-vps, or from the current client name n when correlated with N4D request paths or persistence artifacts
• tools/call activity invoking command-execution, file-write, or database-query tools
• Publicly reachable MCP endpoints without authentication, especially those exposing shell or code-execution tools
• Child processes spawned by an MCP server, particularly curl, wget, shell interpreters, or executables written to temporary directories

Host telemetry

• Process execution from /dev/shm, /tmp, or /var/tmp named kworker* or using hidden dotfiles
• Writes to /etc/cron.d/.s, /etc/cron.d/.sys-health, /etc/cron.d/.syscheck, /etc/profile.d/.sys_alias.sh, or /etc/systemd/system/sys-resource.service
• Creation of /dev/shm/.agent.lock, /dev/shm/.agent.pid, /tmp/.n4d*, /tmp/.agent, /tmp/.sys-health-monitor, /var/tmp/.a, or /var/tmp/.wd
• Download activity referencing /api/agent/full, /api/agent/binary, cdnorigin.net, 209.99.186.73, or 209.99.186.235
• HTTP telemetry containing X-Mesh-Auth, X-Operator-Key, /api/task/, /api/beacon, /api/register, /api/result/, /api/deployed, or /api/pty
• cloudflared launched from a world-writable temporary directory; treat generic *.trycloudflare.com DNS activity as a correlation lead, not attribution on its own

Network telemetry

• Connections to 209.99.186.73 or 209.99.186.235, and DNS/HTTP activity for cdnorigin.net
• Requests to /api/agent/full, /api/agent/binary, and other controller API paths
• Cloudflare Quick Tunnel traffic correlated with temporary-path execution or other N4D host artifacts

Here are some YARA rules for tracking the campaign: one for the newer loader, one for unobfuscated or debug agent builds, and one for delivery scripts. Packed or newly obfuscated agents may not expose enough plaintext for the second rule to match.

rule N4D_Linux_Loader_2026
{
    meta:
        description = "Tracks N4D Go loaders delivering architecture-specific agents"
        date = "2026-07-13"
    strings:
        $module = "n4d-agent/loader" ascii
        $full = "/api/agent/full?arch=" ascii
        $legacy = "/api/agent/binary?arch=" ascii
        $beacon = "/api/beacon?k=n4d" ascii
        $cron = "/etc/cron.d/.sys-health" ascii
        $stage = "/tmp/.sys-health-monitor.tmp" ascii
        $domain = "cdnorigin.net" ascii
    condition:
        uint32(0) == 0x464c457f and filesize < 20MB and
        $module and 3 of ($full, $legacy, $beacon, $cron, $stage, $domain)
}

rule N4D_Mesh_Agent_Unobfuscated
{
    meta:
        description = "Tracks unobfuscated N4D mesh agent builds"
        date = "2026-07-13"
    strings:
        $mcp1 = "tools/list" ascii
        $mcp2 = "tools/call" ascii
        $api1 = "/api/register" ascii
        $api2 = "/api/result/" ascii
        $tunnel = ".trycloudflare.com" ascii
        $profile = "/etc/profile.d/sys_alias.sh" ascii
    condition:
        uint32(0) == 0x464c457f and filesize < 40MB and
        all of ($mcp*, $api*, $tunnel, $profile)
}

rule N4D_Linux_Delivery_Script
{
    meta:
        description = "Tracks N4D shell downloaders and watchdogs"
        date = "2026-07-13"
    strings:
        $shell = "#!/bin/" ascii
        $full = "/api/agent/full?arch=" ascii
        $legacy = "/api/agent/binary?arch=" ascii
        $domain = "cdnorigin.net" ascii
        $new_ip = "209.99.186.235" ascii
        $watchdog = ".sys-health-monitor" ascii
        $setsid = "setsid" ascii
        $cron = "/etc/cron.d/.sys-health" ascii
    condition:
        filesize < 200KB and $shell and
        4 of ($full, $legacy, $domain, $new_ip, $watchdog, $setsid, $cron)
}

VirusTotal Livehunt can also apply a behavior rule to normalised sandbox results from packed files. The enabled rule correlates N4D's MCP autodeployment markers with reporting to the controller:

import "vt"

rule N4D_Dynamic_MCP_Autodeploy
{
    meta:
        description = "N4D MCP exploitation followed by controller reporting"
        date = "2026-07-14"
    condition:
        for any path in vt.behaviour.files_written : (
            path endswith "/tmp/.n4d_autodeploy_debug" or
            path endswith "/tmp/.n4d_nid"
        ) and
        for any http in vt.behaviour.http_conversations : (
            http.request_method == vt.Http.Method.POST and
            (http.url contains "/api/intel" or
             http.url contains "/api/deployed")
        )
}

Keep file and behavior rules in separate Livehunt rulesets so high-volume behavioral pivots do not exhaust notification limits for high-confidence file matches. Monitor notifications through the API, then enrich each new SHA-256 with submissions, relationships, behavior, TLSH, telfhash, vhash, and dropped-file links before clustering it.

Additional tracking opportunities include passive DNS for new resolutions of cdnorigin.net, certificate transparency pivots on newly observed TLS certificates, hosting/ASN changes around the controller IPs, and VirusTotal relationship pivots from new loaders to contacted URLs and downloaded files. Monitor the SSH public key above, the Go module path n4d-agent/loader, the version string 33.8-go-titan, and the node key prefix n4d- in any newly recovered configuration. Track *.trycloudflare.com only when it correlates with .cf_h, temporary-path cloudflared execution, or another N4D indicator.

Some concise threat hunting ideas

Here are a few starting points for threat hunts to check for N4D related activity in your environment:

If your rules use OCSF-normalised fields, they can apply across whichever log sources you have already onboarded, instead of depending on a single integration.

Response guidance

Isolate affected hosts before removing persistence. Preserve the process tree, executable, shell scripts, open connections, and temporary files for analysis. Remove cron, profile, systemd, SSH-key, and watchdog persistence only after evidence collection is complete. Rotate cloud credentials, SSH keys, database credentials, API tokens, and any secrets available to the MCP process or stored on the host.

For exposed MCP services, require authentication, bind local-only services to loopback, and put remote access behind an authenticated proxy. Inventory advertised tools and remove command execution, unrestricted file access, and broad database capabilities where they aren't required. Where command execution is a legitimate requirement, put it behind explicit per-tool authorisation and a strict allowlist, then run it in a short-lived, unprivileged sandbox with a read-only root filesystem, no host mounts or credentials, blocked cloud-metadata access, constrained egress, and resource and time limits. Log MCP tool invocation with the authenticated principal, client identity, tool name, arguments, resulting child process, and sandbox outcome.

Indicators of compromise

References

• Original N4D Mesh Controller research
• German Fernandez's campaign summary on X