Xarxes de comptes Hydra: Com 20.000 comptes esdevenen un sol actor (CA)

El número més útil de l'informe d'Anthropic de febrer de 2026 sobre atacs de destil·lació no són els 16 milions d'intercanvis ni els aproximadament 24.000 comptes fraudulents. És aquest: "una única xarxa de proxies va gestionar més de 20.000 comptes fraudulents simultàniament."

Simultàniament. Vint mil comptes, actius al mateix temps, sota un sol operador.

Això és una xarxa hydra, i és un disseny d'adversari específic — no descuit, no oportunisme, sinó una arquitectura construïda explícitament per sobreviure a la defensa que espera trobar. Entendre per què funciona és el requisit previ per trencar-la, perquè la fallada que explota no és una regla que falta o un llindar mal ajustat. És un error de categoria en el que la defensa està mesurant.

Punts clau

• Una xarxa hydra distribueix una campanya a través de milers de comptes de manera que cap compte individual excedeixi cap llindar per compte.
• Reduir els llindars no ajuda. L'atacant simplement afegeix comptes — l'entrada més barata del sistema.
• Els senyals que exposen aquestes xarxes són relacionals: dispositius compartits, xarxes compartides, mètodes de pagament compartits, sincronització compartida, biometria compartida. Un veredicte per compte no els pot produir.
• Cerca facial 1:N vincula dos comptes a un ésser humà. L'anàlisi de dispositius i IP vincula comptes a infraestructures compartides. Junts, col·lapsen el gràfic de comptes en un gràfic d'actors.
• El codi únic més valuós en aquest context és DEVICE_RECOVERED_HIGH_CONFIDENCE — un dispositiu que ja s'ha vist abans, tornant després d'un restabliment o reinstal·lació. Això és regeneració, detectada a la porta.
• La vinculació no és una acusació. Els senyals duplicats són informatius per defecte — tu decideixes la política.

Què és realment una xarxa hydra

Si eliminem els detalls, una xarxa hydra té quatre propietats.

Distribució horitzontal. La càrrega de treball es divideix de manera que el comportament de cada compte s'ajusta còmodament a la normalitat. Anthropic va descriure patrons que "suggerien 'equilibri de càrrega'" — que és exactament la paraula correcta. Aquest és un problema d'infraestructura que es resol amb un pensament d'infraestructura.

Regeneració barata. Es poden crear nous comptes més ràpidament del que s'eliminen els antics. Cada eliminació és un error d'arrodoniment enfront de l'oferta.

Substrat compartit. Sota la superfície, els comptes funcionen amb un grup finit de recursos reals — dispositius, rangs d'IP, números de telèfon, instruments de pagament, i en molts casos un petit nombre d'éssers humans reals que completen les comprovacions existents.

Homogeneïtat conductual. Com que un sol operador els controla tots, els comptes convergeixen. Anthropic va observar "patrons idèntics, mètodes de pagament compartits i sincronització coordinada", i variacions de sol·licituds que arribaven "desenes de milers de vegades a través de centenars de comptes coordinats."

La tercera propietat és la vulnerabilitat. La distribució és barata a la capa de comptes i cara a la capa física. Pots crear 20.000 adreces de correu electrònic de franc. No pots crear 20.000 cares humanes, 20.000 terminals no modificats o 20.000 adreces IP residencials en rangs no relacionats sense un cost que escala.

Tota xarxa hydra és més estreta a la part inferior que a la superior. Tot el joc consisteix a mesurar a la part inferior.

Per què els llindars són l'instrument equivocat

Considerem una plataforma que marca qualsevol compte que superi les 50.000 sol·licituds en un mes amb una distribució de consultes concentrada. Regla raonable. Contra un únic compte abusiu funciona.

Contra un operador amb 20.000 comptes, significa que cada compte pot fer 2.500 sol·licituds sense ser mai revisat — 50 milions de sol·licituds, totalment sota el radar. Redueix el llindar a 5.000 i l'operador passa a 250 sol·licituds per compte i afegeix comptes si és necessari. Cada reducció del llindar et costa falsos positius en desenvolupadors reals i a l'atacant gairebé res.

Aquest és un intercanvi perdedor, i perd per una raó estructural: el llindar es denomina en la unitat que l'atacant controla.

L'atacant tria quants comptes utilitzar. No tria quantes cares té, quants dispositius físics posseeix o quants camins de xarxa independents pot assolir. Mou la mesura a una unitat que l'atacant no controla i l'economia s'inverteix.

Les primitives d'enllaç

Quatre famílies de senyals fan el col·lapse. Cadascuna respon a una versió diferent de "ja ho he vist abans?"

Biometria — és la mateixa persona?

La Cerca facial 1:N cerca una cara contra totes les verificacions aprovades que la teva aplicació ja ha realitzat. És gratuïta amb la verificació d'identitat de Didit i retorna en menys de dos segons.

