xlabs_v1 DDoS-for-Hire IoT Botnet Exposed: One Operator Error. An Entire Operation Revealed

During routine monitoring of bulletproof-hosting netblocks in early April 2026, our open directory intelligence tool AttackCapture™ flagged an exposed directory on a Netherlands-hosted server at 176.65[.]139.44 The operator left their full toolkit publicly accessible on TCP/80 with no authentication required, and we had it indexed before they knew anyone was looking.

What followed was a full reconstruction of the operation from the captured files: two ELF binaries, infection payloads, proxy credentials, and a target placeholder. The production ARM32 binary was UPX-packed and stripped. The development build wasn't. Cross-referencing both, recovering the ChaCha20 string table through known-plaintext analysis, and mapping the wire protocol gave us a complete picture of how xlabs_v1 operates, what it targets, the infrastructure behind it, and who is running it.

Key Findings

• Mirai-derived botnet, self-branded xlabs_v1, operated by Tadashi, sold as a DDoS-for-hire service targeting game servers and Minecraft hosts with bandwidth-tiered pricing.

• 21 flood variants across TCP, UDP, and raw protocols, including RakNet and OpenVPN-shaped UDP, capable of bypassing consumer-grade DDoS protection.

• Infection vector is Android Debug Bridge on TCP/5555, with multi-architecture builds covering ARM, MIPS, x86-64, ARC, and Android APK, meaning any internet-exposed device running ADB is a potential target: Android TV boxes, set-top boxes, smart TVs, residential routers, and any IoT-grade hardware shipping with ADB enabled by default.

• Bandwidth profiling via 8,192 parallel sockets used to price-tier each compromised device by upstream capacity.

• ChaCha20 string table with weak key and full nonce reuse, recovered from a single known plaintext, exposing C2 domain, operator handle, and authentication token.

• Full operation consolidated within a single bulletproof /24 (Offshore LC, AS214472, Netherlands), including C2, distribution, staging, and co-located Monero cryptojacking infrastructure.

Here's what we found.

Starting Point of the Research

Our investigation began with the discovery of an Attack Capture File Manager web interface exposed on TCP/80 of 176.65.139[.]44, a host announced by Offshore LC out of the Netherlands, showing clear signs of a Mirai botnet activity.

The interface presented a directory listing rather than a login page, immediately revealing a six-file toolkit and inviting closer inspection. The listing showed both raw binary artifacts and supporting plain-text files, with no authentication required to retrieve any of them.

Our platform shows included file sizes, modification dates, and an automated tagging column. Two of the files were tagged as malware artifacts in the panel itself: arm7 was flagged as Mirai, and payloads.txt was flagged as Exploit and ext mismatch.

The presence of operator-side automatic tagging on a public-facing directory is itself a tradecraft observation: the operator is using analyst-grade tooling on a host that has not been hardened against analysts.

Direct file enumeration produced a six-entry inventory totalling roughly two hundred kilobytes. The captured set comprised arm7 (the production ARM32 bot, 68 KB UPX-packed), debug.o2 (a non-stripped x86-64 development build of the same source tree, 88 KB), payloads.txt (nine ADB-targeted infection one-liners, 868 bytes), proxies.txt (a single SOCKS5 URL with embedded credentials, 60 bytes), and targets.txt (a nine-byte placeholder containing only the literal string 00.00.0.0). We generated arm7.unpacked locally during analysis by running UPX 4.2.4 against the original arm7.

With the toolkit retrieved, we moved to static analysis. The unstripped debug.o2 build had function names, source-file references, and printf calls intact, making it straightforward to reconstruct the production ARM7 behavior.

Inside the Bot

The xlabs_v1 codebase reads as a focused commercial product rather than an opportunistic Mirai derivative. Its twenty-one flood variants, ChaCha20 string protection, OpenNIC-aware DNS resolution, and Speedtest-driven bandwidth profiling are subsystems aimed at a single outcome: keeping a fleet of compromised IoT devices reachable, accountable, and profitable for the operator. Everything else in the binary serves that goal or protects it.

Operational Goals

