The Dual-Origin Prefix: One /24, Two Autonomous Systems, One Maintainer

TI-2026-088F — Bulletproof Hosting series · Addendum to TI-2026-088 "The DMZHOST Trinity"

Confidence: HIGH — the finding is present verbatim in the live RIPE database, reproduced on direct query, not reconstructed from correlated signals.

The finding in one paragraph

The parent dossier argued that two "separate" autonomous systems — AS47890 (UNMANAGED LTD) and AS48090 (DMZHOST / TECHOFF SRV LIMITED) — are one bulletproof operator wearing two corporate faces. The argument rested on shared names, a shared Gmail abuse desk, and a shared Spamhaus judgement. This addendum supplies the one piece of evidence that does not depend on inference at all: in the RIPE Internet Routing Registry, the prefix 2.57.122.0/24 carries two live route objects at once — one declaring origin AS47890, the other declaring origin AS48090 — and both are authenticated by the same maintainer, TECHOFF-MNT. In RPSL, only the holder of a maintainer's credentials can create a route object. Two origin claims for one prefix, signed by one maintainer, is not a coincidence you can explain away with "shared tooling." It is one entity holding the keys to both autonomous systems and pre-authorising itself, in RIPE's own database, to fly the same address space under either flag. That is the network-layer merge the whole series has been circling, stated by the registry itself.

1. What RPSL actually says — and why it cannot be faked sideways

A route: object in the RIPE database is a small, specific assertion: this prefix is legitimately originated by this autonomous system. It exists so that route-origin validation and IRR filtering can distinguish a real announcement from a hijack. Two fields matter here:

• origin: — the AS number permitted to announce the prefix.
• mnt-by: — the maintainer object whose credentials authenticated the route object's creation. RIPE will not insert or modify a route object without a valid signature from the referenced maintainer.

That second field is the load-bearing one. You cannot register a route object for someone else's prefix, and you cannot register one under a maintainer whose password you do not hold. So when the same maintainer signs two route objects for the same prefix naming two different origin ASes, the registry is telling you something it is designed to make hard to fake: the same credential-holder controls the origin claims for both AS47890 and AS48090 over this address space.

2. The record, quoted

RIPE whois/RDAP for 2.57.122.0/24, queried 2026-07-21:

Both route objects are live in the database simultaneously. The AS48090 origin object was created first, in June 2020; the AS47890 origin object was added two years later, in August 2022. The chronology matters — it is the operator extending an existing prefix's origin set to a second, newer ASN, not two independent networks that happened to collide. One maintainer, one prefix, two origins, added deliberately, two years apart.

[DOCUMENTED] 2.57.122.0/24 carries route objects for both AS47890 and AS48090, both maintained by TECHOFF-MNT. The prefix is portable between the two ASNs at the operator's discretion, with RIPE's own IRR pre-authorising the flip.

3. The two autonomous systems it flips between

The dual-origin prefix binds together two ASNs that the registry otherwise presents as unrelated GB companies:

Read the allocation dates against the route-object dates and a sequence emerges. AS48090 is the elder — allocated September 2019, its route object on the prefix from June 2020. AS47890 arrives later — allocated July 2020, its route object added August 2022. The platform's own entity-resolution classifier, working independently of this analysis, tags AS48090 a rebrand and AS47890 a front. That is exactly the shape the dual-origin object describes: an older network (AS48090/DMZHOST) that acquired a newer, cleaner-looking companion (AS47890/UNMANAGED LTD) and wired the second one into the same address space. Both are on Spamhaus ASN-DROP — the registry's most severe network-level judgement, "treat all traffic as hostile by default" — and both are classified bulletproof at ~95/100. The dual-origin prefix is the seam where the two halves of one operator are stitched together.

4. What lives on the prefix — the scale of a single node

2.57.122.0/24 is not a dormant registration; it is a working attack surface. Its busiest node, 2.57.122.238, is a study in volume:

• AbuseIPDB: 100/100 confidence across ~81,795 reports (climbing daily — an earlier crawl recorded 81,943). That is tens of thousands of distinct other networks independently reporting this one address.
• On our own honeypot: 689 hits, threat score 100, first seen 2026-07-01, still active 2026-07-21. Open services SSH/22 and Apache 2.4.41 on 80; fingerprinted go_scanner, HASSH 2ec37a7cc8daf20b10e1ad6221061ca5.
• ISP field: TECHOFF SRV LIMITED; usage type "Data Center/Web Hosting/Transit"; geolocated RO despite the GB registration.

It does not act alone. The /24 fields a coordinated cluster — 2.57.122.150 (219 hits, threat 99), 2.57.122.168 (268 hits), 2.57.122.209 (139 hits, threat 100) — three of which the behavioural classifier labels botnet / c2_infrastructure and one scan / brute-force, all sharing the same registrant org (TECHOFF SRV LIMITED) and the same Gmail abuse desk. Across the prefix the honeypot logged 134 distinct credential pairs over 673 sessions, and the wordlist is worth a second look.

5. The wordlist's tell — hunting crypto, not just servers

