🌐 TI-2026-021D · The Architecture of Impunity · Part 4 of 10

🪦 The Abuse Report Graveyard: 96% Failure Rate and the Five Ways Reports Die

You file an abuse report. You attach logs, screenshots, packet captures, timestamps, reverse DNS, WHOIS output, malware hashes, and a clean statement of impact. You send it to the address listed in the registry because that is what the system tells you to do. Then you wait. Nothing happens. You send a second report, this time shorter, more explicit, easier to process. Silence again. Perhaps an auto-response arrives thanking you for helping keep the internet safe. The abusive host remains online. The scanner returns. The credential-stuffing resumes. The proxy comes back through a new port. The same infrastructure that received the report continues to monetize the activity described in it.

This is usually narrated as administrative overload, imperfect due diligence, unfortunate prioritization, or the ordinary friction of cross-border operations. Those explanations are not entirely false. They are simply incomplete. The more precise description is harsher: the abuse-report pipeline is built to absorb complaint energy while minimizing mandatory consequences. It creates the appearance of recourse without reliably producing remediation. It provides forms, mailboxes, registries, policy references, and ticket numbers. What it rarely provides is coercive power over the operator profiting from the abuse. In that gap, entire classes of infrastructure learn that being reported is not a business-ending event. It is a costless background condition.

The evidence in this series points to that conclusion directly. Comparable hosting documented in TI-2026-026O showed a 96% failure rate for abuse reporting. Parallel work against Chinese cloud infrastructure in TI-2026-031F identified five recurring failure modes that keep repeating across providers, jurisdictions, and abuse categories. A targeted 90-day observation set on 35 reported IPs showed zero remediation action. RIPE NCC policy requires an abuse-c contact, but it does not require that the contact answer, investigate, or act. Spamhaus and AbuseIPDB can document a problem, but documentation is not takedown authority. The result is not occasional underperformance. It is systemic non-enforcement.

The four IPs foregrounded here—191.101.33.115, 191.101.33.110, 179.61.232.244, and 198.204.244.210, all tied to ASN14670—matter because they are not abstract theory. They represent the kind of infrastructure that gets reported, listed, discussed, and escalated while remaining effectively intact. The issue is not whether every abuse desk employee is corrupt, nor whether every provider knowingly protects every malicious customer. The issue is structural: when the reporting path loops back into the operator, crosses conflicting jurisdictions, hides behind weak contracts, rests on unenforced registry policy, and imposes higher costs on defenders than on providers, the outcome is predictable.

The architecture exists because it serves multiple constituencies at once. It serves criminal operators, who need time and continuity. It serves hosting providers, who prefer recurring revenue over labor-intensive enforcement. It can also serve intelligence services, because environments where malicious infrastructure is tolerated are useful places to watch, seed, redirect, or conceal operations. That is why the abuse-report graveyard matters. It is not administrative decay. It is a functioning political economy.

1. The 96% number: where it comes from, how it was derived, and what it means

The 96% figure is not a slogan. It emerges from the comparative research documented in TI-2026-026O, where multiple abuse-tolerant environments were measured against a simple and practical question: when defenders report clearly abusive infrastructure through the formal channels provided, how often does that report produce meaningful remediation? Meaningful remediation was defined narrowly on purpose. It did not mean a polite acknowledgment. It did not mean a promise to review. It did not mean the provider saying the matter had been forwarded internally. It meant an action that altered the attacker’s operational capacity: suspension, withdrawal of service, null-routing, takedown, customer removal, or another visible interruption of abuse continuity.

That methodology matters because the abuse ecosystem is full of pseudo-responses designed to inflate the appearance of diligence. Automated acknowledgments, ticket references, “please provide more evidence” loops, or vague replies about acceptable use are often counted by providers as evidence that the process is working. For the victim, however, the relevant outcome is not conversational. It is operational. If the scanner, phish kit, proxy, malware node, brute-force endpoint, or control host remains reachable after the report, then the system has not solved the underlying problem. By that standard, the failure rate observed across comparable hosting in TI-2026-026O rose to 96%.