The bot has one primary commercial goal and several supporting goals that all serve it. A botnet operator selling DDoS doesn't bolt on credential theft or cryptojacking. Those features add detection risk without adding revenue. A skilled botnet operator selling DDoS does not bolt on credential theft or cryptojacking, because those features increase detection risk without serving the primary revenue stream.

The bot is purpose-built to receive an attack command from the operator's panel and produce flood traffic on demand. Twenty-one flood variants are registered into a single dispatch table at the attack-registry initializer, and every other behavior in the binary serves this engine.

The function pointer plus attack-ID pattern allows the operator's panel to dispatch attacks by integer ID without binding the panel to specific function names. This indirection makes attack-set evolution between builds straightforward, and it is the architectural reason the production arm7 carries six new attack IDs (3, 17, 21, 22, 23, 24) that are absent from the development build.

The attack repertoire targets game servers specifically: a RakNet flood variant hits Minecraft via the RakNet protocol, a UDP variant shapes outbound packets to mimic OpenVPN traffic and bypass OpenVPN-aware filters, and a raw-TCP variant uses HTTP request templates to defeat L7 anti-DDoS protection. The distribution server even exposes the bot binary on TCP/25565, the default Minecraft port.

The bot is statically-linked ARMv7, runs on stripped Android firmwares, and is delivered through ADB-shell pastes into /data/local/tmp. The operator's nine-variant payload list is tuned for Android TV boxes, set-top boxes, smart TVs, and IoT-grade ARM hardware that ships with ADB enabled.

To put that exposure surface in perspective, we queried Hunt.io for internet-exposed hosts with TCP/5555 open. The results returned over 4 million hosts observed in the past 180 days. Not all of them run ADB, but any that do are a potential target for this infection chain.

SELECT ip, port, timestamp
FROM httpv2
WHERE port == 5555
AND timestamp > NOW - 180 DAY
GROUP BY ip, port, timestamp
ORDER BY timestamp DESC

                
Copy

Output:

With the infection surface mapped, we turned to the binaries themselves to understand how xlabs_v1 behaves once it lands on a device.

The deca string passed as argv[1] by the netcat-based payload variants is captured into an internal thirty-two-byte ID buffer and then overwritten with zeros in the original argument vector. From this point forward, ps aux and /proc/<pid>/cmdline will not reveal the infection-vector tag, but the C2 panel still receives it in the registration handshake.

The bandwidth-profiling routine opens 8,192 parallel TCP sockets to the geographically nearest Speedtest server, saturates them for ten seconds, and reports the measured Mbps back to the panel. The only commercial reason to measure per-bot bandwidth this carefully is to price-tier the fleet for DDoS-for-hire customers.

The panel uses the resulting Mbps figure to assign each bot to a pricing tier. A 500-Mbps fiber-connected Android TV box is sold at a different rate from a 20-Mbps DSL victim. This is product-management code, not security or evasion code, and its presence is direct evidence that xlabs_v1 is a commercial operation.

The killer subsystem walks /proc/, identifies non-whitelisted processes holding socket file descriptors, and SIGSTOPs then SIGKILLs them. A separate routine evicts a hard-coded rival-bot port (TCP/24936). The reason is commercial: two coexisting botnets share the host's upstream bandwidth, so killing competitors guarantees the bot delivers its full bandwidth quota to whichever attack the operator orders.

Killing competitors is also a market-positioning move. The hard-coded port 24936 in particular indicates a specific known-rival-bot signature; the operator did not invent that port, the rival uses it. Defenders who observe a sudden disappearance of a TCP/24936-bound process on a recently active host should correlate with prior process listings to identify which competitor was displaced.

The C2 domain is resolved first via OpenNIC root nameservers, which still serve .lol when ICANN resolution is blocked, and only via the system resolver as a fallback. If outbound C2 fails, the bot falls through to a SOCKS-style fallback listener on TCP/26721 protected by a five-variant iptables ACCEPT punch.

Together, these mechanisms give the operator two redundancy layers. If a registrar suspends xlabslover[.]lol, OpenNIC roots may still resolve it. If the C2 IP itself becomes unreachable, the inbound fallback listener on TCP/26721 turns every still-alive bot into a reachable SOCKS endpoint that the operator can connect to from any IP.

