📄 TI-2026-024F · Offshore Bulletproof · Part 6 of 8

🚇 The Pfcloud Transit Hub: Spamhaus DROP and the Israeli Connection

The internet has an attribution habit that helps infrastructure brokers more than it helps defenders. We focus on the node that scanned, the bot that authenticated, the command-and-control host that served the payload, or the prefix that tripped a reputation feed. Those are visible. The harder question is the one in the middle: who keeps the traffic moving after everybody already knows the downstream is toxic? In the Pfcloud case that middle layer matters more than the edge cases it serves. A transit sponsor does not need to deliver phishing mail itself or run the panel for a malware family itself. It only needs to carry the abusive network, keep the routing stable, and keep the paperwork credible enough that the customer can remain online a little longer.

That is what makes Pfcloud UG important. The evidence set around AS51396 does not describe a random small German hoster accidentally caught adjacent to bad clients. It describes a route-and-sponsorship platform sitting between formal European number-resource governance and a set of networks that have already crossed into the internet’s harshest reputation category. Spamhaus ASN-DROP is not a mild warning label. In June 2026 the DROP corpus stood at 1,430 subnets covering roughly 14.7 million IP addresses. Placement there means major providers and gateways may block all traffic, upstreams inherit reputational exposure, and ordinary routing becomes materially harder. When an operator keeps providing transit to networks in that condition, the service is not “connectivity” in the innocent sense. It is continuity for customers others increasingly refuse to touch.

The Pfcloud cluster is therefore best read as a hub, not merely a hoster. The user-supplied investigation data, the existing dossier store, and the surrounding intelligence corpus converge on the same pattern: Pfcloud UG / Daniel Mishayev functions as a German LIR and sponsorship layer; AS202412 Omegatech and the TechTies network move through that layer; GHOSTYNETWORKS extends the ecosystem into a US corporate wrapper; and WHITELABEL-MNT or whitelabel.sh appears as the commercial abstraction that turns routing into a product. The numbers are not trivial. The Mishayev/Pfcloud ecosystem in the local intelligence store accounts for 36–37 tracked IPs, 951 honeypot hits, 67 command-and-control servers, and 16 malware families. The direct Pfcloud ASN itself may generate relatively little noise compared with its customers. That is the point. Middlemen are quieter than the customers they enable.

This article is not about nationality as suspicion marker. It is about structure. The case includes an Israeli national operating through a Bavarian company shell, a German number-resource surface, a Kentucky-linked US arm, a Seychelles/Kentucky/Germany bridge through the wider Pfcloud ecosystem, and customer ASNs that appear in Spamhaus DROP with the predictable signs of sparse peering and abuse tolerance. The question is not whether every entity touching the chain is criminal. The question is whether the chain, taken as a system, exists to keep criminal infrastructure supplied with transit after the rest of the network has already judged it radioactive. The evidence says yes.

1. The middleman problem: who transits the already-burned networks?

Security reporting has a bias toward endpoints because endpoints are where the telemetry is loud. Honeypots see the scanners. Sandboxes see the payloads. sinkholes see the callbacks. But BGP transit is where an abusive ecosystem becomes durable. Once a network reaches the point where abuse desks, feed operators, and large gateways recognize it as structurally toxic, somebody still has to do the unglamorous institutional work of keeping that network visible in the global table. Somebody has to sponsor, route, register, answer enough correspondence, and preserve enough procedural normality that the hostile customer does not immediately disappear from view. That role is less cinematic than a botnet panel, but strategically it is often more important.

Pfcloud sits inside exactly that gap. The central evidentiary fact is not merely that Pfcloud UG appears on Spamhaus ASN-DROP itself. It is that Pfcloud provides transit to multiple downstream ASNs that are already DROP-listed. In ordinary network operations, a provider with one problematic customer can invoke accident, lag, or poor abuse handling. In a clustered pattern, where several separate abusive ASNs converge on the same transit sponsor, the innocent explanations thin out quickly. The sponsor stops looking like an unlucky upstream and starts looking like a service layer selected because it will keep carrying traffic others no longer want.

The economics reinforce that reading. A RIPE NCC LIR is not free, but it is also not out of reach for a small operator who understands the market value of administrative legitimacy. The verified fee structure relevant here is €1,000 sign-up, €1,800 annual membership, and €50 per ASN. That is an ordinary cost base for a legitimate regional provider. It is also a very manageable price for a company selling access to number resources, route origination, or sponsored visibility to risk-heavy customers. Once the shell exists and the ASN is live, the operator is no longer selling server metal alone. It is selling institutional access.