That number should not be read carelessly. It does not mean that 96% of all hosting providers everywhere ignore every complaint. It means that within the abuse-tolerant sample set relevant to this series, formal reporting almost never produced a meaningful interruption. That distinction is important because it blocks an easy escape route. Defenders often hear that their negative experiences are anecdotal or confined to a handful of bad networks. The cross-case comparison shows otherwise. The failure pattern persists across different geographies, different operator identities, and different abuse types because the same institutional weaknesses recur. The number is therefore descriptive of a system condition, not of one isolated provider.

The number also has a temporal dimension. Abuse reports are often defended as slow but necessary; providers claim investigation takes time. That is why the 90-day tracking window used later in this article matters so much. If a provider needs some time to validate, then longitudinal observation should eventually show a change. Instead, 35 reported IPs observed across three months produced no visible remediation. A process that fails after 24 hours might be blamed on queue depth. A process that fails after 90 days is something else. It is not overwhelmed. It is permissive.

Most importantly, the 96% figure reframes the purpose of reporting. In an ordinary accountability system, reporting is supposed to convert private knowledge of harm into public intervention. In the current architecture, reporting often functions more like evidence preservation for the victim than enforcement against the operator. It creates documentation, helps build intelligence pictures, and may support later reputational measures such as blocklisting. But it rarely compels the provider to choose public safety over customer retention. The number tells us that the abuse-report channel is weak not because defenders are using it badly, but because the channel itself is not designed to force action.

When a mechanism fails 96% of the time under the conditions it claims to address, the honest question is no longer “why isn't it working?” but “what is it actually for?”

2. Failure Mode 1: the closed loop — when abuse@ points back to the operator

The first and most brutal failure mode is also the simplest: the reporter and the reported do not face each other as adversaries; they meet inside the same administrative organism. The abuse mailbox exists. It satisfies policy. It may be listed in WHOIS, RIPE, or a provider portal. Yet the mailbox is answered by the same operator, reseller, or service layer that profits from the continued availability of the abusive host. The report is not leaving the hostile environment. It is being delivered deeper into it. This is why the phrase closed-loop abuse desk matters. It names a structural fraud, not merely bad customer service.

In such arrangements the provider can claim perfect process compliance. There is an abuse address. Tickets are received. Some are even acknowledged. But the power to interpret the complaint and the power to ignore it belong to the same side of the transaction. That destroys the independence that makes complaint systems meaningful. Imagine filing a fraud complaint to the cashier who earns commission on the fraud, or a safety complaint to the machine owner whose output drops if the machine is shut down. That is what much of internet abuse reporting actually looks like. The institution presented as oversight is operationally indistinguishable from the entity under complaint.

The infrastructure sample attached to this article illustrates the problem. Addresses such as 191.101.33.115 and 191.101.33.110 in ASN14670 can be reported cleanly, repeatedly, and with supporting evidence. Yet if the abuse workflow ultimately routes to people whose incentives are aligned with continuity of service, then the report is not a threat. It becomes intelligence about what the defender sees. A hostile or indifferent operator learns whether the victim has correlated activity, which artifacts were captured, and how urgently the complaint was framed. The defender supplies free telemetry into a system that may never punish the customer at all.

This is why blocklists are so often better at describing the landscape than the abuse desk is at changing it. Spamhaus, AbuseIPDB, and related systems operate as documentation layers. They preserve institutional memory and help other networks defend themselves. But they do not break the loop. If the hoster is content to remain listed while transit remains available and customers keep paying, then the listing becomes a reputational annotation rather than an enforcement event. Closed-loop abuse handling therefore converts what should be an accountability pipeline into a managed reputation problem.

The deeper consequence is epistemic. Defenders are encouraged to believe that official channels are the responsible first step. They are told not to escalate too quickly, not to shame publicly, not to assume bad faith. But in a closed loop the “responsible” path is also the least coercive path. The formality of the channel masks the futility of the outcome. That is how the graveyard fills: not with rejected complaints, but with complaints that vanish into mailboxes whose existence is more important than their behavior.

3. Failure Mode 2: jurisdiction arbitrage — the report goes to country A, the operator is in B, the server is in C

