The Chinese Ecosystem Part B — Yisu Cloud: 100% Abuse Rate and the Seychelles Phone Number

This article treats Yisu Cloud not as a stray anomaly but as the operational face of the larger architecture. The phrase matters. The operational face is the layer that customers see, criminals rent, investigators encounter, and defenders block. It is the part that turns a corporate shell game into live malicious traffic. In the wider Chinese corpus for this series, 710 Chinese IPs across 84 ASNs were observed; 117 of those IPs were pinned to abuse confidence 100. State telecoms accounted for 65% of the observed Chinese attack surface. Big Tech accounted for another 24%. AS4134 alone contributed 115 IPs with roughly 90% of them scoring as abusive. Baidu contributed 79 IPs with a 100% abuse rate in the observed sample. ByteDance contributed 54 IPs with 100% abuse. Tencent contributed 9 IPs with 100% abuse. The macro pattern is already ugly. Yisu matters because it shows what that architecture looks like when the mask comes off and the ratio approaches purity.

The phone number is the hinge. A Seychelles number, +248-4-610-795, appears as a contact artifact across more than fifteen autonomous systems, through at least eight organization names, spanning the Cloud Innovation / LARUS / Yisu environment. A single shared phone number is not, by itself, proof of criminal intent. Companies outsource registration. Providers recycle contact details. Resellers inherit stale records. But those explanations become weak when the same contact artifact appears in combination with a perfect abuse-rate sample, a narrow peering profile, repeated Hong Kong and Seychelles identity shifts, and a documented tendency to fragment names while keeping the operational substrate intact. Any one clue might be survivable as coincidence. The cluster is not.

The analytical standard in this piece is evidence, not theater. Nothing here requires a leap into secret ownership theories or unprovable state command narratives. It is enough to say what the records support. The Yisu layer exhibits a pattern of maximum-abuse scoring, contact reuse, organizational fragmentation, and constrained network topology that looks engineered for abuse tolerance rather than engineered in spite of it. That is the threshold question for defenders: not whether someone can draft an innocent explanation for each isolated artifact, but whether the full architecture still looks innocent when the artifacts are considered together. On that question the evidence is unusually direct.

That collapse matters more than the headline number itself. AbuseIPDB confidence 100 is not a decorative metric. It requires cumulative independent reporting, consistency over time, and the absence of meaningful counter-signal. An address can be malicious without reaching 100. Many do. A clean provider with one bad tenant can still produce some 100s if the tenant is aggressive enough. What is extraordinary is a provider-specific sample in which every scored address reaches the ceiling. That pattern says less about one offender and more about the environment that repeatedly permits the offender to exist, operate, and persist. The right question is no longer, “Was this IP used for abuse?” The right question becomes, “What sort of provider keeps reproducing IPs that all end up here?”

The dossier data is explicit. In the enriched Yisu sample, sixteen addresses drawn from AS138152 and AS142403 all returned AbuseIPDB confidence values of exactly 100. The concrete records include addresses such as 154.221.23.179, 154.92.17.58, 154.209.4.195, 154.221.20.92, 103.210.237.224, 154.83.16.14, 103.100.211.40, 154.209.4.208, 154.221.17.137, 39.109.104.252, and 103.146.159.173. These are not one-report curiosities. Several carry thousands of reports, not dozens. Some show high shares of categories consistent with mass scanning, SSH credential attacks, and repeated malicious automation. The telemetry is emphatic because the infrastructure is emphatic.

It is worth being precise about what this does and does not prove. It does not prove that every system ever hosted by Yisu Cloud is malicious. It does not prove that every operator behind every observed IP works for the same principal. It does not prove direct state tasking. What it does prove is narrower and, for defenders, more useful: the observed Yisu operational cluster repeatedly emits infrastructure that the outside world independently converges on as malicious with maximum confidence. Once that happens uniformly across a sample rather than sporadically within it, the analytical burden flips. The provider is no longer entitled to the assumption of ordinary abuse victimhood.

2. AS138152 and AS142403: The Operational Face

