Introduction et Kali — Notions
Avant de lancer le moindre outil, il faut poser deux choses : la tête de l'attaquant et le décor. Sans le décor (un laboratoire isolé), la tête ne sert à rien : on finit devant un juge. Sans la tête, le décor ne sert à rien non plus : on lance des commandes au hasard et rien ne tombe.
Tout ce qui est enseigné ici s'applique exclusivement à des machines que vous possédez, ou pour lesquelles vous avez une autorisation écrite (RoE, contrat, bug bounty). Scanner un site que vous n'avez pas la permission de toucher, c'est déjà une infraction dans la plupart des juridictions. Le cours vous apprend à attaquer. La loi vous apprend où.
Ce que vous saurez faire après cette leçon
- Expliquer avec vos mots ce qu'est un test d'intrusion, et pourquoi ce n'est pas un audit.
- Distinguer vulnérabilité, exploit et impact — les trois mots que tout le monde mélange.
- Poser un état d'esprit d'attaquant : partir de la cible, pas de l'outil.
- Nommer les grandes phases d'une attaque (la fameuse kill chain), pour savoir où vous êtes à tout moment.
- Comprendre pourquoi Kali Linux existe, et ce qu'il vous apporte concrètement.
1. Pourquoi ce métier existe
Une entreprise a bâti une application, un réseau, une infrastructure cloud. Elle croit que c'est sécurisé parce que personne n'a essayé de le casser. C'est exactement pour ça qu'on vous paye : essayer de le casser avant qu'un vrai méchant le fasse.
Le testeur d'intrusion, c'est le cambrioleur légal. Le client vous remet la clé, vous demande d'essayer d'entrer par la fenêtre, la cheminée, la boîte aux lettres, le fils du voisin, la femme de ménage — et de tout raconter ensuite, avec les preuves, pour qu'il puisse boucher les trous.
Un pentest ne vaut rien pour son nombre de failles trouvées. Il vaut pour :
- Les preuves que vous ramenez (captures, logs, fichiers extraits).
- La reproductibilité : le client doit pouvoir refaire le pas après remédiation.
- Les recommandations : ce qui se fait lundi matin pour boucher le trou.
Un rapport sans preuve, c'est un ragot. Un ragot ne clôture pas un ticket.
Définition — un shell, mot qu'on va employer dix fois par leçon
Un shell, c'est une interface qui accepte des commandes et les fait exécuter par le système. Quand vous ouvrez un terminal sur votre ordinateur et que vous tapez ls, vous êtes dans un shell.
Pour un attaquant, « obtenir un shell » sur une machine distante signifie exactement une chose : pouvoir taper des commandes sur cette machine, comme si vous étiez assis devant. C'est le premier vrai jalon d'une attaque. Tant qu'on n'a pas de shell, on n'a rien. Une fois qu'on l'a, on peut tout envisager : regarder les fichiers, essayer de monter en privilèges, sauter vers une autre machine.
Deux formes reviennent tout au long du cours. Le bind shell, où la cible ouvre un port et attend qu'on s'y connecte : simple mais bruyant, un pare-feu le voit. Le reverse shell, où la cible se connecte à vous depuis l'intérieur : bien plus fréquent en pratique, parce que la plupart des pare-feux laissent sortir sans regarder.
2. Les trois cousins qu'on confond tout le temps
| Métier | Ce qu'on fait | La question à laquelle on répond |
|---|---|---|
| Audit | On lit la doc, on interviewe, on regarde les configs. | Est-ce conforme à la politique / à la norme ? |
| Pentest | On attaque, dans un périmètre limité, sur un temps limité. | Peut-on entrer, et jusqu'où ? |
| Red team | On simule un attaquant réel, discret, avec des objectifs métier. | Combien de temps avant qu'on se fasse détecter, et l'aurions-nous été ? |
L'audit passe par la case entretien. Le pentest passe par la case exploit. La red team passe par la case évasion des défenses — et souvent la case ingénierie sociale.
Vous apprenez le pentest, avec des ouvertures régulières vers la red team dans les modules avancés (8 à 11).
Définition — le purple team, et pourquoi le mot revient partout
Red team et blue team désignent depuis longtemps l'attaque et la défense. Le purple team n'est pas une troisième équipe : c'est le moment où les deux travaillent ensemble. Concrètement, l'attaquant lance une technique et prévient la défense ; celle-ci regarde si son SIEM l'a détectée. Si non, on ajuste les règles ; on rejoue. On répète pour chaque technique du catalogue MITRE ATT&CK.
L'intérêt est double. La défense apprend ce qui la traverse aujourd'hui et comment le voir demain. L'attaquant apprend quelles techniques sont bruyantes et lesquelles passent — indispensable pour une future mission furtive. Un vrai purple team de deux semaines vaut mieux qu'un pentest annuel où le rapport ne sort qu'après le départ des consultants.
Pour aller plus loin — audit et pentest sont complémentaires, pas concurrents
Un audit ISO 27001 vérifie que la politique de mots de passe est écrite et applicable. Il ne dit rien de sa robustesse réelle : si le document précise « 12 caractères minimum » mais que la moitié du parc tolère encore huit, l'auditeur ne le verra pas.
C'est exactement là que le pentest complète : il essaye de casser cette politique, avec de vraies attaques de mots de passe, et il rapporte le taux de comptes tombés. Les deux démarches se soutiennent — un audit sans pentest peut certifier une organisation qui reste triviale à compromettre, et un pentest sans audit trouve dix trous sans expliquer pourquoi ils existent.
3. Vulnérabilité, exploit, impact — arrêtez de les mélanger
Trois mots. Trois choses différentes. Confondre les trois, c'est écrire un rapport que le client jettera.
Vulnérabilité : une faiblesse. Un bout de code, une config, un mot de passe par défaut. En soi, ça ne fait rien.
Exploit : le geste concret qui transforme la faiblesse en accès. Le code, la commande, le clic qui prouve la chose.
Impact : la conséquence métier de l'exploit. Ce n'est jamais un score CVSS. C'est « avec ça, j'ai lu la base clients complète » ou « avec ça, je bloque la production trois jours ».
Un exemple pour graver la distinction :
- Vulnérabilité : le serveur web tourne avec une version vulnérable à
CVE-2021-41773(Apache path traversal). - Exploit : je lance
curlavec un chemin traversant, je récupère/etc/passwd. - Impact : les identifiants d'un compte de service tournaient dans un fichier
.envdu même dossier, j'ai obtenu la connexion à la base de données de production.
Le client se moque de la CVE. Il retient la base de données. C'est ça qu'on met en tête de rapport.
Définition — CVE, ce qu'est ce numéro et ce qu'il n'est pas
CVE, Common Vulnerabilities and Exposures, est un catalogue public tenu par le MITRE aux États-Unis. Chaque vulnérabilité rendue publique reçoit un identifiant de la forme CVE-2021-41773 : le millésime est celui de l'attribution, pas de la découverte. Le catalogue nomme la faille, il ne la corrige pas.
Trois pièges qui coûtent aux débutants. Une CVE n'implique pas qu'un exploit public existe : environ un tiers des CVE n'ont jamais eu de code d'exploitation publié. Toutes les CVE ne sont pas graves : beaucoup ne s'appliquent qu'à des configurations rares. Et surtout, une CVE d'un composant ne concerne pas forcément votre installation — si la fonctionnalité fautive n'est pas activée, la version vulnérable est inoffensive. C'est la première chose à démontrer avant d'écrire « critique » dans un rapport.
Définition — CVSS, le score de gravité et ses limites
CVSS, Common Vulnerability Scoring System, attribue un score de 0 à 10 à une vulnérabilité. Il agrège l'impact potentiel — confidentialité, intégrité, disponibilité — et la facilité d'exploitation — accessible par le réseau ou seulement en local, avec ou sans authentification, avec ou sans interaction de l'utilisateur.
Ce score est utile pour trier une pile de tickets. Il est inutile pour un rapport de pentest, et voici pourquoi. CVSS ignore votre contexte. Une faille notée 9,8 sur un serveur isolé sans données sensibles est moins urgente qu'une faille notée 6,5 sur la passerelle qui protège votre production. Le rapport doit dire « avec cette faille, un attaquant obtient l'accès à ces données », pas « score CVSS 9,8 ». Le score aide le client à décider entre deux failles voisines ; il ne remplace jamais votre analyse.
4. Le mental de l'attaquant
L'ingénieur système part de la machine et se demande « qu'est-ce que je fais tourner ? ». L'attaquant part du même point et se demande « qu'est-ce qui dépasse ? ».
Les cinq réflexes qui font la différence :
- Toujours regarder ce qui écoute. Un port ouvert, c'est une porte. Une porte, c'est un service. Un service, c'est une version. Une version, c'est une histoire de bugs connus.
- Toujours regarder ce qui parle. Les bannières, les en-têtes HTTP, les messages d'erreur — ils racontent tout.
- Toujours regarder ce qui a été oublié. Un fichier
.git, unbackup.sql, unrobots.txt, une capture d'écran laissée dans un dossier public. La négligence est plus fréquente que la vulnérabilité zero-day. - Toujours enchaîner. Une faille seule est rarement critique. Deux failles moyennes chaînées, c'est un désastre. Cherchez la chaîne, pas la faille.
- Toujours douter du succès. Si ça marche du premier coup, c'est peut-être un piège (honeypot). Vérifiez que la machine que vous tenez est vraiment celle que vous croyez.
« Ce que le développeur a oublié de vérifier, c'est exactement là où j'entre. »
Définition — les trois états d'un port, parce qu'on va le lire dans chaque rapport
Un port n'est pas « ouvert ou fermé » : il a trois états, et confondre les deux derniers vous fera passer à côté de vraies cibles.
Open : quelque chose écoute et répond. C'est ce qu'on cherche.
Closed : la machine existe, elle a répondu, mais aucun service n'attend sur ce port précis. La cible est vivante, et le port est simplement inutilisé.
Filtered : la machine n'a pas répondu — ou seulement par un message d'erreur — parce qu'un pare-feu a intercepté le paquet en amont. Vous ne savez pas si le port est ouvert ou fermé. C'est précieux : cela indique qu'il y a un filtrage, donc que le service est probablement sensible et volontairement protégé.
Nmap ajoute deux nuances plus rares. Unfiltered : le port répond mais Nmap ne peut pas conclure ; c'est fréquent avec certains types de scans. Open|filtered : Nmap hésite, souvent en UDP où l'absence de réponse peut vouloir dire les deux. Vous apprendrez à lire ces états au module 4.
Définition — root, Administrator, SYSTEM, ce qu'on veut à la fin
Sur les systèmes Unix — Linux, macOS, BSD — le compte tout-puissant s'appelle root. Il a l'identifiant numérique zéro. Il lit et écrit tous les fichiers, tue tous les processus, charge et décharge les pilotes noyau.
Sur Windows, la hiérarchie est plus fine. Administrator est le compte administrateur historique, celui du bureau. Au-dessus, invisible pour l'utilisateur, siège SYSTEM — l'identité sous laquelle tournent les services Windows eux-mêmes, y compris ceux qui gèrent l'authentification et la sécurité. Un pentester préfère SYSTEM à Administrator : SYSTEM peut lire la base des mots de passe (SAM) que même Administrator ne peut pas ouvrir sans passer par des astuces. C'est pour cette raison que la démonstration du module cible directement un shell SYSTEM.
Un troisième niveau existe sur les postes joints à un domaine Windows : Domain Admin. Compromettre Domain Admin équivaut à posséder l'annuaire entier — donc, en général, l'ensemble du parc.
5. La kill chain — la carte pour ne jamais se perdre
Une attaque n'est pas un coup de génie unique. C'est une suite d'étapes. La séquence classique, en sept temps :
- Reconnaissance — apprendre sur la cible sans la toucher (OSINT). Module 3.
- Reconnaissance active — scan de ports, énumération de services. Module 4.
- Recherche de vulnérabilités — corréler les versions vues avec les CVE connues. Module 5.
- Exploitation initiale — obtenir le premier shell. Modules 7 et 8.
- Élévation de privilèges — passer d'un compte quelconque à
rootouSYSTEM. Module 9. - Mouvement latéral — sauter de machine en machine, exfiltrer des données. Module 10.
- Rapport — remettre les preuves, les recommandations, la timeline. Module 12.
Chaque module de ce cours répond à une étape. Quand vous serez perdu(e) en mission, revenez à cette liste : elle vous dit où vous en êtes, et ce qui manque.
Pour aller plus loin — d'où vient la kill chain, et pourquoi MITRE ATT&CK l'a remplacée
La Cyber Kill Chain a été formalisée en 2011 par Lockheed Martin. Elle transposait sur le numérique le raisonnement militaire déjà appliqué à la destruction d'une cible physique : Find, Fix, Track, Target, Engage, Assess. Sa force est pédagogique — elle est linéaire, mémorisable en une minute — mais sa faiblesse s'est révélée à l'usage : une vraie attaque n'est pas linéaire. Elle boucle. L'attaquant revient à la reconnaissance après un premier accès, il change d'axe, il abandonne une chaîne pour en essayer une autre.
MITRE ATT&CK, publié pour la première fois en 2013, remplace la ligne par une matrice. Les colonnes sont les grandes catégories — Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact. Chaque colonne contient plusieurs techniques concrètes, chacune avec un identifiant unique du type T1078. Cette granularité permet à un défenseur de dire « j'ai des règles pour tel identifiant, aucune pour tel autre ».
Dans ce cours nous partons de la kill chain parce qu'elle sert de fil narratif, mais dès le module 4 le vocabulaire ATT&CK apparaît. Un bon pentester sait passer des deux.
6. Pourquoi Kali, et pas Ubuntu
Kali Linux est une distribution Debian bourrée d'outils offensifs. On aurait pu tous les installer à la main sur une Ubuntu. On ne le fait pas, pour trois raisons :
- Tout est là, tout de suite. Nmap, Metasploit, Burp Suite, John the Ripper, Hashcat, Wireshark, Bloodhound, Impacket — plus de 600 outils préinstallés et à jour.
- Les mises à jour vont dans le bon sens. Le canal
kali-rollingpousse les versions offensives récentes. Sur une Ubuntu LTS, Nmap peut avoir un an de retard sur les scripts NSE. - La communauté sait ce que vous faites. Un souci ? Vous cherchez « kali nmap segfault », vous trouvez la réponse en trente secondes. Sur une distribution générique, personne ne comprendra votre problème.
Kali n'est pas « un OS pour hackers ». C'est une caisse à outils avec un système d'exploitation autour. Vous n'y stockez rien, vous ne l'ouvrez pas au réseau public, et vous le recréez d'un snapshot dès qu'il devient bizarre.
Définition — une distribution rolling, et pourquoi cela change la vie du testeur
Une distribution rolling, littéralement « qui roule », publie les mises à jour au fil de l'eau, sans version numérotée figée. Vous mettez à jour un lundi, les paquets sont dans l'état où ils étaient ce lundi ; vous mettez à jour deux mois plus tard, ils ont avancé. Il n'y a pas de Kali 2023.4 qu'on installe pour deux ans avant de tout réinstaller — il y a un flux permanent.
À l'opposé, Ubuntu LTS publie une version tous les deux ans et ne bouge presque plus dessus, sauf pour les correctifs de sécurité rétroportés. C'est un choix pertinent pour un serveur de production, où la stabilité prime. Pour un attaquant, c'est un handicap : une signature d'exploit ajoutée dans Metasploit la semaine dernière n'atteindra votre Ubuntu qu'après un cycle de rétroportage, souvent jamais.
La contrepartie du modèle rolling est réelle : une mise à jour peut casser un outil du jour au lendemain. C'est pour cette raison qu'on prend un instantané VirtualBox après chaque mise à jour réussie, et qu'on n'y revient qu'après avoir testé la nouvelle version dans un environnement de rechange.
Définition — un instantané de machine virtuelle
Un snapshot, ou instantané, est un enregistrement de l'état complet d'une machine virtuelle à un moment donné : contenu du disque, contenu de la mémoire vive, configuration matérielle simulée. VirtualBox et VMware stockent cet état à côté du disque virtuel principal, sous forme de fichier différentiel — seuls les blocs modifiés depuis la prise sont recopiés, ce qui rend l'opération rapide même pour une VM de dizaines de gigaoctets.
Deux usages en pentest. Le premier est défensif : avant d'installer un outil douteux ou d'exécuter un binaire suspect, on prend un instantané ; si la VM se comporte mal, un clic la remet à l'état d'avant. Le second est expérimental : sur la machine cible du laboratoire, on prend un instantané base-vulnerable avant la première exploitation. On peut alors rejouer indéfiniment la même attaque, ce qui est indispensable pour vérifier une remédiation ou pour former quelqu'un d'autre. Sans instantané, une cible détruite ne se rejoue pas.
7. Les confusions qui coûtent du temps
Corrigez-les maintenant, avant qu'elles ne vous mordent en semaine 5.
| On dit souvent… | La bonne notion |
|---|---|
| « J'ai trouvé une CVE » | Une CVE, c'est un identifiant. On trouve une vulnérabilité, qui correspond peut-être à une CVE. |
| « Je l'ai hacké » | Non, vous avez exploité une vulnérabilité. Le mot hack ne dit rien de précis. |
| « C'est du code malveillant » | Un exploit n'est pas un malware. Un exploit déclenche une faille. Un malware fait quelque chose de mauvais une fois en place. |
| « Nmap m'a trouvé une faille » | Non, Nmap voit des ports et des versions. Vous faites le lien avec la vulnérabilité. |
| « Le port est fermé » | Un port peut être closed (le service dit non), filtered (un pare-feu intercepte), ou open (quelqu'un écoute). Trois états, trois histoires. |
| « Metasploit a hacké la machine » | Metasploit livre un exploit et gère la session. Il ne pense pas à votre place. |
8. Ce qu'il faut retenir
- Un pentest est cadré, autorisé, mesuré. Sans ce cadre, ce n'est plus un pentest, c'est un délit.
- La valeur d'un pentest est dans les preuves et les recommandations, pas dans le nombre de trouvailles.
- Vulnérabilité, exploit, impact : trois mots, trois choses. Ne les mélangez plus.
- L'attaquant regarde ce qui dépasse, ce qui parle, ce qui a été oublié, et il enchaîne.
- La kill chain vous dit toujours où vous en êtes.
- Kali est votre caisse à outils. Pas votre bureau, pas votre coffre-fort.
Prochaine leçon : on installe Kali, on lance le premier scan, et on regarde une machine tomber — dans un laboratoire fermé à double tour.