Borrowed names

The last chapter left Superior installed on a TV and the victim unable to get rid of it. This one starts with the labels hanging off it, which are almost never its own:

calls itself            superior-v21
its Android package     com.android.logcatd        # Kimwolf's
one of its attacks      kimwolf
what it writes          t[.]me/mozibotnet          # Mozi, a famous botnet
on the console
the contact             "Rise", with the face of a hacker wanted by the FBI
antivirus engines       trojan.mirai

Five names that belong to others and one of its own. What follows is why I stick with its own, what's inside the critter, and what can be seen of whoever runs it.

01What it carries inside

Unpacked, the native bot from the TV is 540 KB of C, static and without symbols. Its configuration sits in a table of 46 entries encrypted with an eight-byte XOR, Mirai style, identical across the three architectures. Decrypted, it says who it is:

version          superior-v21
server           coolcams.duckdns.org
fake name        kworker/0:1
console          key superior-swarm-••••       # I'm hiding it: it would give control of the network
SOCKS proxy      socksuser / sockspass123      # nobody reads these two entries
lure             "S Y S T E M   U P D A T E … Build 2026.10.31-1543 · Channel stable"
attack           browser User-Agents, sec-ch-ua headers, SSH banners,
                 paths and cookies from Cloudflare's challenge

The lure is what it prints on start-up, on the console, on standard output and in the kernel log: a system update that does nothing. The "build" date may be the compile date, 31 October; or it may just be text.

What it can do, in short:

DDoS             37 entries in its attack catalogue, from layer 3 to layer 7, one called "kimwolf"
spreading        Telnet, with 45 username and password pairs
                 and a service finder that sends the banners home
theft            a catalogue of files it's interested in, and a way to upload them
competition      rival killer, folder watcher, app uninstaller
persistence      on Android, the one from the last chapter; on Linux, attempted
control          central C2; a P2P mesh and a console, switched off in this version
hiding           kernel thread and system daemon names, picked at random
                 wipes wtmp, btmp and lastlog on start-up on Linux

Of those 37 entries, the one called kimwolf is a high-throughput UDP flood. Its help text offers an option to spoof the source address, but without a raw socket it can't do it: the option is decorative. It's an ordinary attack with a famous name, not Kimwolf code.

UDP    pps udp udpbypass kimwolf udpxor tcprst tcpsynack dnsq gameudp rtc query icmp damp ssdp
TCP    ack stomp ssh hold bypass tcp fivem tcpkill minecraft ovhkill
HTTP   http2 http1 httpbypass cdn http3 httpdown h2cont captcha cfbypass tlsfull ws httpemu odom

02How it calls home

To find its server it doesn't trust the system resolver: it carries its own, which asks public resolvers directly. Then it tries two routes. First TLS on 443, with a TLS client of its own whose hello changes size on every attempt and carries variable filler values, as browsers do. That, probably, so that fixed TLS fingerprints don't recognise it. If that fails, plain TCP on 29444 (on start-up it also tries 14444).

On 29444 it introduces itself with an encrypted announcement. And the encryption has a textbook flaw: it always uses the same key, the same one-time number and the counter at zero, on every connection and in every bot. The key is inside the binary. So the announcement isn't secret: anyone with the binary can read it, and a network detector can read it on the fly. It says this:

type                0x0d
architecture        aarch64
version             superior-v21
CPU and memory      2 · 1967 MB
build label         acer
root?               yes
command line        /usr/sbin/cupsd           # already disguised
ephemeral key       32 bytes, new on every connection
device fingerprint  8 bytes
label               piharnessapk              # the installer's

The session that comes afterwards does include authentication: the operator's public key is baked into the binary, and the exchange requires their private key to establish the intended session. That's why I never gave it commands. That doesn't mean everything is protected: its TLS and the authentication of some of its commands have flaws of their own and unchecked loose ends.

The acer label is the build's; the installer's travels separately, in the last field. What acer is to the operator, a campaign, a customer or nothing, I don't know. On the TV, once installed in the system and relaunched by its supervisor without arguments, the announcement only carried acer: the label for the way in gets lost along the way.

Besides the encrypted channel, it talks a lot in the clear. In the ARM64 virtual machine, to port 80 on its server: [ARCH] a=aarch64 on start-up, a [SERIAL] with the machine identifier every minute, thousands of [CATALOG] with the system's executables and a POST /r with the header Host: cnc carrying its file inventory. On the TV, as we saw, almost all of that went to 5821. And if its installer asks it to, right after start-up it sends a beacon to 8099, GET /b/y/<PID> with Host: beacon: the proof that the binary really runs.