curl -X POST 'https://verification.didit.me/v3/face-search/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -F 'user_image=@./selfie.jpg' \
  -F 'search_type=most_similar' \
  -F 'save_api_request=true' \
  -F 'vendor_data=account-8842'

La resposta embolcalla un objecte face_search singular — { request_id, face_search: { ... } } — que conté total_matches i una matriu matches, on cada coincidència inclou session_id, similarity_percentage, vendor_data, verification_date i is_blocklisted. Si el mateix operador va verificar 40 comptes amb la mateixa cara, una trucada mostra els 40 — amb la teva pròpia vendor_data en cadascun, de manera que pots mapejar-los directament a IDs de compte.

Això s'executa automàticament durant la prova de vida dins d'una sessió de verificació, de manera que en el cas comú obtens el senyal sense fer una trucada separada en absolut.

Dispositiu — és la mateixa màquina?

L'anàlisi de dispositius i IP costa 0,03 $ i s'inclou en el paquet de verificació de 0,33 $. Els codis que importen per a la multiplicació de comptes:

Advertència	Què et diu
DUPLICATED_DEVICE_FINGERPRINT	El mateix dispositiu està darrere de múltiples verificacions
DEVICE_RECOVERED_HIGH_CONFIDENCE	Un dispositiu vist abans, que torna després d'un restabliment o reinstal·lació
DUPLICATED_IP_ADDRESS	La mateixa adreça està darrere de múltiples verificacions
AUTOMATION_FRAMEWORK_DETECTED	El client està scriptat en lloc de ser controlat per humans
DEVICE_EMULATOR_DETECTED	Un emulador, no un telèfon real
DEVICE_ROOTED_OR_JAILBROKEN	Un sistema operatiu compromès
DEVICE_RUNTIME_HOOKING_DETECTED	Instrumentació en temps d'execució al client
DEVICE_APP_TAMPERED	Un binari d'aplicació modificat
PRIVATE_NETWORK_DETECTED	Una ruta de xarxa privada o anonimitzadora
COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP	La geografia del document i la de la xarxa no coincideixen

DEVICE_RECOVERED_HIGH_CONFIDENCE mereix una atenció especial. Didit distingeix un dispositiu duplicat d'un dispositiu recuperat — un dispositiu que reapareix després de ser esborrat, restablert o amb l'aplicació reinstal·lada. Esborrar el dispositiu és el moviment estàndard per a un operador que regenera comptes després d'una prohibició. Aquest codi és el pas de regeneració de l'hydra, fet visible.

Contacte — és la mateixa identitat accessible?

La verificació de correu electrònic i telèfon (0,03 $ per correu electrònic; telèfon mitjançant SMS, WhatsApp, Telegram, RCS o veu) comprova si un punt de contacte és real i accessible en lloc de simplement ben format. Els comptes "farmats" depenen en gran mesura d'adreces d'un sol ús i números reciclats. Els valors de telèfon es normalitzen a E.164, de manera que el mateix número no es pot amagar darrere de diferències de format.

Document — és la mateixa credencial?

La verificació d'identitat emet DUPLICATED_DOCUMENT quan el mateix document es torna a enviar, i POSSIBLE_DUPLICATED_USER quan un enviament es resol a una persona que ja es troba en el teu conjunt verificat. Tots dos detecten comptes que comparteixen una credencial fins i tot quan la cara o el dispositiu són diferents — i POSSIBLE_DUPLICATED_USER s'omet quan el número de document es troba a la teva llista blanca de documents, de manera que les credencials conegudes i vàlides no generen soroll.

Del gràfic de comptes al gràfic d'actors

Individualment, aquestes són només advertències. Juntes, col·lapsen un gràfic.

Suposem que la vostra capa de trànsit marca el compte acct_7781 — consultes concentrades contra una capacitat, temps inusual. La revisió per compte us dóna un veredicte sobre un compte.

En canvi, preneu la sessió de verificació darrere d'aquest compte i pivoteu:

1. Cara — cerqueu la cara de la sessió entre els vostres usuaris verificats. Dotze comptes la comparteixen.
2. Dispositiu — la sessió porta DUPLICATED_DEVICE_FINGERPRINT. Nou comptes més comparteixen el dispositiu, quatre dels quals no es troben al conjunt de cares perquè una persona diferent va completar aquestes comprovacions.
3. Xarxa — DUPLICATED_IP_ADDRESS a través d'un rang CIDR atrau un altre clúster.
4. Contacte — tres dels comptes recentment descoberts comparteixen un número de telèfon en format E.164.

Un compte marcat s'ha convertit en un clúster de més de trenta, descobert a partir d'una única alerta, utilitzant senyals que ja es van recollir en l'incorporació. I no vau necessitar inspeccionar cap sol·licitud per arribar-hi. La capa de trànsit us va dir aquí hi ha alguna cosa malament; la resolució d'identitat us va dir fins on arriba.