Even when the abuse contact is not fully self-referential, the second major failure mode appears: jurisdictional fragmentation. The company may be incorporated in one country, the reseller may be elsewhere, the data center may sit in a third jurisdiction, and the affected victims may be distributed across several more. Every participant can point to someone else as the proper decision-maker. The result is not legal complexity in the abstract. It is strategic delay. No actor needs to deny the abuse categorically. They only need to explain why action properly belongs somewhere else.

This is where the public imagination often lags behind the technical reality. Infrastructure is not constrained to the neat borders suggested by company registration. A U.S.-registered ASN can host traffic through assets operated from Europe; a reseller in Asia can provision servers through a carrier in North America; routing and geolocation can diverge; the listed abuse contact can belong to a contractor with no authority to suspend anything. The defender may think the report has reached “the provider.” In practice it may have reached a node in a transnational supply chain with neither the will nor the capacity to act.

The evidence pattern from TI-2026-031F matters here because it showed these layers recurring against Chinese cloud infrastructure: reports landed in one formal jurisdiction while the accountable operator, actual controller, or economic beneficiary lived somewhere else. The same logic appears across bulletproof hosting ecosystems more broadly. Jurisdiction arbitrage is not a side effect of globalization; it is one of the product features. Complexity is monetized because complexity raises the cost of coercion. If victims or researchers must map three or four legal interfaces before a single account can be shut down, many will stop before they arrive at the real decision point.

For the four ASN14670-linked IPs in this article, that means reporting may reach a formally correct contact while still failing to reach a decisive contact. The difference is everything. A formal contact can acknowledge, request more detail, or state that the issue is under review. A decisive contact can actually terminate service, null-route space, or demand customer identification. Jurisdiction arbitrage ensures these are often not the same person or the same legal entity. The system therefore creates the illusion of route-to-remedy while withholding the leverage needed for remedy itself.

The consequence is cumulative. Over time, repeat-abuse ecosystems learn which jurisdictions produce friction, which ones produce indifference, and which combinations create nearly consequence-free operating space. Abuse does not merely survive fragmentation. It selects for it. That is why the architecture remains stable even when individual companies change names or countries. The real asset is not one firm. It is the transnational pattern that allows everyone involved to say, truthfully enough for immediate survival, “this is not entirely our problem.”

4. Failure Mode 3: provider immunity — contracts that disclaim responsibility before the first complaint arrives

The third failure mode is contractual rather than geographic. Many providers embed some version of pre-emptive immunity into their terms of service, acceptable use frameworks, or liability disclaimers. These texts usually sound ordinary: no warranty of uninterrupted service, no liability for customer conduct, no obligation beyond limited internal review, no consequential damages, broad provider discretion, broad provider protections. None of this looks dramatic when read one clause at a time. Together, however, such clauses create a simple reality: the provider enters the abuse economy already insulated from most of the downside of inaction.

This matters because abuse handling is expensive. It requires human review, log preservation, customer confrontation, possible service interruption, and sometimes legal consultation. Revenue from the customer is immediate and measurable. The benefit of protecting third-party victims is diffuse and often externalized. Contractual immunity shifts the starting position even further toward passivity. If the provider can say, in effect, that it is not responsible for customer misuse absent extraordinary circumstances, then every abuse report becomes a discretionary cost center rather than a binding duty.

From the victim’s perspective, this feels absurd. The infrastructure exists, the traffic is visible, the customer relationship is known to the provider, and the abuse is occurring on the provider’s platform. Yet the contractual structure reframes the provider as a neutral intermediary whose obligations are minimal. This is one reason that blocklists and public reporting loom so large. They operate in the reputational domain precisely because the liability domain is so constrained. Documentation accumulates because responsibility is contractually thinned out before evidence even arrives.

The important point is not that every clause is unlawful or unusual. It is that the entire contractual environment encourages non-intervention. A provider does not need to celebrate abuse to protect it. It only needs a risk model in which investigation is optional, liability is remote, and customer removal threatens revenue. Under those conditions, “we take abuse seriously” becomes a brand statement rather than a measurable operating principle.

That is why abuse reports so often die politely. The answer is rarely “we support criminal operations.” The answer is a softer and more durable form of impunity: “we are not in a position to determine this conclusively,” “please work through law enforcement,” “we have forwarded the complaint,” “we are not liable for third-party conduct,” or simple silence backed by contractual asymmetry. Provider immunity does not have to be absolute to be effective. It only has to make inaction cheaper than action. In most abuse ecosystems, it does.

