J’ai récemment obtenu une nouvelle certification, et pas des moindres que ce soit en termes pécunier qu’en termes de temps investit ! L’OSCP (OSCP+ maintenant) :
La certification OSCP (Offensive Security Certified Professional), proposée par Offsec, est une certification orientée pentesting. Elle permet d’attester que l’étudiant ayant obtenu la certification est en mesure de réaliser un pentest, ou du moins, d’appliquer la méthodologie « Offsec ». La méthodologie inculquée dans le cours impose notamment la non utilisation de certains outils (Outils automatiques, Metasploit, SQLmap, IA, etc), et favorise la bonne connaissance des outils plus « basiques ».
Elle est notamment connue pour proposer un examen final de 48h, 24h de pentesting en black box suivi de 24h de rédaction de rapport (en Anglais). La difficulté est souvent considérée, par les étudiants, comme étant relevée. Bien évidemment, la difficulté intrinsèque des épreuves est assez relative, cependant, la contrainte de temps peut amener à se mettre une pression supplémentaire.
Je vais donc exposer quelques points clés, qui m’ont aidé ou que j’aurais aimé savoir durant l’examen.
#1 Enumérer, puis énumérer encore
L’énumération est un point clé de chaque CTF ou pentest. En effet, sans cela, on ne peut pas avoir une idée claire de l’état de la cible. C’est pourquoi il est important de dédier du temps à l’énumération. Dans le cadre des challenges/exam de chez Offsec, qui ne sont pas des environnements de production, on peut alors utiliser des commandes assez bruyantes.
Pour énumérer TCP :
nmap -p- -A 192.168.50.50 -o scan.nmapEt, ne pas oublier UDP :
nmap --top-ports 1000 -sU 192.168.50.50Il se peut que cela ne suffise pas, mais cela donnera déjà une bonne idée de la situation de la cible. On peut après approfondir port par port.
#2 Varier les exploits
Après l’énumération, certaines cibles peuvent sembler vulnérables à des CVE bien connues et « faciles » à exploiter. Cependant, certains exploits trouvable sur le web ne sont pas fonctionnels, il faut alors se forcer à utiliser toutes les versions disponibles.
Il ne faut pas hésiter à effectuer des modifications sur les exploits car ils peuvent parfois être inefficaces pour des raisons très simples. D’ailleurs, une bonne technique pour trouver des exploits publics est d’utiliser les google dorks, permettant ainsi de filtrer certains site connus comme github.
#3 Utiliser des ports différents
Celle ci peut coûter assez cher, on peut penser que son exploit n’est pas fonctionnel alors que on est tout simplement bloqué par le pare feu de la cible.
Prenons l’exemple d’une cible Windows qui est un serveur web et ftp. Les ports 21 et 80 sont alors ouverts. Imaginons que l’on ai un exploit pour le FTP, et que celui ci ouvre un reverse shell vers notre machine attaquante. On va souvent utiliser un listener sur un port particulier (par exemple 4444) pour le réceptionner, mais il se peut que la cible utilise un pare-feu qui bloque aussi les connexion sortantes.
Alors peu importe ce que l’on tentera, la connexion passera uniquement en utilisant les ports 21 ou 80. Pour éviter de perdre du temps inutilement, il faut impérativement tester moult ports mais surtout ceux qui sont probablement non filtrés (en fonction de la cible).
N.B.: Cela peut aussi être appliqué à la distribution des payloads, si le serveur web de votre machine est sur le port 8080, il se peut que la cible ne puisse pas le joindre et donc ne pourra pas récupérer la charge utile. Il faudra alors trouver un port qui passe au travers du pare-feu.
#4 Bien utiliser hashcat
Celui là peut avoir de grandes répercussions sur le temps qu’on met à cracker un hash. Le plus souvent on utilise Kali linux en machine virtuelle avec peu de CPU et donc de puissance de calcul. Il m’est arrivé de penser qu’un hash était « incassable » mais en réalité il s’agissait juste du processeur de la VM qui n’était pas assez puissant. A titre de comparaison, un hashcat sur CPU peut prendre plusieurs heures alors qu’avec un GPU basique (ex. RTX3060 ou équivalent AMD) il sera presque instantané.
On peut même quantifier cette différence avec le mode benchmark de hashcat :
hashcat -bAlors, ne pas hésiter à disposer d’une carte graphique pour effectuer les tâches de cracking !
#5 Réutiliser les identifiants
On le sait (surtout quand on est passé par la case Admin Sys) l’une des pratiques les plus répandues, qui est parfois un sport olympique chez certains, est la réutilisation des mots de passe.
On le remarque notamment dans les différents labs et proving grounds, quand on trouve un mot de passe (même sans le nom d’utilisateur qui va avec) on doit absolument essayer de le réutiliser !
Si on est dans un environnement AD, on vérifie bien entendu la politique de mot de passe avant :
nxc smb 192.168.50.50 -u USER -p PASSWORD --pass-polD’ailleurs, si on est en capacité de récupérer la politique de mot de passe, ça veut souvent dire qu’on est en capacité de lister les utilisateurs du domaine. Alors surtout on ne se prive pas pour en créer une liste qui servira à tester les mots de passe qu’on peut trouver.
net user /domain# Bonus : Prendre des notes
En mention honorable, je dirais qu’il est très important de prendre des notes et des captures d’écran de chaque étapes. J’ai eu la chance de finir mon examen plusieurs heures avant la fin de l’accès aux labs, me permettant ainsi de refaire pas à pas les étapes du pentest. C’est pourquoi il faut toujours prendre des notes, on ne sait jamais si on aura le temps d’y revenir avant la fin !