That distinction helps explain why transit hubs tend to look cleaner in direct attack counts than the customers behind them. The sponsor does not need to flood the internet with brute-force traffic. The sponsor needs to make sure that the customer’s own /24s stay announced. In the Pfcloud universe the record points to several such customers: AS202412 (Omegatech), AS214940 (KPROHOST), TechTies, VPSDEDICATED, STEALTHVM, STORMING, and the US-facing GHOSTYNETWORKS cluster. Some are better documented than others, but the aggregate picture is stable: Pfcloud appears where one expects a facilitator, not a bystander.

The criminal customer needs bandwidth. The bulletproof enabler needs paperwork, peering, and the willingness to keep saying yes after everyone else has already said no.

This is why the Pfcloud story belongs in an Offshore Bulletproof series even though one anchor sits in Germany. Offshore is not merely a map location. It is a functional separation between legal face, routing face, and abusive use. Pfcloud’s value is precisely that it gives already-burned networks another face to stand behind.

2. Daniel Mishayev: Israeli national, Bavarian company, German LIR

The biography at the center of the Pfcloud case is legally ordinary and investigatively revealing. The record supplied for this article describes Daniel Mishayev as an Israeli national operating from Bavaria through Pfcloud UG, with company-registry traces in Germany and RIPE surfaces tying the operator to number-resource administration. None of those facts is illicit by itself. Cross-border entrepreneurs exist. Israeli nationals form German companies. German residents run infrastructure businesses. The significance comes from the interaction between the biography and the network behavior. Mishayev’s importance is not that he is Israeli. It is that an Israeli national operating through a Bavarian shell appears repeatedly in the administrative layer of a transit ecosystem serving DROP-listed networks.

The available corporate evidence places Pfcloud UG in Bavaria, with the user’s dataset noting a Bavarian company-registry record and the existing dossier store associating the company with District Court Passau and an address trail in Hauzenberg. The same dossier layer characterizes Mishayev as the German gatekeeper for a broader customer ecosystem. That wording is analytically sound. Gatekeepers in infrastructure cases are not always the loudest actors. They are the people whose names appear where the institution needs a human or company to exist: in LIR membership, sponsorship chains, billing, registry contacts, or formation documents.

There is also an operational asymmetry in the data that makes the biography matter. Israel itself is nearly absent from the honeypot evidence relevant to this cluster. The narrative evidence summarized in the dossier describes the anomaly plainly: 7 Israeli IPs, 0 honeypot hits. Yet the Mishayev/Pfcloud ecosystem, associated with an Israeli national operating through European shells, accumulates 930–951 hits across customer and adjacent infrastructure. That divergence does not prove state activity, and it should not be inflated into one. But it does demonstrate a classic offshore pattern: the operator’s national anchor and the abuse-facing network geography are intentionally decoupled.

That decoupling is valuable. A national jurisdiction can remain statistically quiet in direct telemetry while its citizens or commercial operators play meaningful roles at higher layers of the infrastructure chain. In forensic terms, this is one reason country-level heat maps mislead. A country can look absent from attack traffic if the work that matters happens in sponsorship, brokering, shell formation, resource leasing, or transited hosting elsewhere. Mishayev’s biography illustrates that difference. The visible problem is not Israeli IP space. The visible problem is a German shell operated by an Israeli national that keeps abusive foreign networks connected.

The key discipline is not to romanticize the biography. There is no need. The paper trail already explains enough. Mishayev shows up not as a distant rumor but as the human point at which a German legal wrapper, RIPE legitimacy, and an abusive downstream ecosystem meet. That is sufficient.

3. Pfcloud UG: the German corporate shell and why a UG is useful

Pfcloud’s legal vehicle matters because the UG (haftungsbeschränkt) is one of the most useful company forms in Europe for a low-capital operator who wants formal structure without the friction of a larger corporate commitment. It is essentially the “mini-GmbH,” designed to permit limited-liability incorporation with minimal starting capital. Theoretical minimum capital can be as low as €1. That fact by itself does not taint the entity. Thousands of normal small businesses use UGs. But in the context of abusive infrastructure, the UG’s virtues are exactly the features a bulletproof-enablement layer wants: fast formation, limited liability, procedural seriousness toward banks and registries, and a German flag that looks respectable to counterparties who stop reading after the first page.