The bot zeroes argv[1] after capturing the infection-vector tag, masquerades as /bin/bash via a prctl call to set the kernel comm field, daemonizes through setsid plus close(0/1/2), and ignores SIGCHLD so workers auto-reap. None of this defeats security software; it defeats casual administrative inspection, which is enough to keep the bot alive long enough to amortize the operator's infection cost.

The masquerade choice (specifically /bin/bash) is well-judged. Almost every Linux-derivative system has a legitimate /bin/bash process at any given time, and any administrator running ps without specific filters will see the masqueraded bot blend into a list of legitimate shells. The bot also carries a development banner string that prints to stdout immediately before the close(0/1/2) sequence; in production, this banner is unreachable, but in interactive runs (such as during operator testing), it surfaces and reveals the operator's active rivalry with a fork called xlab 2.

Bootstrap and Process Masquerade

Once the loader has dropped the bot into /data/local/tmp/arm7 and invoked it, control reaches the bot's main routine via the ELF entry stub. The first instruction blocks SIGINT through the standard sigemptyset / sigaddset / sigprocmask sequence so that the launching shell cannot Ctrl-C the process before daemonization completes. The bot then captures argv[1] into a thirty-two-byte ID buffer, zeroes the original argv[1] in place, and proceeds to the cryptographic-table initialization that brings every sensitive string into memory.

Below the cryptographic step, the bot seeds its pseudo-random-number-generator state, then executes the masquerade and daemonization sequence: argv[0] is overwritten with the decrypted /bin/bash, a prctl call to set the kernel comm field updates the kernel's comm field, the development banner is written to stdout, the SIGCHLD ignore installs a child auto-reap, setsid detaches from the controlling TTY, and close(0/1/2) closes standard input, output, and error. From this point onward, the process appears as /bin/bash with no parent shell and produces no observable output.

The string-table initializer runs before the masquerade, which means the strings exist in plaintext in memory before the process becomes invisible to ps. A defender capable of dumping the bot's memory immediately after spawning can therefore recover the C2 domain and authentication token without solving the cipher. The same memory contents persist for the lifetime of the process, but the process is now harder to find.

ChaCha20 String-Table Decryption

Sensitive strings are stored encrypted in .rodata and decrypted on startup by the string-table initializer at 0xE240. The cipher is standard twenty-round ChaCha20 with the literal sigma constants expand 32-byte k, confirmed by the column and diagonal quarter-round index pattern. The thirty-two-byte key at 0x37744 has only five effective bits per byte, with every byte less than or equal to 0x1F, which is structurally inconsistent with cryptographically random key material.

The same key, the twelve-byte nonce at 0x37764, and the counter value of one are reused across all sixteen decryption calls. Because each blob is shorter than the sixty-four-byte ChaCha20 block, every call processes only the first N bytes of the same keystream. This is a textbook key-reuse pattern and means the keystream prefix is recoverable from any single known plaintext. For our analysis, the known string /proc/ at one of the table positions was used to recover the leading bytes of the keystream, which then trivially decrypted every other blob in the table.

Decryption of all sixteen blobs yields the C2 domain xlabslover[.]lol, the agent tag xlabs_v1, the operator handle Tadashi, the authentication token 3Wb5WfDEblAOkD0xF3OTPmxWe6cmsR, the development banner (a profanity-laden message naming a rival fork as xlab 2 and including a racial slur), the /bin/bash masquerade name, and ten /proc-related path components used by the killer subsystem. A self-contained Python implementation of the decryption procedure is provided in the appendix of this report.

Recovered Identifiers and Branding

The decrypted string table yields a coherent picture of the operator's self-identification. The botnet brand is xlabs_v1, the literal value transmitted in every C2 registration handshake as the agent tag. The trailing v1 suggests the operator anticipates future versions, and analysts should expect xlabs_v2 or similar tags to appear in future captures of new builds. The operator handle is Tadashi, a common Japanese given name; no claim about actual nationality should be drawn from this name alone, since botnet operators routinely select handles from East Asian, Latin, or fictional sources for marketing purposes regardless of their real identity.

