The C2's Landlord

Chapter 29 ended on an honest note of frustration: shem talks to its C2 over a bare IP, no domain in front of it. And an IP with no domain is a dead end if you want to follow the operator: when he stands up his next server, there's no name resolving to the new address to lead you to him. The trail forward goes cold.

But the trail backward - the box he used this time - you can walk. And this particular box was reported so heavily that the public record tells the whole story: where these things get hosted, and how the hosting that shelters them is built, piece by piece, so there's no one left to complain to.

In 29 I wrote that the network was already telling the story - it just didn't know whose. This is going and asking the network about the landlord. And it turned into the same question asked four times over, climbing a floor each time: who do you hold responsible for this? Fair warning on the answer - every floor points to the one above it.

01One IP, two license plates

I started with the boring part: who owns 176.65.134.121? And the first oddity showed up right there. It depends who you ask.

RIPE, VirusTotal and AbuseIPDB agree: it belongs to Pfcloud UG, in Germany, under autonomous system AS51396. Its reverse DNS backs that up, 176.65.134.121.ptr.pfcloud.network. But Shodan, which scanned it right during the campaign, filed it under a different operator: AS215240, “Silent Connection Ltd”. Same address, two owners depending on which map you read.

It isn't one feed getting it wrong. I looked at the whole /24 (176.65.134.0/24, registered as “PFCLOUD-NET”) and Shodan sees 118 machines there, 87 tagged “Pfcloud” and 31 “Silent Connection”, sharing the same block. Among them, what you'd expect from a neighbourhood like this: OpenSSH all over the place, nginx, plus open VNC and a couple of proxies stood up with Ncat. The block was created by its holder on 1 August 2025 and is maintained by an entity called MNT-ZEXOTEK.

It took me a while to realise I wasn't looking at a misfiled record. The double plate is the product: two autonomous systems taking turns with the same addresses means that, depending on which feed whoever comes to complain happens to check, someone else is on the hook. It isn't administrative mess - it's administrative mess by design, paid for.

First floor, first answer: it depends who you ask. Which is an elegant way of not answering.

02A company they shut down that’s still open

Who is “Silent Connection Ltd”, the IP’s second name? This is where third parties come in, and it’s the ugliest part. Spamhaus described that autonomous system as a “hotbed” of abuse (botnet command centres, phishing, brute force, spam) and - the detail that nails it - as the last link in a chain of decoy ISPs: layers of front companies stacked one in front of the other so that, when someone complains, there’s nobody there.

And there’s more: per Spamhaus, Silent Connection was forcibly dissolved (along with another one called “Dolphin 1337”), and even so its network kept operating. What I found lines up with that: AS215240 today is registered to a different company, “Microdex UG”, and no longer even announces routes. New name, recycled plate, same garage.

Second floor: the company you’d complain to is dissolved. And its network is still live.

03A shopping mall of botnets

shem wasn’t the only tenant, not by a long way. Researchers who watch this block week after week documented that, the same week as our campaign, the hosting was handing out several IoT families at once: a phanes.<arch> that, they note, “replaces” a morte.* from the week before, a /SBIDIOT/ directory, and ours. Every week the shop changes its sign; the premises stay the same.

And the neighbourhood closes in on itself: the IP right next door to our C2, 176.65.134.48, turns up in those same researchers’ infrastructure correlation, alongside the operator’s scanning nodes. It’s no coincidence of address: it’s the same business holding adjacent addresses. And for anyone following the blog, this isn’t the first time this corner shows up: we’ve already run into machines from the same block in earlier cases.

The conclusion stings a little: shem isn’t “the” bug on this server. It’s one more in the catalogue. shem’s operator rents; the landlord bills shem, and phanes, and morte, and whoever calls.

Third floor: the landlord isn’t shem’s. He’s everyone’s - and that’s exactly why none of them matter to him.

04Life and death of a throwaway server

The nice thing about having so many eyes on it is that you can date the server’s whole life cycle without touching it. Here’s what other people’s clocks say, raw:

18 Sep        first delivery URLs recorded on the IP (abuse.ch)
                → the server comes to life
  22–24 Sep     the C2’s own attack window: 100+ SSH login attempts
                go out from the address against third-party decoys (AbuseIPDB/Cowrie)
  18–27 Sep     span of the ~370 delivery URLs seen: mostly on port 8080,
                with spikes on the bot’s high formula ports
  30 Sep        urlscan still catching requests to its 8080 (thousands of scans logged)
  late Sep      the 8080 starts returning an empty 404, Shodan stops seeing it change,
                and every delivery URL is now logged as down
                → the server empties out
  to 13 Oct     still being “reported”, but always re-sending the same 22–24 Sep window
                → residual reputation, not fresh activity

Bottom line: about ten days of life, and on to the next. For a business that treats servers as disposable, ten days is normal. What lasts isn’t the box: it’s the landlord. So the question moves again: if the landlord holds while the boxes come and go, who keeps his premises connected?

05And who connects all this to the internet?

Bulletproof hosting doesn’t live in a vacuum: it needs someone to give it transit, to pass its traffic to the rest of the network. That’s the boring question that actually stings, because whoever provides transit does tend to be a normal, locatable company.

I looked at Pfcloud’s routing neighbours, and one dominates by far: aurologic GmbH, another German operator (AS30823). It’s the one that, in practice, puts this block on the internet’s map. With the due caveat, which I’ll say before going on: I confirmed aurologic is the autonomous system’s main provider, but pinning that it’s the provider of this specific prefix needs another pass over BGP. That said, the direction of the thread is clear and it isn’t new: aurologic shows up again and again as the conduit the problematic German hosting breathes through.

And here the chain of shadows ends. Pfcloud renames itself, “Silent Connection” is dissolved, the boxes last ten days - but the one passing the traffic is a German GmbH with an address, a phone number and an abuse mailbox somebody reads. Fourth floor, and the only one in the whole stack you can actually put the question to.

06This is as far as the thread goes

And this is where the thread pulls taut and snaps, right where we already knew it would. I’ve been able to reconstruct who hosts shem, how that hosting camouflages itself and how long this server lasted. What I can’t do is make the jump to the operator’s next box.

You’ve known the reason since the first line, and here’s the proof of how walled-off the path is: VirusTotal knows of just one resolution for this IP - its own reverse DNS. Not a domain, no passive DNS to follow, no certificate coming up fresh, nothing that one day points at another address and tips you off to the move. When the operator stands up his next server (probably in this same neighbourhood, or the one next door) he’ll do it with a fresh IP and in silence, and it’ll be back to hunting him from the decoy, not following him from here.

It’s not a tidy ending, but it’s the honest one. shem’s operator is, for now, a nameless shadow. His landlord, though, has a name, a license plate (two, in fact) and even someone who gives him transit. Sometimes, when you can’t point at the one breaking in to rob the place, you can at least point at the one who rents him the safe house and asks no questions.

07Indicators (infrastructure)