TI-2026-099 — The Complaint Department: Who Is Actually Accountable for the Attacks

Classification: HIGH · Forensic threat intelligence · Abuse-contact / accountability vector · Series: The Complaint Department

Every other dossier in this program asks who is attacking us. This one asks the quieter, more uncomfortable question that comes after: who are you supposed to tell? Every attacking IP has, by the internet's own design, an accountable contact — a WHOIS abuse desk, a registrant, a maintainer, a human or role you can report it to. The honeypot resolves all of them, and the resulting directory of 749 "persons" is the map of accountability itself. Read it closely and the map dissolves in your hands. The hundreds of names collapse onto a handful of shared mailboxes; the granularity is a mirage; and a whole tier of it exists specifically so that the question "who is responsible?" has no answer. This is the complaint department, and it is mostly a wall.

1. Not the Attackers — the Accountable

First, what this data is not. The 749 records here are not perpetrators. Every one carries risk_score: 0.0, because they are not attacking anything — they are the published contacts the attacking IPs resolve to: the abuse@ addresses, the registrant names, the RIR maintainers that WHOIS lists as accountable for the address space. Prachi Singh is not a hacker; she is an IP-administration contact at Microsoft. The link_count on each record is the number of attacking IPs that trace back to that contact — a measure of how much of the attack surface each desk is nominally on the hook for.

This is the accountability layer made legible. It is the answer to "who do I complain to," rendered as a graph. And the top of it looks reassuringly like responsibility working as designed:

A handful of the world's largest carriers and clouds are responsible for thousands of attacking IPs. That is not surprising — big networks host big attack volumes. What is surprising is what happens when you stop reading the names and start reading the mailboxes.

2. The Collapse

The 749 "persons" imply 749 distinct accountable parties. They are nothing of the sort. Sort the list by email address and the named-individual granularity collapses onto a few shared mailboxes — in the top 100 contacts alone, four addresses absorb roughly forty-five of them.

The clearest case is China Telecom. These are all separate records in the directory, each a differently-named "individual":

Jinneng Wang · Xianghong Cao · Bin Ren · Yali Xiao · Changhai Liu · Hongbiao Zhang · Wu Xiao Li · Xin Ruosheng · zhaolong li · Weng Wen Qian · Hostmaster of Beijing Telecom · shanxitele tech · Yang Zhanrong · …

Every one of them lists the same email, anti-spam@chinatelecom.cn, and the same NIC handle, CH93-AP / IRT-CHINANET-CN. They are not fourteen accountable people. They are one national abuse role desk, wearing the names of provincial hostmasters. The identical pattern repeats:

• China Unicom — zhaoyz3@chinaunicom.cn, handle CH1302-AP / IRT-CU-CN — behind ~11 named "individuals" (sun ying, Lan Li, Xifei Xie, yun hu, Guangyu Zhan, huang zheng…).
• Rostelecom — abuse@rt.ru, ROSTELECOM-MNT / IE1277-RIPE — behind ~5 (Ilya Evreinov, Michael Avdonin, Vladimir Sherstnev, Nikolaenko Ilia, Andrey Kolganov).

This is accountability diffused by scale. A single overwhelmed role mailbox stands behind dozens of names and thousands of attacking IPs. Reporting one of those IPs is not reporting it to a person; it is dropping a note into a national telecom's abuse@ — a mailbox whose volume guarantees it functions as a black hole. The person-level "who" the directory seems to offer does not exist; there is only the mailbox, and the mailbox does not answer.

3. The Second Wall: Accountability by Design

The carriers diffuse responsibility as a side effect of scale. The fourth collapse-center does it on purpose, and it is the more interesting one.

report@abuseradar.com, with the maintainer netutils-mnt, is the shared abuse contact for roughly fifteen unrelated RIPE resource holders. They have nothing in common but this address:

Matteo Martelloni trading as DELUXHOST · Cyber Assets FZCO · Chunkserve / Mateusz Peplinski · Furcop Innovation Sdn Bhd · BreezeHost · Ethernet Servers · Jake Brander / Brander Group · "JSC Ukrtelecom" · "MB Lirutis" · "SC Lithuanian Radio and TV Center" · …

This is a commercial abuse-forwarding service — an "abuse desk as a service" that many small hosters point their WHOIS abuse-c at. In principle that is a legitimate outsourcing. In practice its structural effect is a single funnel through which a defender's complaint about any of fifteen different networks lands in the same third-party inbox, one step removed from whoever actually controls the space — and the tenant list skews toward the small, disposable, bulletproof-adjacent end (a "trading as DELUXHOST", a "Cyber Assets FZCO", brands that come and go). Note also the country fields: "JSC Ukrtelecom" and "MB Lirutis" — plainly Ukrainian and Lithuanian entities — are both stamped US. Whether sloppiness or seeding, the geo is wrong, and wrong geo is one more thread cut between an attacking IP and a real jurisdiction.