The thirty-character authentication token 3Wb5WfDEblAOkD0xF3OTPmxWe6cmsR is a per-build secret embedded into the bot at compile time and emitted on the wire during C2 registration. It serves the operator's panel as a build-authentication mechanism, ensuring that only bots compiled from the operator's build chain are accepted by the panel. From a defender's perspective, the token is a high-specificity IDS signature: any TCP stream containing this exact thirty-byte sequence within the first hundred bytes after a TCP handshake is near-certainly an xlabs_v1 bot registration.

The internal codename aterna is visible only in the development build. It does not appear on the wire and is not present in the production arm7 image. The codename is purely a developer-facing identifier; analysts encountering aterna in any code, logs, or chat snippets should treat it as a strong correlation signal to this same source-code family. The pair (xlabs, aterna) is the operator's public/private brand split.

Competitor Eradication

Before establishing C2 communication, the bot eliminates competing malware from the host. The killer subsystem walks /proc/, filters on PID directories, readlinks /proc/<PID>/exe to obtain executable paths, and opens /proc/<PID>/fd/ to find socket descriptors. Suspicious processes that hold an open socket are added to a singly-linked list, SIGSTOPed immediately to freeze them before they can react, and SIGKILLed on a second pass.

Separately, the rival-port-eviction routine runs once at startup and targets TCP port 24936 specifically. The routine parses /proc/net/tcp to find the inode bound to that port, walks /proc/<PID>/fd/ to identify the owning PID, and SIGKILLs it. Port 24936 is the hard-coded bind port of a specific competitor bot. Its inclusion in the killer routine indicates either a recent operator skirmish or a long-standing rivalry, and defenders observing this port disappearing from a host shortly after an xlabs_v1 infection should correlate with prior process listings to identify which competitor was displaced.

Persistence and Operator Re-Entry

Persistence in this family is implemented entirely as a fallback re-entry mechanism rather than a boot-time relaunch hook. The bot does not write itself to disk persistence locations, does not modify init scripts, does not create systemd units, and does not register cron jobs; instead, it relies on the operator's ability to re-infect the same host through ADB exploitation if the bot process dies. The fallback re-entry mechanism becomes important only when the bot is alive but cannot reach its outbound C2 channel.

If the C2 connection cannot be established or drops, the fallback-listener routine runs five iptables variants with -A INPUT --dport 26721 -j ACCEPT across all common iptables binary paths (plain, /bin/iptables, /usr/bin/iptables, /bin/busybox iptables, busybox iptables). At least one variant succeeds on every plausibly stripped firmware. The routine then calls socket/bind / listen on TCP 0x6861 (26721). The accept loop spawns a per-connection worker thread implementing a SOCKS5-like protocol plus the same command-dispatcher used for the outbound C2 channel, giving the operator inbound re-entry on hosts whose outbound traffic to xlabslover[.]lol is filtered.

Attack Registry

On startup, the attack-registry initializer populates a global attack registry with twenty-one entries, each a struct of (function pointer, attack ID byte). The C2 dispatches incoming attack commands by indexing this registry on the opcode byte. Cross-referencing the arm7 production registry against the symbol-named flood functions in debug.o2 yields a complete name-to-ID mapping for fifteen of the variants, with six additional variants present only in the production build, indicating post-development-build feature additions.

The named variants cover TCP SYN derivatives (ACK, ACK-Stomp, SYN-with-data, Brazilian-handshake, socket exhaustion, Slowloris-style holding, raw flexible-flag, HTTP-template bypass), UDP variants (plain, raw with spoofed source, OpenVPN-shaped, anti-mitigation bypass, Mirai STD, RakNet for Minecraft DDoS), and the GRE-IP raw flood. The presence of a RakNet flood variant combined with the operator's distribution server exposing the bot binary on TCP/25565 (the default Minecraft port) strongly suggests game-server DDoS-for-hire is the primary commercial product.

On any attack opcode, the bot's attack dispatcher parses the target list and parameter TLVs, looks up the matching flood function in the registry by attack ID, and spawns up to sixteen pthread workers via thread spawning. Each worker runs the flood function with the parsed context, opening its own raw socket or epoll set and emitting packets at the maximum rate the host's network stack and bandwidth allow. After the operator-specified duration elapses, the main thread issues thread teardown to every worker, and the attack ends.

Bandwidth Profiling

