godhive: A Novel Rust Crypto-Stealer and Miner Framework

TLP:CLEAR. Cleared for public release. Captured by the Kinryū Labs honeypot sensor network. Indicators below are defanged.

Executive summary

• 6,946Docker-API events in one automated burst
• 946Rust source modules in the binary
• 8+blockchains its wallet-drainer targets
• 9command-channel types

godhive is a Rust-compiled worm, crypto-stealer, and miner framework that reached our honeypot network through an exposed Docker Remote API. A single operator ran a high-volume, automated campaign against the Docker honeypot, and the tooling self-reported an end-to-end compromise 21 times. Kinryū Labs assesses with high confidence that godhive is purpose-built crimeware rather than a commodity miner: it carries its own brand, its name is absent from public threat intelligence, and the recovered binary contains 946 distinct Rust source modules and months of development.

The operator never fetched the framework from a URL. They base64-printf-ed the ELF into a container inline, chunk by chunk. Because the honeypot logged every chunk, we reconstructed the binary in full from our own capture: 215 chunks reassembled into a 6.2 MB x86-64 ELF (SHA-256 4194f2337c2b261ed6e1fd0b6d18f0ba75388bdc91a2658eb827a154ed784f36), which is not present on VirusTotal.

The distinguishing finding is that godhive is not primarily a miner. Mining is its fallback. Its main business is theft: automated withdrawals across six major exchanges and fund-sweeping across more than eight blockchains, with Monero mining only when no wallets are found.

Delivery: an exposed Docker API

The entry point is the oldest one in the container world: an unauthenticated Docker Remote API on TCP/2375. From there the chain is textbook host takeover, drawn from the captured docker_* events.

The operator creates a container from alpine:latest that is privileged: true, uses network_mode: host, and bind-mounts the entire host filesystem read-write (/:/host:rw). That single container configuration is the escape: mounting host root into a privileged container is root-equivalent control of the machine. It then clears rival miners (pkill -9 xmrig; pkill -9 lolMiner; pkill -9 minerd; pkill -9 godhive_c2), writes its persistence directory into the host at /etc/godhive, and reads host secrets straight through the mount, dumping /etc/shadow and /root/.ssh/authorized_keys.

Only then does the recognisable cryptojacking appear. godhive fetches an XMRig build from an anonymous file host, deploys it, opens an ngrok tunnel for out-of-band access, and posts results to a Telegram bot. It finishes by querying the cloud-metadata service (169.254.169.254) for credentials and probing for Kubernetes, Elasticsearch, and Kibana to broaden reach. The operator’s own tooling logged docker_attack_chain_complete 21 times against our sensor.

The mining is the least of it

The recovered binary is much bigger than the chain we watched run. Its 946 Rust modules and their build strings lay out a broad offensive toolkit. Some of it is backed by compiled code (duplicated literals from Rust monomorphisation, error-handling paths, and crate build directories); other parts are only module names and configuration stubs, so read the list below as intent as much as proven function.

The monetisation pipeline is the core. A harvester walks the filesystem for wallet.dat, .env, SSH keys, and wp-config.php; a scorer prices BTC, XMR, ETH, and Ravencoin against CoinGecko and ranks victims by value; a credential stage stuffs stolen logins with 2CAPTCHA integration to defeat login challenges; and a drainer pulls funds through the CCXT exchange library and on-chain DeFi sweeps, deriving keys from stolen seed phrases and choosing the cheapest chain for each withdrawal. A developer comment left in the binary optimises stablecoin withdrawals to avoid Ethereum gas fees, which is the level of care that separates a working drainer from a proof of concept.

Around that core sits the rest of the kit: a worm that scans with Masscan and Nuclei and exploits Docker, Redis, Kubernetes, Elasticsearch, WordPress, and a set of Windows and Java vulnerabilities including Log4Shell; an EDR killer targeting nine endpoint vendors by process name; five layers of persistence up to a UEFI bootkit with TPM manipulation; a WASM plugin system for pushing new capabilities to the fleet without touching the C2; ransomware gated to fire only above a 1,000 US dollar value threshold; a clipboard hijacker; a DDoS module; and anti-forensics that deletes wtmp, btmp, and journal logs and plants fake syslog noise to waste an analyst’s time. It masquerades every module under a fake sysd process name, and it disguises its own traffic as YouTube streaming by borrowing real googlevideo.com SNI hostnames.

Two details temper the picture. The framework detects fifteen honeypot platforms and a rack of sandboxes and hypervisors, yet it missed ours. And several of its configurations are unfinished: the default mining pool shut down in 2022, a clipboard ENS name was never registered, and an encryption key is still a CHANGE_ME placeholder. The capability is compiled and real; parts of it are not yet wired up.

ngrok, and why it is a hacktool

The sample that first flagged this campaign is the legitimate, signed ngrok binary, pulled from ngrok’s own CDN. It is not malware. It is a commercial reverse-tunnelling tool, and antivirus engines label it a hacktool precisely because it is so useful after a compromise. Once godhive has code execution inside a privileged container, ngrok dials out to ngrok’s cloud and exposes a chosen local service through a public URL, with no inbound port opened and nothing for a perimeter firewall or egress-only NAT to stop. The operator confirmed the tunnel by polling ngrok’s local agent API (127.0.0.1:4040/api/tunnels) and shipped the resulting public URL to their Telegram bot, turning every freshly-owned host into a click-to-connect handle.

