Passer au contenu principal
Didit lève 7,5 M$ pour bâtir l'infrastructure pour l'identité et la fraude
Didit
Retour au blog
Blog · 4 août 2026

Réseaux de comptes Hydra : Quand 20 000 comptes ne font qu'un acteur (FR)

Coupez un compte, deux autres apparaissent. Les réseaux Hydra sont conçus pour déjouer l'examen individuel des comptes. Voici comment le chaînage inter-comptes (visage, appareil, IP, e-mail, téléphone) réduit des milliers de.

Par DiditMis à jour le
hydra-account-networks-ai-api-abuse.png

Le chiffre le plus utile du rapport d'Anthropic de février 2026 sur les attaques par distillation n'est pas les 16 millions d'échanges ou les quelque 24 000 comptes frauduleux. C'est celui-ci : « un seul réseau proxy a géré plus de 20 000 comptes frauduleux simultanément. »

Simultanément. Vingt mille comptes, actifs en même temps, sous la direction d'un seul opérateur.

C'est un réseau hydra, et c'est une conception d'adversaire spécifique — pas de la négligence, pas de l'opportunisme, mais une architecture construite explicitement pour survivre à la défense qu'elle s'attend à rencontrer. Comprendre pourquoi cela fonctionne est le préalable pour le briser, car la défaillance qu'il exploite n'est pas une règle manquante ou un seuil mal ajusté. C'est une erreur de catégorie dans ce que la défense mesure.

Points clés à retenir

  • Un réseau hydra répartit une campagne sur des milliers de comptes afin qu'aucun compte individuel ne dépasse un seuil par compte.
  • Abaisser les seuils n'aide pas. L'attaquant ajoute simplement des comptes — l'entrée la moins chère du système.
  • Les signaux qui exposent ces réseaux sont relationnels : appareils partagés, réseaux partagés, méthodes de paiement partagées, synchronisation partagée, données biométriques partagées. Un verdict par compte ne peut pas les produire.
  • La Recherche Faciale 1:N relie deux comptes à un être humain. L'analyse des appareils et des adresses IP relie les comptes à une infrastructure partagée. Ensemble, ils transforment le graphe des comptes en un graphe d'acteurs.
  • Le code unique le plus précieux dans ce contexte est DEVICE_RECOVERED_HIGH_CONFIDENCE — un appareil qui a déjà été vu, revenant après une réinitialisation ou une réinstallation. C'est la régénération, détectée à la porte.
  • Le chaînage n'est pas une accusation. Les signaux dupliqués sont informatifs par défaut — c'est vous qui décidez de la politique.

Ce qu'est réellement un réseau hydra

Enlevez les spécificités et un réseau hydra a quatre propriétés.

Distribution horizontale. La charge de travail est divisée de sorte que le comportement de chaque compte reste confortablement dans la normale. Anthropic a décrit des modèles qui « suggéraient un 'équilibrage de charge' » — ce qui est exactement le bon mot. Il s'agit d'un problème d'infrastructure résolu avec une pensée d'infrastructure.

Régénération bon marché. De nouveaux comptes peuvent être créés plus rapidement que les anciens ne sont supprimés. Chaque suppression est une erreur d'arrondi par rapport à l'offre.

Substrat partagé. Sous la surface, les comptes fonctionnent sur un pool fini de ressources réelles — appareils, plages IP, numéros de téléphone, instruments de paiement, et dans de nombreux cas un petit nombre d'êtres humains réels effectuant les vérifications existantes.

Homogénéité comportementale. Parce qu'un seul opérateur les gère tous, les comptes convergent. Anthropic a observé « des modèles identiques, des méthodes de paiement partagées et une synchronisation coordonnée », et des variations de prompts arrivant « des dizaines de milliers de fois sur des centaines de comptes coordonnés. »

La troisième propriété est la vulnérabilité. La distribution est bon marché au niveau des comptes et coûteuse au niveau physique. Vous pouvez créer 20 000 adresses e-mail pour rien. Vous ne pouvez pas créer 20 000 visages humains, 20 000 combinés non modifiés ou 20 000 adresses IP résidentielles dans des plages non liées sans un coût qui augmente.

Chaque réseau hydra est plus étroit en bas qu'en haut. Tout le jeu consiste à mesurer en bas.

Pourquoi les seuils sont le mauvais instrument

Considérez une plateforme qui signale tout compte dépassant 50 000 requêtes par mois avec une distribution de requêtes concentrée. Règle raisonnable. Contre un seul compte abusif, cela fonctionne.

Contre un opérateur avec 20 000 comptes, cela signifie que chaque compte peut faire 2 500 requêtes sans jamais être examiné — 50 millions de requêtes, entièrement sous le radar. Réduisez le seuil à 5 000 et l'opérateur passe à 250 requêtes par compte et ajoute des comptes si nécessaire. Chaque réduction du seuil vous coûte des faux positifs sur de vrais développeurs et ne coûte presque rien à l'attaquant.

C'est un échange perdant, et il perd pour une raison structurelle : le seuil est libellé dans l'unité que l'attaquant contrôle.

