Hydra, Gobuster & SQLMap : Quand
Deviennent Tes Meilleurs Profs de Sécurité 👽

Laisse-moi te raconter un truc qui m'est arrivé il y a quelques mois. J'avais passé des semaines à sécuriser une application web, vérifié mes inputs, mis en place des protections... et puis j'ai lancé SQLMap dessus. En 30 secondes, j'étais dans la base de données. Mon premier réflexe ? La panique. Mon deuxième ? "OK, je dois absolument maîtriser ces outils."

Aujourd'hui, je vais te parler de trois outils qui ont complètement changé ma façon de penser la sécurité : Hydra, Gobuster et SQLMap. Ces trois-là, c'est un peu la trinité offensive du pentesting. Et si tu es comme moi – développeur qui veut vraiment comprendre comment on casse les systèmes pour mieux les défendre – tu es au bon endroit.

Avant de Commencer : Le Disclaimer Obligatoire (Mais Vraiment Important)

STOP. Sérieusement, lis bien ce qui suit.

Ces outils sont illégaux à utiliser sur n'importe quel système qui ne t'appartient pas sans autorisation écrite explicite. Je ne déconne pas. Utiliser ces outils sur le site de ton voisin "juste pour voir" peut te valoir des poursuites judiciaires. Point final.

Tout ce que je vais te montrer ici doit être pratiqué uniquement dans :

Ton propre lab local
Des environnements spécifiquement conçus pour l'entraînement (DVWA, Juice Shop, etc.)
Des plateformes éducatives légales (TryHackMe, Hack The Box)
Des systèmes pour lesquels tu as un accord écrit et un scope défini

Maintenant qu'on a éclairci ça, plongeons dans le vif du sujet.

Hydra : Le Bélier qui Enfonce les Portes d'Authentification

Qu'est-ce que c'est, vraiment ?

Hydra (ou THC-Hydra pour les intimes) est un outil de brute-force d'authentification. En gros, c'est comme avoir un robot ultra-rapide qui essaie des milliers de combinaisons login/mot de passe par minute sur à peu près n'importe quel service : SSH, FTP, HTTP, RDP, MySQL... la liste est longue.

Mon premier contact avec Hydra

Je me souviens de mon premier test. J'avais monté un serveur SSH local avec un compte "admin" et un mot de passe que je pensais correct : "Admin2023!". Solide, non ? J'ai lancé Hydra avec la wordlist rockyou.txt (un classique avec 14 millions de mots de passe courants).

Temps pour craquer mon "super mot de passe" : 2 minutes 37 secondes.

J'étais sidéré. Et humilié. Mais surtout, j'avais compris quelque chose de fondamental : si ton mot de passe existe dans une wordlist quelque part, il n'est pas sûr. Point.

Ce que Hydra fait vraiment bien

1. La parallélisation Hydra n'essaie pas les mots de passe un par un comme un idiot. Il lance des dizaines de tentatives simultanées. Sur certains services mal configurés, j'ai pu tester 50+ combinaisons par seconde.

2. Le support multi-protocoles Tu peux attaquer :

Des formulaires web (login HTTP/HTTPS)
SSH et Telnet
FTP et FTPS
Bases de données (MySQL, PostgreSQL, MongoDB)
RDP (Remote Desktop)
Et une vingtaine d'autres services

3. La flexibilité Tu peux fournir :

Une liste d'utilisateurs et une liste de mots de passe
Un utilisateur fixe avec une liste de mots de passe
Des combinaisons personnalisées
Même restaurer une session interrompue

Un exemple concret (sur ton propre lab !)

Imagine un formulaire de connexion basique :

# Attaque contre un formulaire web HTTP POST
hydra -l admin -P /usr/share/wordlists/rockyou.txt \
  192.168.1.100 http-post-form \
  "/login.php:username=^USER^&password=^PASS^:Invalid credentials"

Décortiquons :

