ES EN
Index

XorDDoS · Chapter 16

The tenant who'd been there eleven years

Comes from chapter 1 · Someone brought their malware to my house

A bot walked into my honeypot, stayed 62 seconds and left. I filed it as Gafgyt and I was wrong. A week later I followed its command servers and ended up inside an operation that has been running since 2015 — one I'd had in my hands from day one.

One night in August 2026, in the small hours, someone knocked on my honeypot's SSH door, walked in with root : ubnt — the factory password on Ubiquiti gear — and was gone 62 seconds later. It left a binary behind. I opened it up, wrote two chapters about it, and put a label on it: Gafgyt.

The label was wrong. But I didn't find that out by re-reading my notes: I found out a week later, going all the way round the other way — an IP, a landlord, a tenant, a hundred and thirteen samples belonging to other people — until I came back to where I started and discovered that the operator had been sitting in my honeypot since day one, wearing the wrong name.

This is that lap. It isn't the dissection of a critter: it's the tracking of the people who run it, as far as public records will take you.

How to read thisThree levels, always kept apart: seen (I ran and checked it myself), read (a third party says so) and inferred (that's my interpretation, with its confidence). Mixing the three is exactly when I get it wrong — and I got it wrong eight times here, all of them written down.

01A needle in four million

Those 62 seconds deserve some scale. Across its logging window — eight days — the honeypot piled up 3,874,029 events. Searching that entire haystack for this campaign's full signature turns up two events, one session, one IP, one day.

And of the 52 distinct hashes that landed that week — miners, botnets of every stripe, thirty-nine that aren't catalogued anywhere at all — exactly one belonged to this operator.

Though "distinct" is generous: most of them are repeats — persistent little things. Thirteen of the ones I keep weigh exactly 1,608 bytes — the same script over and over, with the download filenames swapped on every delivery. Change one letter and it's a different file to any catalogue.

It wasn't a campaign hammering the door. It was a grain of sand that turned out to be the whole case.

02The wrong name (and I wasn't the only one)

That binary went into my catalogue as Gafgyt / Bashlite. In with it went its download server, its persistence (/etc/cron.hourly/gcc.sh, /var/run/gcc.pid), the trick of renaming wget to good, and a sixteen-byte XOR key I pulled out with Ghidra: BB2FA36AAA9541F0.

All of that is XorDDoS's signature, not Gafgyt's. The key is its own — the one it's named after. The gcc.pid is its PID file. Renaming the tools is its house mark. And when I finally checked, three independent engines agreed: Elastic's rules, ditekSHen's, and ReversingLabs' engine — all of it visible on its public MalwareBazaar page. seen

What consoles me little and teaches me a lot is that I wasn't the only one. The same object is catalogued four different ways:

same binary, four labels
my catalogue ............. Gafgyt / Bashlite
MalwareBazaar ............ DDoSAgent
ThreatFox (its server) ... Mirai
another honeypot network . mdrfckr-ssh-backdoor
--------------------------------------------
the file's own YARA rules .. XorDDoS
ReversingLabs .............. Linux.Trojan.XorDDoS

And one detail finishes it off: whoever reported that server as "Mirai" is the same person who uploaded the sample to MalwareBazaar as "DDoSAgent", two and a half months before me. Another honeypot caught the exact same thing and also gave it the wrong name.

The lesson that governs everything elseFamily labels in repositories and feeds are noise. They copy one another and nobody checks. The only thing that settles the question is opening the binary and reading what's inside. Everything that follows comes from having done exactly that.

03The other way round: an IP and a landlord

The investigation didn't start from the binary. It started with something far more boring: who owns this box?

The IP was 141.98.11.51. The owner, a small reseller in Lithuania (AS209605, UAB Host Baltic). Nothing remarkable. What was remarkable came from asking who lives there:

what hangs off that IP
aaa.xxxatat456.com   ppp.xxxatat456.com
ppp.gggatat456.com   www1.gggatat456.com   b12.gggatat456.com
p5.dddgata789.com

Keyboard-mash names. And then their age in the public registries, which was the surprise: xxxatat456.com and gggatat456.com have been registered since 31 March 2015, renewal paid through to 2027 — the third one, dddgata789.com, is later: February 2017. seen

Eleven years of domains. Being renewed. And still resolving.

What was already publishedThis family isn't a discovery of mine: MalwareMustDie exposed it in 2014, Microsoft analysed it in 2022 and Unit 42 documented a campaign in 2023 using these very domains. What none of those reports covers is what comes next: the full eleven years, the operator behind it, and the generation that is alive today. read

04The binary talks: sixteen rotations

Here's the technique that cracks the case open, and it's worth telling because it's what separates reasoning from clues and reading the object.

A single indicator from ThreatFox came with one specific sample attached. Pulling on that, I downloaded the family's entire public corpus: 113 samples.

Their configuration is encrypted with the same key from chapter 2. With one detail that cost me a while: each string starts at its own offset, so applying the key aligned to the start of the file only decrypts part of it. Trying all sixteen rotations of the key, almost everything comes out.

the loop that opens it
# each string starts wherever it likes: you have to try all 16 offsets
KEY = b"BB2FA36AAA9541F0"
for rot in range(16):
    k  = KEY[rot:] + KEY[:rot]
    dx = bytes(data[i] ^ k[i % 16] for i in range(len(data)))
    # look in dx for: config.rar, domain:port, http://

78 of the 113 samples give up their configuration. And the first thing that appears changes the whole case.

In that same Lithuanian box lived another domain, sys-kernel-update.to, with Icelandic nameservers and a spotless certificate. Its whole tradecraft was different from the 2015 cluster's, so I had it filed as a different operator, from a different family. Two samples say otherwise:

decrypted config · April 2026 sample
http://sys-kernel-update.to/config.rar
telemetry-pipe.sh:1430|api-metadata-v6.is:1430|sys-kernel-update.to:1430

It's written there, encrypted with XorDDoS's key, inside binaries three engines sign as XorDDoS. It wasn't a neighbour from another family. And port 1430 matched exactly what ThreatFox had published on its own: two sources that don't talk to each other, pointing at the same place. seen

05One operator, not two

For several days I held that two tenants shared that box. With the passive DNS history in hand, that idea falls apart.

The two sets of domains — the 2015 veteran and the Icelandic one launched in 2026 — move into the same machine on the same day and then move together four more times:

  1. 22 Feb141.98.10.38 — both arrive, same day.
  2. 22 Mar141.98.10.24 — they move together.
  3. 24 Mar141.98.10.115 — together again, nearly three months.
  4. 12 Jun141.98.10.161 — together.
  5. 21 Jun141.98.11.51 — together, to this day.

Sharing a box is a reseller coincidence. Moving in on the same day and relocating four times in lockstep is not. seen

What happened in February 2026 wasn't a neighbour arriving: it was the same operator launching a new set of domains with new tradecraft — Icelandic registrars, proper TLS — and running it on the very same machines as the old one. Two generations of craft from the same hand, side by side.

06February 2026, by the clock

There's a third set of domains — aass654, xxcc789 and three more — bought as a block on 22 March 2024. It looked like "the same school". It's rather more than that: of the 40 IPs it ever used, 35 were also used by the veteran cluster. That's 87 %. And not consecutively — simultaneously: on one of those machines the two sets lived together for eight straight months. seen

With that, what happened last February reads end to end with no gaps:

  1. 23 Janlast sample of the 2024 set.
  2. 16 Feball five domains get suspended at once.
  3. 18 Febfirst sample using a brand-new set.
  4. 19 Febtwo more domains registered, in Tonga and Iceland, five hours apart — and that same day there's already a sample using them.

Five domains taken down, and a replacement running in under 72 hours, fleeing his usual registrar for Tonga, Iceland, Laos and Montenegro.

What you have to tell yourself"Two new sets up and running" is more than the evidence supports. Looking at the passive DNS for all six domains, only one has actually resolved. What holds up is: one live host with five more names written into the binary as fallbacks, most of which never came up at all. A name in a config file is not infrastructure.

07Eleven years of moving house — and the origin

With the full history, the biography writes itself. xxxatat456.com has passed through 110 distinct addresses between April 2015 and today:

eleven years of landlords
2015 ......... Hong Kong, Thailand, Korea
2016 - 2022 .. OVH, France  — home base, seven years
2023 - 2024 .. PEG Tech, United States
2025 ......... Vietnam, Hong Kong, France
2026 ......... Lithuania

And the beginning of it all is in that first line. The reverse passive DNS of that 2015 Hong Kong machine returns this:

103.240.141.54 · spring 2015
2015-04-20   ns3.hostasa.org
2015-04-28   www.xxxatat456.com
2015-05-10   www1.gggatat456.com
2015-05-18   gggatat456.com

hostasa.org is the command server of the first documented XorDDoS, the one MalwareMustDie exposed in 2014. And there it is, sharing a machine with our operator's first domains, inside a four-week window. seen

It isn't the only sign. One and the same binary carries hardcoded, at adjacent offsets, hostasa's config address and atat456's server list — and not just in 2022: in a sample from January 2025 too.

The caveat that changes what this proveshostasa.org lapsed and had been dead since 2019. So in the 2025 samples that address was no longer serving anything: it was a dead string dragged along in the code. Which means the binary evidence proves code lineage — the same builder, the same template — and proves genuinely shared infrastructure only up to 2019. That's a lot, but it isn't the same thing. That it's the same person in 2015 and in 2026 is likely, not proven.
hostasa.org is backWhat's above was true until August 2025. Not any more. RDAP says somebody re-registered the domain on 4 August 2025, and today it resolves: hostasa.org and aa.hostasa.org both point at 34.41.139.193. seen

So the sentence holds for the 2025 samples up to that August, and stops holding after it: any bot still dragging that string around today is talking to somebody.

To whom, I don't know, and I'm not going to guess. What I can say is how that address behaves: it's a Google Cloud host answering nginx 200 on hundreds of ports. That profile isn't a delivery server's; it looks far more like a research sinkhole, the kind somebody stands up to see who is still calling. deduced

And on either reading — whether the operator got it back or a researcher picked up the corpse — it reinforces the lineage argument: that somebody would pay to revive a domain dead since 2019 says the name is still worth something.

A detail with its own irony: the 2015 landlord was called ClearDDoS Technologies.

08The branch that isn't mine

This is where to slow down, because it's the point where overreaching would be easiest. Alongside the lineage I've just described there's a second one, which shares things with it and which is not attributed.

Five domains — enoan2107.com, gzcfr5axf6.com, myserv012.com, checkokdomain.com and monstervp.com — have shared the same pair of name servers since 2019 and, more importantly, travel the same machines on the same dates for five years. Three of them land together on 103.254.75.120, in Hong Kong, on 18 March 2024. They're still there. seen

Measure the signal before believing itOf the four name servers on that account, two are shared by thousands of unrelated domains that have nothing to do with any of this: on their own they mean nothing. What actually groups by account is the specific pair formed by the other two, and I checked that against third-party domains before accepting it. It's the discipline that runs through the whole case: ask how many hosts have this same property without being my target.

In favour of it being the same hand: they share the same configuration host as the atat456 binaries, aa.hostasa.org, and they share the 2015 DNS column. Against, and it weighs heavily: their landlord rotation never touches ours at any point, and between the two branches there is not a single address overlap. Exactly the opposite of the sibling cluster, where the overlap was 87%.

With that on the table, the only thing that holds is same operation, different division. inferred And there I stop. It's the question this case leaves open, and forcing it would be precisely the mistake I've spent the whole investigation trying not to make.

A warning that applies to the whole familyenoan2107.com was registered in 2021 and gzcfr5axf6.com in 2016. They are not, therefore, "the classic 2014-2015 domains", however often they're cited as such in this family's literature. The ones from that era are hostasa.org and the dsaj2a branch.

09The landlords, all the way up

The method is the same one from the beginning, and it's boring on purpose: from the address to the hosting, from the hosting to whoever owns the space, and from them to whoever rents it to them. All the way up.

Where the command server lives today we've already seen: Lithuania, a small reseller. What I hadn't said is what company it keeps. Of the 500 recent scans urlscan holds for that network, 71% are fake pharmacies — 85 distinct domains — and another 5% are casino impersonations. Our operator is a minority tenant there. seen

Bias declaredurlscan measures what people scan and report, not the house's real traffic. It's good for portraying the neighbourhood, not for taking its census.

Where the Hong Kong branch lives is two separate network numbers that are really the same house: same administrator, same phone, same mailboxes, and one giving transit to the other with China Telecom above them. Of their hundred most recent scans, 87 carry an impersonated brand in the domain name itself — WhatsApp, OKX, Bitpie, DeepSeek. Their administrative mailbox points to a domain they let expire, now parked in the Netherlands. The abuse one does work, and it's a free Outlook account: for two networks and some nine thousand addresses.

And where the loader lives — the machine that actually does the infecting — there are four floors for a single box:

169.239.130.20 · four floors
space ..... South African AFRINIC, registered 2021
holder .... Zappie Host — Trinity House, Victoria, Seychelles
announced . AS49870 Alsycon B.V., Netherlands
resold by . HostMayo — 126 machines in the /24, nearly all SSH-only

African space, owner in the Seychelles, Dutch announcement, resold as cheap boxes. And the bottom rung paints its own portrait: Zappie Host rents from $4.50 a month in New Zealand, South Africa and Chile — the odd-geography niche — throws in routing sessions free to anyone who asks, takes PayPal and bitcoin under the verbatim pitch "bitcoin, Where privacy matters", and publishes no abuse policy. You don't need a purpose-built bulletproof host when this exists for the price of two coffees.

That box runs Apache on Ubuntu, its root returns a 403, and the only thing that answers is new.php. And it has an external check tying it to my honeypot: urlscan scanned it before I ever saw it and came away with 114,144 bytes — exactly the size of the binary that landed on me that August night. Eighty-two days serving the same payload from the same place, verified by somebody who isn't me. seen

And here comes the contrast that portrays him best, and it comes out of my own honeypot. Of the binaries I kept from that week, thirteen are the 1608-byte droppers I mentioned at the start. The only thing that changes between them is the download names: 156 distinct names across the thirteen, not one repeated, all pointing at the same Dutch machine. That campaign manufactures a fresh script and twelve fresh addresses on every delivery, so that no hash- or URL-based blocklist is any use to anyone. seen

Our operator does the exact opposite. One single address, untouched for eighty-two days. The same domains renewed since 2015. The same key since 2014.

It's not that he doesn't know how to do the other thing — when five of his domains went down at once in February, he had the replacement running in three days. It's that with these he doesn't need to. inferred

The asymmetry I can't explainThe five domains suspended in February were from 2024 and had, as far as I know, not a single public report on them. The 2015 ones have been in Unit 42's report, in Talos's, and even on official Chinese blocklists for years — and there they still are, live, renewal paid through to 2027. What is unknown gets taken down; what is documented is left alone. I don't know why. visto

10I had the wrong decade

With the Hong Kong landlords I came close to slipping one of the invisible errors into this text, because the fact isn't false: it's a true fact placed in the wrong year.

I had written that the space belongs to an address wholesaler and is announced by a Hong Kong company that sells, among other things, DDoS protection. And that's true. Today. The trouble is that branch's command server lived there in 2022 and 2023, and I was describing those years with a 2025 photograph. Internet registries, by default, only show the current state: who owns it now. Asking them about the past is a different matter.

What does answer "who was announcing this range on that date?" is the BGP history. And it answers with dates:

who announced each range, and since when
23.235.171.197  C2 2022-2024  →  AS136800 MOACK.Co.LTD (Korea) + AS40065 CNSERVERS
                                  2021-06 → 2024-03
23.248.237.29   C2 2022       →  AS136800 MOACK.Co.LTD   2021-06 → 2023-12
43.249.172.214  C2 2022       →  AS136800 MOACK.Co.LTD   2021-06 → 2023-12

The landlord back then was MOACK, a Korean company, with a US co-announcer. Not the ones from now. seen

And correcting the error turned up something better than the error. The company that announces that space today doesn't start doing so until 18 March 2024 — precisely the month the Hong Kong branch abandons those ranges and jumps to another house. The operator moved out, roughly, when the house changed owner. I'm not forcing the causation, but the coincidence of dates is there.

A finishing touch, at my own expense: moack.net was already listed as a contact for one of those ranges in my own notes, written three hours earlier that same night. It was the thread running through it and I had it in front of me without seeing it.

The irony I dropped back at the origin also takes another turn. The 2015 landlord was called ClearDDoS; the company that holds the Hong Kong space today sells DDoS protection. I don't offer that as complicity, but as a description of the market: whoever sells mitigation owns exactly the network whoever sells attacks needs.

For the record, with its dateThe names, since every other landlord in this case gets theirs: today that space is announced by Yancy Limited (AS138415, Hong Kong), which sells transit, address leasing and DDoS protection, and its holder in the American registry is RedLuff, LLC, an address broker with fifteen blocks and nearly 41,000 addresses. Neither had anything to do with this space in 2022 and 2023, which is the period that matters here: Yancy's network number and RedLuff's registry objects are both later. I name them because I name every other landlord, not because there is anything to pin on them.

11Who this actually hits

Throughout the investigation the most obvious question was missing. This is a machine for doing harm: who does it harm?

The only available list is the 171 addresses Cisco Talos published alongside its report. I resolved reverse DNS on all of them; 61 answered. The result doesn't leave much room for interpretation:

who's on the other end
c-73-95-47-244.hsd1.co.comcast.net  a house in Colorado
fl-69-69-2-11.dhcp.embarqhsd.net    a house in Florida
p5b360a39.dip0.t-ipconnect.de       a house in Germany
189-47-95-188.dsl.telesp.net.br     a DSL line in Brazil
2-77-15-250.kcell.kz                a mobile in Kazakhstan
233.226.205.221.adsl-pool.sx.cn     an ADSL line in China

47 % of the ones that answer are residential connections. These aren't data centres: they're ordinary people's home internet, across five continents. seen

And it fits what the DDoS-for-hire market actually is. A booter isn't hired to bring down infrastructure: it's hired to kick someone off the internet — a rival in a game, a personal dispute, someone you want to shut up. inferred

Eleven years of infrastructure renewing itself, and a trail of landlords across half the world, to knock out someone's house in Colorado.

An anomaly I'm not calling solvedEleven of those addresses sit in US Department of Defense space, and none has reverse DNS. Those ranges are the classic place to spoof the source addresses of an attack, precisely because nothing comes back. So most likely those eleven aren't victims but forged origins that slipped into the list. inferred It can't be settled with this data — but calling them "targets" and leaving it there would be exactly the mistake I've spent the whole case trying not to make.
It doesn't always come in the back doorMy honeypot watched it come in by SSH brute force, the classic route for this family. But it isn't the only one: in 2020 Tencent documented that someone registered a domain impersonating rinetd — a legitimate port-forwarding tool — and served a trojanised copy from it that pulled XorDDoS down by itself. A supply-chain poisoning. And the command-server list in that analysis contains, one by one, this operator's domains. read

12The money, and the human who doesn't show up

This isn't a hobbyist with a trojan. It's a product that gets sold: there's a control panel, a builder and several versions, with sales pitches translated from Chinese that are pure consumer-product language — "over 10,000 online with no lag". read

Where the business actually is doesn't appear in any Western report, but it does in an official Chinese CERT report from 2019. It describes, without naming it, the largest group in this family that year: it used "a large number of malicious domains containing specific strings", was linked to "a public organisation discovered in 2014", and served the pirate game-server, porn and gambling industries. Its command centres were mostly in France — our home base — and in November 2018 a single group was running more than 70,000 infected machines. seen, read from the original PDF

That's the market: not espionage or sabotage, but wars between underground businesses DDoSing each other.

And the person? The panel's creator left a messaging contact and an alias inside it. Talos, who found them, doesn't publish them — not the data, not even the hash of the file they're in. So the wall isn't "they don't distribute the sample": it's that the artefact isn't publicly identified at all. There's no door to force.

Though in the Chinese-speaking world he isn't a stranger. The Chinese state network-security notification centre publishes blocklists, and in July 2025 one of them carries a subdomain of this cluster, with the family named. seen And there are Chinese analysts who have already named the group — they call it by the same string I do, ata — and credit it, with just two domains, with two out of every three attack orders in the whole family. That last figure I couldn't verify: the article sits behind an anti-bot wall and all I've seen is the search-engine snippet. read, unverified

A logical leap worth flagging before the reader doesThat contact and that alias are in the central panel: they belong to whoever built and sells the product. Our operator could perfectly well be one of its customers — there are a dozen different server sets using the same builder. Treating them as "our operator's face" would be joining two different people together. I'm not doing that.

13The circle closes

With the corpus decrypted and the technique in hand, it was time to do the thing I hadn't done: apply it to the binary my own honeypot caught — the one filed as Gafgyt.

That I still had it isn't luck, and it has its funny side. After that visit I set a watchman on the lab: a script that listens to the downloads directory and copies every sample the instant it appears, with a rule never to delete — because Cowrie rotates fast and whatever you don't copy is gone. In its comments, explaining the hurry, I wrote "the Gafgyt in chapter 1 did it in 62 seconds". The sample now disproving that label was saved by a tool that exists because of it.

my own sample's configuration
https://api-metadata-v6.is/config.rar
telemetry-pipe.sh:1529|api-metadata-v6.is:1529|sys-kernel-update.to:1529

That's exactly the server set launched in February 2026. sys-kernel-update.to resolves to 141.98.11.51 — the Lithuanian box, right next to the 2015 domains. seen

I went all the way round — an IP, a landlord, a tenant, a family, 113 other people's samples, eleven years of moving house, reports from half the world — to come back to the starting point and find that it was already there.

The honeypot wasn't the beginning of a road leading somewhere else. The honeypot had the operator in its hands from day one, wearing the wrong name.

Who else is watching thisPublic feeds watch in bursts. February's Icelandic domains were flagged by someone the same day they were registered — there are automated trackers watching new registrations. Meanwhile the five domains of the sibling cluster have not a single record in the feeds I can query, and neither do three of the five in Hong Kong. There are parts of this operation that have been running for years with nobody looking. seen
Still trueI resolved all seven names again. All seven land in the same box, 141.98.11.51 — the six from the 2015 cluster and sys-kernel-update.to, which is the C2 I pulled out with Ghidra back in Chapter 2. seen

It wasn't an August snapshot: twelve days on, everything is still where it was.

And the ending, which isn't the one I wanted but is the one there is: this isn't a faceless botnet. It's a face a third party saw, that I can't read and that probably isn't even my operator's but that of whoever sold him the software.

And it would be quite the joke if some bloke with a laptop had put a name to him where a multinational in the trade couldn't. But that's not what happened.

To be continued — the honeypot is still on. So is the tenant. 🍯

Comments