The credentials sprayed against 2.57.122.0/24 are not only the generic root:123456 staples of the wider cluster. They include a distinct, targeted seam aimed at cryptocurrency and blockchain infrastructure: node:ethereum, solana:solana, validator:validator, and similar validator-node and wallet-daemon defaults. That is a deliberate targeting choice. Generic credential stuffing casts for any weak login; a wordlist salted with validator:validator and solana:solana is fishing specifically for staking nodes, RPC endpoints, and validator boxes — machines that, once accessed, sit on or near real funds. The dual-origin prefix is not just bulletproof address space; it is bulletproof address space being pointed, in part, at the crypto economy. This is a narrower, higher-value intent than the cluster's baseline password-guessing, and it rides on the same infrastructure the route objects expose.

[DOCUMENTED] The 2.57.122.0/24 credential set includes crypto/validator-node lures (node:ethereum, solana:solana, validator:validator) alongside generic weak-password stuffing.

6. The prefix's provenance — older than the shell that holds it

The dual-origin object is not the prefix's first anomaly; the prefix has a lineage, and it predates the company that now holds it. The inetnum for 2.57.122.0/24 was created 2019-03-21, but its current organisation object (TECHOFF SRV LIMITED) dates only to 2024-11-20. Something held this address space for five years before TECHOFF SRV existed. Team Cymru's independent "Jingle Shells" research (December 2024) traced that earlier holder: until 2024-10-04, 2.57.122.0/24 was associated with PPTECHNOLOGY LIMITED, a UK company dormant since its August 2019 registration and sharing TECHOFF SRV LIMITED's registered address. The sequence is a clean shell substitution: a dormant shell (PPTECHNOLOGY) parks the prefix → the org handle on the prefix changes on 2024-10-04 → a fresh shell (TECHOFF SRV LIMITED) is incorporated on 2024-11-20 → the RIPE org object updates to TECHOFF SRV on 2024-11-26. New nameplate, same address, same address space, same maintainer.

Team Cymru's report also fixes what runs on the prefix in terms this dossier will not soften: it identifies 2.57.122.72 as a Metasploit command-and-control server, "assigned to AS47890, operated by UNMANAGED LTD." That is an independent, prior (December 2024) observation of offensive C2 infrastructure sitting inside the exact dual-origin prefix examined here — corroboration from outside the LSN telemetry entirely. The prefix is not abstract bulletproof inventory; it has carried a Metasploit C2, it has churned through a dormant-shell substitution, and it remains co-signed to two ASNs by one maintainer. Each of those is a separate red flag; together they describe address space engineered to outlive scrutiny.

[DOCUMENTED] 2.57.122.0/24 inetnum predates its current holder (created 2019, org 2024); Team Cymru independently placed a Metasploit C2 (2.57.122.72) on it and traced the prior holder PPTECHNOLOGY LIMITED (handle changed 2024-10-04). [INFERRED] the PPTECHNOLOGY → TECHOFF handover was a premeditated shell substitution rather than administrative lag.

7. Seven questions

Q1. Couldn't two unrelated networks legitimately originate the same prefix (multi-origin routing)? Multi-origin AS (MOAS) exists, but it is a red flag, not a routine state, and it is almost always different maintainers — two organisations that genuinely share an anycast prefix each sign their own route object. Here a single maintainer signed both. That is not shared routing; it is one hand holding both pens.

Q2. Why keep both route objects live instead of just moving the prefix? Because keeping both valid is the point. With both origins pre-authorised in the IRR, the operator can shift the announcement from AS47890 to AS48090 (or back) the instant one ASN gets more heavily filtered or blocklisted — no registry change, no propagation delay, no window where the prefix is unroutable. The dual-origin object is the failover mechanism for a network that expects to be blocked.

Q3. Is TECHOFF-MNT on both objects really dispositive? It is the strongest single fact in this dossier. A maintainer is a credential. RIPE authenticates every route-object write against it. Two writes, two origins, one credential means one credential-holder — and credential-holding is control. Everything else in the series (shared names, shared Gmail, shared tooling) is corroboration; this is the load-bearing joint.

Q4. The prefix is registered NL, the org is GB, the IPs geolocate RO — which is real? All and none, and that incoherence is itself the finding (see [TI-2026-088I on jurisdictional arbitrage]). For this dossier the geography is beside the point: the route objects and maintainer are unambiguous regardless of where any packet claims to originate.

Q5. A node with 81,795 AbuseIPDB reports — hasn't it been dealt with? No — and that is what "bulletproof" means. Tens of thousands of abuse reports and an ASN-DROP listing are precisely the pressure that a bulletproof host is built to absorb. The dual-origin object exists so the operator can keep the prefix routable through that pressure. Reports accumulate; the address stays up.

Q6. Why does the crypto wordlist matter if it's just guessing? Because targeting reveals intent, and intent guides defence. root:123456 says "we'll take any box." validator:validator says "we specifically want your staking node." A crypto exchange, a validator operator, or an RPC provider seeing this prefix in their logs should read it as a directed attempt at their sector, not ambient noise.

