NadMesh Botnet — AI & MCP Infrastructure Credential Hunt

Looks for: the multi-path loader from the NadMesh persistence trio — a hidden file literally named .a dropped into /tmp, /var/tmp or /dev/shm. This is the single highest-fidelity signal in the pack. FP: low, but not zero — some build toolchains emit static-library artifacts named .a; those are normally lib*.a under a build tree, not a bare dotfile in /tmp.

// HUNT: NadMesh disk-backed loader — hidden ".a" in world-writable paths
// MITRE: T1105, T1036.005
// CONF: high  FP: low  COST: low
// REQUIRES: Falcon Linux sensor file-write telemetry
// FALSE POSITIVES: build systems emitting ar(1) static libraries named ".a"
// TUNING: exclude known build hosts by aid, or ContextBaseFileName in (gcc, ld, ar, make)
#event_simpleName=/ELFFileWritten|NewExecutableWritten/
| FileName=/^\.a$/i
| (TargetFileName="*/tmp/.a" or TargetFileName="*/var/tmp/.a" or TargetFileName="*/dev/shm/.a")
| table([@timestamp, aid, ComputerName, UserName, TargetFileName, FileName, ContextBaseFileName, FileSize], limit=200)

Looks for: the cron half of the persistence trio — process activity referencing the hidden watchdog files .sys_monitor or .s under /etc/cron.d. Hunted through CommandLine because cron-file writes are not reliably surfaced as a dedicated file event on Linux; a companion basename filter on file telemetry is in Q2b below. FP: low — a dot-prefixed file in /etc/cron.d is anomalous by itself, and cron actually ignores names containing a dot, which is precisely why the operator chose them (the entries are invisible to a casual ls and inert to cron's own parser until invoked directly).

// HUNT: NadMesh cron watchdog — hidden .sys_monitor / .s under /etc/cron.d
// MITRE: T1053.003
// CONF: high  FP: low  COST: low
// REQUIRES: Falcon Linux sensor process telemetry
// FALSE POSITIVES: admin scripts that enumerate /etc/cron.d during audits
// TUNING: exclude ParentBaseFileName in (ansible, puppet, chef-client, cloud-init, aide, tripwire)
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| CommandLine=/cron\.d\/\.(sys_monitor|s)(\s|$|")/i
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine, ParentBaseFileName, GrandparentBaseFileName], limit=200)

Looks for: the same artifacts from the file-write side, matched on basename so there is no path slash to escape. FP: low. Caveat: generic (non-executable) file-write visibility on Linux varies by sensor version and policy — if this returns zero events across a long window while Q2 returns hits, your tenant is not emitting the file event and Q2 is your authoritative control.

// HUNT: NadMesh cron watchdog — file-write basename match
// MITRE: T1053.003
// CONF: high  FP: low  COST: low
// REQUIRES: Linux file-write telemetry  (⚠ validate in tenant — generic file-write
//           coverage on Linux varies by sensor version / policy)
// FALSE POSITIVES: none expected — dot-prefixed cron.d entries are not a normal admin pattern
#event_simpleName=/ELFFileWritten|NewExecutableWritten/
| FileName=/^\.(sys_monitor|s)$/i
| TargetFileName="*/etc/cron.d/*"
| table([@timestamp, aid, ComputerName, UserName, TargetFileName, FileName, ContextBaseFileName], limit=200)

Looks for: a process appending to authorized_keys — the third leg of the persistence trio, delivered by the /api/beacon script itself. FP: high, and honestly so. Configuration management legitimately rewrites this file constantly. This query is only useful with the exclusions applied — in an estate running Ansible or cloud-init at scale, the unfiltered version is unusable. Treat it as a hunt with a tuned allowlist of writers, never as a standalone alert.

// HUNT: SSH authorized_keys modification (NadMesh public-key backdoor)
// MITRE: T1098.004
// CONF: high  FP: high  COST: medium
// REQUIRES: Falcon Linux sensor process telemetry
// FALSE POSITIVES: Ansible/Puppet/Chef/Salt, cloud-init, ssh-copy-id, provisioning and
//   golden-image pipelines, IdP key-sync agents. Volume will be dominated by these.
// TUNING: exclude the parents below, then baseline the surviving writers per host role
//   and alert only on writers that are NOT on the allowlist for that role.
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| CommandLine=/authorized_keys/i
| CommandLine=/\b(echo|printf|cat|tee|sed|curl|wget|python3?|perl)\b/i
| ParentBaseFileName!=/^(ansible|python3|puppet|chef-client|salt-minion|cloud-init|ssh-copy-id)/i
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine, ParentBaseFileName, GrandparentBaseFileName], limit=200)

