ES EN
Index

Cling · Chapter 20

Twelve alibis and a mailbox

Comes from chapter 19 · A Mirai that couldn't attack?

The previous chapter left a question the binary doesn't answer: of the thirteen STUN servers Cling beacons to, one has to be the operator's mailbox —because the bot announces its ports only to those thirteen, to nobody else— and yet all thirteen look like innocent VoIP providers. I didn't catch it issuing an order; I found it by elimination and exclusivity, using public records to see who talks to each one. Twelve have an alibi. The thirteenth doesn't.

This thread starts where the teardown chapter left off: one of the thirteen STUN servers Cling —an IoT bot that turned out to be a proxy— beacons to has to be the operator's mailbox, and yet all thirteen look like innocent VoIP providers. Telling the one that isn't from the twelve alibis can't be solved by reading the binary; it's solved with public records, without touching a single machine and without capturing a single order. That's what I do here.

How to read thisThree levels, always kept apart: seen (I checked it myself), read (a third party says so) and inferred (my interpretation). And one warning up front, because it governs everything else: I never saw the mailbox issue an order. What follows is a case built on elimination and exclusivity — strong, but not a signed confession. I say it here and I give it a whole section of its own (section 05).

01The question isn't «whether», it's «which»

That one of the thirteen has to belong to the operator isn't a hunch, and it's worth nailing down before going on. The bot learns its thirteen public ports over STUN and announces them only to those thirteen; the strace in the teardown shows it without ambiguity —«any other IP: 0»—. seen And without that calling card the ports are ephemeral and nobody knows how to reach it: whoever commands it must have received the beacon — almost certainly, one of the thirteen. I say «almost» because remote loopholes remain —that they compromised one of the legitimate STUN servers, or that someone was listening to the traffic upstream, among others—; possible, but a lot to ask. inferred

NAT is the «how it gets back», not the argumentEvery beacon also punches a hole in the victim's NAT, and that's the physical path the reply takes. It helps — but it isn't what holds the case up, and that's why I don't lean on it: it doesn't matter how the router is configured (full cone, public IP, whatever). The argument is simpler and harder: the ports are announced only to the thirteen, therefore whoever gives the orders is among the thirteen.

And at that point the question stops being interesting in the abstract and becomes concrete and boring, which is how I like them: who, exactly, is each one of these thirteen addresses?

02Twelve alibis

I resolved the reverse name for all thirteen and looked at them one by one on Shodan. Twelve have a textbook alibi: they are STUN servers belonging to real VoIP and telecom providers, with their name in the registry — and half of them, on top of that, in reverse DNS.

twelve of thirteen · who each one is
74.125.250.129   Google            stun.l.google.com
212.227.67.34/33 IONOS             stun.1und1.de
81.187.30.115    Andrews & Arnold  natisevil.aasip.co.uk  (British ISP)
5.39.72.109      antisip           sip.antisip.com
83.211.9.232     IRIDEOS           clouditalia.com
212.53.40.43     SIPNET            sipnet.ru
207.38.82.134    velia.net · 85.17.88.164 LeaseWeb · 77.72.169.211/213 Finarea
216.93.246.18    CounterPath       (historic stun.ekiga.net)

Most of them answer STUN right now; a couple don't reply on :3478 from where I'm watching —ekiga is a historic service long since shut down, though its address is announced today by CounterPath, a softphone maker still in business; SIPNET, on the other hand, is still active on other ports, so that's more «I can't see it from here» than «it's dead»—. Either way, all twelve have a real VoIP provider identity, which is what matters. seen

Important, and I mean itThese twelve are victims of a disguise, not accomplices. The bot speaks real STUN to them —a Binding Request with its magic cookie— and they answer the way they'd answer any video call, with no idea they're being used as cover. Publishing them as malicious indicators would be unfair and would flood anyone who trusted them with false positives. They go in as context. The only one I point at is the one that doesn't fit.

03The one with no alibi

One is left: 145.249.115.184. And it resembles the other twelve in nothing that matters.

It isn't a VoIP provider. The registry and the AS place it at Global Connectivity Solutions LLP (AS215540) — one of those hosts they call bulletproof, not a telco. seen But that on its own is weak: anyone can rent bulletproof. The real proof is something else, and it's what closes the case — I asked VirusTotal: who talks to each of these IPs?

VirusTotal · who talks to each IP
                        Google (public)      IRIDEOS (obscure)    145.249.115.184
population VT sees      thousands (40 shown)  dozens (40 shown)   71 · the WHOLE list (12 Sep)
file types              PDF · EXE · Android   ELF + PDF/EXE        only ELF + shell
benign / unclassified   26                    18                   0
of the Mirai family     0                     19                   71
".cling" in the name    0                     19                   65