It also asks ip-api.com about its own IP: country, region and provider and, above all, whether it belongs to a proxy or a data centre. It seems to want to know whether it has landed in a home.

03What it carries switched off

The binary's strings promise more than it does. A big part ships compiled in and doesn't work:

P2P mesh "swarm"    SWR1 greeting on 443, peers in .swarm_peers, SCARE and KILL commands
                    between bots. It all hinges on a flag nobody sets to 1:
                    the only write it gets sets it to 0
console             also on 443, with its key; exits if that flag is 0
SOCKS proxy         username and password in the table; nobody reads them, there's no code
anti-emulator       strings for qemu, goldfish, ranchu… without a single reference
eBPF hiding         a "hide" program that does nothing: return 0
lifeline 42428      a rescue channel; on Linux it never gets to listen

I searched for it every way I could think of: direct writes, by offset, in pairs, through memory copies, through stored pointers. The mesh flag is only written once, with a zero. In twenty minutes of running, not one listener on 443 and not one SWR1 greeting. The "hybrid" bot its strings promise is, in this version, a central-server bot.

Screenshot: the mesh switch, in GhidraGhidra

The lifeline has its funny side. On Linux it never listens: the process that handles it, when it turns into a daemon, closes descriptors 0, 1 and 2 out of habit, and everything points to one of them being its own socket. On the TV, on the other hand, it was listening on 42428. How you get in through it I'm not telling: it's a back door on the victims.

What does start is a separate piece, which the code calls HYDRA. It opens UDP 8346 and is written to greet, every thirty seconds, a list of up to sixteen siblings handed to it by the server, with authenticated messages; if someone sends it one that doesn't check out, it reports it home as [MESH]|probe=1|ip=…, and so gives away whoever probes the port. But it has a flaw: the sibling list is received by the main process, and the lookout runs in a separate process, with its own table. According to the static analysis and a trial run in the cage, that list never reaches it, so, as it stands, it doesn't know whom to greet. What it does do, and this was seen on the TV, is watch a heartbeat file that the bot only touches while it's connected to its server: if the heartbeat goes stale, it tries to warn the peers in its table and turns on ten minutes of "dark mode", during which the bot kills its own attacks. The attempts to get back home carry on, and so does the spreading.

04The flaws that give it away

For a bot with its own cryptography and its own TLS, it has quite a few parts that could be better, and some of them in key places. Some only matter to the bot itself. Others are useful for hunting it, and don't depend on an IP or a domain that could change:

the "local" sweep          wants to sweep its own network and sweeps the Internet (below)
the banner to the server   its standard output ends up being the C2 socket, and the banner
                           "S Y S T E M   U P D A T E" travels inside the connection
the announcement           same key and same nonce every time: it can be read on the fly
the plain-text reports     one TCP connection per message: over a thousand a minute on the TV
Linux persistence          tries to copy itself from "/memfd:kworker/9 (deleted)", a path
                           that doesn't exist, and doesn't get copied
the unpacker               no cache barriers: probable cause of the SIGILL and SIGSEGV on real ARM
the update                 according to a static analysis I haven't checked, no hash
                           a file of 0 to 3 bytes passes for a valid executable
the killer                 reports kills that don't happen

The first one is the best. Every half hour, if its address is private, the bot wants to probe its local network: the 254 addresses in its /24. But it stores the IP with the bytes reversed and changes the first octet instead of the last. A TV on 192.168.1.50 doesn't sweep 192.168.1.1 to 192.168.1.254: it sweeps 1.168.1.50, 2.168.1.50… up to 254.168.1.50. 253 addresses, none of them on its network and almost all of them on the Internet, every half hour, from every infected home.

Screenshot: the sweep, in GhidraGhidra

What it looks for on them is interesting: thirteen services, among them Telnet, ADB, IRC from old botnets, panels on 4444 and 31337, and two it calls superior-c2 (29444) and superior-ui (29596). It seems to be looking for panels, rivals' and its own. It sends the banners home as [CNC]|ip=…|port=…|kind=…|banner=….

05Its war