Looks for: any contact with the three published atomic indicators, in one pass. Run this first — it is the cheapest possible answer to "are we already in this?". FP: low. Critical caveat on the hash: XLab published a SHA1, and most Falcon tenants index and surface SHA256HashData as the primary process hash. SHA1HashData is a real data-model field but is not populated in every tenant or every event type — if the hash clause never fires, that is a telemetry gap, not a clean result. Confirm SHA1HashData is populated in your tenant before drawing a negative conclusion, and lean on Q1/Q2 as the authoritative controls.

// HUNT: NadMesh atomic IOCs — C2 IP / C2 domain / agent SHA1
// MITRE: T1071.001, T1105
// CONF: high  FP: low  COST: low
// REQUIRES: NetworkConnectIP4, DnsRequest, ProcessRollup2 (+ SHA1HashData populated)
// FALSE POSITIVES: none expected — these are campaign-specific published indicators
// NOTE: ⚠ validate in tenant — SHA1HashData is a valid Falcon field but is not populated
//   in every tenant/event type. A silent zero on the hash clause may be a gap, not a clear.
// NOTE: the published SHA1 covers ONE of five concurrent builds (Garble + UPX -9 + random
//   padding), so hash coverage is inherently partial. Behavioural queries carry this pack.
#event_simpleName=/NetworkConnectIP4|DnsRequest|ProcessRollup2|SyntheticProcessRollup2|ELFFileWritten/
| RemoteAddressIP4="209.99.186.235"
   or DomainName=/(^|\.)cdnorigin\.net$/i
   or SHA1HashData="31c69b3e12936abca770d430066f379ec1d997ec"
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine, RemoteAddressIP4, RemotePort, DomainName, SHA1HashData, SHA256HashData], limit=200)

Looks for: the NadMesh controller URI paths (/api/beacon, /api/task/, /api/result/) appearing on a command line — i.e. the infection script being fetched, or the bot invoking its task/result endpoints via a shell helper. FP: low; /api/beacon is a distinctive path. Scope note: this only sees C2 traffic that passes through a command line. Agent-internal HTTP from the Go binary will not appear here — that is Q11's job, and true URI-level coverage needs proxy logs (see Section 15).

// HUNT: NadMesh beacon/task/result API paths on a command line
// MITRE: T1105, T1071.001
// CONF: high  FP: low  COST: low
// REQUIRES: Falcon Linux sensor process telemetry
// FALSE POSITIVES: internal apps that happen to expose an /api/result or /api/task route
// TUNING: if noisy, require the curl/wget clause AND a non-RFC1918 destination
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| CommandLine=/\b(curl|wget|fetch|python3?)\b/i
| CommandLine=/api\/(beacon|task|result)\b/i
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine, ParentBaseFileName, GrandparentBaseFileName], limit=200)

Looks for: the delivery primitive — curl … | sh. NadMesh's /api/beacon endpoint serves a shell script that installs the SSH backdoor, and this pattern catches it regardless of which controller served it. FP: medium. This is also how a great deal of legitimate software installs itself (Rust, Homebrew, Docker convenience scripts, many CI bootstraps), so expect real volume on developer and build hosts. It earns its place because it catches NadMesh variants whose C2 you do not yet know.

// HUNT: remote script piped to a shell (NadMesh beacon delivery primitive)
// MITRE: T1105, T1059.004
// CONF: high  FP: medium  COST: medium
// REQUIRES: Falcon Linux sensor process telemetry
// FALSE POSITIVES: legitimate install one-liners (rustup, homebrew, get.docker.com,
//   nvm, CI bootstrap scripts). Heavy on dev/build hosts.
// TUNING: exclude known-good install domains in CommandLine, and exclude build-agent aids;
//   prioritise hits on production/GPU hosts where no one should be curl-piping anything.
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| CommandLine=/\b(curl|wget)\b/i
| CommandLine=/\|\s*(sudo\s+)?(ba|da|z|k)?sh\b/i
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine, ParentBaseFileName, GrandparentBaseFileName], limit=200)

Looks for: the behaviour that actually costs you money — a process touching ~/.aws/config or credentials, ~/.docker/config.json, .env files, or the Kubernetes service-account token path. This is the NadMesh objective, and it is the query to run even if every other query is clean. FP: medium. Legitimate tooling reads these constantly — the AWS CLI reads its own config, kubelet reads SA tokens, deploy scripts read .env. The signal is in who is reading them: an unexpected parent (a web service, a shell spawned by a container runtime) reading all four categories in quick succession is the pattern.