A note on method, because this is exactly where they'd try to knock it down: VirusTotal doesn't give you a census, it paginates relationships — what you see is what it lists first, and the ordering shapes the sample. For Google, those 40 are a splinter of thousands (I kept going and at 80 there were still more); but that splinter already comes out diverse, and that's what matters: a sample that is already diverse cannot be hiding a monoculture underneath. For 145 I did the opposite — I followed the list to the end. It's 71 files —the ones VirusTotal sees talking to it (communicating_files), as of 12 September— and that's where it stops: it isn't a sample, it's the entire population. All 71 are malware, every one of them from the Mirai family, 65 carrying the string .cling, zero benign. In its whole known history on VirusTotal, the only thing that has ever talked to 145 is the bug. seen

And here it's time to be honest rather than convenient. I ran the same query against the obscure STUN servers on the list, and they don't come out clean: IRIDEOS and antisip are around 50% .cling. It's a real effect —VirusTotal over-represents malware on services with little legitimate traffic, so obscurity alone already dirties the picture— and anyone who preaches cross-checking can't keep quiet about it. And it has to be said in full, because the percentage on its own separates nothing: some of the twelve go far lower —SIPNET's keeps barely 1% benign traffic—. What isolates 145 isn't how much malware talks to it: it's what its population is made of. The twelve get everything —PDFs, Windows executables, Android, archives—, four or five different types each. Two things talk to 145: ELF binaries and shell scripts. Exactly what a loader hands out, and nothing else. None of the other twelve reaches that extreme, not even the obscure ones. seen inferred

As a bonus: when I looked at it, in the summer, that same box had, next to the :3478, a kittenx panel on :8443 and a :443 that only answered depending on the SNI. seen An operator's kit, not a telco's. inferred

The VK certificate: why I do NOT use it as proofAn earlier reading of mine leaned on the fact that that :8443 presents an O=VK CN=www.vk certificate, and I read that as «it's impersonating VK». I correct myself: it's VK's real certificate, and it appears on thousands of hosts (about 2,800) because it's a proxy technique —borrowing the TLS of a big legitimate site so traffic looks like it's going to VK and slips past inspection (REALITY/VLESS style)—. So: 145 is, on top of everything else, a node using that technique. It fits with it being proxy infrastructure, but it proves nothing on its own — it's one of thousands. I'll leave it as what it is: consistent, not probative. read

04Someone else's clock confirms it

Exclusivity already settles which one it is. What clinches it is time — and not my clock, but the one the operator himself leaves behind as he changes skin. Cross-referencing this family's public samples by date, the biography of its command centre writes itself:

  1. 2025C2 via a dynamic DNS domain (boymoder.ddns.net), with the config encrypted. The classic model: a name that resolves to his server.
  2. Jul 2026C2 on a single bare IP, embedded in the binary (94.154.43.158). It looks like the clumsiest of the three steps… until you look at where that IP lives: a /24 that has changed ASN five times in fifteen months, and in one of those hops whoever dropped it is precisely whoever provides transit to whoever picked it up. seen It wasn't an address that was easy to take down: it was one that changes country without moving. inferred
  3. Aug 2026C2 disguised as STUN: the mailbox 145 hidden among twelve legitimate servers. The sample that landed in my honeypot.

And since when has 145 been the mailbox? Its :3478 is first seen by Shodan on 2 September, the day before my capture — but that's when Shodan scanned it, not when it was born: a scanner comes round when it comes round, not when the service starts. The good data is in the samples. I took the oldest one of the wave —from 21 August— and looked on VirusTotal at which addresses it contacts: all thirteen, 145 included — the same list, exactly, as the sample that landed in my honeypot two weeks later. seen

That rules out the easy reading: 145 didn't slip in halfway through the campaign, and Cling didn't pick it up off some public STUN list — it was on the list from the first known day. And it fits the clock of the moves: an operator running forwards away from takedowns —from a name that can be suspended (2025), to a bare IP that can be blocked (July), to hiding inside traffic nobody blocks because it looks like a video call (August)—. Each move harder to catch than the last. And here it's worth not reading too much into it: that it was there from the beginning rules out an accident, but it doesn't prove intent — a list copied and compiled in would also come out fixed. inferred

05What I can't prove

This is where I have to stop, because this is where it would be easiest to overreach. I have three things pointing the same way —that one of the thirteen has to be the mailbox (the registration only goes to them); that the other twelve do have an alibi; and that what talks to 145 looks like nothing that talks to anyone else—. That's a lot. But it isn't a confession.

The proof I'm missing, and why I'm missing itThe only thing that would settle this completely would be watching 145 issue an order to a bot — catching it red-handed, not inferring it. I don't have that. A legitimate STUN server and a mailbox that speaks STUN look identical until one of them sends a command, and in the time I watched the traffic, none of the thirteen did. So the honest thing is to say it plainly: 145 is the mailbox with high confidence —by exclusivity and by the clock— but I didn't record it talking. inferred

And a nuance I already flagged when comparing (§03) which carries weight here: exclusivity, measured crudely, is a gradient, not a switch — the obscure STUN servers on the list also come out half infested with Cling, because VirusTotal dirties anything with little traffic. What isolates 145 isn't «it has malware», it's the extreme: zero legitimate traffic and a population made of two file types and nothing else, where even the most obscure of the twelve receives everything. And even that extreme I don't sing on its own: what closes the case is putting it together with the bulletproof hosting, the absence of a VoIP identity, and the clock. Not one of the other twelve has the whole set.