This is why corporate form is not trivia in network investigations. A transit sponsor does not only sell routes. It sells confidence to the institutions around the route: RIRs, providers, exchanges, customers, and casual due-diligence reviewers. A German UG is not a fake company. That is precisely its value. It is a real company form, but one that can be acquired with low capital and used as a credibility amplifier relative to the actual risk of the customer base. Combine that with RIPE LIR membership and you have a structure that can look boring enough to exist while carrying networks that are anything but boring.

The verified RIPE cost model sharpens this point. The year-one cost to step into this institutional layer is not enormous: €1,000 sign-up, €1,800 annual fee, and €50 per ASN. For a legitimate operator that is membership overhead. For a bulletproof transit hub it is the price of market access. Once inside, the company can sponsor or coordinate resources for customers that do not want their own beneficial ownership, compliance burden, or reputational exposure too close to the surface. The operator with the shell becomes a broker between abuse-tolerant customers and the governance layer that allocates routing identity.

In that sense Pfcloud UG is not merely a hoster. It is a jurisdictional adapter. German law gives the entity an addressable corporate existence. RIPE membership gives it institutional standing in number-resource management. BGP gives it operational power. And the customer stack turns those abstract affordances into cash. The point is not that Germany intended to provide bulletproof infrastructure. The point is that the company form is neutral, the registry process is formal rather than forensic, and actors who understand the gap can exploit it.

Investigators often talk as if “offshore” means a palm-tree secrecy haven. Pfcloud shows a more modern pattern. Offshore logic can run through a German company form just as effectively if the structure separates the legal face from the abuse-facing reality. The UG does not need to hide the operator completely. It only needs to make the operator look administratively normal while the customer mix tells a different story.

4. AS51396 and the transit stack: what Pfcloud carries for others

The routing picture is where the case becomes unequivocal. Pfcloud’s AS51396 is not just another small autonomous system with occasional bad tenants. The dossier record, user-supplied evidence, and search corpus align on the point that AS51396 provides upstream transit to a cluster of downstream networks already on Spamhaus DROP or EDROP. The observed set includes AS202412 (Omegatech), AS214940 (KPROHOST), TechTies, VPSDEDICATED, STEALTHVM, STORMING, and the Pfcloud-adjacent AS205759 GHOSTYNETWORKS. The existing corpus also notes Pfcloud’s own upstream relationship to Tube-Hosting / AS49581, itself on Spamhaus DROP. That is not one dirty leaf on an otherwise healthy tree. It is a stacked abuse-tolerant hierarchy.

AS202412 is the strongest individual example because the metrics are so stark. The verified data for this article states that the ASN advertises 20 IPv4 /24 prefixes, meaning 5,120 addresses; 15 of those 20 prefixes are in Spamhaus DROP; 114 ThreatFox IOCs were tagged to AS202412 between January and May 2026; and only two BGP peers are visible, a sparse-peering pattern entirely consistent with a fragile bulletproof network dependent on a small number of willing upstreams. If one of those upstreams is Pfcloud, then Pfcloud is not peripheral. Pfcloud is one of the reasons the network still exists.

The same logic applies to the other named downstreams. A DROP-listed KPROHOST fed through the same German upstream is no accident. A TechTies network on the same pipeline is not an isolated administrative coincidence. A whitelabel-enabled stack that repeatedly terminates on the same transit sponsor tells us what the sponsor is selling. It is selling the answer to a very specific customer problem: how do I stay online after my network reputation is already irreparably bad?

There is also a geographic texture to the infrastructure. The enrichment record spans address space and operational presence across Germany, the Netherlands, and the United States, with the user’s dataset additionally placing a linked botnet node at 154.83.16.160 in Hong Kong and cited examples like 45.135.194.111 and 176.65.134.8 in Pfcloud’s German ranges. Those locations are not the conclusion by themselves. They become meaningful because they appear under a single administrative ecosystem whose customer list is already pre-selected for reputational toxicity.

This is the architectural core of the case. Pfcloud is not only another bad ASN. It is a hub that makes other bad ASNs viable.

5. The “7 IPs, 0 hits” Israeli anomaly

