Questions d'entretien OSCP

Un binaire SUID-root s'exécute avec les privilèges de root, et s'il est accessible en écriture par tous, un attaquant peut le remplacer ou le modifier pour exécuter du code arbitraire en tant que root — une voie classique d'élévation de privilèges locale. Retirez le bit SUID, corrigez le propriétaire et les permissions, et enquêtez sur l'origine de cette mauvaise configuration, car elle peut indiquer une compromission. Chiffrer le fichier laisse intact le chemin exécutable, et le renommer ne fait que déplacer le problème sans supprimer l'élévation. Aucune de ces options ne traite la cause racine.

Les règles d'engagement excluent généralement le déni de service en production, et un plantage non planifié cause un dommage réel à l'activité et peut annuler la mission. Vérifiez d'abord le périmètre ; si une preuve de concept destructrice n'est pas autorisée, prouvez la vulnérabilité par des moyens plus sûrs et documentez clairement l'impact probable. Lancer l'exploit pour une capture d'écran est imprudent. Le lancer à répétition pour des « métriques de fiabilité » multiplie la panne. Le passer sous silence cache au client un risque sérieux et exploitable.

Les missions professionnelles se terminent par un nettoyage complet et un inventaire des artefacts, pour ne pas laisser de nouvelle surface d'attaque ni brouiller l'environnement du client. Laisser des shells ou des comptes au client à trouver est négligent et dangereux — un vrai attaquant pourrait les réutiliser. Conserver une porte dérobée « pour la prochaine fois » est contraire à l'éthique et probablement illégal. Supprimer vos propres journaux d'activité détruit la piste d'audit dont le client a besoin pour valider le test et reconstituer ce que vous avez fait.

Ce qui compte, c'est l'impact : un identifiant de service réutilisé ou surprivilégié qui débloque l'admin du domaine ou des systèmes critiques est le constat qui compte, alors testez la réutilisation et cartographiez les privilèges et le chemin de mouvement latéral. Casser d'abord tous les autres hashs est une perte de temps qui retarde l'essentiel. Changer le mot de passe du compte de service est destructeur, casse la production et alerte les défenseurs. Envoyer un identifiant actif en clair par e-mail est en soi une exposition et une mauvaise hygiène opérationnelle.

Découvrir une intrusion active est une urgence hors bande : les règles d'engagement doivent définir une procédure d'escalade, alors déclenchez-la immédiatement, préservez les preuves et évitez de contaminer un incident en cours. Continuer à tester peut interférer avec le vrai attaquant ou détruire les preuves mêmes dont les intervenants ont besoin. Tenter d'expulser l'attaquant vous-même est hors périmètre, risqué et peut l'alerter. Attendre le rapport final pourrait signifier des jours de violation continue et de perte de données.

Prouvez la vulnérabilité sans nuire au client ni accumuler ses données : montrez que vous pouvez lire des données arbitraires via la version de la base, le schéma ou un seul échantillon anonymisé, puis arrêtez-vous. Extraire l'intégralité des données personnelles crée une responsabilité de notification de violation et de traitement pour les deux parties. Supprimer une table est destructeur et dépasse de loin la preuve de concept. Chiffrer la base et exiger une prime, c'est de l'extorsion, pas un test : c'est un délit, pas un constat.

L'autorisation définit la mission : tester hors du périmètre convenu est potentiellement illégal et viole les règles d'engagement, aussi tentante que soit la cible. Documentez ce que vous avez vu, arrêtez-vous et obtenez l'accord écrit du client avant d'aller plus loin. Exploiter pour « plus de constats » ne justifie jamais un accès non autorisé. L'exploiter discrètement en pensant ne pas être pris est à la fois contraire à l'éthique et un délit, et étendre le périmètre vous-même prive le client de son consentement éclairé.

Cela confirme le XSS. Si alert() s'est déclenché du tout, c'est que le navigateur a analysé et exécuté votre JavaScript injecté dans le contexte de la page : c'est la vulnérabilité. Une fenêtre vide signifie simplement que l'argument chaîne que vous avez transmis ne s'est pas affiché comme prévu (gestion des guillemets, encodage ou altération du contexte ont cassé le message), pas que la charge est bloquée. Le point d'exécution est actif ; vous affinez la charge à partir de là.