Above these sit the purer anonymisation moves: RIPE "Private Customer" (62 attacking IPs behind ten PC-#### privacy handles, real holder hidden by policy), and — importantly, on the honest side — Emerald Onion, a US nonprofit that runs Tor exit nodes and is anonymous by mission, not evasion. The layer is a mixture, and saying so is the discipline: genuine privacy, sloppy data, and deliberate obfuscation all live in the same directory, and only the third is a finding.

One thread ties this back to the rest of the program. PITLINE — the bulletproof autonomous system this series recorded sitting dark in the census of TI-2026-096A — appears here twice, as two abuse contacts (abuse@pitline.net, PITLINE-MNT, and a PITLINE-MNT record via abusep@kharkiv.com). The dark-reserve inventory and its accountability face are the same operator, seen from two vectors. The complaint department has a PITLINE desk; it simply does not take complaints.

4. Why the Mirage Matters

Pull the threads together and the finding is structural, not accusatory. The internet's designed mechanism for holding networks responsible for their traffic — the WHOIS abuse contact — funnels thousands of attacking IPs into (a) a small number of state-carrier role desks so voluminous they are black holes, and (b) a forwarding-and-privacy layer built, whether by outsourcing convenience or by intent, to stand between the complaint and the controller. A WHOIS "who" is not a who. It is a mailbox, and often a mailbox chosen so that the trail ends there.

That has two concrete consequences for anyone doing attribution or abuse response. First, person-level attribution via WHOIS is largely theatre: resolving an attacker to "Jinneng Wang" or "Matteo Martelloni" feels like reaching a human, but it reaches anti-spam@chinatelecom.cn or report@abuseradar.com — a role, shared with dozens of others. Second, abuse reporting, as a control, is structurally throttled: the reports that matter most (against the highest-volume sources) land in exactly the desks least able or willing to act on them. The complaint department is not broken by accident; its shape is the predictable result of scale on one side and deliberate diffusion on the other.

5. The Counter-Narrative

Steelman. "You have discovered that abuse contacts are role addresses and that big telcos have one abuse desk. That is how WHOIS is supposed to work — role mailboxes are correct practice, RIR privacy is a feature, and abuse-desk outsourcing is legitimate. You have dressed normal registry hygiene up as a conspiracy."

The objection is right about the facts and wrong about the implication, and the letter is built on conceding the first:

• "This is normal." Exactly — and the normality is the finding. No malfeasance is alleged of any named contact; every one is doing standard registry practice at risk_score 0.0. The finding is not that someone broke the system; it is that the system, working as designed, funnels accountability into black holes and forwarders. A structural gap that emerges from everyone following the rules is more important than one caused by a bad actor, because it cannot be fixed by catching anyone.
• "Role mailboxes are correct." Yes, which is why the mirage is dangerous. The problem is not that anti-spam@chinatelecom.cn exists; it is that a WHOIS-name-to-human pipeline treats the fourteen names in front of it as fourteen accountable parties when they are one desk. Naming that collapse stops an analyst from mistaking registry granularity for real granularity.
• "AbuseRadar and Private Customer are legitimate." Mostly, and the letter says so. Outsourced abuse desks and RIR privacy are lawful and often benign; Emerald Onion is explicitly flagged as mission-anonymous, not evasive. The claim is narrow: these mechanisms, whatever their intent, diffuse accountability, and their tenant lists at the bulletproof-adjacent end (DELUXHOST, Cyber Assets FZCO, PITLINE) show the diffusion is useful to operators who want it.

What is not claimed: that any named contact is an attacker (all are risk-0 published contacts); that AbuseRadar, Private Customer, or any carrier is unlawful (they are standard mechanisms); that the collapse counts are exhaustive (they are read from the top 100 of 749 and stated as approximate); or that geo-mislabels are necessarily deliberate (they may be registry error). The claim is that the accountability layer, in aggregate, resolves attackers to shared mailboxes rather than responsible parties.

Confidence: HIGH that the abuse-contact graph concentrates thousands of attacking IPs into a small set of contacts and that named individuals collapse onto shared carrier mailboxes; MEDIUM that the AbuseRadar/privacy layer constitutes deliberate accountability diffusion rather than benign outsourcing (established as a real effect, not as intent).

6. Defence Response

• Cluster attackers by abuse mailbox, not by WHOIS name. The real unit of the accountability layer is the shared email/handle (anti-spam@chinatelecom.cn, report@abuseradar.com), not the person string. De-duplicate to the mailbox before you count "distinct responsible parties," or you will over-count accountability tenfold.
• Triage abuse reports by desk responsiveness, not by volume. A complaint to a national-carrier abuse@ black hole is near-worthless; the same complaint to a small, single-tenant host may actually land. Spend reporting effort where a report can act, and treat the mega-desks as blocklist material rather than remediation partners.
• Flag the diffusion layer as a signal. A resource holder whose abuse-c is a shared forwarding service (AbuseRadar/netutils-mnt), a RIPE "Private Customer" role, or carries a mismatched country is not necessarily malicious — but the combination is a reliable marker of the small/disposable/bulletproof-adjacent tier, and worth weighting.
• Cross the accountability graph with the dark census. When an abuse contact (PITLINE) also appears in the held-dark reserve (TI-2026-096A), you have the same operator from two angles — a stronger attribution anchor than either vector alone.

7. A Note on Method

Built entirely through honeypot_persons — the honeypot's resolution of attacking IPs to their WHOIS abuse/admin/registrant contacts, read for email, nic_handles, link_count, contact_kind, and country. The collapse counts are derived by grouping the top ~100 contacts on shared email and handle; they are stated as approximate because they are drawn from the top of a 749-record list, not its entirety. All named contacts are public registry data at risk_score 0.0 and are presented to characterise the accountability structure, not to attribute wrongdoing. No SQL touched the investigation.

8. Investigation Metadata

Cristian Lișneanu · shuffle-on.com · Threat Intelligence