BruteForceAI : quand un LLM choisit les sélecteurs de formulaire à votre place

Le problème que le projet attaque : repérer les champs avant de tirer

Un outil de force brute classique a besoin qu'on lui dise où écrire. Sur un formulaire de connexion, cela veut dire fournir un sélecteur CSS ou XPath pour le champ identifiant, un autre pour le mot de passe, et un troisième pour le bouton de soumission. Sur une cible unique, ce travail manuel prend quelques minutes. Sur un fichier de cinquante URL, il devient la partie la plus longue de l'engagement, et la plus fragile : dès qu'un formulaire change de structure, le sélecteur écrit à la main casse sans message d'erreur utile.

BruteForceAI cible précisément cette étape. Le README décrit deux étapes distinctes. La première, analyze, envoie le HTML de la page à un modèle de langage qui doit en extraire les éléments du formulaire. La seconde, attack, réutilise ces sélecteurs pour exécuter les tentatives. L'outil s'adresse donc à des testeurs d'intrusion et à des chasseurs de bug bounty qui traitent des cibles nombreuses ou hétérogènes, pas à quelqu'un qui doit tester une seule page qu'il connaît déjà par cœur.

Deux étapes, une base SQLite comme mémoire

Le flux est séquentiel et persistant. La commande analyze prend une liste d'URL, récupère le contenu des pages, en extrait le HTML utile et le soumet au fournisseur LLM choisi. Le README mentionne un mécanisme de nouvelle tentative avec retour d'information : si le modèle produit des sélecteurs qui ne fonctionnent pas, l'outil peut réessayer en lui signalant l'échec. C'est le point le plus intéressant du projet, parce que c'est là que se joue la différence entre un simple appel d'API et une boucle de correction.

Les résultats sont conservés dans une base SQLite, qui sert aussi de journal complet des tentatives. Cette base explique deux comportements documentés : la prévention des doublons, l'outil sautant les essais déjà enregistrés, et l'option de forcer leur reprise. Elle explique aussi la commande clean-db, qui vide des tables. Concrètement, la base est l'état de l'outil : si vous la supprimez, vous perdez à la fois les sélecteurs découverts et l'historique des tentatives.

Côté exécution, Playwright pilote Chromium, ce qui permet de valider le succès par détection de changement du DOM plutôt que par recherche d'une chaîne dans la réponse HTTP. C'est plus robuste sur les pages qui rechargent en JavaScript, et plus coûteux en ressources qu'une simple requête POST.

Installation : venv, Playwright, puis un fournisseur LLM

Le README demande Python 3.8 ou supérieur, puis l'isolation dans un environnement virtuel :

python -m venv .venv source .venv/bin/activate pip install -r requirements.txt playwright install chromium

L'étape playwright install chromium est obligatoire et distincte de pip : le paquet Python ne télécharge pas le navigateur. Les dépendances citées sont playwright, requests et PyYAML, cette dernière servant à la lecture YAML pour la vérification des mises à jour.

Le fournisseur LLM se choisit au moment de l'analyse. En local avec Ollama, le README propose ollama pull llama3.2:3b puis :

python BruteForceAI.py analyze --urls urls.txt --llm-provider ollama --llm-model llama3.2:3b

En cloud avec Groq, il faut une clé passée en ligne de commande :

python BruteForceAI.py analyze --urls urls.txt --llm-provider groq --llm-model llama-3.3-70b-versatile --llm-api-key YOUR_KEY

Le README recommande llama-3.2:3b comme modèle Ollama par défaut et signale llama-3.1-8b-instant chez Groq comme déconseillé à cause de limitations de débit, avec trois tentatives ou plus nécessaires. Ces chiffres viennent de la documentation du projet, pas d'une mesure indépendante.

Le mode attaque : threads, jitter et deux stratégies opposées

La commande attack accepte les listes d'identifiants et de mots de passe, un nombre de threads, un délai et un jitter :

python BruteForceAI.py attack --urls targets.txt --usernames users.txt --passwords passwords.txt --threads 20 --delay 5 --jitter 2

Deux modes sont documentés. Le mode bruteforce teste toutes les combinaisons identifiant/mot de passe. Le mode passwordspray, activé par --mode passwordspray, teste chaque mot de passe contre tous les identifiants. Ce second mode est celui qu'on utilise quand on craint le verrouillage de compte, parce qu'il espace les tentatives sur un même compte au lieu de les concentrer.

Le README décrit des délais synchronisés entre tentatives visant le même utilisateur, une rotation des User-Agent via --user-agents user_agents.txt, un support de proxy, et un contrôle de la visibilité du navigateur. L'option --success-exit arrête l'exécution dès qu'un identifiant valide est trouvé, et --output results.txt capture la sortie dans un fichier. Des notifications webhook sont prévues pour Discord, Slack, Teams et Telegram ; la ligne d'exemple du README est tronquée à --discord-webhoo, donc le nom exact du paramètre côté Slack ou Teams n'est pas vérifiable dans le matériel fourni.