5. Failure Mode 4: RIPE NCC policy gaps — abuse-c exists, enforcement does not

The fourth failure mode is institutional. RIPE NCC policy requires an abuse-c contact. That sounds meaningful until one asks the next question: what, exactly, must that contact do? The uncomfortable answer is very little. The registry requirement establishes that a contact exists. It does not reliably mandate response times, investigative standards, suspension thresholds, or measurable enforcement duties. In other words, the system can satisfy the form of accountability without guaranteeing any of its substance. The presence of a mailbox is treated as evidence of responsibility even when no actual response obligation attaches to it.

This gap matters more than it appears to. Regional internet registries occupy a quasi-governance position in the public imagination. Their data is used by investigators, platforms, providers, and law enforcement to identify who appears linked to an address space. When a registry mandates an abuse contact, many outsiders infer that the contact is part of an accountability framework. But if the contact can ignore reports with minimal consequence, then the registry has unintentionally helped build the theater of responsiveness. It has created a standardized place for complaints to die.

The harm is not theoretical. In a case set where 35 reported IPs remained unremediated for 90 days, a listed abuse contact did not translate into actual disruption. That should force a re-reading of what abuse-c really represents. It is not enforcement. It is metadata. It can help identify where complaints are supposed to go, but it cannot force those complaints to matter. Defenders who confuse the two end up participating in a ritual that produces paperwork while leaving criminal availability intact.

This policy gap is one of the reasons malicious infrastructure can remain visible for so long without being meaningfully interrupted. Defenders are encouraged to trust the administrative map. Yet the map only tells them who is on paper. It does not tell them who is bound to care. That distinction is crucial. Governance without enforcement is not neutral. It advantages the side that can continue operating while others spend time documenting failure.

There is also a reputational shield effect. Providers can point to RIPE records and say they are compliant. Outsiders see structured contact data and infer seriousness. The registry preserves order in the database while disorder persists in the network. That is why this failure mode belongs in the architecture of impunity. It shows how administrative completeness can coexist with operational abandonment. The problem is not missing data. It is missing consequence.

6. Failure Mode 5: economic disincentives — ignoring abuse is cheaper than investigating it

The fifth failure mode explains why the first four persist: the money runs in the wrong direction. Investigating abuse costs labor. It may require skilled staff, multilingual communication, evidence review, customer friction, legal risk assessment, and lost revenue if the account is terminated. Ignoring abuse, by contrast, is cheap. At most it produces some reputational wear, occasional blocklisting, and complaints from parties who are not paying customers. Unless the provider’s upstreams, banks, or regulators impose real cost, the economically rational path is often passivity.

This is the part defenders sometimes hesitate to say aloud because it sounds cynical. But it is not cynicism. It is incentive analysis. If a provider earns recurring income from customers whose behavior generates complaints, and if those complaints rarely lead to regulatory sanctions, then every act of serious abuse handling is effectively subsidized by the provider’s goodwill. Goodwill is not a stable governance mechanism. It is especially unstable in high-margin gray markets where rapid customer replacement is easy and reputation can be managed through dispersion, rebranding, or simple indifference.

Blocklists do not fully reverse this equation. Spamhaus and AbuseIPDB are extremely valuable for defenders because they convert isolated observations into shared intelligence. But from the provider’s side they are often just one more business variable. If a listed network still retains transit, still attracts permissive customers, and still avoids binding regulatory consequences, then listing becomes manageable overhead. Documentation without coercive follow-through does not destroy the business model. It can even help stratify it, pushing the most abuse-tolerant customers toward the most abuse-tolerant providers.

This economic mismatch also explains why many abuse desks seem responsive in language but inert in outcome. Courtesy is cheap; enforcement is expensive. Templates scale; investigations do not. The more a provider can substitute process appearance for substantive action, the longer it can preserve both reputation and revenue. This is not merely unfortunate. It is adaptive. The desk evolves to manage complaints rather than to reduce abuse.