Triggered by C2 opcode 0xFC, the bandwidth-profiling routine measures the victim's upstream bandwidth and reports the result to the panel. The routine fetches speedtest-config.php from www[.]speedtest[.]net to obtain the victim's latitude, longitude, and public IP, then fetches speedtest-servers-static.php from c[.]speedtest[.]net and parses every server entry, computing the haversine great-circle distance from the victim's coordinates to each server. The bot selects the geographically nearest endpoint, opens 8,192 parallel TCP sockets to it, and streams a 128-kilobyte random POST body through every socket for up to ten seconds.

The bot then sums the bytes successfully written, converts to megabits-per-second, sends the result to C2 as a length-prefixed ASCII string, and exits. The exit step is significant: a bandwidth probe causes the bot to terminate, not merely report. The operator's loader must re-infect the host before the bot becomes available for attacks again. This design suggests the operator views bandwidth probing as an infrequent fleet-tier-update operation rather than a per-attack pre-flight check, and the resulting exit-and-re-infect cycle is the design intent. The 8,192 parallel sockets sustained for ten seconds also constitute a brief denial-of-service against the chosen Speedtest endpoint, particularly when fleet-wide opcode 0xFC is broadcast simultaneously.

Command-and-Control Protocol

The C2 channel uses a plaintext-framed binary protocol over TCP/35342 with selective wire-field encryption. There is no TLS layer; cryptography in this family is reserved for the embedded string table and for specific handshake fields, not for the transport itself. The framing layer is a two-byte big-endian length prefix followed by exactly that many bytes of payload. The bot reads the length, byteswaps to host order, validates that the value is between one and 0x2000, and then reads the indicated number of bytes into a static receive buffer.

On successful connection, the bot resolves to xlabslover[.]lol via a randomly selected OpenNIC root nameserver from a hardcoded ten-IP table, falling back to the system resolver if all OpenNIC queries fail. The bot then emits an eight-chunk registration handshake including the four-byte magic word, the bot hostname, the agent tag xlabs_v1, the CPU count, and RAM size as ASCII decimal strings, the thirty-two-byte ID buffer carrying the infection-vector tag, and the per-build authentication token.

Three of the chunks (uptime, RAM-MB, infection-vector ID) are individually ChaCha20-encrypted using the second key/nonce pair at 0x376C4 and 0x376E4. Every six idle iterations afterward, a two-byte zero keep-alive flows outbound to defeat NAT timeouts.

Opcode dispatch: 0xFC triggers bandwidth probe and exit (see section 4.15); 0xFD walks the parameter list looking for ID 29, treats its value as a URL, builds wget <url> -O /tmp/.upd && chmod +x /tmp/.upd && /tmp/.upd, runs it via system(), and exits the current bot; 0xFE reads /proc/self/exe via readlink and re-execs the same path via execve, preserving the PID but regenerating internal state. Any other opcode is treated as an attack ID and dispatched through the per-attack worker spawner.

Network errors during the command loop trigger reconnection through the resolver-and-connect path, with exponential backoff on consecutive failures. After nine failures, the bot calls a reset helper and re-resolves the C2 domain. If reconnection cannot be re-established at all, the bot falls through to the fallback-listener routine described in the Persistence and Operator Re-Entry subsection above.

With the bot's internal behavior fully characterized through static analysis, we turned to the indicators recovered from the malware itself to hunt the operator's externally visible infrastructure. The pivot chain begins with the C2 domain embedded in the decrypted string table and expands outward through IP resolution, SSL certificate history, netblock enumeration, and open-directory captures on adjacent hosts. All queries in this section were performed through Hunt.io.

Infrastructure Analysis

The first pivot is the C2 domain xlabslover[.]lol, recovered from the ChaCha20-encrypted string table at index 3. Querying the domain on Hunt.io returns a sparse but structurally informative profile (Figure 15). The domain resolves to a single A record at 176.65.139[.]134, with nameservice delegated entirely to Ultahost infrastructure (ns1--ns4.ultahost.com). No WHOIS registrar data is present, a common pattern for domains registered through privacy-shielded or bulletproof-friendly registrars. At the time of our query, the domain carried zero Hunt.io detections across C2/Malware, Phishing, URLs, Open Directory, and IOC categories, indicating the operator had not previously attracted automated detection against this domain.