One of the more interesting facts in this cluster is negative evidence: the near-absence of Israel in the direct honeypot dataset. The local intelligence record summarized for this article notes 7 Israeli IPs and 0 honeypot hits. On a superficial read, that would imply Israel is irrelevant to the case. Yet the Pfcloud/Mishayev strand shows why national traffic maps can be deceptive. The Israeli connection in this story is not a flood of Israeli attack infrastructure. It is an operator-layer connection: an Israeli national administering a German shell that provides transit to hostile foreign networks.

That matters because it is exactly how professional separation is supposed to work. If one wants to preserve plausible deniability, one does not necessarily route abuse through one’s most personally exposed jurisdiction. One builds a layered structure in which the beneficial or controlling human sits in one national context, the company in another, the transited customers in others still, and the abuse-facing IP space in whatever geography is most operationally convenient. The result is statistical invisibility where amateurs expect visibility. Defenders looking for “Israeli attack IPs” will find little. Defenders looking at who routes for whom find far more.

The anomaly is therefore not proof of clandestine state direction, and it should never be used that way. The correct inference is narrower and more useful. It shows that people-layer attribution and IP-layer attribution are not the same analytical object. The absence of Israeli IP activity does not absolve an Israeli operator’s role in a European bulletproof transit business. It simply shows that the operator has succeeded in separating personal jurisdiction from abuse telemetry.

This distinction is easy to miss in modern infrastructure cases because so much OSINT is still map-first. We color countries by malicious IP counts and then infer operational significance from density. That works for mass scanning from commodity cloud or residential botnets. It works badly for shell-heavy infrastructure brokerage. In those environments the meaningful activity is the choreography of formation, sponsorship, route origination, and customer survival. Israel’s role here is seen through Mishayev and adjacent entities, not through the raw attack histogram.

Silence in the traffic map is not absence of participation. Sometimes it is evidence that the participant understands the map.

That is why the Israeli connection belongs in the title, but only in a disciplined way. It is not an accusation against a nationality. It is a description of the human anchor inside a routing structure that otherwise tries very hard to look like a mundane German hoster.

6. whitelabel.sh: transit as a marketplace product

If Pfcloud were merely an abuse-tolerant operator, the corporate and routing story would already be serious. The whitelabel.sh element pushes the case further because it suggests productization. The site is described in the evidentiary record as offering “white-label” hosting solutions. That branding language matters. A white-label service is not a server rented to an end user in a simple retail sense. It is infrastructure that another party can resell or rebadge as its own. In the context of BGP transit and sponsored ASN provisioning, white-label language implies that the operator understands its business not as ordinary retail hosting but as infrastructure wholesaling for intermediaries.

This is exactly what one would build if the goal were disposable ASN manufacturing. A customer does not want only a rack. The customer wants the ability to show up in RIPE, originate prefixes, and appear operationally distinct from the next shell in line. A transit-and-sponsorship supplier can make that possible. The customer brings a legal entity or uses one supplied elsewhere in the ecosystem. The transit broker provides the upstream path, peering surfaces, or related routing services. From outside, the result looks like multiple separate small networks. From inside, it looks like a production line.

The investigation record states this conclusion plainly: Pfcloud Pipeline: Disposable ASN manufacturing via whitelabel.sh. That is strong language, but the supporting facts justify it. Omegatech and TechTies sit on the same Pfcloud pipeline. Multiple abusive or reputation-burned ASNs recur around the same sponsor. The service is branded in terms that emphasize reseller abstraction. The enabler layer ties together entities across Germany, Seychelles, Kentucky, and related shells. This is not a normal neighborhood host selling a few VMs. It is a system for giving customers a fresh-looking network shell and enough transit to make it real.

The strategic value of that system is hard to overstate. Reputation is expensive to lose and difficult to recover. But if the operator can cycle shells and provision routing through a reusable sponsor layer, the cost of burning one network identity falls dramatically. The customer does not need a clean conscience. The customer needs a clean next wrapper. whitelabel.sh appears to exist precisely in that space.

In short, whitelabel.sh makes the Pfcloud story commercial. It tells us this is not simply tolerated chaos around one operator. It is a marketable service model.

7. Intelligence Hosting LLC / AS400328: the US arm of the same pattern