-l admin : on teste le user "admin"
-P rockyou.txt : liste de mots de passe
http-post-form : type d'attaque
Le chemin et les paramètres avec ^USER^ et ^PASS^ comme placeholders
"Invalid credentials" : le message d'erreur qui indique un échec

La première fois que j'ai vu Hydra trouver un mot de passe, affichant [80][http-post-form] host: 192.168.1.100 login: admin password: password123, j'ai eu un mélange d'excitation et de peur.

Les limites et dangers d'Hydra

Le bruit que ça fait Hydra, c'est comme arriver à une fête avec une sono à fond. Impossible de passer inaperçu. Les logs vont exploser avec des centaines/milliers de tentatives échouées. N'importe quel système de monitoring digne de ce nom va hurler.

Le blocage de compte Sur mes tests, j'ai régulièrement bloqué des comptes après 3-5 tentatives. Beaucoup de systèmes modernes implémentent ce genre de protection. Et c'est une bonne chose.

La charge système J'ai crashé quelques-uns de mes serveurs de test en poussant Hydra trop fort. Les connexions parallèles massives peuvent mettre à genoux un serveur mal dimensionné.

Comment se défendre contre Hydra

Après avoir utilisé Hydra pendant des semaines, voici ce qui m'a vraiment arrêté :

1. Rate limiting et verrouillage

Limite de 3-5 tentatives avant blocage temporaire (15-30 minutes)
Délais exponentiels entre les tentatives
CAPTCHA après X échecs

2. Multi-Factor Authentication (MFA) Hydra ne peut rien contre un bon 2FA. Même si le mot de passe tombe, l'attaquant reste dehors.

3. Monitoring agressif Configure des alertes sur :

Pics de tentatives d'authentification échouées
Connexions depuis des IPs suspectes
Patterns inhabituels (100 tentatives en 2 minutes = pas normal)

4. Politiques de mots de passe strictes Les mots de passe dans les wordlists courantes ? Interdits. Force la complexité réelle, pas juste "8 caractères avec une majuscule".

Gobuster : L'Explorateur qui Trouve les Portes Cachées

C'est quoi ce truc ?

Gobuster est un outil d'énumération écrit en Go (d'où la rapidité). Son job ? Découvrir des répertoires, fichiers, sous-domaines et vhosts que tu n'es pas censé trouver. C'est comme avoir un détective qui teste systématiquement toutes les portes d'un bâtiment pour voir lesquelles s'ouvrent.

Mon moment "whoa" avec Gobuster

J'étais en train de tester une application que j'avais développée. Interface clean, tout semblait bien. Je lance Gobuster juste pour voir.

gobuster dir -u http://localhost:3000 -w /usr/share/wordlists/dirb/common.txt

Résultats en 30 secondes :

/admin (200 OK) – Oups, j'avais laissé le panel admin accessible
/backup (200 OK) – Un vieux dossier de backup avec des fichiers sensibles
/.git (200 OK) – Mon repo Git ENTIER exposé publiquement
/config.php.bak (200 OK) – Fichier de config avec les credentials de la DB

J'ai eu des sueurs froides. Toutes ces portes dérobées que je ne savais même pas avoir laissées ouvertes.

Les modes de Gobuster

1. Directory/File enumeration Le mode classique : trouver des chemins cachés.

# Recherche de répertoires
gobuster dir -u https://target.com -w wordlist.txt

# Recherche de fichiers spécifiques
gobuster dir -u https://target.com -w wordlist.txt -x php,html,txt,bak

2. DNS subdomain enumeration Trouver des sous-domaines non listés publiquement.

gobuster dns -d target.com -w subdomains-list.txt

J'ai trouvé une fois un dev.target.com avec une version de staging complètement non sécurisée. Jackpot (dans un contexte légal, évidemment).

3. Vhost enumeration Chercher des virtual hosts sur un serveur.

Pourquoi Gobuster est si efficace