The absence of historical detections is consistent with a relatively recently stood-up C2. The Ultahost delegation is notable: Ultahost is a bulletproof-friendly hosting provider whose nameservers are frequently observed in IoT botnet malicious infrastructure, and the choice of .lol as a TLD is consistent with the operator's informal branding style (xlabs, xlabslover).

Pivoting from the domain to its resolved A record, 176.65.139[.]134 is hosted by Offshore LC (Kerkrade, Limburg, Netherlands) under ASN AS214472 within the 176.65.139.0/24 prefix (Figure 16). Hunt.io records one associated domain, two signals, and thirteen available pivots for this IP. The only port visible in the current scan is TCP/22 (SSH), suggesting the C2 listener on TCP/35342 was not active or was filtered at the time of the Hunt.io crawl.

The Signals tab (Figure 17) shows that this IP was last observed hitting Hunt.io honeypots on 15 October 2025, approximately six months before our investigation. Two honeypot signal categories are recorded: HTTP crawler and ENV file crawler. The HTTP crawling behavior is consistent with reconnaissance activity; the ENV file crawling indicates the operator or a co-tenant on this host was scanning for exposed .env credential files. Portscans from this IP are marked as not potentially spoofed, meaning the activity originates from the host itself.

The SSL History tab for 176.65.139[.]134 (Figure 18) reveals three historical TLS certificates served from this IP across two ports. Two certificates on TCP/5986 carry the Subject Common Names "Cloudbase-Init WinRM" and "SERVER-SERVER", both consistent with Windows Remote Management infrastructure. The third, on TCP/3389 (RDP), carries the CN "Godisgood", an operator-chosen string with no standard software meaning. This certificate was active in May 2025, predating the April 2026 botnet capture by nearly a year, suggesting the operator has maintained a presence on this IP for an extended period.

We pivoted on the non-standard CN "Godisgood" using Hunt.io's Advanced Search with the query Certificates.SubjectCommonName:"Godisgood" (Figure 19). The search returns exactly two results: 176.65.139[.]134 on TCP/3389 (last seen October 2025) and 172.94.96[.]75 on TCP/3389 (last seen September 2025, hosted by Telchak Gold Ventures in Germany). The same self-signed RDP certificate appearing across two geographically distinct hosts operated by different providers is a strong indicator of the same actor managing both machines with a common certificate template or tool.

Querying 172.94.96[.]75 directly (Figure 20) shows it is hosted by GSL Networks Pty Ltd in Frankfurt, Germany (AS137409, 172.94.96.0/24). Unlike the Netherlands C2 IP, this host carries no associated domains and no Hunt.io signals, making it a lower-confidence but plausible operator-controlled asset linked solely through the shared certificate CN. We assess this host as a probable secondary management endpoint, a jump box or administrative workstation rather than an active C2 or distribution infrastructure.

All three operator-controlled IPs identified during the investigation 176.65.139[.]9 (distribution server), 176.65.139[.]42 (secondary distribution), and 176.65.139[.]44 (staging host) fall within the same /24 prefix as the C2 IP (176.65.139[.]134), all announced by AS214472 (Offshore LC). Querying this netblock on Hunt.io surfaces a grouped view of the three confirmed hosts (Figure 21), each carrying both C2/Malware History and Attack Capture History entries, confirming the operator consolidated the entire operation within a single bulletproof /24.

Expanding the C2/Malware History entry for 176.65.139[.]44 (Figure 22) shows a 95% confidence Mirai classification on TCP/80, with a first-seen timestamp of 2026-03-31 and a last-seen of 2026-04-01, precisely the window in which we captured the open directory. The classification subsystem is recorded as C2, meaning Hunt.io's crawler observed active Mirai C2 traffic or a Mirai-matching HTTP banner on this IP during that two-day window. The confidence score of 95 is near-certain, and the timing corroborates the April 2026 capture date of the arm7 production binary.

Open Directory Captures

Hunt.io's Attack Capture File Manager indexes open directories observed during active crawls and preserves their file listings, timestamps, and automated malware tags. Three open directories within the 176.65.139.0/24 netblock were captured, each corresponding to a distinct operator function.