Once that becomes visible, the 96% failure rate stops looking shocking and starts looking mathematically unsurprising. The architecture rewards the provider that minimizes expensive interventions while remaining just credible enough to retain upstream relationships. It rewards the criminal customer that selects providers on the basis of delay, ambiguity, and tolerance. And it punishes the victim, who must spend skilled labor to create evidence that may never alter the attacker’s operating conditions at all.

7. The 90-day experiment: 35 reported IPs, zero action

Numbers are persuasive, but timelines expose character. That is why the 90-day observation window matters so much. A short monitoring period can always be dismissed as impatience. Providers claim queues are long, evidence requires verification, and some customers are given time to respond. Very well. Extend the clock. Watch what actually changes. In this case the result was stark: 35 reported IPs, tracked for 90 days, produced zero remediation action. Not one visible suspension. Not one durable withdrawal. Not one observable indication that the underlying business relationship had been materially altered.

This is the moment where excuses lose analytic value. A few days of silence can be incompetence. A week can be backlog. A month can be procedural drift. Three months across 35 already-reported systems is institutional choice. It tells us that the abuse-report mechanism is not broken at the last minute; it is weak at the design level. It lacks binding triggers, oversight escalation, and economic compulsion. The experiment therefore does not merely document provider indifference. It measures the half-life of consequence inside the current system and finds it effectively absent.

The forensic value of the experiment lies in what it controls for. These were not unreported IPs. They were not unknown to the relevant parties. The observation period was long enough to absorb ordinary operational delay. The sample also existed in an ecosystem where supporting documentation could be corroborated by blocklist systems and prior research. In other words, this was not a test of whether defenders can write better emails. It was a test of whether the formal system reacts when it has the information it claims to need. The answer was no.

The outcome should alter defender expectations. Abuse reporting remains useful as evidence preservation, coordination, and escalation groundwork. But defenders should stop treating it as a reliable remediation path in high-tolerance environments. The 90-day result shows that the reporting channel cannot be assumed to protect the victim on any operational timeline relevant to active intrusion, credential abuse, phishing, proxy churn, or malware distribution. By the time a formal complaint might matter, the campaign will likely have moved, replicated, or been monetized already.

What remains, then, is a grim but necessary clarity: the report is often written for history, not for help. It tells future analysts what was known, when it was known, and which institutions were informed. That is important. But it is not the same as interruption. The experiment proves the distinction.

8. Who benefits: the triple-beneficiary structure

Once the five failure modes are visible together, the system stops resembling negligence and starts resembling a triple-beneficiary structure. The first beneficiary is obvious: criminal operators. They need infrastructure that survives complaints long enough to extract value. Whether the activity is credential abuse, malware delivery, phishing, proxy resale, or command-and-control, time is money. Every hour of continued reachability matters. An abuse-report system that acknowledges without enforcing is almost ideal from their perspective. It converts detection into noise rather than disruption.

The second beneficiary is hosting and transit providers. They do not need to be ideologically aligned with abuse to benefit from the architecture. They only need the revenue. Abuse-tolerant customers pay bills, lease addresses, occupy racks, and purchase connectivity like anyone else. Investigating them is costly. Removing them risks replacement delay. So long as upstream pressure remains weak and registry policy remains non-coercive, the provider can occupy a sweet spot: visibly compliant on paper, minimally interventionist in practice, and financially rewarded for the difference.

The third beneficiary is more politically uncomfortable: intelligence agencies and related state actors. Tolerated abusive infrastructure provides cover, observability, and occasionally usable deniable terrain. A network where malicious activity is expected attracts malicious actors. A poorly enforced hosting ecosystem becomes a sensor field, a staging area, a place to blend, or a place to misdirect attribution. None of this requires every tolerated host to be knowingly protected by an intelligence service. It only requires that the persistence of such environments is useful to them. Operational cover is often created not by direct control, but by stable non-enforcement.

This structure explains why reform is so difficult. The problem is not one villain. It is aligned convenience. Criminal operators want tolerance. Providers want payment. States often prefer a messy, instrumentable internet to one in which every suspicious platform is rapidly neutralized. Victims are the only party consistently asking the system to become more expensive for everyone else. That is not a morally neutral position, but it is the analytically correct one. The system is not malfunctioning equally for all parties. It is selectively working.