La vitesse Écrit en Go, Gobuster est rapide. J'ai scanné des sites avec 10,000+ requêtes en quelques minutes. C'est beaucoup plus performant que des alternatives en Python ou Bash.

La simplicité Pas de configuration complexe. Tu donnes une URL, une wordlist, et c'est parti.

La discrétion relative Comparé à d'autres scanners, Gobuster peut être configuré pour être moins bruyant (avec throttling et user-agent custom).

Mes découvertes typiques avec Gobuster

Sur mes différents tests (légaux et autorisés), voici ce que j'ai régulièrement trouvé :

Panels d'administration non protégés (/admin, /administrator, /wp-admin)
Fichiers de backup exposés (.bak, .old, .backup, ~)
Répertoires Git (.git/) permettant de télécharger tout le code source
Fichiers de configuration (config.php, .env, settings.ini)
Anciennes versions de l'app (/v1, /old, /deprecated)
Endpoints API non documentés (/api/internal, /api/v2/admin)

Chaque découverte était une leçon : "Ne laisse JAMAIS ça exposé en production."

Les défenses qui m'ont arrêté

1. Web Application Firewall (WAF) Les bons WAF détectent les patterns d'énumération et te bloquent ou te ralentissent drastiquement. Après 50 requêtes 404 en 10 secondes, tu es grillé.

2. Rate limiting Des limites strictes du genre "10 requêtes par minute par IP" rendent Gobuster beaucoup moins efficace. Un scan qui prenait 2 minutes peut prendre 2 heures.

3. Honeypots J'ai déjà tombé sur des répertoires /admin qui étaient en fait des honeypots. Dès que tu y accèdes, ton IP est flaggée et tous tes accès futurs sont loggés agressivement.

4. Configuration propre Le plus simple : ne pas avoir de ressources sensibles accessibles. Pas de .git en prod, pas de backups dans le webroot, pas de panels admin sur des URLs prévisibles.

Comment se défendre

Côté infrastructure :

Désactive le listing de répertoires
Supprime TOUT fichier inutile du serveur web (backups, fichiers de dev, etc.)
Utilise des chemins d'admin non-standard (mais sans tomber dans le "security by obscurity")
Implémente une authentification sur TOUT ce qui est sensible

Côté monitoring :