Non. CORS n'est pas une défense contre le CSRF : il assouplit en réalité la politique de même origine pour qu'une page puisse lire des réponses cross-origin qu'elle ne pourrait pas lire autrement. Le CSRF n'a pas besoin de lire la réponse ; il a juste besoin que le navigateur de la victime envoie une requête authentifiée qui modifie l'état. Les vraies défenses sont les jetons anti-CSRF, l'attribut de cookie SameSite, et la vérification d'Origin/Referer.

Filtré. Un port filtré rejette silencieusement le paquet, donc le scanner n'obtient aucune réponse et doit attendre un délai d'expiration : il n'apprend rien sur l'existence même de l'hôte, et le scan est considérablement ralenti. Un port fermé renvoie un RST TCP, qui confirme que l'hôte est vivant et répond, offrant gratuitement à l'attaquant une valeur de reconnaissance.

Pas à lui seul. HTTPS empêche le MITM uniquement quand la validation du certificat est strictement appliquée et que le client atteint le site en HTTPS dès le départ. Si une AC malveillante est de confiance (proxy d'entreprise, racine installée par un logiciel malveillant), si l'utilisateur passe outre les avertissements de certificat, ou si du SSL stripping rétrograde la connexion vers HTTP avant le démarrage de TLS, un attaquant peut toujours se placer au milieu.

Un désassembleur comme Ghidra ou IDA vous donne la carte statique complète : références croisées, pseudocode décompilé et chaque chemin de code, qu'il s'exécute ou non. Un débogueur comme x64dbg vous permet d'exécuter l'échantillon sous contrôle — poser des points d'arrêt, inspecter registres et mémoire, observer le déchiffrement se produire, et suivre le chemin que le code prend réellement avec de vraies entrées. On lit la structure et l'intention statiquement, puis on attache le débogueur pour résoudre ce que l'analyse statique ne peut pas : chaînes déchiffrées au runtime, API résolues dynamiquement, charges utiles empaquetées, et quelle branche une condition prend. Les deux ensemble comblent leurs lacunes mutuelles.

L'injection de processus exécute du code malveillant à l'intérieur d'un autre processus pour se cacher et hériter de sa confiance. L'injection distante classique alloue de la mémoire dans une cible avec VirtualAllocEx, écrit une charge utile via WriteProcessMemory, et l'exécute avec CreateRemoteThread. Les variantes incluent l'injection de DLL via LoadLibrary, le process hollowing qui démappe un processus légitime suspendu et remplace son image, l'injection APC qui met du code en file d'attente sur un thread, et le chargement réflexif ou mappé manuellement qui évite LoadLibrary entièrement. On les repère par les séquences d'API révélatrices, la mémoire RWX dans un processus normalement propre, les threads sans fichier de sauvegarde sur le disque et les anomalies parent-enfant.

La décompression récupère le code original que le packer a caché. Pour les packers connus, vous utilisez le décompresseur correspondant ou un émulateur. Pour les packers personnalisés, vous décompressez manuellement : exécutez l'échantillon dans un débogueur, laissez le stub décompresser la charge utile en mémoire, trouvez le moment où il saute vers le point d'entrée original (souvent en posant un point d'arrêt sur de la mémoire qui devient exécutable, ou sur le saut de queue), puis dumpez l'image du processus depuis la mémoire et reconstruisez la table d'adresses d'imports avec un outil comme Scylla ou PE-sieve. Le résultat est un PE exécutable ou analysable contenant la véritable charge utile.

Le WSTG est une méthodologie adossée à une checklist qui fait passer une application par des catégories de test : collecte d'informations, configuration et déploiement, identité et authentification, autorisation, gestion de session, validation des entrées (injection/XSS), gestion des erreurs, cryptographie, logique métier et côté client. Il offre une couverture systématique avec des identifiants de test stables, de sorte que les constats sont reproductibles et que rien d'évident n'est oublié.

PTES définit sept phases : pré-engagement (périmètre, règles d'engagement, autorisation), collecte de renseignements (OSINT, reconnaissance), modélisation des menaces, analyse de vulnérabilités, exploitation, post-exploitation (pivotement, données de valeur, persistance) et reporting. La structure rend les missions reproductibles, défendables et liées au risque métier plutôt qu'à du hacking improvisé. Le pré-engagement et le reporting sont les phases que les juniors sous-estiment.

Un pentest vise une large couverture — trouver autant de vulnérabilités que possible dans une cible délimitée. Une red team est une émulation d'adversaire pilotée par objectif : choisir un but (par ex. atteindre les données les plus précieuses), émuler les TTP d'un acteur de menace précis, rester furtif pour tester la détection et la réponse, et éviter le scan bruyant. La red team mesure l'équipe bleue et toute l'organisation, pas seulement l'actif ; les deux exigent des règles d'engagement strictes et une autorisation.

Commencez par comprendre le modèle de menace de l'application et où elle manipule des entrées non fiables, des secrets, de l'authentification et de l'autorisation. Utilisez le SAST pour scanner largement et le DAST contre l'application en cours d'exécution, mais traitez la sortie des outils comme des pistes, pas des constats — triez les faux positifs. Consacrez ensuite le temps humain aux zones à forte valeur et dépendantes du contexte que les outils manquent : logique d'autorisation, logique métier, usage de la cryptographie et frontières de confiance. Tracez le flux de données de la source au sink.

On commence par un scan complet des ports TCP, puis on énumère en profondeur chaque service ouvert — bannières, versions, identifiants par défaut, accès anonyme et contenu web — avant de toucher au moindre exploit. La plupart des machines tombent grâce à une énumération minutieuse, pas à des exploits astucieux, ce qui est le cœur de l'état d'esprit « try harder ».

Le scan nmap par défaut ne couvre que les 1000 ports les plus courants, donc un service sur un port haut serait entièrement manqué. Le schéma efficace est un scan SYN rapide des 65535 ports d'abord, puis un scan ciblé de versions et de scripts par défaut uniquement sur les ports trouvés ouverts.

Énumérez méthodiquement : vérifiez sudo -l, les binaires SUID/SGID, les tâches cron, la version du noyau et de l'OS, les fichiers inscriptibles dans des chemins privilégiés, les capabilities et les identifiants stockés. Des outils comme LinPEAS automatisent le balayage, mais vous vérifiez chaque découverte avec GTFOBins ou une technique connue.

Identifiez le service et la version exacts, cherchez sur Exploit-DB ou searchsploit un PoC correspondant, puis lisez le code ligne par ligne avant de l'exécuter — corrigez l'IP cible, le port et l'adresse du reverse shell, régénérez tout shellcode, et comprenez ce qu'il fait pour qu'il ne se retourne pas contre vous.

Identifiez d'abord le format du hachage (hashid ou contexte), puis lancez hashcat ou John avec le mode correct contre une wordlist comme rockyou, en appliquant des règles pour muter les candidats. Utilisez le bon flag de format (NTLM, sha512crypt, NetNTLMv2, etc.) pour que l'outil hache les essais de la même façon que la cible.

Utilisez l'hôte compromis comme relais vers le sous-réseau inaccessible. Mettez en place une redirection de port pour un service unique, ou un proxy SOCKS dynamique (SSH -D ou chisel) et routez vos outils à travers lui avec proxychains, pour que votre machine d'attaque atteigne les hôtes internes via le pivot.

Pour SMB, énumérez les partages, vérifiez l'accès anonyme/session null, listez les utilisateurs et identifiez la version pour les CVE connues. Pour SNMP, essayez les community strings par défaut comme « public » et parcourez la MIB pour extraire noms d'utilisateurs, processus en cours, logiciels installés et détails réseau.

On lance un pseudo-terminal (généralement python -c 'import pty; pty.spawn("/bin/bash")'), on le met en arrière-plan avec Ctrl-Z, on exécute stty raw -echo côté local, on le remet au premier plan, puis on réinitialise TERM et le nombre de lignes/colonnes. On obtient un TTY complet avec contrôle des tâches, complétion par tabulation et éditeurs fonctionnels.

Identifiez la stack à partir des en-têtes et du source, puis brute-forcez répertoires et fichiers avec gobuster ou feroxbuster en utilisant une bonne wordlist et les extensions pertinentes. Cherchez panneaux d'administration, sauvegardes, fichiers de configuration et points d'upload, et vérifiez les hôtes virtuels quand le site répond à un nom d'hôte.

Énumérez les privilèges actuels (whoami /priv), les services mal configurés (permissions faibles, chemins de service non quotés), AlwaysInstallElevated, les tâches planifiées, les identifiants stockés et les correctifs manquants. WinPEAS ou PowerUp automatisent le balayage ; les abus de privilèges de jetons comme SeImpersonate sont des gains fréquents à forte valeur.

Isolément, une SQLi expose ou modifie des données et peut atteindre le RCE ; une XSS stockée détourne les sessions dans le navigateur des victimes. Enchaînées, vous pouvez utiliser la SQLi pour implanter une charge XSS stockée qui se déclenche dans la session d'un admin, voler sa session et passer au contrôle total de l'application.

Tout utilisateur du domaine authentifié peut demander un ticket de service Kerberos (TGS) pour n'importe quel compte ayant un SPN. Ce ticket est chiffré avec le hachage de mot de passe NTLM du compte de service ; vous l'extrayez et cassez le mot de passe hors ligne — aucun accès privilégié requis au départ, et c'est quasi silencieux.

La reconnaissance passive recueille des informations sans interagir directement avec les systèmes de la cible — OSINT, enregistrements DNS, transparence des certificats. La reconnaissance active touche la cible, comme le balayage de ports ou la capture de bannières, ce qui est plus bruyant mais donne plus de détails.

Un test d'intrusion passe par le pré-engagement (cadrage et règles d'engagement), la reconnaissance, le balayage et l'énumération, l'exploitation, la post-exploitation et le reporting. Chaque phase alimente la suivante, et le reporting est le moment où la valeur est réellement livrée au client.

Le pivoting transforme un hôte compromis en relais pour atteindre des segments internes vers lesquels votre machine ne peut pas router. Vous utilisez le port forwarding, un proxy SOCKS sur votre canal C2 (par ex. Chisel, le forwarding dynamique SSH) ou un routage par agent, puis vous lancez des outils à travers ce tunnel pour attaquer le sous-réseau suivant.

Énumérez d'abord : privilèges actuels, droits sudo, binaires SUID/SGID, tâches cron, fichiers inscriptibles dans le PATH, version du noyau et identifiants stockés. Puis exploitez le chemin le plus simple et fiable — souvent une règle sudo mal configurée ou un GTFOBin SUID — avant de recourir à un exploit du noyau.

Énumérez les privilèges du compte et les mauvaises configurations de l'hôte : privilèges de jeton comme SeImpersonate, chemins de service non entre guillemets, permissions de service faibles, AlwaysInstallElevated et identifiants stockés. Puis abusez du plus fiable — l'usurpation de jeton (attaques Potato) est une voie courante vers SYSTEM.

Un bind shell ouvre un port d'écoute sur la cible et attend que vous vous y connectiez. Un reverse shell fait que la cible se connecte en sortie vers un écouteur que vous contrôlez. Les reverse shells l'emportent généralement car le trafic sortant contourne les règles de pare-feu entrantes et le NAT.

Un bon rapport sert deux publics : un résumé exécutif qui cadre le risque métier pour la direction, et des trouvailles détaillées et reproductibles avec preuves, évaluations de risque exactes et remédiation priorisée pour l'équipe technique. Le rapport — et non l'exploit — est le livrable.

L'injection SQL permet à l'entrée d'un attaquant de modifier une requête. Les techniques en bande renvoient les données directement : celle basée sur UNION ajoute un UNION SELECT pour extraire des colonnes supplémentaires, et celle basée sur les erreurs fait fuiter les données via les messages d'erreur de la base. Quand aucune sortie n'est visible, les attaquants utilisent la SQLi à l'aveugle — la booléenne déduit les données des différences de réponse vrai/faux, et la temporelle utilise des délais comme SLEEP() pour lire les données bit par bit.