The Pfcloud ecosystem does not stop in Germany. One of the more useful corrective facts in the research set concerns AS400328. Earlier attribution had apparently pointed toward Webdock, but the verified OSINT correction is explicit: ARIN RDAP identifies AS400328 as Intelligence Hosting LLC / pfcloud.io, not Webdock. That matters for two reasons. First, it narrows the corporate picture and removes a false lead. Second, it demonstrates that the Pfcloud brand extends into a US legal wrapper rather than remaining purely a German shell.

The user’s investigation data places this US arm in Kentucky. Again, the significance is not that Kentucky is intrinsically suspicious. The significance is that a German/Israeli transit ecosystem has a US corporate manifestation tied to the same pfcloud.io identity. This is textbook offshore engineering in the functional sense: multiple jurisdictions, each serving a role. Germany supplies the UG and RIPE-facing respectability. The United States supplies another corporate shell and another registry surface. Customer ASNs sit elsewhere. Abuse telemetry lives elsewhere still. The operator can then answer different questions with different entities depending on who is asking.

That modularity is useful both commercially and defensively. Commercially, a US entity may help with certain contracts, registrations, or customer reassurance. Defensively, it diffuses accountability. Investigators who stop at a single jurisdiction never see the whole machine. An abuse complainant focused on one AS may miss the corporate sibling. A provider focused on pfcloud.io branding may miss the German registry or the Kentucky company or the Seychelles customer. Each individual record looks incomplete because incompleteness is a design feature.

The ARIN correction is therefore more than bookkeeping. It demonstrates why corporate precision matters. When a network ecosystem is deliberately layered, small attribution errors are gifts to the operator. Correcting AS400328 back to Intelligence Hosting LLC / pfcloud.io closes one of those gaps and shows the US arm for what it appears to be: another administrative limb of the same enabling organism.

Once that map is visible, the whole structure becomes less mysterious. Pfcloud is not one company in one country doing one thing. It is a multi-jurisdictional service arrangement whose stable function is to make difficult customers easier to keep online.

8. GHOSTYNETWORKS: 67 command-and-control servers and 16 malware families

The abstract routing story becomes concrete when one looks at what the ecosystem actually enables. The user-supplied findings identify GHOSTYNETWORKS and the wider Pfcloud cluster as associated with 67 C2 servers and 16 malware families. Breakglass intelligence is cited specifically for the Omegatech range 158.94.210.0/24, where those C2 counts were observed upstream of Pfcloud UG. One does not need every family name to draw the operational conclusion. A transit-and-sponsorship stack that repeatedly surfaces next to dozens of C2 nodes has moved far beyond the realm of generic shared hosting misfortune.

Command-and-control infrastructure is not ambient internet pollution. It is purpose-built coordination machinery. A network that accumulates 67 observed C2 servers does so because multiple operators, campaigns, or malware lines have found it sufficiently durable, permissive, or replaceable to trust it with active hostile operations. The 16-family count strengthens that inference because diversity of malware families argues against a single rogue tenant explanation. This looks like a service environment that many unrelated or loosely related malicious customers can use.

The honeypot and enrichment layers around Pfcloud also suggest cross-ASN campaign coordination. The dossier record notes shared HASSH fingerprints linking Omegatech IPs to TechTies and even to Private Layer comparators. The interpretation should be careful: a shared HASSH value is not a confession. But in combination with shared transit, shared route sponsorship, and repeated reputational burn, it is strong circumstantial evidence that the ecosystem is hosting operationally similar customers who reuse infrastructure practices, tooling, or deployment habits.

That is why the label bulletproof matters in its older, precise sense. Bulletproof hosting is not defined by ideology or by the moral self-image of the operator. It is defined by what customers can get away with before the provider stops them. The presence of 67 C2 servers and 16 malware families across a Pfcloud-enabled environment implies the stopping threshold is very high or functionally absent.

In that light, GHOSTYNETWORKS is not an outlier. It is the visible end product of the Pfcloud pipeline. Transit, shells, route legitimacy, and white-label brokerage are not interesting for their own sake. They matter because they enable malware operators to keep their infrastructure alive long enough to monetize it.

9. The 951-hit ecosystem: what the honeypot data says