Que també és el límit del que això fa. La resolució d'identitat no impedeix l'extracció de models, i no la detecta. Mai veu les vostres sol·licituds. El que fa és convertir una alerta en el conjunt complet de comptes que hi ha darrere, i fer que el proper compte amb la mateixa cara, dispositiu o xarxa sigui car de crear. Els controls de sortida a nivell de model i la detecció de trànsit semàntic segueixen sent capes separades i necessàries — i segueixen sent vostres.

La regla que manté això honest

Un enllaç no és un veredicte.

Didit és deliberat en això. A la Cerca Facial, status és "Declined" només quan es troba una coincidència amb la llista negra. Una coincidència duplicada pura retorna "Approved" amb DUPLICATED_FACE a les advertències — informatiu. La política de deduplicació és vostra, no nostra.

Aquest valor per defecte és correcte, perquè els duplicats tenen explicacions innocents. Un desenvolupador amb un compte personal i un compte d'empresa. Una xarxa d'oficina compartida que produeix DUPLICATED_IP_ADDRESS per a una dotzena d'enginyers no relacionats. Un dispositiu familiar. Un laboratori universitari on vint estudiants verifiquen des de la mateixa sala.

La manera correcta d'utilitzar els enllaços és com a evidència que augmenta o disminueix una decisió que ja estaves prenent, no com una prohibició automàtica. Dos comptes que comparteixen una cara són febles per si sols. Dotze comptes que comparteixen una cara, un dispositiu, un rang de xarxa i una signatura de consulta no són gens febles. Les accions d'advertència són configurables per codi — una coincidència amb la llista negra pot forçar un rebuig mentre que un senyal de dispositiu recuperat es dirigeix a revisió — de manera que l'escala d'escalada és vostra per establir-la.

Casos d'ús

Plataformes d'API d'IA que correlacionen una alerta de la capa de trànsit amb el conjunt complet de comptes que controla un operador, en lloc de prohibir-ne un i esperar el següent.

Abús de proves i crèdits — l'ús de comptes gratuïts utilitza mecàniques idèntiques. Les mateixes primitives que detecten un clúster de destil·lació detecten un clúster d'abús de promocions.

Mercats i plataformes de serveis a la carta que detecten venedors o repartidors que es tornen a registrar després de ser eliminats.

iGaming que aplica regles de compte únic i autoexclusió, on la mateixa persona que torna sota una nova identitat és el principal incompliment de la normativa.

Preguntes freqüents

Això requereix emmagatzemar dades biomètriques?

La Cerca facial s'executa contra l'índex facial que la vostra aplicació construeix a través de verificacions prèvies — sessions amb save_api_request=true, o Liveness passiva amb save_api_request=true. Vós controleu què entra a l'índex i vós controleu la retenció, d'acord amb la vostra pròpia política de privadesa i base legal. Si no registreu cares, la cerca 1:N no té res a cercar.

Què passa si l'operador utilitza persones diferents per a cada compte?

Llavors la capa biomètrica s'aprimarà i les capes de dispositiu, xarxa i contacte assumiran el pes — que és exactament per què la vinculació utilitza diverses famílies independents en lloc d'una. Pagar a humans reals per completar les comprovacions és també la forma més cara de crear comptes, que és el punt: mou l'atacant cap a costos que escalen.

Quina rapidesa té una cerca 1:N?

Resposta en menys de dos segons. També s'executa automàticament durant la prova de vida dins d'una sessió de verificació, de manera que en la majoria dels fluxos el senyal de vinculació arriba amb el resultat de la verificació.

Això no generarà falsos positius en xarxes compartides?

DUPLICATED_IP_ADDRESS per si sol és un senyal feble i s'ha de tractar com a tal — oficines, universitats i NAT d'operadors mòbils el produeixen legítimament. Peseu-lo baix, requeriu corroboració d'una família independent i configureu l'acció per codi en lloc de rebutjar qualsevol advertència.

Puc cercar una cara que mai no va passar per una verificació de Didit?

Sí. La cerca facial accepta qualsevol user_image (jpg, jpeg, png, tiff o webp, fins a 5 MB — no s'accepten PDF) i la cerca contra el vostre índex. Si no es detecta cap cara, la trucada retorna HTTP 400.

Preparat per començar?

La vinculació entre comptes està disponible a tots els comptes de Didit — sense producte separat, sense mínims.

• Llegiu la documentació — Cerca facial 1:N i el catàleg d'advertències d'anàlisi d'IP i dispositius.
• Vegeu el producte — Verificació d'usuaris.
• Consulteu els preus — publicats: Cerca facial 1:N gratuïta, anàlisi d'IP i dispositius 0,03 $, paquet complet de verificació 0,33 $.
• Comenceu gratuïtament — business.didit.me, 500 verificacions KYC al mes sense cost.