A good part of its code is devoted to the competition. The killer has four workers. It hunts 32 botnet families by name and cryptocurrency miners (it doesn't mine: it kills miners), scores suspicious processes, takes the ports other bots use so they can't open them, and watches /tmp, /var/tmp, /dev/shm and /var/run with inotify to delete any new file that isn't itself, except a few that are critical to the system. And it carries a farewell, which it writes to another process's output; judging by the tone, a rival's:

sorry brother I own this box

Screenshot: the farewell, in GhidraGhidra

And on Android, the list of apps it uninstalls is a who's who of this year's TV-box botnets:

com.n2.systemservice06, …061, …062, …063, …0644    # Kimwolf
com.oreo.mcflurry, com.android.log_handler_v2,
com.android.boothandler                            # Lorikazz aliases
com.android.docks                                  # Snow
com.google.android.gms.update                      # Jackskid's disguise
com.iranbot.loadd                                  # IranBot?
com.abcproxy.*, com.proxypeer.peerapp, io.earnify  # proxyware
com.meowrisee.service                              # unidentified

That com.iranbot.loadd is almost the com.iranbot.load that already came up in chapters 7 and 21, with one extra d. Whether it's the same one with a typo or a different one, I don't know. Uninstalling rivals isn't new on this turf: Jackskid and Lorikazz do it too. What this one adds is doing it dressed as one of them.

The last one on the list, com.meowrisee.service, contains "meow", like its own meowbox, and "rise", like the Telegram contact we'll come to. It could be a coincidence, an earlier version of its own or a rival. There's nothing public about that package.

To spread, it tries its 45 credentials over Telnet on 23 and 2323 and, if it gets in, downloads a script with whatever the machine has (wget, curl, busybox, toybox or, if there's nothing, a hand-built HTTP request with nc). Before that, it discards victims that look like a trap: if the response mentions cowrie, kippo, dionaea, glastopf, conpot, "honeypot", tarpit, canarytoken, dshield, shadowserver, "internet census", "capture the flag" or "malware analysis", it leaves.

And to steal, it catalogues files by extension and by header across eighteen system roots (.key, .pem, .crt, .env, .db, .sqlite, .sql, configs, scripts, APKs…) and, if its server asks for them, uploads them over TCP 5822 or with a POST /pull. The killer can do the same with rivals' binaries before killing them, although that option, according to the code, ships switched off.

06It isn't Kimwolf

Kimwolf is one of the most documented TV-box botnets this year: XLab described it in December 2025 and Unit 42 published its version 7 in August. Superior carries its package name, an attack named after it, a similar naming scheme (meowbox versus niggabox), the v7 suffix on its instance lock and the same habit of passing a label as the first argument. So I compared it with what has been published and, after that, with real samples: an APK and a v7 ELF from Unit 42 that are on MalwareBazaar under the Kimwolf signature.

                 Kimwolf                                Superior
TLS              wolfSSL; static BoringSSL (v7)         its own
authentication   ECDSA signature                        X25519 + BLAKE2s + ChaCha20, its own
C2               ENS, DNS over TLS, Tor                 DuckDNS, TLS on 443, TCP on 29444
main use         residential proxy (96.5% of commands)  no proxy: DDoS, theft, control
spreading        ADB via proxies; no scanner in v7      Telnet with 45 credentials
size (ARM)       1.7 MB                                 about 550 KB (217 KB packed)
lock             @niggaboxv<n>                          @superior:instance:v7

Out of 8,739 and 2,389 strings, they share 155, and all of them are generic: the C library both of them link, the headers for imitating Chrome, the TLS 1.3 labels. None of the 37 names in its attack catalogue appears in Kimwolf. Not its configuration, not its credentials, not its templates, nothing of its own. In the Java layer, the same: of 4 components against 14, they share the two generic ones, and that sample's APK is a Tor launcher. The code is different. High confidence.

With one caveat about names. Unit 42 documented com.android.logcatd first, in April, as an alias of Lorikazz, and then, in August, as the Android variant of Kimwolf v7. And the Tor sample I used fits the variant described in its Lorikazz report. They're names from a single constellation, which according to Nokia splintered into more than twenty botnets from March onwards. For what matters here it makes no difference: Superior shares no code with any of those samples.

But it does wear that package. And that has a practical consequence: public rules that look for Kimwolf by package name may call Superior Kimwolf. Antivirus engines, for their part, file it under Mirai: the APK is detected by 24 or 25 out of 75 engines, and the consensus label is "trojan.mirai", the drawer where any bot that scans devices and floods ends up. ThreatFox even tags its domain as EchoBot, another Mirai variant, which turns out to be on its list of rivals. It isn't a family: it's a shelf.

It uses two packages itself: com.android.logcatd and com.superior.node. Why wear someone else's package, I don't know. It could be to blend in where Kimwolf has already been, or to take the spot: Android doesn't allow installing a package with the same name and a different signature, so wherever the genuine Kimwolf already is, Superior can't get in, and wherever Superior gets in, Kimwolf won't be able to any more. That last part I haven't checked.

07Neither Mozi nor "Rise"

The same goes for Mozi's name. Under certain conditions, if its mesh has no peers, Superior writes to the device's console:

t[.]me/mozibotnet

Screenshot: the signature, in GhidraGhidra

In the virtual machine I saw it on its console; in the TV's logs it didn't show up. Mozi was a P2P botnet of IoT devices, very widespread between 2019 and 2021, whose operators were arrested in China and which went dark in 2023. I looked for its marks in the binary: the mesh over the BitTorrent network, its configuration between tags, its fixed key, its name. There are none. Superior's mesh is a different design, and on top of that it's switched off. The only "mozi" thing it carries is the console signature and one word in its list of 32 rivals that it kills. It uses the name and hunts the family. Same as with Kimwolf.

I visited that Telegram address once, over Tor, without JavaScript and without writing to anyone. It isn't a channel: it's a personal account, with the display name "Rise", and no bio. The bot writes a person's contact on every infected device, which fits a sales or contact advert better than a news channel. There's nothing public about "Rise" in this field.

I'm not showing the profile photo, but I'll explain it. I searched for it by exact image match, without facial recognition, and it appears 227 times on 81 sites, almost all of them news outlets and agencies, since 2018: it's the photo the FBI circulated on the poster of a North Korean programmer charged over the Sony Pictures hack and over WannaCry. It's a borrowed avatar, like the names. That person has nothing to do with this case, and I'm not going to suggest otherwise. What it does do is say something about the persona the operator puts together: an attack with Kimwolf's name, a signature with Mozi's and the face of a legendary hacker.

08A Frankenstein with its own thread

Put it all together and you can see where each piece comes from:

Telnet credentials     from Mirai and derivatives     public data, not code
killing rivals         Mirai's idea                   its own code
P2P mesh               Mozi's and Hajime's idea       a different design, and switched off
Android disguise       Kimwolf's                      no shared code
turf and way in        TV boxes over ADB, like the Kimwolf ecosystem
browser attacks        the DDoS-for-hire scene        its own
method catalogue       names from for-hire panels     its own
front names            Kimwolf, Mozi, Lazarus         point to others

what's its own         its own cryptography, its own TLS, the HYDRA lookout, file
                       theft, the scare screen, the deletion of legitimate apps

It borrows names, data and ideas; the code seems to be its own. That it chose those names to pass itself off as others is my reading, not something the binary says. And it's sewn together in a hurry: half-assembled pieces, parts that could be better and, at the same time, a build a day. Its list of rivals is a who's who of IoT botnets, so it knows the scene well. It doesn't look like a variant of any of them: it looks like a newcomer that imitates the big ones and competes with them for the same TV boxes.

09Eight months of the same domain

A DuckDNS subdomain belongs to an account. So the history of coolcams.duckdns.org is, probably, that of the same operator, unless they handed it over. And it goes back a long way:

February         the domain's first DNS records and the first Mirai binary that talks to it
March · April    serves a classic Mirai at /bins/<arch>, from 176.65.139.42
May              another bot, a different one, with cat.sh, from the same IP; on the 12th a blog analyses a bot
                 from this domain, very probably that one
June             moves to 31.56.209.231: that bot, recompiled, and among other things iran.<arch>,
                 the public IranBot kit
July · October   after two more hops, it lands in the 77.239.124.0/24 block and goes through several IPs
November         Superior, and a second bot in Rust, from 77.239.124.167

The same thing was served by two other DuckDNS names, r34fa352.duckdns.org and toomanyways.duckdns.org: the files they handed out are byte-for-byte identical to coolcams'. Three names for the same files. That they serve as backups for one another is the usual explanation; here it's an interpretation.

But I can't close the lineage going backwards. The spring IP was a shared server: other bot brands, miners and even phishing-looking domains went through it in 2025. And in March, on the same dates as coolcams, that IP was also serving, according to Hunt.io, another TV-box botnet that gets in through ADB, xlabs_v1. Compared with what has been published about it, I haven't found anything in common. They shared a server, and at the same time, but it was a server with many tenants, so that doesn't prove kinship. I can't rule it out either. There's a loose end that could tip it: a cool.sh that IP served on 10 March, which is associated with xlabs but whose name is reminiscent of coolcams, and of which no copy remains. And the IranBot kit was being served by more than forty machines in the autumn. That the coolcams operator went from an off-the-shelf Mirai to a bot with a public codebase and from there to one of their own is a reasonable reading. It isn't proof.

Where there is continuity is in the hosting, which is permissive. The 77.239.124.0/24 block is the same one DIICOT was delivering from in chapter 34, and at least half a dozen operators live side by side in it. Behind it there are three layers: a recently created British company that fronts it, a Romanian company that announces the addresses and an Estonian provider that all the routing goes through, on rented IPv4 addresses that change hands within weeks. It isn't "bulletproof" hosting with a brand and advertising: it's hosting put together out of disposable layers.

ROCKET & MARINICA LTD    British company (Companies House 17340426), incorporated on
("RocketCloud")          15-Jul-2026, hosting, a single director, Proton email,
                         address at a virtual office in London; domain rocket-cloud.org
                         its organisation in the European registry, a day earlier (14-Jul)
                         AS219141 "ROCKET-MARINICA", 24-Jul; also 31.77.227.0/24
BANATSYNC                Romanian SRL, AS198364; announces 77.239.124.0/24 since 18-Jul
TakeHost                 Estonian OÜ, AS214639: BANATSYNC's main transit
before                   the block was announced by Aeza (2025), Alfahost and Ace Data Centers II,
                         the US wholesaler that leases out the addresses

10A product team

What says the most about the operator isn't their infrastructure, but how they work. Their ADB scanner (almost certainly theirs: the same sequence, from their own block and from the same provider as one of their installers), the one with the five questions from the last chapter, was already knocking on this decoy's door on 19 October, from rented servers in Japan, Germany and Singapore and from their own block, among others. On a public honeypot, its greeting shows up from early October. First it filters; days later, another machine installs.

And the installer carries telemetry. The /s script, the one that downloads the bot onto machines reached through Telnet, introduces itself in its header as "superior — telnet dropper". I downloaded it once, over Tor, and read it as text. It's commented in an English that explains the why of every decision. This is what it does, and what changed between 7 and 10 November:

funnel beacons       new on the 10th:
                     /b/s  the installer has run
                     /b/x  the binary is downloaded (with its size)
                     /b/b  the binary is launched
                     /b/y  the bot is alive (sent by the bot itself, with its PID)
reinfections         changes on the 10th: the 7th's killed the old copies; the 10th's no longer does:
                     "A duplicate is cheaper than a hole"
routers              already on the 7th: reads the shell's ELF header to know the architecture,
                     because "uname -m lies on a lot of routers", and before that ended in SIGILL;
                     the 10th adds more readers, and if od is missing it checks by size
                     that what was downloaded isn't an error page
download             seventeen ways to download the binary, plus TFTP and hand-built HTTP
panel                in both: each route's label lets the boxes be told apart
                     "on the CNC panel without a rebuild"

It measures the conversion of its infection funnel: how many installers run, how many download, how many launch and how many bots actually start. It's what a product team does. And the SIGILL comment is the flip side of the last chapter: they too know what it's like to install the binary and watch it die.

Not even the duplicate line is entirely theirs: it appears word for word in three unrelated repositories from this year, one of them a project for an AI coding assistant. Those comments may have been written by an AI. I don't know.

The pace fits: three versions of the APK in two days, the /s rewritten in three (and the one from the 10th gets through clean: 0 of 75 on VirusTotal), a new installer on the same day as the infection. And it doesn't only get in through ADB and Telnet: according to ThreatFox, its /s was also being served by exploiting a PHPUnit vulnerability on web servers, CVE-2017-9841.

11A second bot

On 8 November, between Superior's /s of the 7th and the one of the 10th, the same address served something else. I got each of the three from a different source:

7-Nov    Superior                         # from MalwareBazaar
8-Nov    another bot: RUSTBOX             # from the copy urlscan kept
10-Nov   Superior                         # the one I downloaded; already circulating on the 9th

The one from the 8th is served by a server that introduces itself as Server: rustbox, carries the same explanatory English and downloads another bot, written in Rust, which also puts ADB on 12108 and uses a supervisor with the same name, .srvc. The same operator, and that I do claim with high confidence, alternating their two bots on the same address: it looks like an A/B test.

What I don't claim is that the second descends from the first. The code is different, and the cryptography, although it uses pieces from the same family, is put together another way. It could be a rewrite with the same design or a new bot that the same operator also runs; the code doesn't say. That's the next chapter.

12Indicators

Those for the infection and the TV box are in the last chapter. These cover the binary, its network and its infrastructure.

To hunt it without depending on its address: a box on a private network that, every half hour, tries to connect to 253 addresses, almost all of them on the Internet, that share the last three numbers of its IP. It's a distinctive pattern, which lets you look for it without depending on the domain.