Alerte sur les pics de 404/403 depuis une même source
Détecte les patterns de scanning (requests rapides sur des URLs séquentielles)
Log les User-Agents suspects (beaucoup d'outils ont des signatures reconnaissables)

SQLMap : Le Roi de l'Injection SQL

L'outil le plus puissant (et le plus dangereux)

SQLMap est une bête. C'est l'outil qui automatise la détection et l'exploitation des injections SQL. Et quand je dis "exploitation", je veux dire qu'il peut :

Extraire des bases de données complètes
Lire des fichiers système
Exécuter des commandes sur le serveur (dans certains cas)
Prendre le contrôle total d'un système mal configuré

C'est puissant. Trop puissant si tu ne sais pas ce que tu fais.

Ma première fois avec SQLMap

J'avais créé une petite app de blog avec une fonction de recherche. Le code ressemblait à ça :

$search = $_GET['q'];
$query = "SELECT * FROM posts WHERE title LIKE '%$search%'";

Oui, je sais. C'est horrible. Mais c'était pour apprendre.

J'ai lancé SQLMap dessus :

sqlmap -u "http://localhost/search.php?q=test" --dbs

En moins d'une minute, SQLMap avait :

Détecté la vulnérabilité (injection SQL error-based)
Identifié le DBMS (MySQL 5.7)
Listé toutes mes bases de données
Me proposé d'extraire les tables et les données

J'étais littéralement en train de regarder mon système se faire démonter automatiquement. C'était fascinant et terrifiant.

Les types d'injections que SQLMap détecte

SQLMap est intelligent. Il teste plusieurs techniques :

1. Error-based Force des erreurs SQL qui révèlent des infos dans les messages d'erreur.

2. Boolean-based blind Pose des questions vrai/faux et déduit les données selon la réponse de l'application.

3. Time-based blind Utilise des délais (SLEEP, WAITFOR) pour extraire des données bit par bit. C'est lent mais ça marche même quand tu n'as aucun retour visible.

4. UNION-based Utilise UNION SELECT pour joindre des résultats et extraire des données directement.

5. Stacked queries Exécute plusieurs requêtes à la suite (quand supporté).

Un exemple concret de progression

Voici ce que j'ai fait sur mon propre lab vulnérable :

# Étape 1 : Test basique
sqlmap -u "http://localhost/product.php?id=1"

# Étape 2 : Lister les bases
sqlmap -u "http://localhost/product.php?id=1" --dbs

# Étape 3 : Cibler une base
sqlmap -u "http://localhost/product.php?id=1" -D mydatabase --tables

# Étape 4 : Dump une table
sqlmap -u "http://localhost/product.php?id=1" -D mydatabase -T users --dump

# Étape 5 : Chercher des colonnes spécifiques
sqlmap -u "http://localhost/product.php?id=1" --search -C password,email

Résultat ? J'ai extrait tous les users, emails et passwords hashés de ma base. En quelques commandes.

Les fonctionnalités avancées (à utiliser avec EXTRÊME prudence)

SQLMap peut faire des trucs vraiment hardcore :

Lecture de fichiers système :

sqlmap -u "..." --file-read="/etc/passwd"

Écriture de fichiers :

sqlmap -u "..." --file-write="shell.php" --file-dest="/var/www/html/shell.php"

Exécution de commandes OS :

sqlmap -u "..." --os-shell

J'ai testé ces fonctionnalités sur mes propres VMs. Obtenir un shell complet sur un serveur via une simple injection SQL, c'est... impressionnant. Et effrayant.

Les dangers réels de SQLMap

C'est TRÈS intrusif SQLMap génère énormément de requêtes. Sur certains tests, j'ai vu des dizaines de milliers de requêtes envoyées. Ça peut :

Surcharger le serveur
Corrompre des données (avec les injections write)
Crasher l'application
Remplir les logs à ras bord

C'est détectable Les WAF modernes reconnaissent facilement les patterns SQLMap. Les payloads ont des signatures reconnaissables.

C'est légalement dangereux SQLMap affiche lui-même un disclaimer légal au lancement. L'utiliser sans autorisation = grave infraction. Ne rigole pas avec ça.

Comment se défendre contre SQLMap (et les injections SQL en général)

Après avoir utilisé SQLMap extensivement, voici ce qui l'arrête net :

1. Prepared Statements / Parameterized Queries La défense ultime. Si tu utilises correctement les prepared statements, SQLMap ne peut rien faire.

// BIEN
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$id]);

// MAL
$query = "SELECT * FROM users WHERE id = $id";

2. ORM sécurisés Les bons ORMs (Eloquent, SQLAlchemy, Hibernate) gèrent automatiquement l'échappement.

3. Validation stricte des inputs Si tu attends un nombre, vérifie que c'est un nombre. Si tu attends un email, valide le format.

4. Principe du moindre privilège Le compte DB utilisé par l'app ne devrait pas pouvoir :

Lire les tables système
Écrire des fichiers
Exécuter des commandes
Accéder à d'autres bases

5. WAF et monitoring

Détecte les patterns d'injection (quotes multiples, commentaires SQL, UNION SELECT, etc.)
Alerte sur des requêtes inhabituellement longues ou complexes
Monitor les temps d'exécution (time-based injections créent des délais artificiels)

Ma config MySQL de défense :

-- Compte app avec droits minimaux
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp.* TO 'appuser'@'localhost';
-- Pas de FILE, PROCESS, SUPER, etc.

Où Pratiquer Sans Finir en Prison