A command channel built to survive takedown

godhive does not rely on a single C2. It stacks channels in order of how hard each is to remove. At the bottom is a peer-to-peer Kademlia mesh with proof-of-work join challenges and NAT traversal, which has no central point to seize. Above it sits EtherHiding, where the current backend address is stored in a blockchain smart contract that cannot be revoked, resolved at runtime through a live Cloudflare Workers relay (c2-proxy.operator.workers[.]dev) that hides the backend from defenders. Above that are algorithmically generated backup domains fetched over DNS-over-HTTPS with spoofed SNI, a Tor hidden service, dead-drops in GitHub gists, eight software-as-a-service channels, and Telegram as the primary operator channel. Burn detection watches for a run of empty command polls and automatically migrates the operator to fresh infrastructure with an encrypted config backup, and a federation feature supports coordination across multiple bots.

We fingerprinted the Cloudflare Workers relay externally and confirmed it is live and processing requests: registration, task-dispatch, and dashboard endpoints route to a backend, while unauthenticated input is rejected, consistent with the AEAD-encrypted tokens the binary uses for C2 authentication. The operator also runs a hardened admin dashboard behind it, with Argon2 password hashing, multi-factor authentication, role-based access, and even post-quantum options in its TLS configuration. This is someone treating a botnet as production infrastructure, down to exporting Prometheus metrics for it.

The other half: amateur operations

For all that engineering, the deployment is careless in ways that matter. The campaign came from a single United States Verizon Wireless consumer mobile connection (174.230.35[.]232, reverse DNS 232.sub-174-230-35.myvzw.com, Gainesville, Florida), not a bulletproof host or a VPS, in a tight automated burst with no infrastructure reuse. The Telegram bot token is hardcoded in plaintext, a single point of takedown. The XMRig payload was served from a public anonymous file host. And the framework ran its entire chain against a honeypot while carrying a module whose whole job is to detect honeypots.

The binary was built on macOS, under a user named dev, in a directory called research/godhive. Read alongside the deliberate anonymisation of the operator’s Telegram identity, the unfinished configurations, and the self-attributing deployment, the most economical reading is a skilled solo developer testing and running their own framework rather than a customer of a malware-as-a-service platform. The brand is polished, with a custom golden-hive logo and the tagline “one mind, one purpose, one hive”; the operations are not.

Attribution

The campaign ties to a single operator through their Telegram infrastructure. godhive ships stolen credentials, tunnel URLs, and infection confirmations to a hardcoded bot, @godhive_bot (bot id 8836117161). Its captured chat_id resolves to a personal account, @godhive77 (user id 7659611777), with underscores for a display name and no profile photo, an attempt at anonymity that the godhive77 handle itself undoes. The same operator holds a matching reservation channel, @godhive (one subscriber, no public posts, forwarding disabled), and the sequential Telegram user id dates the account to late 2024. The godhive77 handle is the strongest pivot for further attribution.

Indicators of compromise

Attacker infrastructure is defanged. Legitimate third-party services the malware abuses are left intact for detection.

Network and host

Indicator	Context
c2-proxy.operator.workers[.]dev	Live Cloudflare Workers C2 relay (report to Cloudflare)
hxxps://files.catbox.moe/p46h39.gz	XMRig payload on an anonymous file host (SHA-256 cb49ae0793b2…)
bin.equinox.io/c/.../ngrok-v3-stable-linux-amd64.tgz	ngrok download (legitimate CDN); egress to bin.equinox.io from a server is the signal
127.0.0.1:4040/api/tunnels	ngrok local agent poll (reads the assigned public tunnel URL)
169.254.169.254/latest/meta-data/	Cloud-metadata SSRF for credential theft
api.telegram.org	Telegram bot C2 and exfiltration; egress from server workloads is the hunt signal
gitlab.com/nzyme/	Static tool staging (sshpass, redis-cli, wget, tor, proxychains)
2captcha.com, hashes.org, nitrxgen.net	CAPTCHA solving and hash-cracking services abused in the credential pipeline
r[1-20]---sn-*.googlevideo.com, manifest.googlevideo.com	Real YouTube CDN hostnames used for TLS SNI spoofing; alert when they resolve to non-Google IPs

Actor, C2 identity, and payout

Indicator	Context
174.230.35[.]232	Campaign source (Verizon Wireless mobile, 232.sub-174-230-35.myvzw.com, Gainesville FL); a dynamic carrier address with low blocking value
@godhive_bot (Telegram bot id 8836117161)	Malware C2 and exfiltration bot; token hardcoded in the binary (secret redacted here; reported to Telegram for takedown)
@godhive77 (Telegram user id 7659611777)	Operator’s exfiltration account and strongest attribution pivot
@godhive (Telegram channel id -1002105830453)	Operator’s reservation channel
49aXwwgXBKRKTUVgYuLy3fZkTeLP3PWgMhwiyK55Ur7WhgYXJ33N8JZG87vzUV1UyVdZzPGLvx1w9YQHk7faWPn1UzJte2R	Confirmed Monero payout wallet (paired with the live XMRig config)
pool.minexmr.com:4444	XMRig config pool; note minexmr shut down in 2022, so this default would fail