To understand why Yisu is the operational face of the architecture, begin with the layer that traffic actually traverses. AS138152 and AS142403 are the public routing identities that turn shell-company paperwork into reachable infrastructure. In RDAP, WHOIS-adjacent records, and BGP presentation, these ASNs anchor the Yisu brand. They are what appears when investigators pivot from attack logs into network ownership. They are what defenders see when they reverse-map a hostile IP. They are what abuse desks should see when they ask who is responsible. In a normal cloud business this layer is where clarity improves. With Yisu it is where clarity becomes multiplicative: the routing identity reveals not one company behaving badly, but a set of interlocking entities presenting different names over the same operational scaffold.

AS138152 is especially revealing. The June 2026 BGP profile cited in the evidence set shows 45 IPv4 prefixes, 11,520 IPv4 addresses, five BGP peers, and no IPv6. On its face that is not a hyperscale network. It is large enough to matter and small enough to remain curated. That combination is analytically useful. Small networks can, in theory, drift into abuse concentration if one or two bad customers dominate the space. But small networks with 45 prefixes and only five peers are also easier to police than sprawling global clouds. They have fewer interconnection pathways, fewer organizational seams, and fewer excuses. When such a network still produces a scored sample that converges on 100, investigators are looking at a provider that either cannot control its customer base or does not prioritize doing so. The rest of the record points toward the second explanation.

AS142403 complements rather than contradicts that picture. It expands the cluster, broadens the footprint, and helps show that the Yisu problem is not confined to one accidental block or one badly supervised product line. The published dossier places 71 IPv4 prefixes on AS142403, giving the pair a combined footprint of 115 announced prefixes. That is enough diversity to expect heterogeneity if the infrastructure were being used by an ordinary mix of customers. Instead, the scoring pattern remains unnaturally concentrated. Different ranges, same result. Different labels in the records, same result. Different investigative entry points, same result. The provider surface shifts, the operational signal does not.

There is also a strategic reason the AS-layer view matters. Corporate shells can be sold, renamed, or disclaimed. Routing behavior is harder to fake consistently because it has to keep carrying packets. If a provider repeatedly fragments its identity while maintaining coherent BGP presentation, that tension itself becomes evidence. In Yisu’s case, the brand-level label, the offshore support layer, and the routing identifiers do not point away from each other. They point into the same cluster. The infrastructure therefore behaves like a deliberately partitioned business model: one layer for legal distance, one layer for technical administration, one layer for customer-facing abuse exposure.

3. What 100% Abuse Confidence Means in Practice

Analysts often wave around abuse scores as if the number alone settles the argument. It does not. Scores are signals, not verdicts. But some signals are so strong that ignoring them becomes a methodological error. AbuseIPDB confidence 100 does not mean an address merely appeared in one blacklist. It means independent reports accumulated with enough weight and consistency to push the address to the ceiling. Some of the Yisu-linked IPs in the evidence set were reported thousands of times. Several show attack patterns aligned with SSH brute force, scanning, and sustained credential abuse. The issue is not that one vendor generated one opinion. The issue is that disparate observers kept running into the same infrastructure and describing the same kind of behavior often enough that the public scoring system exhausted its scale.

What would it take for a legitimate provider to produce this by chance? First, it would require an implausible concentration of abusive tenants within a bounded, manageable routing environment. Second, it would require those tenants to persist long enough, or be replaced quickly enough by similar tenants, that the addresses remain continuously reportable. Third, it would require the provider’s onboarding, monitoring, and response mechanisms to fail in essentially the same direction across the sample. Fourth, it would require that failure to coexist with repeated reuse of offshore contact artifacts and identity fragmentation. Each step is individually possible. The joint probability is the point. Coincidences do not merely add here; they compound into absurdity.