// HUNT: NadMesh credential harvesting — AWS config, docker config, .env, K8s SA token
// MITRE: T1552.001, T1552.007, T1528
// CONF: high  FP: medium  COST: medium
// REQUIRES: Falcon Linux sensor process telemetry
// FALSE POSITIVES: aws-cli, kubectl, kubelet, docker/compose, terraform, deploy scripts,
//   backup jobs, and secret-scanning tools all legitimately read these paths.
// TUNING: exclude FileName in (aws, kubectl, kubelet, docker, terraform, helm) and exclude
//   ParentBaseFileName in (systemd, containerd, dockerd). Then rank by hosts where a SINGLE
//   process touched MORE THAN ONE of the four secret categories inside a few seconds.
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| CommandLine=/(\.aws\/(config|credentials)|\.docker\/config\.json|serviceaccount\/token|\.env(\s|$|"))/i
| CommandLine=/\b(cat|grep|egrep|head|tail|tar|base64|curl|python3?|xxd|strings|cp)\b/i
| FileName!=/^(aws|kubectl|kubelet|docker|terraform|helm)$/i
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine, ParentBaseFileName, GrandparentBaseFileName], limit=200)

Looks for: execution of a dot-prefixed binary out of /tmp, /var/tmp or /dev/shm — the runtime half of Q1, and the shape of a UPX-packed Go agent regardless of build version. Because NadMesh runs five concurrent obfuscated builds, this behavioural query outlives any hash. FP: medium. Installers, package post-install scripts and some CI runners genuinely execute from /tmp; the dot-prefix requirement removes most of that, but not all.

// HUNT: hidden binary executing from a world-writable path (NadMesh Go agent shape)
// MITRE: T1027.002, T1036.005
// CONF: high  FP: medium  COST: low
// REQUIRES: Falcon Linux sensor process telemetry
// FALSE POSITIVES: installers and package post-install scripts staging in /tmp; some CI
//   runners execute hidden helper binaries from /tmp.
// TUNING: exclude build/CI aids; exclude ParentBaseFileName in (dpkg, rpm, apt, yum, dnf).
//   Cross-reference any hit against Q1 — same host in both is a confirmed infection.
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| (ImageFileName="*/tmp/*" or ImageFileName="*/var/tmp/*" or ImageFileName="*/dev/shm/*")
| FileName=/^\./
| ParentBaseFileName!=/^(dpkg|rpm|apt|apt-get|yum|dnf)$/i
| table([@timestamp, aid, ComputerName, UserName, ImageFileName, FileName, CommandLine, ParentBaseFileName, SHA256HashData], limit=200)

Looks for: your own attack surface — which hosts are running ComfyUI (8188), Ollama (11434), n8n (5678) or Gradio (7860), plus the infrastructure ports NadMesh prizes (Docker API 2375/2376, K8s API 6443, kubelet 10250, etcd 2379, Redis 6379). This is a preventive hunt: it produces an inventory, not an alert. FP: "medium" only in the sense that most results are legitimate services — the finding is any of them being reachable from outside its intended boundary, which this query cannot tell you on its own. Pair it with the external scan in Section 7.

// HUNT: inventory of AI/dev and infra services on NadMesh priority ports
// MITRE: T1190 (exposure-side)
// CONF: medium  FP: medium  COST: low
// REQUIRES: NetworkListenIP4 telemetry
// FALSE POSITIVES: by design — most hits are legitimate internal services. This query
//   builds an inventory; exposure must be confirmed externally.
// TUNING: none. Review the full output as an asset list, then externally scan the hosts.
#event_simpleName=/NetworkListenIP4/
| LocalPort=8188 or LocalPort=11434 or LocalPort=5678 or LocalPort=7860
   or LocalPort=2375 or LocalPort=2376 or LocalPort=6443 or LocalPort=10250
   or LocalPort=2379 or LocalPort=6379 or LocalPort=9200 or LocalPort=8265
| groupBy([ComputerName, aid, LocalPort, LocalAddressIP4, FileName], function=[count(as=listen_events)])
| sort(field=LocalPort, order=asc, limit=1000)

