DarKnight : un agent RAG contre les CAPTCHA du dark web

Contexte

Les enquêteurs en renseignement sur les cybermenaces (CTI) surveillent les marchés du dark web pour suivre les identifiants de comptes divulgués et les listes de données piratées. Avant que leur crawler puisse voir la moindre page, il doit franchir les CAPTCHA que les opérateurs installent pour bloquer la collecte automatisée. Ces épreuves varient d'un site à l'autre. Ce verrou est donc un obstacle quotidien, pas un cas rare.

Deux approches existent aujourd'hui. La première consiste à affiner un modèle pour chaque site. Chaque nouveau marché impose une nouvelle collecte de données et un nouvel entraînement, ce qui coûte cher et ne passe pas à l'échelle. La seconde appelle l'API d'un modèle vision-langage (VLM) commercial. Ce choix remet le contrôle au fournisseur. Un changement de politique, un blocage des sorties Tor, une réglementation publique ou une mise à jour silencieuse du modèle peuvent casser le solveur ou modifier son comportement du jour au lendemain. Chaque appel et chaque nouvel essai alourdissent aussi la facture.

DarKnight, décrit dans un article publié sur arXiv, vise cette situation. C'est un framework agentique qui s'améliore tout seul. Il est conçu pour tourner sur un seul GPU de station de travail, à côté du crawler Tor de l'enquêteur. Il n'utilise qu'un petit VLM open-weight hébergé en local. Il ne demande aucun entraînement par marché et aucun service tiers : aucune décision d'un fournisseur ne peut donc lui retirer son solveur.

Analyse approfondie

L'idée centrale est de laisser un petit modèle réfléchir avant de répondre, plutôt que de grossir le modèle. Pour chaque CAPTCHA, le système commence par retrouver les essais antérieurs sur des images similaires. Il récupère à la fois les réussites et les échecs. L'article parle de génération augmentée par récupération (RAG) à double signal. Les cas réussis montrent ce qui a fonctionné. Les cas ratés montrent ce qui a déjà fait ses preuves comme impasse. Ensemble, ils aident le système à éviter les erreurs connues mieux qu'une mémoire limitée aux succès. Ensuite, le framework construit un pipeline de prétraitement propre à cette image. Il choisit quelques outils dans la boîte de traitement d'image disponible et les range dans un ordre utile. Il n'applique pas le même traitement à toutes les images. Ce choix compte, car un prétraitement uniforme peut abîmer des images déjà faciles à lire. La dernière étape est une boucle de retour. Le site visé renvoie un résultat, succès ou échec, pour chaque réponse. DarKnight traite ce résultat comme un vrai signal d'apprentissage et le conserve pour les recherches futures sur des images proches. La source ne décrit ni mise à jour des poids ni annotation humaine dans cette boucle. Le système progresse à l'usage, tout en restant local et sans entraînement par marché.

Les preuves viennent d'une étude de cas sur quatre vrais marchés du dark web, dont le niveau de protection diffère. Sur le marché le mieux protégé, un VLM open-weight déployable associé à DarKnight atteint 83,2 %. C'est 37,2 points de plus que le même modèle sans le framework. C'est aussi mieux que le modèle de pointe Claude Opus 5, qui obtient 44 %. Dans cette étude, le choix d'outils par l'agent l'emporte sur l'augmentation de la taille du modèle. L'article chiffre aussi l'effet de DarKnight sur les cas individuels. Le framework corrige 48,2 % des échecs de référence. Il provoque aussi 7,6 % de régressions, c'est-à-dire des cas que la référence résolvait et qui deviennent faux. Ce coût est le prix d'une intervention sur les images. Sa faible ampleur appuie l'affirmation des auteurs : choisir les outils image par image évite l'essentiel de la perte causée par un prétraitement uniforme.

Impact sur l'industrie

Pour les équipes de sécurité, le gain principal est la maîtrise. Un solveur que la politique d'un fournisseur, un blocage régional ou un changement de version du modèle peuvent interrompre est un maillon fragile dans une chaîne de renseignement qui tourne en continu. Un modèle open-weight local supprime cette dépendance. Il supprime aussi les frais par appel et par nouvel essai, qui grossissent avec le volume de collecte. Tourner à côté du crawler Tor sur un seul GPU garde le dispositif à la portée d'une petite équipe d'enquête.

Le résultat offre aussi un schéma utile hors de cette niche. La comparaison entre 83,2 % et 44 % suggère qu'un petit modèle muni de récupération et d'outils peut battre un modèle commercial bien plus gros sur une tâche visuelle étroite. Les équipes qui travaillent en environnement restreint, ou qui ne peuvent pas dépendre d'API externes, peuvent reprendre l'idée. Le modèle gagne en compétence au moment de l'inférence, grâce à l'expérience stockée et aux outils externes, et non grâce à plus de paramètres.

Un double usage mérite d'être signalé. La capacité qui aide les enquêteurs à franchir les barrières posées par les opérateurs reste, en général, une méthode de résolution de CAPTCHA. La source cadre le travail autour de la surveillance CTI, et cet article suit ce cadrage.

Perspectives

Les preuves de l'article se limitent à quatre marchés. Rien ne montre encore que les gains tiennent sur davantage de sites et sur une plus longue durée. Les opérateurs peuvent modifier leurs CAPTCHA en réaction, et comme le framework s'appuie sur le retour du site, sa mémoire devra suivre ces changements.

Plusieurs questions restent ouvertes. Comment la mémoire à double signal doit-elle choisir et mettre à jour son expérience ? Jusqu'où peut-on élargir la boîte à outils avant que la sélection ne devienne plus difficile ? Le taux de régression de 7,6 % peut-il baisser encore sans réduire les 48,2 % de corrections ? Les réponses diraient si l'usage sélectif des outils peut passer d'une étude de cas prometteuse à une pratique fiable pour les équipes CTI.