The staging host at 176.65.139[.]44 (TCP/80) was captured on 2026-04-01 with six files totalling 188 KB (Figure 23). The listing exposes the complete operational toolkit: the production ARM32 binary arm7 (95 KB, tagged Mirai), the development build debug.o2 (88 KB), two payload files (payloads.txt tagged both ext mismatch and Exploit, payloads.txt.txt tagged Exploit), proxies.txt, and targets.txt (3 KB). The presence of both payload variants with an extension-mismatch tag suggests the operator renamed or reused files without updating extensions, a common tradecraft shortcut on self-managed staging hosts.

The distribution server at 176.65.139[.]42 on TCP/8080 was captured three days later, on 2026-04-04, with two shell scripts totalling 4 KB (Figure 24). Both files are infection delivery scripts: apt0.sh carries 12 malware-engine detections and dob.sh is tagged as Exploit with four engine detections. These scripts represent the active infection layer; they are the payloads delivered to vulnerable Android/IoT devices through the ADB exploitation chain that the arm7 binary initiates. The choice of TCP/8080 as the delivery port avoids the default port-80 crawl surface while remaining accessible to victim bots.

A second capture from 176.65.139[.]42, this time on TCP/80, dates to 2026-03-09, nearly four weeks before the staging host capture (Figure 25). This earlier snapshot reveals a /bins directory containing multi-architecture binaries: arm, arm5, arm6, arm7, m68k, mips, mipsel, ppc, alongside a shell script cool.sh. The multi-architecture payload set is a direct signature of Mirai-lineage botnets, which distribute architecture-specific builds to maximise infection coverage across heterogeneous IoT device populations. The presence of arm7 in both the March /bins listing and the April staging-host capture confirms the same binary version persisted across at least one month of active distribution.

With the bot's behavior fully characterized, we turned to the identifiers recovered from the string table to build a picture of the operator behind it.

Threat Actor

The infrastructure pivots gave us the footprint. The recovered identifiers gave us the operator. Here is what we know about the operator.

Operator Handle and Branding

The operator self-identifies as Tadashi, a value embedded as a ChaCha20-encrypted string in every build of the bot. The handle is not transmitted on the wire and is not used in C2 framing; it appears to function as an internal credit field, possibly displayed by the operator's panel as a vendor identifier.

The botnet itself is branded xlabs_v1, a wire-visible value sent during every C2 registration handshake. The trailing v1 implies version planning, and analysts should expect xlabs_v2 or similar tags to appear in future captures of new builds. The development build's log strings are prefixed with a different brand, aterna, suggesting the operator chose to rebrand for marketing purposes between development and release.

Searching underground markets for the conjunction of Tadashi, xlabs, and xlabslover should locate the operator's public seller storefront if one exists. Such storefronts in this period typically appear on hackforums, XSS, BreachForums, and Telegram channels dedicated to DDoS-for-hire advertising. Customer reviews on these storefronts have historically revealed target verticals (commonly Minecraft and small game-server hosts), pricing models (usually expressed as USD or Monero per Mbps per minute), and competitive positioning against rival vendors.

The xlab 2 Rivalry

The decrypted development banner, a profanity-laden message that names a rival fork as xlab 2 and contains a racial slur, reveals an active rivalry with a competing fork branded xlab 2. The single-letter difference (xlab versus xlabs) and the version differential (xlabs_v1 versus xlab 2) strongly suggest a code-split or plagiarism event in the underground community. One party leaked or stole the codebase, and the two resulting forks now exist in parallel under nearly identical names. The banner's language is consistent with rival-vendor hostility common in DDoS-for-hire underground communities. The specific content has been documented internally but is not reproduced here.

The xlab 2 brand is itself an OSINT pivot. A market search for the rival fork yields the rival operator's public storefront, which (if found) provides correlation evidence: shared customers, shared targets, shared payment infrastructure, or shared codebase forks. Both operators may be the same person under two personas, or two genuinely separate parties, or a single party with shared resources but separate brands. The OSINT yields evidence in any of these cases. Hunters should additionally watch for xlab2 / xlab-2 / xlab_v2 spelling variants.