This also clarifies why outrage alone changes little. One can expose individual providers, publish indicators, or shame specific response failures. Those acts matter, but they do not erase the incentive alignment beneath them. Without upstream liability, registry enforcement, or meaningful pricing pressure, the architecture simply routes around reputational hits. The triple-beneficiary structure is resilient because its rewards are practical, not symbolic.

9. The abuse report as theater: why the system exists if it rarely works

If abuse reporting fails so consistently in these environments, why does the system exist at all? The answer is not that it is entirely fake. It serves several real functions. It gives legitimate providers a way to receive and act on complaints when they choose to. It provides a standardized administrative interface for defenders. It creates a documentary trail that can support later sanctions, investigations, or public attribution. But in the abuse-tolerant segment, those useful functions coexist with another role: the abuse-report channel performs legitimacy. It reassures outsiders that the internet has a mechanism for self-correction even when the mechanism lacks teeth.

Theater is not absence. It is managed visibility. There is an address to email, a registry object to inspect, a policy paragraph to cite, a ticket number to reference, and perhaps even a courteous template reply. All of these artifacts help maintain the appearance that what failed was an individual case rather than the structure itself. The victim is encouraged to believe that another escalation, another follow-up, or another phrasing of the evidence might finally unlock action. Meanwhile the provider preserves the posture of procedural reasonableness without accepting a binding duty to inconvenience a paying customer.

That theatrical function is politically useful. It allows regulators and governance bodies to claim that the abuse problem is being handled through existing mechanisms. It allows providers to say they maintain abuse desks. It allows intelligence communities to operate in a world where hostile infrastructure is visible but not automatically extinguished. And it allows the broader ecosystem to confuse reportability with enforceability. The form of accountability survives even when the substance dies.

The abuse report survives because it is useful to everyone who needs the appearance of order more than the fact of intervention.

For defenders, the implication is grim but clarifying. Do not abandon abuse reporting; it remains necessary as evidence, coordination, and institutional record. But do abandon the naive belief that the mailbox itself is the remedy. In high-tolerance environments the remedy, if it comes at all, comes from elsewhere: blocklist adoption, upstream pressure, public exposure, pricing consequences, law-enforcement leverage, or direct defensive controls on the victim side. The report is part of the dossier, not the end of the story.

The graveyard therefore teaches a broader lesson about internet governance. Systems can be highly structured and still function as impunity machines. Requirements can exist without enforcement. Contacts can exist without responsibility. documentation can exist without remedy. A 96% failure rate is not evidence that no architecture exists. It is evidence that the architecture serves other masters.

10. Conclusion: the architecture is the message

Look again at the chain. Victim security teams submit structured reports. Spamhaus and AbuseIPDB document abuse. RIPE records contain abuse contacts. Providers advertise acceptable use policies. Yet the same infrastructure persists. In this article’s sample, 35 reported IPs stayed effectively untouched across 90 days. Across comparable hosting in TI-2026-026O, the failure rate reached 96%. Across related research in TI-2026-031F, five recurring failure modes reappeared with numbing consistency. The only honest conclusion is that persistence is not an accident. It is the output of the system as currently designed.

The four highlighted ASN14670 IPs—191.101.33.115, 191.101.33.110, 179.61.232.244, and 198.204.244.210—are therefore more than indicators. They are exhibits in a governance pattern. They show what happens when complaint loops are self-referential, jurisdictions are fragmented, contracts immunize intermediaries, registry policy stops at metadata, and economics reward indifference. None of those components alone guarantees impunity. Together they nearly industrialize it.

The practical implication is severe. Defenders should continue reporting, but they should measure success realistically. Reports create records. They help intelligence sharing. They may support future sanctions or public naming. They are rarely enough by themselves. If the goal is actual interruption, then the center of gravity must move upward and outward: toward upstream responsibility, stronger registry obligations, public consequence for non-responsive abuse desks, and cost transfer back onto the providers who currently externalize harm.

That is why this graveyard deserves its name. Complaints are not merely unheeded; they are interred inside an architecture designed to metabolize them. The point of forensic work is to say this plainly. The report dies not because the facts were weak, nor because the victim was careless, nor because the system lacked a mailbox. It dies because the architecture was built to let it die.