OK, tu as lu tout ça, tu es excité, tu veux tester. STOP. Où tu vas pratiquer légalement ?

Les environnements que j'utilise

1. OWASP Juice Shop Mon préféré. Une application e-commerce volontairement bourrée de vulnérabilités. Tu peux tout casser sans conséquences.

docker run -p 3000:3000 bkimminich/juice-shop

Parfait pour SQLMap et Gobuster.

2. DVWA (Damn Vulnerable Web Application) Le classique. Plusieurs niveaux de difficulté (low, medium, high, impossible).

docker run -p 80:80 vulnerables/web-dvwa

J'y ai passé des semaines à affiner mes techniques.

3. Metasploitable Une VM Linux intentionnellement vulnérable. Parfaite pour Hydra (SSH, FTP, etc.).

4. Plateformes éducatives

TryHackMe : Parcours guidés, labs structurés
Hack The Box : Challenges plus difficiles, machines réalistes
PentesterLab : Exercices ciblés sur des vulnérabilités spécifiques

Ces plateformes sont légales, gratuites (ou peu chères), et conçues pour apprendre. Aucune excuse pour aller jouer ailleurs.

Mon setup de lab perso

J'ai créé mon propre environnement de test :

Hardware :

PC principal (Kali Linux en VM)
Réseau virtuel isolé (VirtualBox/VMware)
Plusieurs VMs cibles (Ubuntu, Windows Server, applications custom)

Applications vulnérables custom : J'ai développé mes propres apps intentionnellement faillibles pour tester des scénarios spécifiques. C'est le meilleur moyen d'apprendre : casser ce que tu as toi-même construit.

Les Leçons que Ces Outils M'ont Apprises

1. La sécurité n'est pas une checklist

Avant d'utiliser ces outils, je pensais que "suivre les bonnes pratiques" suffisait. Faux. Il faut comprendre comment les attaques fonctionnent pour vraiment défendre.

2. La défense en profondeur est essentielle

Un seul contrôle ne suffit jamais. Sur mes tests :

WAF seul ? Contournable
Rate limiting seul ? On peut être patient
Validation seule ? On trouve des edge cases

Mais tous ensemble ? Ça devient vraiment difficile.

3. Les outils automatisés trouvent ce que tu rates

J'ai découvert des failles dans mon propre code que j'avais relu 10 fois. SQLMap les a trouvées en 30 secondes. Humiliant mais instructif.

4. Le monitoring est aussi important que la prévention

Tu ne peux pas tout empêcher. Mais tu peux détecter rapidement et réagir. Mes meilleurs défenses ne bloquaient pas toujours les outils, mais elles me prévenaient immédiatement.

5. L'éthique n'est pas négociable

Ces outils donnent un pouvoir énorme. Ce pouvoir vient avec une responsabilité énorme. Chaque fois que j'utilise ces outils, même en lab, je me rappelle : "Si c'était un vrai système, quelles seraient les conséquences ?"

Configurations SIEM et Détection Pratique

Voici ce que j'ai configuré dans mes environnements de monitoring :

Pour détecter Hydra :

RULE: IF authentication_failures > 10 FROM same_source IN 60_seconds
THEN alert("Possible brute-force attack") AND rate_limit(source_ip)

Pour détecter Gobuster :

RULE: IF http_404_errors > 50 FROM same_source IN 60_seconds
THEN alert("Possible directory enumeration") AND investigate(source_ip)

Pour détecter SQLMap :

RULE: IF sql_query CONTAINS ('UNION SELECT', 'OR 1=1', 'SLEEP(', 'WAITFOR DELAY')
THEN alert("Possible SQL injection") AND block(request)

Ces règles sont basiques mais efficaces. Elles m'ont permis de détecter 95% de mes propres tests.

Ressources pour Aller Plus Loin

Documentation officielle :

Hydra : Kali Linux Tools documentation
Gobuster : GitHub repository (OJ/gobuster)
SQLMap : sqlmap.org (avec le disclaimer légal complet)