There is a temptation, especially among those who have never operated an abuse desk, to imagine that malicious traffic is just background weather that every hoster must endure. That view confuses occasional exposure with structural tolerance. Real providers show friction. Accounts are suspended. Ports close. complaints are answered, sometimes badly, sometimes late, but answered often enough to change the telemetry over time. Reputation scores rise and fall. Dirty pools are reallocated or quarantined. The reason Yisu stands out is not because it exists in a hostile internet. It is because the normal corrective mechanisms appear absent from the outcome data. The sample does not look like a provider struggling against abuse. It looks like a provider coexisting comfortably with it.

4. Representative Records: What the IP-Level Evidence Actually Shows

One of the strongest indicators that a hosting cluster is not merely unlucky is the texture of the underlying reports. Take 103.100.211.40, an address on AS142403 routed as 103.100.211.0/24. The dossier records YISU CLOUD LIMITED in RDAP, a Hong Kong country attribution across multiple sources, YISUCLOUDLTD-HK in Cymru-style ASN mapping, and YISU CLOUD LTD in AbuseIPDB. The abuse scoring is not marginal. Confidence is 100. Reports exceed a thousand. Distinct reporting users exceed five hundred. Categories cluster around mass scanning and SSH credential attacks. The included reports describe repeated port scanning, invalid-user login attempts, and attack behavior consistent with automated harvesting rather than a single human mistake. This is not an address that tripped a sensor once. It is an address that became familiar.

The same pattern repeats across other addresses in the sample. 154.92.17.58 is recorded with confidence 100 and more than three thousand reports. 154.209.4.195 carries confidence 100 with more than six thousand reports. 154.221.23.179 shows confidence 100 with more than two thousand reports. 154.209.4.208 approaches six thousand reports. 39.109.104.252 approaches five thousand. These are not edge cases cherry-picked because they are dramatic. They are representative precisely because they recur across the Yisu-linked space. If an analyst wants to defend the proposition that Yisu is a legitimate host merely suffering from abuse, the defense must explain not one bad server but an entire repeating gallery of aggressively reported addresses.

Notice also what does not appear in the same place. The records do not show a balancing sample of clearly clean Yisu infrastructure routed under the same operational identity and producing strong countervailing reputation. The dossier does note Yisu-associated infrastructure in the broader series data beyond the perfect-score subset, and it is correct not to pretend that the whole world equals the focal sample. But the question here is narrower. When investigators landed on the Yisu operational layer in the high-confidence subset, did they find statistical variety or behavioral convergence? The answer is convergence. The evidence does not say “some Yisu addresses are bad.” It says the scrutinized operational surface behaves like a service tier in which malicious use is normal enough to define the provider’s public reputation.

There is a second order point here for methodology. IP-level evidence is often dismissed because attackers rent, rotate, and discard infrastructure quickly. That is fair when one is trying to map ultimate ownership from a single transient box. It is not fair when the same provider repeatedly appears with the same kinds of reports, the same routing identities, and the same supporting artifacts. At that point the volatility of individual machines stops being a weakness and becomes part of the evidence. The churn itself is what a tolerant infrastructure sells: not permanence, but continuity of hostile service through replacement.

5. The Seychelles Phone Number as an Attribution Break

The most damaging artifact in the Yisu cluster is not a server banner or a leaked invoice. It is a telephone number. +248-4-610-795 is registered in Seychelles, the same jurisdiction that sits at the top of the Cloud Innovation chain documented in Part A. On its own, a phone number is soft evidence. Contact fields can be outsourced, inherited, or lazily copied from old records. But the value of a contact artifact rises when it persists across multiple layers of an infrastructure stack. In this case the number is not a stray entry. It is a pivot that reappears across Cloud Innovation Ltd, Cloud Innovation Support, and the Yisu-linked space, connecting more than fifteen ASNs through a single offshore administrative signature.

This is why the phone number is best understood as an attribution break rather than a curiosity. The corporate story says these are different organizations, different brands, different administrative presentations. The phone number says the separation has limits. A legitimate enterprise may use a shared headquarters number across subsidiaries. It usually does so openly, and not in combination with repeated abuse-heavy infrastructure. A provider that relies on fragmented RDAP naming while recycling one Seychelles contact across many ASNs is doing something else. It is preserving technical continuity while complicating the paper trail. That is not proof of a single beneficial owner in the legal sense. It is proof that the network wants the outside world to encounter multiple names while the contact layer keeps collapsing inward.