Co-Located Cryptojacking

Co-located infrastructure within the same 176.65.139[.]0/24 netblock has previously been observed distributing the VLTRig Monero-mining toolkit on host 176.65.139[.]42. Independent samples of the VLTRig deployment scripts use the HashVault Monero pool at pool[.]hashvault[.]pro:443 with TLS-encrypted submissions to mask traffic as HTTPS, and target the wallet address 47Hpw2YEnA58M2LDm9LCPJ3uwyd4qNDUoD4Lu2knCf7tdkYbdqsDmmLSEjgxVP6WeFgHqA2qvipQuRuecb8M3Kqi6hjDzNs+1000. The mining binary itself is staged from github.com/HashVault/vltrig with cron-based persistence and process masquerading as systemd-journal, dbus-daemon, irqbalance, or similar legitimate names.

Whether xlabs_v1 and the VLTRig operation share an operator cannot be determined from the captured artifacts alone. The shared netblock and shared upstream provider are correlation signals, but Offshore LC is a known multi-tenant bulletproof-hosting environment, and any individual /24 is statistically likely to contain unrelated tenants. The wallet address above is, however, an actionable IOC: any victim host observed connecting to pool[.]hashvault[.]pro:443 with the listed wallet should be investigated as a co-victim of both campaigns.

Tradecraft Assessment

The xlabs_v1 operation exhibits moderate tradecraft. Positive indicators include ChaCha20 string encryption, argv[1] zeroing, the /bin/bash process masquerade, UPX packing of the production binary, OpenNIC DNS fallback for ICANN-block resilience, and accurate haversine-based Speedtest server selection. Negative indicators include the non-stripped x86-64 development build shipped to a public-facing staging server with printf calls that emit decrypted strings, the structurally weak ChaCha20 key with five effective bits per byte, the same key/nonce/counter triple reused across all sixteen decryption calls, the Decodo SOCKS5 credentials sitting in plaintext on the same exposed staging server, and the operator's rivalry with xlab 2 captured in a hard-coded development banner that ships in every build.

In commercial-criminal terms, xlabs_v1 is mid-tier. It is more sophisticated than the typical script-kiddie Mirai fork (which would lack the ChaCha20 layer, the multi-architecture binary set, the bandwidth profiling, and the registered-attack diversity), but less sophisticated than the top tier of commercial DDoS-for-hire operations (which would use TLS on the C2 channel, would not ship a debug build to production paths, would rotate cryptographic material across builds, and would not ship a hard-coded competitor-rivalry banner). This operator is competing on price and attack variety, not technical sophistication. Consumer IoT devices, residential routers, and small game-server operators are the target. Treat it accordingly.

Full IOC set below, ready to operationalize.

Indicators of Compromise

Full indicators below, grouped by category. Network indicators include domains, IPs, ports, and operator credentials. Host indicators include filesystem and process artifacts. String indicators include the operator handle, brand, and authentication token. File hashes cover all six artifacts in the capture.

Network Indicators

All infrastructure documented in this report is searchable in Hunt.io, including the full 176.65.139.0/24 netblock, associated domains, and C2 classification history. Start Hunting Free.

Beyond network-level detection, the following host artifacts can be used to identify active infections on monitored systems.

Host Indicators

File Hashes

MITRE ATT&CK Mapping

The following MITRE ATT&CK techniques are observed in the xlabs_v1 capture, mapped to the specific subsystems where each technique surfaces.

Conclusion

This operator put real work into the commercial layer: bandwidth-tiered pricing, 21 flood variants, OpenNIC fallback, a competitor-eradication routine hardcoded to a specific rival port. They were thinking like a product manager. They just weren't thinking about who might be watching the staging server.

The dev build, the plaintext proxy credentials, the rivalry banner baked into every production build: those aren't rookie mistakes. That's someone focused entirely on the operation and not at all on exposure. The 'Godisgood' certificate pivot to a second host in Germany, combined with VLTRig infrastructure observed on the same /24, indicates this netblock is hosting more than one active campaign, though whether they share an operator cannot be determined from the captured artifacts alone.

We find infrastructure like this through continuous open directory monitoring and automated C2 classification. If you want to see what we're seeing, book your demo today.