A moins de vivre dans les années 90, on a accès de nos jours à pas mal de matériel/technologie assez puissants pour pouvoir simuler des environnements plus ou moins complexes que l’on est susceptible de rencontrer en situation réelle (en tant que pentester)

  • soit pour apprendre quelque chose de nouveau (par exemple, lorsque l’on commence à s’intéresser à Active Directory, il est recommandé de s’entrainer sur 2-3 choses avant de faire ça en vrai)
  • soit pour maquetter une attaque (on reproduit l’environnement cible et on teste l’attaque afin de voir ses effets et éventuels dommages collatéraux, voire pour l’optimiser ou identifier des IOC)

Une question qui revient souvent c’est le matériel dont il y a besoin. En fait il n’y a pas besoin de grand chose. On peut commencer avec un bête outil de virtualisation capable de faire tourner une VM avec très peu de RAM (genre les VM LampSecCTF), par contre c’est tout juste suffisant pour les environnements de type “boot2root”. Sur mon vieux PC de bureau (un i7 920 avec 12Go de RAM et 1To de stockage) je faisais tourner un petit environnement Windows/AD comprenant :

  • Contrôleur de domaine
  • Serveur (MSSQL)
  • Workstation (Windows7 ou Windows 10)
  • VM d’attaque (Kali)

Et c’était déjà pas mal pour la plupart des scénarios d’attaque les plus répandus tout en étant relativement fluide pour d’autres usages. Tout ça date un peu. Par contre, tout ça implique de lire pas mal de documentation, car certains scénarios nécessitent d’aller fouiller dans les paramètres du système (notamment tout ce qui est lié à des ACL trop souples, ou laisser un mot de passe vraiment trop simple au compte “sa” de MSSQL).

Certains utilisent Azure ou AWS, mais ça a un coût. J’ai opté pour un serveur chez Online qui me coute environ 20€/mois mais parce que j’accepte ce coût également. Ce qui n’est pas forcément le cas de quelqu’un qui débute en sécurité et souhaite s’entrainer en restant dans la légalité. Certains environnements sur root-me (je pense aux “Blue-Box” en particulier) sont pas mal aussi. En revanche il faut composer avec le fait que d’autres joueurs peuvent se ramener et interférer :)

Sur mon environnement de test hébergé chez Online, et qui a nécessité un peu de configuration (on a rien sans rien), j’arrive à y faire tourner un environnement déjà un peu plus complexe dans de bonnes conditions :

  • Contrôleur de domaine
  • Serveurs
    • 2x Ubuntu (14.04 et 18.04)
      • Tomcat avec identifiants faibles (pour un scénario bien connu des pentesters)
      • Squid (pour tester payloads proxy-aware sur les postes clients)
      • SSH (pour tester pivot via SSH)
    • 2x Windows Server
      • IIS (avec support ASPX + file upload vulnérable)
      • MSSQL (avec compte de service mal sécurisé pour Kerberoast + Potato)
  • Workstations (2x Windows 10, 1x Windows 7)
    • EternalBlue :p
    • MS Office (pour scénarios de spear phishing)
    • Navigateurs vulnérables (pour scénarios de spear phishing)
    • KeePass (pour outils type keethief)
  • Une multitude de serveurs faisant tourner des webapps vulnérables
    • Entrainement pour AWAE/OSWE

Evidemment j’ajuste l’environnement en fonction de ce que j’ai besoin de tester. Au fur et à mesure j’ai par exemple ajouté des comptes ou des groupes avec des permissions trop souples (de type GenericAll) permettant de modifier le mot de passe d’un compte administrateur du domaine depuis un compte standard, ou ajouter n’importe quel utilisateur au groupe d’administrateurs du domaine (ce qu’on trouve dans des tutos PowerView).

Un autre élément important à avoir, outre les machines vulnérables, c’est toute l’infrastructure d’attaque, et là ça peut vite devenir ingérable pour une personne seule qui souhaite juste s’amuser. Un lab tel que décrit plus haut peut suffire à simuler des attaques directes en environnement AD ou certains scénarios “web” mais si l’on souhaite jouer avec des scénarios de rebond/pivot suite à compromission d’un asset externe ou d’un phishing réussi, et des redirecteurs pour faire une infrastructure d’attaque propre, ça va demander :

  • un lab légèrement segmenté
    • un réseau cible
    • un réseau d’attaque
  • potentiellement une ou plusieurs adresses IP externes
    • on peut simuler la partie WAN éventuellement en disant qu’un range RFC1918 est en réalité une IP publique dans notre scénario

De plus, il est généralement important de disposer de machines disposant d’un environnement de compilation pour différents systèmes/architectures/versions. Si en plus ça pouvait être fait de manière automatisée, ça serait parfait. Ca permet d’éviter de faire tout un tas d’étapes manuellement (génération de shellcode, intégration à une macro VB pour Office et intégration à un document Word/docx). Il est possible de générer un document Word complet via PowerShell en interagissant avec un objet COM Word. Si l’on couple ça à un peu de scripting, on peut totalement automatiser toute une partie rébarbative qui jusque là nécessitait d’ouvrir word, copier/coller sa macro, la coller, etc etc.

Dans un futur article (un jour, peut-être) je détaillerai un ou plusieurs exemples de configurations volontairement vulnérables, et la manière de les exploiter.

Ce post est potentiellement amené à évoluer au fil du temps.

Update du 12/04/2022: J’ai un peu tardé à mettre ce post à jour, mais l’an dernier, Online/Dedibox m’a informé que le serveur que je louais chez eux arrivait en fin de support et qu’en raison d’une pénurie de composants ils ne seraient pas en mesure d’assurer un support hardware en cas de panne aboutissant à leur décision de couper ce serveur après quelques mois. L’ultimatum était pour avril 2022. Dans le même temps je me suis mis en quête d’une solution pour assurer la continuité de mon lab et je me suis rabattu sur un “microserver” de chez HP (Gen10) auquel j’ai augmenté la RAM et placé un disque dur, sur Le Bon Coin. Après une installation de VMware ESXi, un import de mes VM et quelques retouches de configuration, tout est reparti comme avant sans encombres.