L'attaquant choisit le nombre de comptes à utiliser. Il ne choisit pas le nombre de visages qu'il a, le nombre d'appareils physiques qu'il possède ou le nombre de chemins réseau indépendants qu'il peut atteindre. Déplacez la mesure vers une unité que l'attaquant ne contrôle pas et l'économie s'inverse.

Les primitives de chaînage

Quatre familles de signaux effectuent le regroupement. Chacune répond à une version différente de « ai-je déjà vu cela ? »

Biométrie — est-ce la même personne ?

La Recherche Faciale 1:N compare un visage à toutes les vérifications approuvées que votre application a déjà effectuées. Elle est gratuite avec la vérification d'identité Didit et renvoie un résultat en moins de deux secondes.

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 réponse contient un objet face_search singulier — { request_id, face_search: { ... } } — contenant total_matches et un tableau matches, où chaque correspondance inclut session_id, similarity_percentage, vendor_data, verification_date et is_blocklisted. Si le même opérateur a vérifié 40 comptes avec le même visage, un seul appel les fait apparaître tous les 40 — avec votre propre vendor_data sur chacun, afin que vous puissiez les associer directement aux identifiants de compte.

Cela s'exécute automatiquement pendant la preuve de vie au sein d'une session de vérification, donc dans le cas courant, vous obtenez le signal sans faire d'appel séparé.

Appareil — est-ce la même machine ?

L'analyse des appareils et des adresses IP coûte 0,03 $ et est incluse dans le forfait de vérification à 0,33 $. Les codes importants pour la multiplication des comptes :

AvertissementCe qu'il vous dit
DUPLICATED_DEVICE_FINGERPRINTLe même appareil est derrière plusieurs vérifications
DEVICE_RECOVERED_HIGH_CONFIDENCEUn appareil déjà vu, revenant après une réinitialisation ou une réinstallation
DUPLICATED_IP_ADDRESSLa même adresse est derrière plusieurs vérifications
AUTOMATION_FRAMEWORK_DETECTEDLe client est scripté plutôt qu'humain
DEVICE_EMULATOR_DETECTEDUn émulateur, pas un vrai combiné
DEVICE_ROOTED_OR_JAILBROKENUn système d'exploitation compromis
DEVICE_RUNTIME_HOOKING_DETECTEDInstrumentation d'exécution sur le client
DEVICE_APP_TAMPEREDUne application binaire modifiée
PRIVATE_NETWORK_DETECTEDUn chemin réseau privé ou anonymisant
COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IPLa géographie du document et du réseau ne correspondent pas

DEVICE_RECOVERED_HIGH_CONFIDENCE mérite une attention particulière. Didit distingue un appareil dupliqué d'un appareil récupéré — un appareil qui réapparaît après avoir été effacé, réinitialisé ou après la réinstallation de l'application. L'effacement de l'appareil est la démarche standard pour un opérateur qui régénère des comptes après une interdiction. Ce code est l'étape de régénération de l'hydra, rendue visible.

Contact — est-ce la même identité joignable ?

La vérification des e-mails et des téléphones (0,03 $ pour les e-mails ; téléphone via SMS, WhatsApp, Telegram, RCS ou vocal) teste si un point de contact est réel et joignable plutôt que simplement bien formé. Les comptes de ferme s'appuient fortement sur des adresses jetables et des numéros recyclés. Les valeurs de téléphone se normalisent à l'E.164, de sorte que le même numéro ne peut pas se cacher derrière des différences de formatage.

Document — est-ce le même justificatif ?

La vérification d'identité émet DUPLICATED_DOCUMENT lorsque le même document est soumis à nouveau, et POSSIBLE_DUPLICATED_USER lorsqu'une soumission correspond à une personne déjà dans votre ensemble vérifié. Les deux détectent les comptes partageant un justificatif même si le visage ou l'appareil diffère — et POSSIBLE_DUPLICATED_USER est ignoré lorsque le numéro du document figure sur votre liste blanche de documents, de sorte que les justificatifs connus ne génèrent pas de bruit.

Du graphe des comptes au graphe des acteurs

Individuellement, ce ne sont que des avertissements. Ensemble, ils réduisent un graphe.

Supposons que votre couche de trafic signale le compte acct_7781 — requêtes concentrées sur une capacité, synchronisation inhabituelle. L'examen par compte vous donne un verdict sur un seul compte.

Au lieu de cela, prenez la session de vérification derrière ce compte et pivotez :

  1. Visage — recherchez le visage de la session parmi vos utilisateurs vérifiés. Douze comptes le partagent.
  2. Appareil — la session contient DUPLICATED_DEVICE_FINGERPRINT. Neuf autres comptes partagent l'appareil, dont quatre ne font pas partie de l'ensemble de visages car une personne différente a effectué ces vérifications.
  3. RéseauDUPLICATED_IP_ADDRESS sur une plage CIDR attire un autre cluster.
  4. Contact — trois des comptes nouvellement découverts partagent un numéro de téléphone au format E.164.

Un compte signalé est devenu un cluster de plus de trente, découvert à partir d'une seule alerte, en utilisant des signaux déjà collectés lors de l'intégration. Et vous n'avez pas eu besoin d'inspecter un seul prompt pour y arriver. La couche de trafic vous a dit quelque chose ne va pas ici ; la résolution d'identité vous a dit jusqu'où cela va.