The honeypot numbers around Pfcloud need to be read at ecosystem scale, not ASN-by-ASN in isolation. The user’s findings state 951 total honeypot hits across Pfcloud-transited networks. The existing dossier store breaks the cluster down roughly as follows: Omegatech contributes the overwhelming majority, TechTies adds a substantial secondary stream, direct Pfcloud space remains comparatively quiet, and the wider GHOSTYNETWORKS line rounds out the picture. That distribution is exactly what one expects from a middleman architecture. The sponsor is quieter. The customers are noisier. The network still belongs to the sponsor story because the customer traffic depends on the sponsor’s willingness to keep carrying it.

Numbers of this kind are sometimes dismissed as “mere noise” unless they map one-to-one to a known incident. That is a mistake. Volume in itself is not the proof here; distribution and concentration are. When nearly a thousand hostile interactions aggregate across networks tied together by the same transit and sponsorship layer, the traffic ceases to be anecdotal. It becomes an environmental characteristic of the business. This is especially true when the same environment also overlaps with Spamhaus DROP, ThreatFox IOCs, multi-family C2 hosting, and sparse-peering ASNs. Each source class strengthens the others.

The ecosystem framing also clarifies why a low direct hit count on Pfcloud’s own IPs is not exculpatory. A transit hub can be operationally essential while being behaviorally quiet. In many illicit service chains the enabling node is supposed to look boring. It handles BGP, contracts, registries, or front-door support. The customer-facing abusive acts happen on downstream allocations. To judge the hub only by its own direct packet count is to misunderstand the job of the hub.

The 951 hits therefore matter less as a scoreboard than as proof of dependency. They show that the traffic associated with Pfcloud’s customer stack is not hypothetical. The downstreams are active. They show up in local intelligence. They recur often enough to measure. And they do so under a common transit umbrella that has already been warned by the public reputation layer.

In investigations like this, local telemetry is valuable not because it tells the entire story, but because it proves the story is not academic. The Pfcloud ecosystem is not merely suspicious on paper. It is alive in operational data.

10. Why Germany has not acted: low-friction formation, jurisdictional diffusion, and the Bavarian problem

When a case like Pfcloud becomes legible, the obvious public question follows: why has nobody shut it down? The answer is usually less dramatic than people hope. First, the German UG form is easy to obtain and entirely legitimate as a company vehicle. There is no automatic trigger in German corporate law that says “this operator transits bad ASNs, therefore the company ceases to exist.” Second, BGP transit is an infrastructural role that can preserve plausible deniability longer than direct malware hosting. An operator can always say it provides connectivity, that customers are responsible for content, that abuse is disputed, or that upstream relationships are being addressed. Third, enforcement is fragmented. Corporate law, telecom oversight, criminal investigation, and international abuse handling do not automatically converge just because researchers can see the pattern.

The Bavarian angle matters because local jurisdiction is both real and limited. A company registered in Bavaria falls under German state and federal institutions, but those institutions do not operate like a single reflexive anti-bulletproof machine. A Bavarian company registry verifies filing formalities, not the moral content of routing policy. Law-enforcement bodies such as the BKA or state-level police need evidentiary thresholds, priority allocation, and often cross-border cooperation to move from “this looks bad” to “this is prosecutable.” Meanwhile the operator benefits from every day that the company remains just legitimate enough on paper to continue functioning.

There is also a structural reluctance in democratic bureaucracies to treat transit as culpability absent a more dramatic hook. The criminal justice imagination is still more comfortable with seizing a server full of malware than with dissecting a route-and-sponsorship pipeline. But infrastructure crime increasingly lives in those middle layers. A German shell that routes for a stack of DROP-listed networks can do enormous harm without ever fitting the cinematic stereotype of cybercrime.

Finally, the offshore design itself raises the cost of action. Germany can see the UG. ARIN can see the US arm. Spamhaus can see the reputation. RIPE can see the resource relationships. ThreatFox can see the IOCs. Honeypots can see the traffic. No single institution naturally sees the full merged picture unless someone does the synthesis. That gap between local visibility and systemic visibility is where bulletproof providers survive.

That is the final lesson of Pfcloud. The infrastructure industry still contains a profitable niche for actors willing to monetize other people’s burn status. Pfcloud UG appears to occupy that niche from a Bavarian legal base, with an Israeli operator at the human center and a multi-jurisdictional corporate shell around him. The scandal is not that the downstreams are abusive. The scandal is that even after they are publicly and repeatedly identified as abusive, somebody still provides the transit that lets them continue.