Labs et pratique :

OWASP Juice Shop (juiceshop.owasp.org)
DVWA (dvwa.co.uk)
PortSwigger Web Security Academy (gratuit et excellent)

Livres qui m'ont aidé :

"The Web Application Hacker's Handbook" (même s'il vieillit, les fondamentaux restent)
"Black Hat Python/Go" pour comprendre comment créer ses propres outils

Communautés :

Reddit : r/netsec, r/AskNetsec
Discord : TryHackMe, Hack The Box
Twitter : #infosec, #bugbounty (mais filtre le bruit)

Ma Routine d'Entraînement Actuelle

Voilà comment je continue à affûter mes compétences :

Lundi : Challenge TryHackMe avec Gobuster (découverte) Mercredi : Lab DVWA, focus sur SQLMap et nouvelles techniques d'injection Vendredi : Développement d'une app vulnérable custom pour tester un scénario spécifique Weekend : CTF ou machine Hack The Box pour combiner les outils

Consistance > Intensité. 30 minutes par jour valent mieux que 8 heures le weekend.

L'Équilibre Attaque/Défense

Ce qui est fascinant, c'est que maîtriser ces outils offensifs m'a rendu meilleur défenseur. Maintenant, quand je code :

Je pense "Où Gobuster pourrait-il fouiner ?"
Je me demande "Est-ce que Hydra pourrait casser ça ?"
Je vérifie "SQLMap trouverait-il une injection ici ?"

C'est devenu un réflexe. Et c'est exactement l'état d'esprit qu'on devrait tous avoir.

Conclusion : Des Outils Puissants, Une Grande Responsabilité

Hydra, Gobuster et SQLMap sont des scalpels chirurgicaux. Dans de bonnes mains, ils permettent d'identifier et corriger des failles critiques avant qu'un attaquant malveillant ne les exploite. Dans de mauvaises mains, ils peuvent causer des dégâts considérables.

J'ai passé des centaines d'heures avec ces outils. Ils m'ont appris plus sur la sécurité que n'importe quel cours théorique. Mais la leçon la plus importante qu'ils m'ont enseignée ?

La sécurité n'est pas un état, c'est un processus.

Tu ne "sécurises" pas une application une fois pour toutes. Tu la défends continuellement, tu testes régulièrement, tu t'adaptes aux nouvelles menaces. Ces outils évoluent. Les techniques d'attaque évoluent. Et nous devons évoluer avec elles.

Que tu sois du côté offensif ou défensif (idéalement, tu devrais connaître les deux), ces outils ont leur place dans ton arsenal. Utilise-les sagement. Apprends constamment. Et surtout, reste éthique.

Parce qu'au final, notre job n'est pas de casser des systèmes. C'est de les rendre plus sûrs.

Mon Conseil Final : Ne commence pas par essayer tous les outils en même temps. Choisis-en un seul et deviens vraiment bon avec. Passe deux semaines sur Gobuster uniquement. Teste-le sur tous les labs que tu trouves. Comprends chaque flag, chaque option, chaque scénario. Puis passe à Hydra. Puis SQLMap. La profondeur bat la largeur à chaque fois. Et surtout, pour chaque attaque que tu réussis, demande-toi immédiatement : "Comment est-ce que je défendrais contre ça ?" C'est cette double perspective – attaquant ET défenseur – qui fera de toi un vrai professionnel de la sécurité. Et documente TOUT. Dans six mois, quand tu auras oublié comment contourner ce WAF spécifique ou exploiter cette injection time-based particulière, tes notes seront ton meilleur allié. J'ai un cahier de 300 pages maintenant. C'est mon trésor. 🛡️⚔️

#CyberSecurity #OffensiveTools #Hydra #Gobuster #SQLMap #PenTesting #EthicalHacking #RedTeam #DefensiveStrategy #InfoSec #LearnByBreaking

lundi 13 octobre 2025