The jurisdiction is not incidental. Seychelles offers exactly the sort of offshore administrative distance that benefits a business model under chronic scrutiny. Investigators can document the contact, but the path from documentation to effective compulsion is weak. Abuse complaints can be routed there, but response is not structurally guaranteed. Corporate opacity is easier to sustain. This is why the number matters more than a Hong Kong business address would have mattered. Hong Kong appears in the brand surface and the technical management layer, but Seychelles is where the contact anchor sits when the architecture needs insulation. The phone number is therefore not just a detail about registration hygiene. It is a design choice embedded in the control plane.

And the control-plane interpretation fits the rest of the data. The phone number does not appear in a clean, high-trust, transparently governed cloud that happens to have one abusive customer. It appears in a cluster where abuse scoring maxes out, where routing identity stays coherent while organizational names splinter, and where peering remains narrow enough to suggest a deliberately managed niche rather than an ordinary open market cloud. Once those pieces are assembled, the simplest explanation is not clerical laziness. The simplest explanation is that the shared Seychelles contact helps hold together a distributed abuse-tolerant service architecture.

6. Eight Organization Names, One Operational Substrate

RDAP fragmentation is one of the oldest administrative tricks in the book. It does not make infrastructure disappear; it makes it expensive to describe. Each additional org name gives investigators another thread to pull, another false branch to prune, another mild ambiguity to resolve before they can say with confidence that the same cluster is underneath. In the Yisu case at least eight organization names recur across the same operational environment: Cloud Innovation Support, YISU CLOUD LIMITED, HONG KONG LING JIAN ZHUO, Hongkong Hongdou, IRT-ACEMOB-HK, HK KXSY, HK Kwaifong, and Yisu Cloud Ltd. A legitimate explanation for such fragmentation would be a complex reseller ecosystem with real organizational independence. But if that were true, one would expect meaningful divergence in routing, contacts, reputation, or customer behavior. The divergence instead lives mostly in the names.

The analytical point is simple. BGP tells one story while RDAP tells many. The BGP story is operational unity. The same YISUCLOUDLTD-HK routing identity appears under the ranges associated with these names. The RDAP story is administrative plurality. That mismatch is the evidence. When organizations are truly distinct, technical presentation tends to fragment along with paperwork. Here, the reverse occurs. The paperwork multiplies while the operations remain legible as one cluster. That is why the repeated organization names should not be read as exculpatory diversity. They should be read as the visible seams of an effort to prevent straightforward attribution.

Consider how the names function. “YISU CLOUD LIMITED” is the obvious brand presentation. “Cloud Innovation Support” ties the space back to the Seychelles administrative apex. “HONG KONG LING JIAN ZHUO,” “Hongkong Hongdou,” “HK KXSY,” and “HK Kwaifong” provide locally flavored corporate faces that can look independent at first glance. “IRT-ACEMOB-HK” has the formal flavor of an incident-response handle, which is almost perverse in a cluster saturated with abuse evidence. Each label can absorb a complaint, a query, or an ownership question and slow the analyst down. Yet the network keeps recombining them in ways that reveal the underlying unity.

This is one of the moments where pattern recognition matters more than any single field. Individual administrative records are cheap. Structures are not. A provider can rename entities, shuffle abuse contacts, or adopt new brands. It is harder to constantly recreate the same multi-layer pattern of offshore contact reuse, Hong Kong surface identities, repeated malicious telemetry, and coherent routing control unless that pattern is serving a business function. In Yisu’s case the function appears straightforward: make the service easy to buy, easy to route, and hard to pin down to a single accountable entity.

7. Why the Pattern Looks Engineered Instead of Accidental

