LSN โ€” Local Sovereign Network

Executive Summary

Across the five providers documented in this series โ€” Tencent/Aceville, BytePlus/ByteDance, Yisu Cloud/Cloud Innovation, UCloud, and CDS Global โ€” we track 417 IPs with 253 at maximum abuse confidence generating 2,180 honeypot attacks across 18 countries. The abuse report success rate against this infrastructure is effectively zero. This is not a technology failure โ€” it is a structural design. The reporting mechanisms that form the internet's immune system were built for a world where hosting providers share jurisdiction with their victims. These providers have engineered themselves to exist in the gaps between jurisdictions, where no enforcement mechanism reaches.

The Aggregate Threat

417
Total IPs tracked
253
At abuse confidence 100
2,180
Honeypot attacks
0%
Effective response rate

How Abuse Reporting Is Supposed to Work

The internet's abuse reporting system operates on a simple chain:

  1. Detection: Victim identifies malicious IP via logs/honeypot
  2. Lookup: WHOIS/RDAP query reveals responsible organization and abuse contact
  3. Report: Formatted complaint sent to abuse@ contact with evidence
  4. Action: Provider investigates, warns/terminates offending customer
  5. Resolution: Attack ceases; repeat offenders are deplatformed

This system works when the provider: (a) is reachable, (b) is accountable to some jurisdiction, (c) has commercial incentive to maintain reputation, and (d) can identify and terminate the responsible customer. The Cloud Silk Road providers have eliminated all four conditions.

The Five Failure Modes

1. The Fake Contact (CDS Global, UCloud)

CDS Global's ARIN registration contains no valid abuse contact beyond the standard ARIN-assigned address. UCloud's APNIC registration uses +000000000 as the phone number. When the registration itself contains fabricated information, there is no human reachable by the standard reporting chain.

Result: Reports sent to ARIN/APNIC standard addresses are processed by automated systems with no enforcement authority over the provider.

2. The Jurisdictional Loop (Yisu Cloud / Cloud Innovation)

Abuse report path: Victim โ†’ Cloud Innovation Support (Seychelles phone) โ†’ LARUS Limited (HK technical manager) โ†’ Cloud Innovation Ltd (Seychelles holding company) โ†’ back to Cloud Innovation Support. The loop is self-referential. There is no external party with authority to compel action.

Result: Reports enter a circular routing path between entities controlled by the same beneficial owner across two jurisdictions with no enforcement cooperation.

3. The Wrapper Entity (Tencent/Aceville)

Aceville Pte Ltd (Singapore) is the registered entity for AS132203. Abuse reports go to Aceville โ€” a company whose sole purpose is to hold Tencent's international IP allocations. Aceville has no autonomous compliance function. Tencent China, the actual operator, is one corporate layer removed and in a jurisdiction that does not recognize foreign abuse complaints.

Result: Reports reach a wrapper entity with no independent authority to terminate customers on infrastructure it doesn't operationally control.

4. The Legal Shield (BytePlus)

BytePlus abuse contacts route to @bytedance.com. ByteDance is subject to PRC Data Security Law Art. 36: cannot provide data to foreign judicial/enforcement bodies without PRC government approval. An abuse report from a European victim requesting action on BytePlus Singapore infrastructure requires traversing a legal chain that includes PRC government approval โ€” which will never be granted for routine abuse.

Result: Reports reach an entity legally prohibited from cooperating with foreign enforcement without state permission.

5. The Volume Overwhelm (All Providers)

Even automated abuse platforms (AbuseIPDB, GreyNoise) cannot generate actionable pressure. When 253 of 417 IPs (61%) are already at maximum abuse confidence, the reporting system is saturated. Multiple independent reporters have flagged these IPs. Nothing happened. The signal exists โ€” but there is no receiver.

Result: The abuse reporting ecosystem has documented the problem exhaustively. Documentation without enforcement is surveillance without consequence.

The Budapest Convention Gap

The Council of Europe's Budapest Convention on Cybercrime (2001) is the primary international treaty for cyber offense cooperation. Critical gaps:

  • China is not a signatory โ€” refused to join, citing sovereignty concerns
  • 68 signatories exist โ€” but mutual legal assistance between them takes 6-18 months average
  • The Seychelles is not a signatory โ€” Cloud Innovation's jurisdiction is outside treaty reach
  • Hong Kong SAR's status is ambiguous โ€” post-2020 National Security Law complicates cooperation
  • Singapore is a signatory โ€” but Aceville and BytePlus route enforcement requests to non-signatory parents

The jurisdictional architecture is not accidental. It is specifically designed to place the operational entity (China) outside treaty reach while the registration entity (Singapore/Seychelles/US) provides just enough legitimacy to acquire IP allocations.

Per-Provider Breakdown

ProviderASNIPsAbuse=100Contact MethodFailure Mode
Tencent/Aceville132203181156Singapore wrapperWrapper Entity
UCloud13537714748Fake phone +000000000Fake Contact
BytePlus1504365029@bytedance.comLegal Shield
Yisu/Cloud Innovation138152+1424033516Seychelles loopJurisdictional Loop
CDS Global6319944ARIN genericFake Contact
TOTAL417253Combined: 0% resolution

What Would Work (But Doesn't Exist)

Effective countermeasures would require:

  • RIR allocation conditioned on verifiable contact: APNIC/ARIN/AFRINIC could require functioning phone numbers and mandatory response SLAs. They don't.
  • BGP community-based reputation: Upstream transit providers could depeer ASNs with >50% abuse rate. Commercial incentives prevent this.
  • Cross-RIR entity linking: APNIC, ARIN, and AFRINIC could share beneficial ownership data to reveal that Cloud Innovation (AFRINIC), Yisu Cloud (APNIC), and CDS Global (ARIN) are the same network. No mechanism exists.
  • Treaty coverage of cloud infrastructure: An updated Budapest Convention covering cloud provider obligations in non-signatory jurisdictions. Diplomatically impossible given US-China relations.
  • Automated depeering thresholds: Tier-1 transit providers could implement automated threshold-based depeering when abuse metrics exceed community-agreed levels. No standard exists.

Every effective countermeasure requires cooperation between entities that have no incentive to cooperate. The gap is structural, not technological.

The Economic Incentive Inversion

Why Nobody Fixes This

The economic model is inverted. The entities with power to act (transit providers, RIRs, IXPs) are compensated for connectivity โ€” more traffic means more revenue. The entities harmed (victims, honeypot operators, abuse teams) have no purchasing power in the routing market. The attackers are customers. The victims are not.

Until the cost of hosting attack traffic exceeds the revenue it generates, the regulatory gap will persist. Currently, the cost is zero (no depeering, no fines, no prosecution) while the revenue is substantial (bulletproof hosting commands premium pricing).

Methodology & Sources

Aggregate data from: LSN threat_intel database (417 IPs across 6 ASNs), AbuseIPDB (253 at confidence 100), GreyNoise (malicious classifications), honeypot (2,180 recorded attacks). Legal framework: Budapest Convention on Cybercrime (2001), PRC Cybersecurity Law (2017), PRC National Intelligence Law (2017), PRC Data Security Law (2021). Prior investigations: TI-2026-026O (96% abuse report failure rate), TI-019G (systemic failure analysis), DOSSIER-PRIVATE-CUSTOMER-001 (closed-loop abuse reporting). Economic analysis from industry observation and PeeringDB transit relationship data.

โš  Personal capacity. Research published independently โ€” not reflecting employer views. Derived from passive observation of attacks against personal infrastructure. Full disclaimer โ†’
โ† Previous The Cloud Silk Road โ€” 6 / 10 Next โ†’