06Not a lone genius: the disguise is a 2026 thing

The first time you see a C2 speaking STUN you assume someone very clever invented it. Half true: STUN is creeping across the whole IoT ecosystem in 2026, each family for its own reasons, and that's documented. What may genuinely be Cling's invention is a finer detail; I get to it at the end.

  • MossadProxy (Aisuru ecosystem, a DDoS botnet) puts its own stun.kamru.ru in a config slot separate from the public STUN servers — Deepfield suspects it belongs to the operator, though it no longer resolves today. Its real C2 goes elsewhere: domains registered at REG.RU, with command traffic encrypted using ChaCha20. But the gesture is Cling's: a server of your own camouflaged among the legitimate ones. read
  • Aisuru itself —the biggest IoT DDoS botnet around— had spent months shifting from taking servers down to selling residential proxies (Krebs, October 2025); and Kimwolf, its Android variant, already does both at once. STUN shows up in some of them to check connectivity, in others for NAT traversal: the use changes, the tool repeats. read
  • In samples from those families that I went through myself, the pattern holds: the cover —public STUN from Google/Cloudflare— is shared; the server of one's own each family provides itself. seen

So: Cling didn't invent using STUN, and it isn't an oddity — it joined an undercurrent, half the IoT scene moving from attacking to renting out connections. What may be its own is the finishing touch: putting the order inside the transaction ID, so the command doesn't just travel over a video-call port but has the exact shape of one. I haven't seen that documented in the other families; it may be its signature. inferred

The neighbourhood's epilogueOn 20 March 2026, the US seized the C2 infrastructure of Aisuru, Kimwolf, JackSkid and Mossad —the biggest IoT botnets around— while Canada and Germany moved against the people running them. But it was a disruption, not an ending: four months later, Censys was seeing Aisuru's known infrastructure more than doubled, and Kimwolf fragmented into more than twenty botnets competing with each other. The scene Cling resembles isn't just in law enforcement's sights — it's that when it gets hit, it grows back bigger. Running forwards isn't just this operator's biography: it's the whole neighbourhood's. read

07The neighbourhood, and the family

The neighbourhood. 145's box doesn't exactly host telephony companies. In that same bulletproof hosting there live phishing and scam domains —neyorkk.org and zalusodahi.org right now; and until a few months ago also xenplith.com and layerzro.ru, a crypto typosquat—. It's the neighbourhood you'd expect around an operator's mailbox, and the one you wouldn't expect around a stun.1und1.de. seen

The family. MalwareBazaar labels Cling as Ngioweb — the engine behind NSOCKS, a residential proxy service that Lumen/Black Lotus Labs dismantled in November 2024. It fits what we saw inside: giving access and giving an exit, not attacking. read

An honest asterisk on the labelA STUN server of the operator's own is described in the Aisuru ecosystem (MossadProxy's stun.kamru.ru), not in «classic» Ngioweb, and their exploit catalogues don't fully overlap. So MalwareBazaar's label may be a broad brush: it could be Ngioweb evolved, or an Aisuru-adjacent cousin sharing the same loader generator — which fits the attack-botnet skeleton we found inside, weapons stripped and a tunnel bolted on. What is certain is the function —proxy, not DDoS— and the behaviour. The exact surname I'll leave with its asterisk. inferred

08Indicators (IOCs)

TypeValue
Operator's mailbox (Aug 2026)145.249.115.184 — AS215540 (bulletproof) · :3478 STUN as disguise · monoculture: the 71 files VT sees talking to it (communicating_files, the whole list, as of 12 Sep) are malware — all of them Mirai family, 65 with .cling, zero benign, and of two types only: ELF and shell scripts · :8443 kittenx panel (seen in summer 2026)
Previous C2 (Jul 2026)94.154.43.158 — single embedded IP, in a /24 that hops ASN every few months; in July and today, AS219502 (Storm)
Previous C2 (2025)boymoder.ddns.net — dynamic DNS
Neighbourhood (same host)phishing/scam current: neyorkk.org · zalusodahi.org · historic: xenplith.com (last seen there May 2026) · layerzro.ru (Mar 2026)
Technique (ecosystem)C2 disguised as STUN: 13 servers at once with the transaction ID all zeros + beacon (tag + 13×2 B) every 5 s. The use of STUN belongs to the whole Aisuru ecosystem (e.g. stun.kamru.ru in MossadProxy); the order inside the transaction ID, possibly Cling's own
The twelve are NOT indicatorsThe other twelve STUN servers (Google, IONOS, Andrews & Arnold, antisip, LeaseWeb, Finarea, velia, IRIDEOS, SIPNET…) are legitimate. They go in as context, never as malicious IOCs: blocking them would mean punishing the victim of the disguise.

To be continued — the honeypot's still on, and the STUN disguise is more fashionable by the week. 🍯

Comments