Engineering does not necessarily mean that every detail was planned by a mastermind on a whiteboard. It means the system behaves as though shaped by incentives that reward abuse tolerance. That distinction matters. Analysts do not need to prove a cinematic conspiracy to identify a business model. If every pressure that would normally reduce abuse instead appears dampened or redirected, the provider is revealing its operating logic. In a normal cloud, abuse costs money, reputation, and peering trust, so the provider creates processes to reduce it. In an abuse-tolerant cloud, abuse generates revenue and the processes exist mainly to absorb external pressure without interrupting the customer. Yisu looks like the second type because the external pressure is visible everywhere, yet the infrastructure keeps presenting itself in essentially the same form.

The narrow peering picture is especially important here. A provider with only five BGP peers on AS138152 is not swimming in the uncontrollable complexity of a global transit giant. It operates a bounded interconnection environment. That should make abuse containment easier, not harder. Fewer peers mean fewer handoff points, fewer routing disputes, and fewer excuses for not knowing what kind of traffic repeatedly sources from the space. If, under those circumstances, the public reputation of the network still converges toward perfect abuse scores, the provider has already answered the question of tolerance through behavior. It is not being overwhelmed by scale. It is choosing what kind of customers it can live with.

There is also a timing dimension. Maximum-abuse scoring does not materialize instantly and uniformly. It requires persistence. So does a shared offshore contact that remains useful across many ASNs. So does the maintenance of multiple local corporate faces. The system has to keep being itself long enough for outside observers to independently rediscover the pattern. That is why the “maybe it is all just stale data” defense fails here. Stale data can create one false impression. It does not produce a repeating multi-source architecture in which the same offshore contact sits behind a cloud brand whose sampled addresses are repeatedly identified as malicious.

8. The BGP Shape Tells a Business Story

Threat intelligence often over-rotates on ownership records and under-reads topology. Yet topology can say something almost sociological about a network. AS138152, with 45 prefixes, 11,520 IPv4 addresses, and only five peers, is not merely a technical object. It is the shape of a business. A mainstream cloud trying to attract a broad customer base usually grows connectivity, products, regions, and redundancy in ways that create a richer edge. Even small providers commonly show the rough edges of expansion: multiple upstreams, mismatched allocations, a mix of legacy and newer services. Yisu’s visible profile instead feels tight and controlled. It has enough space to service a meaningful customer population, but not the open, diversified sprawl one associates with a platform built to maximize ordinary enterprise trust.

Topology alone would never convict. Plenty of niche providers are small. Plenty of regional networks have narrow peering. But topology becomes interpretive when combined with behavioral evidence. If a narrow, curated network consistently carries heavily reported malicious infrastructure, that is not just a story about size. It is a story about selection. Somebody is deciding what kinds of workloads are welcome, what kinds of complaints matter, and what kinds of reputation damage are acceptable. The five-peer number becomes relevant because it strips away the excuse of unmanageable scale. This is not AS4134, a state telecom giant with a vast, mixed ecosystem and a bureaucratic maze. This is a bounded environment whose abuse surface still resolves with disturbing clarity.

The absence of IPv6 in the cited AS138152 profile is also revealing in its own modest way. A legitimate modern cloud does not need to be an IPv6 showcase, but complete absence often correlates with utilitarian infrastructure built for immediate demand rather than long-term platform credibility. That by itself proves nothing. In context it fits. The same environment that does not invest in broader trust signals also appears comfortable operating under an offshore contact structure, using fragmented identity layers, and tolerating a high-abuse customer profile. Again, none of these are dispositive individually. Together they describe a service optimized less for respectability than for operational persistence under scrutiny.

9. Yisu in the Broader Chinese Ecosystem

It would be a mistake to isolate Yisu so completely that the rest of the Chinese series disappears. The reason this article matters is not only that Yisu looks bad in absolute terms; it is that Yisu helps explain the architecture of the wider ecosystem. The broader dataset contains 710 Chinese IPs across 84 ASNs. Of those, 117 land at abuse confidence 100. State telecoms account for about 65% of the observed infrastructure. Big Tech accounts for another 24%. AS4134 alone contributes 115 IPs with roughly 90% abuse in sample. Baidu contributes 79 IPs with 100% abuse. ByteDance contributes 54 IPs with 100% abuse. Tencent contributes 9 IPs with 100% abuse. Those numbers show breadth. Yisu shows concentration. It is the place where the ecosystem’s logic becomes easiest to read because it is less diluted by scale, bureaucracy, or brand complexity.