Ce que le projet ne dit pas, et ce qui manque

Le README ne contient aucune section sur les cas d'échec. Trois points méritent d'être posés comme des limites, pas comme des défauts cachés.

Premièrement, la qualité de l'analyse dépend entièrement du modèle. Un petit modèle local peut produire des sélecteurs plausibles mais faux, et le mécanisme de nouvelle tentative avec retour d'information a un coût : chaque essai supplémentaire est un appel LLM de plus, donc du temps CPU en local ou des jetons facturés en cloud. Le README ne donne aucune estimation du nombre d'appels nécessaires par formulaire.

Deuxièmement, envoyer le HTML d'une page de connexion à Groq signifie transmettre du contenu de la cible à un tiers. Sur un engagement avec des contraintes de confidentialité, ce n'est pas anodin. Ollama existe précisément pour ce cas, mais il faut alors accepter un modèle plus petit et un temps d'analyse plus long.

Troisièmement, la détection de succès par changement du DOM est une heuristique. Une page qui affiche un message d'erreur en JavaScript ou qui redirige vers la même URL peut tromper le validateur. Le projet ne documente pas de moyen de fournir une condition de succès personnalisée.

Enfin, la vérification automatique des mises à jour pointe vers mordavid.com, un domaine externe au dépôt. C'est un choix qui mérite d'être connu avant d'exécuter l'outil sur une machine d'engagement.

Face à Hydra ou ffuf : la différence n'est pas la vitesse

Comparons à Hydra, l'outil de référence pour la force brute de protocoles et de formulaires HTTP. Hydra est plus rapide, plus mature, disponible dans les dépôts de la plupart des distributions, et ne dépend ni d'un navigateur ni d'un service LLM. Sa configuration de formulaire repose sur une chaîne écrite à la main qui décrit la requête POST et les emplacements des paramètres. C'est précis, déterministe, et cela ne demande aucun accès réseau sortant vers un modèle.

BruteForceAI échange cette précision contre l'automatisation du repérage. Sur une cible où le formulaire est rendu en JavaScript, Hydra ne voit rien du tout : il travaille sur le HTML brut. Playwright, lui, exécute la page. C'est la vraie différence d'approche, et elle est structurelle : l'un parse, l'autre rend.

Le coût de ce choix est l'opacité. Avec Hydra, un échec signifie que votre chaîne de formulaire est fausse, et vous pouvez la corriger ligne par ligne. Avec BruteForceAI, un échec peut venir du modèle, du sélecteur, du rendu de la page ou du validateur de succès. Le README ne décrit pas de mode de débogage permettant d'inspecter les sélecteurs retenus avant de lancer l'attaque, ce qui rendrait ce diagnostic plus simple.

Licence et maintenance : les deux points à trancher avant l'adoption

Le champ license du dépôt est NOASSERTION, ce qui signifie que GitHub n'a pas su rattacher le projet à une licence reconnue. Le README affiche pourtant un badge License: Non-Commercial. Un badge n'est pas un fichier de licence, et le matériel fourni ne permet pas de confirmer qu'un fichier LICENSE existe à la racine. Pour un usage en entreprise, cette ambiguïté est bloquante tant qu'elle n'est pas levée : une clause non commerciale interdit typiquement l'usage dans un prestataire facturant des tests d'intrusion, même si le texte exact n'est pas connu ici.

Sur la maintenance, le dépôt n'est pas archivé et le dernier push est daté du 17 juillet 2026. Aucune release n'a été récupérée, ce qui veut dire qu'il n'existe pas de version étiquetée à épingler : vous installez l'état de la branche main au moment du clone. Les mises à jour se font donc par git pull, et une modification de requirements.txt ou du format de la base SQLite peut casser une installation existante sans numéro de version pour vous alerter.

Le projet prévoit une commande check-updates qui interroge mordavid.com. Elle ne remplace pas un suivi du dépôt, puisqu'elle dépend d'un service externe dont le contenu n'est pas documenté ici. La page d'accueil du projet est également hébergée sur ce domaine, ce qui concentre la distribution et la vérification des versions sur une seule source.

Conclusion éditoriale

BruteForceAI convient à un pentester qui dispose déjà d'une autorisation écrite et qui veut automatiser la phase ingrate de repérage des sélecteurs sur un lot de pages de connexion, en local avec Ollama pour éviter d'envoyer du HTML client à un tiers. À éviter si vous cherchez un outil installable en production : aucune release n'est publiée, la licence affichée est non commerciale et le dépôt ne contient pas de fichier LICENSE lisible. Vérifiez d'abord la licence réelle et le contenu de requirements.txt avant de lancer pip install.

Sources officielles

1. Issues
2. MorDavid/BruteForceAI on GitHub
3. Project website
4. README