Looks for: a host that has become a NadMesh scanning node. The embedded scanner rescans hit subnets every 5 minutes and dangerous /32s every 15, so an infected host generates a very distinctive fan-out: many distinct destinations on a small set of service ports. FP: low once vulnerability scanners are excluded — but those exclusions are mandatory or your scanner fleet will be the entire result set. COST: high — this aggregates raw network events; run it over a bounded window (a few hours) rather than 7 days.

// HUNT: outbound fan-out on the NadMesh 30-port scan set (host is now a scan node)
// MITRE: T1046, T1595.002
// CONF: high  FP: low  COST: high
// REQUIRES: NetworkConnectIP4 telemetry. Run over a BOUNDED window (2-6h), not 7d.
// FALSE POSITIVES: authorised vulnerability scanners, service-discovery/monitoring agents,
//   container orchestrators health-checking large pod fleets, load balancers.
// TUNING: exclude your scanner aids FIRST, then monitoring agents by FileName
//   (nessus, nmap, masscan, zabbix, prometheus, consul, telegraf).
// Threshold below is a starting point — baseline your estate before promoting.
#event_simpleName=/NetworkConnectIP4/
| ConnectionDirection=0
| RemotePort=2375 or RemotePort=2376 or RemotePort=6379 or RemotePort=6443
   or RemotePort=10250 or RemotePort=2379 or RemotePort=9200 or RemotePort=8188
   or RemotePort=11434 or RemotePort=5678 or RemotePort=7860 or RemotePort=8265
   or RemotePort=8848 or RemotePort=2718 or RemotePort=23
| FileName!=/^(nmap|masscan|zmap|nessusd|zabbix_agentd|telegraf|prometheus|consul)$/i
| groupBy([aid, ComputerName, FileName], function=[count(field=RemoteAddressIP4, distinct=true, as=distinct_targets), count(field=RemotePort, distinct=true, as=distinct_ports)])
| distinct_targets >= 50
| sort(field=distinct_targets, order=desc, limit=200)

Looks for: the family's own branding and protocol strings on a command line — n4d mesh controller, the X-Mesh-Auth / X-Operator-Key headers, and the n4d_panel cookie name. Catches manual operator interaction, script-based beaconing, and analyst-facing artifacts. FP: low — these strings are essentially unique. CONF: medium only because the compiled Go agent sets these headers internally, where a command line will never see them; this fires on the shell-script and hands-on-keyboard portions of the chain.

// HUNT: NadMesh controller branding and protocol strings on a command line
// MITRE: T1071.001
// CONF: medium  FP: low  COST: low
// REQUIRES: Falcon Linux sensor process telemetry
// FALSE POSITIVES: none expected — strings are campaign-unique
// NOTE: the Go agent sets X-Mesh-Auth internally; this only catches the shell-script and
//   hands-on-keyboard portions. Proxy header logging is the complete control (see s15).
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| CommandLine=/(n4d[\s_-]?mesh|n4d_panel|X-Mesh-Auth|X-Operator-Key)/i
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine, ParentBaseFileName, GrandparentBaseFileName], limit=200)

Looks for: the #1 NadMesh exploitation vector — Docker containers API RCE at 30.31% of observed traffic — plus the escape primitives it leads to: remote Docker daemon targeting via -H tcp://…:2375, privileged containers, host-PID/host-network, and a hostPath mount of /. FP: medium. Legitimate platform tooling does run privileged containers and mount host paths (monitoring agents, CSI drivers, node-exporters are the usual offenders). The high-signal combination is a remote Docker host flag on a machine that is not a CI runner.

// HUNT: Docker API abuse and container escape primitives (NadMesh top vector, 30.31%)
// MITRE: T1610, T1611, T1552.007
// CONF: high  FP: medium  COST: medium
// REQUIRES: Falcon Linux sensor process telemetry (host-level; container sensor preferred)
// FALSE POSITIVES: monitoring/CSI/node-exporter DaemonSets legitimately run privileged and
//   mount host paths; CI runners legitimately target remote Docker daemons.
// TUNING: exclude CI-runner aids and known platform DaemonSet images; alert first on the
//   remote-daemon clause (-H tcp) seen on a non-CI host.
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| CommandLine=/\b(docker|ctr|crictl|nerdctl|kubectl)\b/i
| CommandLine=/(-H\s+tcp:|--host\s+tcp:|:2375|:2376|--privileged|--pid=host|--net(work)?=host|-v\s+\/:|--volume\s+\/:|\/var\/run\/docker\.sock)/i
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine, ParentBaseFileName, GrandparentBaseFileName], limit=200)