Seen this way, Yisu is not an outlier floating outside the Chinese stack. It is a clean specimen from within it. State carriers show that the large backbone can be abused at scale. Big Tech shows that mass commercial platforms can host offensive traffic without sufficient friction. Yisu shows what happens when the same strategic environment is stripped down to a more compact abuse-tolerant service layer. The legal buffer remains offshore. The operational surface remains in Hong Kong-facing infrastructure. The complaints go nowhere useful. The evidence keeps piling up. It is almost an explanatory bridge between the macro architecture and the micro behavior.

This is also why Yisu is analytically more useful than a giant platform in some respects. Hyperscalers have real complexity. They host almost everything, including benign and malicious workloads, which gives defenders and public relations teams alike a plausible deniability argument. Yisu has less room to hide behind scale. When a smaller, narrower provider keeps generating the same pattern, the inference is sharper. The series-wide numbers give Yisu context; Yisu gives the series a face. If Part A showed the blueprint, Part B shows the machinery turned on.

10. China, the United States, and the Response Problem

One of the most uncomfortable findings in the wider series is not simply that Chinese infrastructure appears so often in attack telemetry. It is the response asymmetry. In the comparative analysis, the Chinese response rate to abuse reporting sits at effectively 0%, while the United States is closer to 40%. Those percentages do not mean American networks are morally cleaner; the U.S. also hosts enormous quantities of abuse. They mean something narrower and operationally decisive: when abuse is reported into American infrastructure, there is at least a nontrivial chance that someone will eventually act. In the Chinese clusters studied here, that expectation collapses.

Yisu fits that response environment perfectly. A shared Seychelles contact routes accountability into a jurisdictional cul-de-sac. Hong Kong-facing brands provide commercial legitimacy on the surface. The routing layer remains technically coherent enough to function but administratively diffuse enough to slow enforcement. The result is not simply more abuse. It is abuse with very low expected interruption. That is why a criminal customer would choose such infrastructure even if it were not the cheapest or fastest option. Reliability in this market does not mean uptime alone. It means the provider is structurally difficult to pressure.

11. What Defenders Should Pivot On

The worst analytical mistake with a cluster like Yisu is to over-focus on one indicator and underuse the structure. Blocking a single IP is ephemeral. Blocking one /24 may buy time and miss the wider environment. The defensible approach is to pivot on the attributes that the provider keeps reusing because they are harder for it to abandon.

• Routing identities: AS138152 and AS142403
• Contact artifacts: +248-4-610-795, Cloud Innovation Support, tech@cloudinnovation.org, YISUCLOUDLTD-HK
• Organization names: the recurring Hong Kong labels (8+ RDAP orgs)
• Abuse categories: SSH credential attacks and broad scanning
• Correlation method: behavioral recurrence, not just address adjacency

Investigators should also treat the eight RDAP org names as a watchlist rather than as eight separate cases waiting to be resolved individually. Fragmentation is supposed to slow correlation. The answer is to reverse the burden: if a new range appears under one of those names and routes through the same Yisu-linked operational identity, it should inherit suspicion immediately. The same applies to cross-links with UCloud HK and Cloud Innovation Support. The existence of 33 documented Yisu–UCloud cross-links is a warning that the architecture does not live inside a single brand container. Analysts who remain trapped inside brand boundaries will keep rediscovering the same infrastructure under different labels.

For abuse desks, the lesson is even more practical. Measure providers not only by whether they have an abuse contact, but by whether repeated submissions change anything. A provider whose scored sample converges on 100 and whose complaints are routed into a Seychelles shell environment should not be evaluated like an ordinary overwhelmed hoster. It should be handled as an abuse-tolerant service cluster. That means faster escalation, stronger preemptive filtering, and less patience for the fiction that one more carefully worded notice will trigger self-correction.