Burp Intruder pas-à-pas : sniper, pitchfork, cluster bomb (2026)

📍 Article principal du cluster : Burp Suite : le guide pratique 2026
Cet article fait partie du cluster « Burp Suite 2026 ». Pour la base manuelle, voir Repeater pas-à-pas.

Cadre éthique préalable. Intruder peut générer des milliers de requêtes par minute. Utilisé sur une cible sans autorisation, c’est une attaque par déni de service en plus d’être une intrusion. Tous les exemples se font sur PortSwigger Academy, DVWA, Juice Shop, ou un programme bug bounty avec scope clair sur Intruder. Sur Community, le débit est volontairement bridé — sur Pro il ne l’est pas, raison de plus pour rester strict sur le cadre.

Quand Repeater n’est plus suffisant — quand vous voulez tester quinze cents IDs, brute-forcer un mot de passe contre une wordlist, énumérer un sous-domaine — Intruder prend le relais. C’est l’outil de fuzzing intégré à Burp. Quatre modes d’attaque, des wordlists configurables, un système de payload processing puissant. Ce tutoriel détaille les quatre modes, donne des wordlists de référence, et montre comment lire les résultats.

Prérequis

• Burp Suite installé et Proxy fonctionnel (cluster Burp précédent).
• Maîtrise de Repeater. Voir Repeater pas-à-pas.
• Pour les exemples : compte gratuit PortSwigger Academy.
• Wordlists : SecLists (clone git clone https://github.com/danielmiessler/SecLists) — référence du milieu.
• Niveau : intermédiaire.
• Temps estimé : 75 minutes.

Étape 1 — Comprendre la mécanique d’Intruder

Intruder fonctionne en trois étapes conceptuelles. Première : vous prenez une requête (typiquement depuis Repeater ou HTTP history) et désignez les positions à fuzzer — par exemple le paramètre username dans une POST de login. Deuxième : vous chargez un ou plusieurs payloads — listes de valeurs que Burp va injecter à chaque position. Troisième : vous choisissez un mode d’attaque qui détermine comment les positions et payloads se combinent.

Burp lance ensuite la séquence : pour chaque combinaison position/payload, une requête est envoyée, la réponse loguée, et un tableau des résultats se construit. Vous analysez ce tableau — tri par status, par length, par temps — pour repérer les comportements anormaux. C’est l’œil humain qui détecte le finding ; Intruder ne fait que multiplier la vitesse de tests.

Étape 2 — Envoyer une requête à Intruder et désigner les positions

Sur PortSwigger Academy, ouvrez « Lab: Username enumeration via different responses » (Authentication, gratuit). Sur Firefox, allez sur la page de login et faites une tentative bidon — username test, password test. La requête POST atterrit dans HTTP history.

Clic droit sur cette requête → Send to Intruder (raccourci Ctrl+I). Basculez sur l’onglet Intruder, sous-onglet Positions. Vous voyez la requête complète avec des paragraphes du type :

username=§test§&password=§test§

Les § marquent les positions. Burp les a placées automatiquement sur tous les paramètres détectés. Pour ce lab, on veut fuzzer uniquement le username. Cliquez sur « Clear § » pour tout effacer, puis sélectionnez le mot test du paramètre username, et cliquez « Add § ». Le username est maintenant la seule position désignée.

Étape 3 — Mode Sniper : une position, une wordlist

Le mode Sniper est le plus simple. Une seule position fuzzée, une seule wordlist parcourue, une requête par mot de la wordlist. C’est le mode par défaut et le plus fréquent.

Sous-onglet Payloads. Type de payload : « Simple list ». Cliquez sur « Paste » si vous avez une liste dans le presse-papier, ou « Add from list » pour utiliser les listes intégrées de Burp Pro, ou « Load » pour charger un fichier. Pour le lab username enumeration, utilisez la liste fournie par PortSwigger : disponible sur le site du lab, copiez-collez les usernames.

Cliquez sur Start attack (en haut à droite). Une nouvelle fenêtre s’ouvre avec le tableau des résultats en temps réel. Triez par colonne « Length » — la réponse pour un username valide aura souvent une longueur différente d’un invalide. Le username avec une longueur anormale est probablement valide. Sur le lab, le but est précisément ça : trouver le username valide pour passer à l’étape suivante (brute force du mot de passe).

Étape 4 — Mode Sniper avancé : payload processing

Sous-onglet Payloads, section « Payload processing ». Vous pouvez chaîner des transformations sur chaque payload avant envoi. Hash, encoding, prefix/suffix, regex match/replace, encodage URL, etc.

Cas d’usage typique : vous avez une liste de mots de passe en clair, vous voulez les hasher en MD5 avant de les envoyer (parce que l’API attend du MD5). Ajoutez une règle « Hash → MD5 ». Burp hashe chaque entrée de la wordlist avant injection. Pratique aussi pour les API qui veulent du base64 sur les credentials, ou de l’URL encoding sur les payloads SQL.

Le payload processing est l’une des fonctionnalités les plus puissantes d’Intruder. Combiné avec un encodage adapté, il vous évite d’avoir à pré-traiter vos wordlists côté shell. Maîtrisez-le.

Étape 5 — Mode Battering Ram : plusieurs positions, même payload

Battering Ram place le même payload simultanément sur toutes les positions désignées. Cas d’usage : vous voulez tester si une même valeur passée à username ET password fait quelque chose (par exemple admin/admin, root/root, test/test).

Désignez deux positions avec § — une sur username, une sur password. Mode d’attaque : Battering Ram. Payload : votre wordlist de mots de passe communs. Burp envoie pour chaque mot de la liste une requête où ce mot est utilisé pour les deux paramètres en même temps. Mode rare en pratique mais utile pour quelques cas spécifiques.

Étape 6 — Mode Pitchfork : plusieurs positions, plusieurs wordlists alignées

Pitchfork combine N positions et N wordlists, et les parcourt en parallèle. La position 1 reçoit le mot N de la wordlist 1, en même temps que la position 2 reçoit le mot N de la wordlist 2. Si vos deux wordlists ont 100 entrées, vous obtenez 100 requêtes — pas 10 000 (ce serait Cluster Bomb).

Cas d’usage classique : test d’identifiants connus. Wordlist 1 = liste de usernames, wordlist 2 = liste de passwords (alignée, le password à la position N correspond au username à la position N). Vous testez 1000 paires connues sans tester les 1 000 000 combinaisons croisées.

Configuration : désignez deux positions, mode Pitchfork, sous Payloads choisissez « Payload set: 1 » et chargez la wordlist usernames, puis « Payload set: 2 » et chargez la wordlist passwords. Lancez. Triez par length pour repérer les paires qui ont passé l’authentification.

Étape 7 — Mode Cluster Bomb : produit cartésien

Cluster Bomb est le mode le plus destructeur : il parcourt toutes les combinaisons possibles entre les wordlists. Avec 100 usernames × 100 passwords, vous obtenez 10 000 requêtes. Avec 1000 × 1000, vous obtenez un million.

C’est le mode pour les vrais brute-forces — quand vous ne savez pas quel password colle à quel username et que vous voulez tester toutes les combinaisons. Sur Community, ce mode tourne mais bridé à environ une requête par seconde — un million de requêtes prendrait douze jours. Sur Pro, comptez plutôt quelques heures pour un million.

Avant de lancer un Cluster Bomb sur Pro, considérez l’impact côté serveur. Beaucoup d’applications ont des limitations de rate ou des locks après plusieurs tentatives. Un brute force naïf déclenche le verrouillage et la suite des tests devient inutile. Pour les vraies attaques de mots de passe, des outils dédiés comme Hydra ou des Intruder bien configurés (avec backoff, sessions rotatives) font mieux. Cluster Bomb reste utile pour des cas où le rate limiting n’est pas appliqué.

Étape 8 — Lire et analyser les résultats

Pendant l’attaque, la fenêtre de résultats affiche un tableau avec colonnes : Request (numéro), Payload, Status (200, 302, 401…), Length, Comment, et des colonnes additionnelles selon vos options. La détection des findings se fait par tri sur ces colonnes.

Premier réflexe : trier par Length. Une réponse de longueur différente du « bruit de fond » est suspecte. Sur un brute force d’authentification, l’écrasante majorité des tentatives échoue avec « Invalid credentials » et une length identique. La requête qui passe avec une length différente est probablement la bonne.

Deuxième réflexe : trier par Status. Un 200 au milieu d’une mer de 401, c’est intéressant. Un 500 — Internal Server Error — au milieu de 200, ça signale une condition d’erreur déclenchée par votre payload : SQL injection plausible, parser qui crashe, etc.

Troisième : utilisez la colonne « Grep — Match ». Vous configurez Burp pour matcher des chaînes dans la réponse (par exemple « Welcome » qui apparaît seulement après authentification réussie) — la colonne devient un cocher/décocher visuel pour repérer les requêtes qui ont produit ce match.

Étape 9 — Configurer le throttling et les ressources

Onglet Resource Pool (anciennement « Options → Request Engine »). Vous configurez le débit : nombre de threads concurrents, délai entre requêtes, retry sur erreur. Pour un test contre une cible fragile, baissez à 1 thread et ajoutez un délai de 500 ms entre requêtes — vous tournez doucement, vous évitez de tomber le serveur.

Pour une cible qui supporte la charge (lab, application en pré-prod), montez à 10-20 threads. Au-delà, vous risquez d’être détecté par le WAF ou de subir un rate limiting du côté serveur. La règle pratique : commencez doux, observez la réponse du serveur, montez progressivement.

Cette discipline vous épargne aussi des mauvaises surprises côté client — un test qui consomme tout le quota CDN, une instance staging qui s’écroule sous la charge. Les pros calibrent toujours leur Intruder.

Étape 10 — Vérifier votre maîtrise par un cas complet

Pour valider, lancez deux labs PortSwigger Academy en enchaînement. Premier : « Username enumeration via different responses » (Sniper sur la wordlist usernames, tri par length, identification du valide). Deuxième : « 2FA simple bypass » (Pitchfork sur user + 2FA code, ou Cluster Bomb selon le lab — analyse des codes de retour pour repérer les contournements).

Si vous résolvez les deux en moins d’une heure, vous tenez Intruder. Si vous patinez, lisez les solutions officielles, identifiez l’angle manqué, et refaites un lab similaire.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les audits sur des applications hébergées localement (Africa Data Centers, hébergeurs sénégalais, OVH Côte d’Ivoire), la latence est minime et Intruder tourne très vite. Pour les applications hébergées en Europe ou aux États-Unis avec un public africain, la latence ajoute 200 à 400 ms par requête — un Cluster Bomb qui prendrait deux heures en local prend dix heures en cross-Atlantique. Planifiez les attaques massives en heures creuses, et n’hésitez pas à scinder en lots.

Pour les bug bounties internationaux depuis l’Afrique, certains programmes appliquent du géoblocage qui filtre les IPs africaines. Pas par malveillance — par configuration WAF par défaut qui considère certains pays africains comme « high risk ». Si votre Intruder reçoit systématiquement du 403, vérifiez si l’application accepte vos requêtes manuelles. Si non, passez par un VPN avec sortie en Europe pour la durée du test, en respectant les ToS du programme bug bounty.

Côté wordlists, SecLists est gratuite et téléchargeable depuis GitHub. Cinq Go décompressé, des centaines de listes triées par catégorie : usernames, passwords, fuzzing payloads, discovery, web shells. C’est l’arsenal standard. À cloner sur votre poste de pentest et à mettre à jour mensuellement.

Tutoriels frères

• Repeater pas-à-pas — pré-requis manuel avant Intruder.
• Extensions BApp essentielles — Turbo Intruder pour les attaques à très haute concurrence.
• Workflow bug bounty — où Intruder s’intègre dans le flux complet.

Pour aller plus loin

• 🔝 Retour au pilier : Burp Suite : le guide pratique 2026
• Documentation Intruder : portswigger.net/burp/documentation Intruder
• SecLists wordlists : github.com/danielmiessler/SecLists
• Suggestion : enchaînez avec JWT et OAuth pour des tests sur les tokens.

FAQ

Quelle est la limite de débit d’Intruder Community ?
Environ 1 requête par seconde, avec un délai aléatoire ajouté. Sur Pro, aucune limite — vous pouvez monter à 100+ threads selon votre machine et la cible.

Puis-je sauvegarder une attaque Intruder pour la reprendre plus tard ?
Sur Pro, oui — l’attaque est stockée dans le projet. Sur Community avec Temporary project, non — fermer l’attaque la perd.

Comment automatiser des suites d’attaques Intruder en pipeline ?
Pas natif sur Burp desktop. Pour l’automation à grande échelle, c’est Burp Suite Enterprise ou un script externe qui pilote Burp via son API REST.

Intruder gère-t-il les attaques avec sessions multiples ?
Oui via Session Handling Rules dans les options. Vous pouvez configurer Burp pour rotater plusieurs cookies de session pendant l’attaque, ce qui contourne certains rate limitings basés sur la session.

Y a-t-il une alternative gratuite à Intruder ?
ffuf et wfuzz côté CLI sont d’excellents fuzzers gratuits, plus rapides qu’Intruder Community pour les attaques massives. Ils s’intègrent bien dans des pipelines bash. Pour le pentest manuel intégré au reste de Burp, Intruder reste la voie naturelle.

Mots-clés secondaires : Burp Intruder, sniper pitchfork cluster bomb, fuzzing, brute force, wordlists, SecLists, payload processing.