C'est aussi la limite de ce que cela fait. La résolution d'identité n'empêche pas l'extraction de modèle et ne la détecte pas. Elle ne voit jamais vos prompts. Ce qu'elle fait, c'est transformer une alerte en l'ensemble complet des comptes derrière elle, et rendre coûteuse la création du prochain compte avec le même visage, appareil ou réseau. Les contrôles de sortie au niveau du modèle et la détection sémantique du trafic restent des couches séparées et nécessaires — et elles restent les vôtres.

La règle qui garantit l'honnêteté de ce système

Un lien n'est pas un verdict.

Didit est délibéré à ce sujet. Dans la Recherche Faciale, le status est "Declined" uniquement lorsqu'une correspondance avec une liste de blocage est trouvée. Une pure correspondance en double renvoie "Approved" avec DUPLICATED_FACE dans les avertissements — à titre informatif. La politique de déduplication est la vôtre, pas la nôtre.

Ce défaut est correct, car les doublons ont des explications innocentes. Un développeur avec un compte personnel et un compte d'entreprise. Un réseau de bureau partagé produisant DUPLICATED_IP_ADDRESS pour une douzaine d'ingénieurs sans lien. Un appareil familial. Un laboratoire universitaire où vingt étudiants vérifient depuis la même pièce.

La bonne façon d'utiliser les liens est comme une preuve qui élève ou abaisse une décision que vous preniez déjà, et non comme une interdiction automatique. Deux comptes partageant un visage est faible en soi. Douze comptes partageant un visage, un appareil, une plage réseau et une signature de requête n'est pas faible du tout. Les actions d'avertissement sont configurables par code — un signal de liste de blocage peut forcer un refus tandis qu'un signal d'appareil récupéré entraîne un examen — de sorte que l'échelle d'escalade est à votre discrétion.

Cas d'utilisation

Plateformes API d'IA corrélant une alerte de la couche de trafic à l'ensemble complet des comptes qu'un opérateur contrôle, au lieu d'en interdire un et d'attendre le suivant.

Abus d'essai et de crédit — l'exploitation des niveaux gratuits utilise des mécanismes identiques. Les mêmes primitives qui font apparaître un cluster de distillation font apparaître un cluster d'abus promotionnel.

Marchés et plateformes de travail à la demande détectant les vendeurs ou les coursiers qui se réinscrivent après un retrait.

iGaming appliquant les règles de compte unique et d'auto-exclusion, où la même personne revenant sous une nouvelle identité est la principale défaillance de conformité.

Questions fréquemment posées

Cela nécessite-t-il le stockage de données biométriques ?

La Recherche Faciale s'effectue sur l'index facial que votre application construit grâce aux vérifications précédentes — sessions avec save_api_request=true, ou preuve de vie passive avec save_api_request=true. Vous contrôlez ce qui entre dans l'index et vous contrôlez la rétention, conformément à votre propre avis de confidentialité et à votre base juridique. Si vous n'enregistrez pas les visages, la recherche 1:N n'a rien à rechercher.

Que se passe-t-il si l'opérateur utilise des personnes différentes pour chaque compte ?

Alors la couche biométrique s'amincit et les couches d'appareil, de réseau et de contact portent le poids — c'est exactement pourquoi le chaînage utilise plusieurs familles indépendantes plutôt qu'une seule. Payer de vrais humains pour effectuer des vérifications est également le moyen le plus coûteux d'exploiter des comptes, ce qui est le but : cela pousse l'attaquant vers des coûts qui augmentent.

Quelle est la rapidité d'une recherche 1:N ?

Réponse en moins de deux secondes. Elle s'exécute également automatiquement pendant la preuve de vie au sein d'une session de vérification, de sorte que dans la plupart des flux, le signal de chaînage arrive avec le résultat de la vérification.

Cela ne générera-t-il pas de faux positifs sur les réseaux partagés ?

DUPLICATED_IP_ADDRESS seul est un signal faible et doit être traité comme tel — les bureaux, les universités et les NAT des opérateurs mobiles le produisent tous légitimement. Donnez-lui un poids faible, exigez une corroboration d'une famille indépendante et configurez l'action par code plutôt que de refuser sur un seul avertissement.

Puis-je rechercher un visage qui n'a jamais été soumis à une vérification Didit ?

Oui. La Recherche Faciale accepte toute user_image (jpg, jpeg, png, tiff ou webp, jusqu'à 5 Mo — les PDF ne sont pas acceptés) et la recherche dans votre index. Si aucun visage n'est détecté, l'appel renvoie HTTP 400.

Prêt à commencer ?

Le chaînage inter-comptes est disponible sur chaque compte Didit — pas de produit séparé, pas de minimum.

Infrastructure pour l'identité et la fraude.

Une seule API pour le KYC, le KYB, la surveillance des transactions et le screening de portefeuilles. Intégration en 5 minutes.

Demande à une IA de résumer cette page
Réseaux de comptes Hydra et abus d'API par IA | Didit.