Avant le début d’un test d’intrusion, l’équipe de test et l’entreprise doivent en définir la portée. La portée décrit les systèmes qui seront testés, le moment où les tests auront lieu et les méthodes que les testeurs d’intrusion peuvent utiliser. La portée détermine également la quantité d’informations dont disposeront les testeurs avant le lancement du processus.
Lors d’un test de type « boîte noire » (en anglais « BlackBox »), les testeurs ne disposent d’aucune information sur le système cible. Ils ne peuvent s’appuyer que sur leurs propres recherches pour élaborer un plan d’attaque, comme le ferait un pirate informatique dans le monde réel.
Dans un test de type « boîte blanche » (en anglais « WhiteBox »), les testeurs d’intrusion connaissent parfaitement le système cible. L’entreprise fournit des informations telles que les schémas de réseau, les codes source, les identifiants, etc.
Dans un test de type « boîte grise » (en anglais « GreyBox »), les testeurs d’intrusions obtiennent quelques informations, mais en quantité limitée. Par exemple, l’entreprise peut communiquer des plages d’adresses IP pour des dispositifs de réseau, mais les testeurs doivent y chercher eux-mêmes les vulnérabilités.
Une fois la portée définie, les tests peuvent commencer. Les testeurs peuvent suivre plusieurs méthodologies. Les plus courantes sont les directives pour les tests de sécurité des applications de l’OWASP (lien externe à ibm.com), la norme d’exécution des tests d’intrusion (PTES) (lien externe à ibm.com) et le SP 800-115 du National Institute of Standards and Technology (NIST) (lien externe à ibm.com).
Quelle que soit la méthodologie utilisée par l’équipe, le processus suit généralement les mêmes étapes.
1. Reconnaissance
L’équipe de test recueille des informations sur le système cible. Les testeurs utilisent différentes méthodes de reconnaissance en fonction de la cible. Par exemple, si la cible est une application, les testeurs peuvent étudier son code source. Si la cible est un réseau entier, les testeurs peuvent utiliser un analyseur de paquets pour inspecter les flux de trafic réseau.
Souvent, les testeurs s’appuient également sur des renseignements open source (OSINT). En lisant la documentation publique, des articles d’actualité et en consultant les réseaux sociaux et les comptes GitHub des employés, ils peuvent obtenir des informations précieuses sur leurs cibles.
2. Découverte et développement des cibles
Les testeurs d’intrusions utilisent les connaissances qu’ils ont acquises lors de l’étape de reconnaissance pour identifier les vulnérabilités exploitables du système. Par exemple, les testeurs peuvent utiliser un scanner de ports tel que Nmap pour rechercher les ports ouverts sur lesquels ils peuvent envoyer des logiciels malveillants. Pour le volet test d’ingénierie sociale, l’équipe de test peut créer une fausse histoire, ou un « prétexte », qu’elle utilisera ensuite dans un e-mail d’hameçonnage pour voler les identifiants des employés.
Lors de cette étape, les testeurs peuvent vérifier comment les dispositifs de sécurité réagissent aux intrusions. Par exemple, ils peuvent envoyer un trafic suspect au pare-feu de l’entreprise pour voir ce qui se passe. Les testeurs utilisent ce qu’ils ont appris pour éviter d’être détectés pendant le reste du test.
3. Exploitation
L’équipe de test commence l’attaque proprement dite. Les testeurs d’intrusion peuvent tenter diverses attaques en fonction du système cible, des vulnérabilités qu’ils ont trouvées et de la portée du test. Voici quelques-unes des attaques les plus fréquemment testées :
Injections SQL : les testeurs font en sorte qu’une page web ou une application divulgue des données sensibles en introduisant un code malveillant dans les champs de saisie.
Cross-site scripting : les testeurs essaient d’insérer du code malveillant sur le site web d’une entreprise.
Attaque par déni de service : Les testeurs tentent de déconnecter des serveurs, des applications et d’autres ressources du réseau en les submergeant de trafic.
Ingénierie sociale : Les testeurs utilisent l’hameçonnage, le baiting, un prétexte ou d’autres tactiques pour inciter les employés à compromettre la sécurité du réseau.
Attaques par force brute : les testeurs tentent de s’introduire dans un système en exécutant des scripts qui génèrent et testent des mots de passe potentiels jusqu’à ce que l’un d’entre eux fonctionne.
Attaques de type « man-in-the-middle » : les testeurs interceptent le trafic entre deux appareils ou utilisateurs pour voler des informations sensibles ou installer des logiciels malveillants.
4. Escalade
Une fois que les testeurs ont exploité une vulnérabilité pour mettre un pied dans le système, ils essaient de se déplacer et d’élargir l’accès. Cette phase est parfois appelée « vulnerability chaining », car les testeurs passent d’une vulnérabilité à l’autre pour pénétrer plus profondément dans le réseau. Par exemple, ils peuvent commencer par installer un keylogger sur l’ordinateur d’un employé. Grâce à ce keylogger, ils peuvent capturer les identifiants de l’employé. Et avec les identifiants ainsi récoltés, ils peuvent accéder à une base de données sensible.
À ce stade, l’objectif du testeur est de conserver l’accès et d’augmenter ses privilèges tout en échappant aux mesures de sécurité. Tout cela est fait pour imiter les menaces persistantes avancées (APT), qui peuvent se cacher dans un système pendant des semaines, des mois voire des années avant d’être détectées.
5. Nettoyage et reporting
À la fin de l’attaque simulée, les testeurs nettoient toutes les traces qu’ils ont laissées, comme les chevaux de Troie qu’ils ont installés par la porte dérobée ou les configurations qu’ils ont modifiées. De cette façon, les pirates du monde réel ne peuvent pas utiliser les exploits des testeurs d’intrusion pour pénétrer dans le réseau.
Ils rédigent ensuite un rapport sur l’attaque. Le rapport décrit généralement les vulnérabilités qu’ils ont trouvées, les exploits qu’ils ont utilisés, les détails sur la façon dont ils ont contourné les fonctionnalités de sécurité et la description de ce qu’ils ont fait dans le système. Le rapport peut également contenir des recommandations spécifiques sur la résolution des vulnérabilités. L’équipe de sécurité interne peut utiliser ces informations pour renforcer les défenses contre les attaques réelles.