Files and artefacts

• godhive binary (reconstructed): SHA-256 4194f2337c2b261ed6e1fd0b6d18f0ba75388bdc91a2658eb827a154ed784f36 (6.2 MB x86-64 ELF, not on VirusTotal). Its ELF headers are deliberately corrupted to claim ~106 MB and point code past the file end, defeating standard tools.
• Host persistence: /etc/godhive, /host/usr/local/bin/sysd (fake-systemd binary), /host/tmp/godhive_deployed.txt, process godhive_c2, custom in-container image godhive:latest.
• Container escape signature: a container created with Privileged:true, network_mode:host, and a /:/host:rw bind.
• Build artefact: cargo paths under /Users/dev/.cargo/registry/src/ and a research/godhive build directory (macOS developer).
• Host hardening tell: Redis password set to CHANGED_BY_GODHIVE; a b374k.php webshell on hosts where WordPress brute-force was seen.

Behavioural

• pkill -9 xmrig|lolMiner|minerd|godhive_c2 followed by mkdir /host/etc/godhive.
• Reads of /host/etc/shadow and /host/root/.ssh/authorized_keys from a container mount.
• A sysd process that is not the real systemd; efibootmgr writes creating an EFI boot entry labelled “System Core”.
• Nuclei working directory /tmp/.nuclei_assault-t*.

Detection

• Alert on outbound bin.equinox.io and any *.ngrok* host from servers, and on the ngrok agent API poll 127.0.0.1:4040/api/tunnels.
• Alert on any container created with Privileged:true and a /:/host bind; that pairing is a near-certain escape attempt.
• Alert on egress to api.telegram.org, c2-proxy.operator.workers[.]dev, gitlab.com/nzyme/, 2captcha.com, and hash-cracking services from server workloads.
• Alert on a sysd process, on EDR agents being killed or stopped (falcon-sensor, SentinelOne, cbdefense, sophos-edr, cylancesvc), and on CONFIG SET requirepass CHANGED_BY_GODHIVE.
• Treat TLS with googlevideo.com SNI that resolves to non-Google IPs, and manifest.googlevideo.com from non-browser processes, as traffic-shaping.

Mitigation

• Never expose the Docker API on 2375 unauthenticated. Bind it to localhost with TLS client authentication. This is the root cause.
• Enforce no-new-privileges, drop --privileged, and restrict host bind mounts, or run rootless Docker or gVisor.
• Block the cloud-metadata service (169.254.169.254) from containers and require IMDSv2.
• Filter egress: server workloads should not reach anonymous file hosts, ngrok, Telegram, CAPTCHA solvers, or the static-tool staging paths above.
• Enable Secure Boot to blunt the UEFI persistence, and enable tamper protection on endpoint agents, which godhive tries to kill.
• If any host may have been compromised, rotate exchange API keys immediately; godhive automates withdrawals.

MITRE ATT&CK mapping

Tactic	Technique
Initial Access	T1190 Exploit Public-Facing Application (Docker API; Redis, Kubernetes, WordPress, Log4Shell in the arsenal)
Execution	T1610 Deploy Container; T1059.004 Unix Shell
Privilege Escalation	T1611 Escape to Host (privileged container, host mount)
Persistence	T1543 Create or Modify System Process (sysd); T1542.003 Bootkit (UEFI); T1014 Rootkit
Defense Evasion	T1562.001 Impair Defenses (EDR killer); T1070 Indicator Removal (log deletion); T1497 Virtualization/Sandbox Evasion (honeypot/VM detection); T1036 Masquerading (sysd, YouTube SNI); T1027 Obfuscated Files (corrupted ELF)
Credential Access	T1003.008 /etc/passwd and /etc/shadow; T1552.004 Private Keys; T1552.005 Cloud Instance Metadata API
Discovery	T1046 Network Service Scanning (Masscan, Nuclei)
Command and Control	T1572 Protocol Tunneling (ngrok); T1090 Proxy; T1071.001 Web Protocols (Telegram, Cloudflare Workers); T1102 Web Service (GitHub gists, SaaS channels)
Impact	T1496 Resource Hijacking (XMRig); T1486 Data Encrypted for Impact (ransomware); T1657 Financial Theft (exchange and DeFi draining); T1498 Network Denial of Service

Methodology and notes

• Analysis is static binary analysis of the ELF, which was reconstructed in full from the operator’s own inline base64 chunks captured by the honeypot, together with review of the captured Docker-API traffic and authorised external reconnaissance of the operator’s live Cloudflare Workers relay. No malware was executed and no C2 authentication was attempted.
• Indicators are defanged, and legitimate third-party services the malware abuses are left intact for detection.
• Samples are available to other researchers and defenders on request. Email [email protected] with a short note on who you are and what you need them for.