Q7. What would break this finding? A single change to the RIPE record — one route object removed, or the two objects shown under different maintainers. Neither is the case. The record reproduced cleanly on direct query on 2026-07-21, both objects present, both signed by TECHOFF-MNT. Until RIPE says otherwise, the merge is documented.

8. The counter-narrative, steelmanned — then defeated

Steelman: "Route objects are stale artifacts. Networks leave old route objects lying around for years after a prefix moves; the AS48090 object is probably a leftover from before UNMANAGED LTD took over. You are reading two eras of one prefix as if they were simultaneous, and calling routine IRR cruft a conspiracy."

Defeat: Stale objects are a real phenomenon, and if the two objects were under different maintainers the leftover explanation would deserve serious weight. They are not. Both are mnt-by: TECHOFF-MNT — meaning whoever holds TECHOFF-MNT today is the party that signed both, and has left both live. A genuinely superseded origin would typically be cleaned up by the incoming holder or sit under the previous holder's maintainer; instead the current maintainer keeps a valid AS47890 origin and a valid AS48090 origin side by side. Leftover cruft does not stay co-signed by the same active credential across a two-year gap and a corporate rebrand. The tidiest explanation is also the registry's plain reading: one operator, two ASNs, one prefix it can fly under either.

9. Read between the lines

Everything expensive about this operation — the UK shells, the virtual offices, the Gmail abuse desk, the RDAP geography — is facade, built to make the network look like two ordinary hosting companies. The route objects are plumbing, built to make the network work. Facade can lie; plumbing has to function. The operator could give the two ASNs different names, different directors, different registered countries, and did — but it could not give them separate routing without breaking the one thing the whole business depends on: the ability to keep a heavily-blocklisted prefix reachable. So it wired both ASNs to the same prefix under one maintainer, and in doing so left, in RIPE's own database, the single artifact the corporate disguise cannot cover. The lie is in the company registry; the truth is in the routing registry. And that asymmetry is general, not particular to this operator: a bulletproof host can rename its companies at will, but it cannot renumber its resilience. Wherever you find a network built to survive being blocked, look first at the maintainer that signs its route objects — that is where the shell game runs out of shells, because the one thing an operator cannot delegate to a disposable front is the credential that keeps the packets flowing.

10. What if

What if a filtering party treated TECHOFF-MNT — the maintainer — as the unit of enforcement, rather than either ASN or the prefix? Blocklisting AS47890 alone leaves AS48090 to carry the prefix; blocklisting the prefix invites the operator to burn it and register another under the same maintainer. But the maintainer is the constant across both ASNs and every route object they sign. An IRR-aware defender who keys on TECHOFF-MNT catches the failover before it happens and sees the next prefix the day its route object is signed. The dual-origin object is the operator's resilience feature; the maintainer that signs it is the operator's single point of exposure.

11. Documented vs inferred — the honest ledger

12. Infrastructure & IOCs

Prefix        2.57.122.0/24   netname DMZHOSTdotco | org TECHOFF SRV LIMITED (ORG-TSL73-RIPE)
                             mnt-by TECHOFF-MNT | abuse dmzhostabuse@gmail.com | inetnum created 2019-03-21
  route obj   origin AS48090  mnt-by TECHOFF-MNT  created 2020-06-30
  route obj   origin AS47890  mnt-by TECHOFF-MNT  created 2022-08-06   <-- dual origin, one maintainer

AS48090   DMZHOST / TECHOFF SRV LIMITED (GB)   allocated 2019-09-05 | ASN-DROP | risk 94.96 | verdict rebrand
AS47890   UNMANAGED-DEDICATED-SERVERS (GB)     allocated 2020-07-27 | ASN-DROP | risk 96.946 | verdict front

2.57.122.238  AbuseIPDB 100 (~81,795 reports) | honeypot 689 hits | Apache 2.4.41 | HASSH 2ec37a7cc8daf20b10e1ad6221061ca5
2.57.122.150  219 hits threat 99   | 2.57.122.168  268 hits | 2.57.122.209  139 hits threat 100
Prefix wordlist tell:  node:ethereum · solana:solana · validator:validator  (crypto/validator targeting)

Durable pivot:  maintainer TECHOFF-MNT (signs both route objects; the failover's single point of exposure)

Defensive action: treat AS47890 and AS48090 as one operator — blocklisting one without the other leaves the dual-origin prefix reachable via its sibling. Where your tooling is IRR-aware, key detection on the maintainer TECHOFF-MNT, which spans both ASNs and every route object they sign. Crypto-sector operators (exchanges, validators, RPC providers) should treat traffic from 2.57.122.0/24 as directed reconnaissance of their infrastructure, not ambient noise.

13. Sources

RIPE NCC RDAP / whois IRR (inetnum, org, maintainer, and both route objects for 2.57.122.0/24; aut-num records for AS47890/AS48090), queried 2026-07-21; Spamhaus ASN-DROP (AS47890/AS48090); AbuseIPDB (2.57.122.238); LSN honeypot session, fingerprint, and credential capture for the 2.57.122.0/24 nodes; LSN entity-resolution classifier (front/rebrand verdicts). All routing claims reproducible from public RIR/IRR data. TLP:WHITE.