Audit de sécurité
// En une phrase
Conduire une dizaine d'audits de sécurité et de pentests dans des contextes variés (stage, alternance, projets personnels), pratiquer en parallèle plus de 115 challenges CTF résolus et plusieurs vulnérabilités de bug bounty soumises pour bâtir une compétence offensive qui sert avant tout à mieux concevoir la sécurité défensive.
Présentation
Cette réalisation regroupe un ensemble d'actions offensives menées dans des contextes variés : audits de sécurité internes en entreprise, pentests sur clients, scans d'Active Directory en environnement opérateur, participation à des CTF (Capture The Flag) et programmes de bug bounty. Ces expériences se distinguent par leurs contextes et leurs enjeux, mais convergent toutes vers une même démarche : identifier les failles avant qu'un acteur malveillant ne le fasse.
Avoir une posture offensive solide n'est pas, pour moi, un objectif en soi. C'est un outil de compréhension qui sert directement ma trajectoire défensive : on conçoit mieux une infrastructure sécurisée quand on a passé du temps à attaquer des infrastructures mal sécurisées. C'est cette complémentarité entre attaque et défense qui structure mon approche du métier.
Objectifs, contextes et enjeux
L'objectif technique est toujours le même : trouver les erreurs de configuration, les vulnérabilités connues non corrigées, les vecteurs d'exploitation présents sur le périmètre étudié. Ce qui change selon le contexte, c'est l'enjeu et le niveau d'exigence sur le livrable.
En cadre professionnel, l'enjeu est critique. Une faille non détectée peut avoir des conséquences directes sur la confidentialité des données, la continuité de service ou la réputation de l'organisation. Le niveau d'exigence est élevé : méthodologie rigoureuse, scope clairement défini, livrable structuré et exploitable par les équipes IT qui devront corriger. Le rapport ne sert à rien s'il n'est pas compréhensible et actionnable.
En cadre personnel (CTF, bug bounty, lab personnel), l'enjeu est différent. Il n'y a pas de système en production à protéger, pas de client à rassurer. En revanche, c'est un terrain d'apprentissage particulièrement efficace, car les erreurs sont à ma charge et n'ont aucune conséquence sur des tiers. On apprend infiniment plus de ses propres erreurs quand personne d'autre n'en subit les conséquences.
Les risques propres à ces missions sont à prendre au sérieux. Un audit mal cadré peut déborder du périmètre autorisé et entrer juridiquement en zone grise. Un pentest mené sans précautions peut casser le service qu'il était censé évaluer. Une vulnérabilité divulguée publiquement avant correction expose le client à un risque immédiat. C'est pour ces raisons que je travaille toujours avec un cadre formalisé en mission professionnelle (autorisation écrite, scope précis, fenêtre temporelle définie) et que je respecte la responsible disclosure sur les vulnérabilités trouvées hors cadre.
Méthodologie d'audit
Méthodologie en cinq étapes, du cadrage initial à la restitution et au suivi des corrections.
Ma démarche s'appuie sur deux référentiels reconnus : le top 10 OWASP pour les applications web et la matrice MITRE ATT&CK pour structurer la pensée tactique sur l'ensemble du périmètre. Ces référentiels me donnent une grille de lecture commune avec les autres professionnels du secteur, et garantissent que je ne passe pas à côté des catégories de vulnérabilités les plus exploitées en conditions réelles.
Étapes de réalisation
Définir le périmètre, le format de livrable et la grille CVSS
Toute mission professionnelle commence par un cadrage formel. Je liste les éléments inclus dans le scope (hôtes, applications, domaines), j'identifie ce qui en est explicitement exclu, et je détermine la fenêtre temporelle de l'audit pour éviter tout débordement. Le format du rapport est également défini en amont : public technique ou décisionnel, niveau de détail attendu, intégration ou non d'une partie "executive summary".
Je définis ensuite la grille de notation qui sera utilisée pour qualifier les vulnérabilités. Cela passe par les CVE (Common Vulnerabilities and Exposures), identifiants standardisés attribués aux vulnérabilités connues, et surtout par le score CVSS (Common Vulnerability Scoring System) qui permet de mesurer objectivement la criticité d'une faille sur une échelle de 0 à 10, en tenant compte de facteurs comme l'exploitabilité, l'impact sur la confidentialité, l'intégrité et la disponibilité. Cette grille permet de prioriser les correctifs de manière rationnelle plutôt qu'intuitive.
Cartographier la cible avant toute tentative d'exploitation
La phase technique commence systématiquement par un scan réseau, généralement avec NMAP, pour lister les hôtes actifs, les services exposés et les versions logicielles en cours d'exécution. Ce premier inventaire donne déjà une vision claire de l'état de l'infrastructure : ce qui est à jour, ce qui ne l'est pas, ce qui est correctement isolé ou au contraire trop exposé.
En contexte interne (notamment chez Valesys), j'utilisais ensuite OpenVAS pour un scan de vulnérabilités plus exhaustif, complété par des outils spécialisés selon le périmètre : theHarvester et dnsdumpster pour le renseignement passif, Shodan pour repérer ce qui est exposé publiquement, dirb ou gobuster pour le fuzzing de répertoires web.
En contexte Paritel, mon approche d'audit est différente et plus ciblée. Comme l'environnement est très outillé (CrowdStrike, sondes IDS), les remontées d'anomalie fournissent déjà un excellent point de départ : je travaille sur les vulnérabilités déjà signalées par les outils, ce qui me dispense du scan généraliste. En revanche, je pratique régulièrement des scans ciblés de l'Active Directory avec PingCastle, BloodHound et Purple Knight, qui sont des outils dédiés à la détection de mauvaises configurations dans des environnements Microsoft. Ces scans s'apparentent à de l'audit de configuration plus qu'à du pentest pur, mais la méthodologie reste équivalente.
Tester les vecteurs d'attaque les plus courants, démontrer l'impact
Après l'inventaire, je teste les vecteurs d'attaque les plus courants sur les services repérés : brute force avec Hydra sur les services exposés, recherche de mots de passe par défaut, exploitation de mauvaises configurations sur les services récurrents (SSH, RDP, FTP, SMB, interfaces d'administration web).
Dans la grande majorité des cas, les mêmes problèmes reviennent et correspondent aux catégories du top 10 OWASP côté web : injections (notamment SQL, exploitées avec sqlmap), chiffrement faible (flux non chiffrés ou simple Base64 sur le réseau, certificats expirés ou mal configurés), identifiants par défaut sur les plateformes d'administration et les bases de données, CVE connues impactant la disponibilité (DoS, DDoS) ou permettant l'exécution de code, et fuites d'information sur des sources publiques (forums, repositories Git mal configurés contenant des credentials clients).
Sur les environnements WordPress, qui représentent un cas d'usage fréquent, j'ai construit une checklist méthodique au fil des audits : utilisation de WPScan pour énumérer les plugins installés et les utilisateurs, vérification de l'exposition de XML-RPC qui reste une porte d'entrée trop souvent oubliée, contrôle de la présence de 2FA sur les comptes administrateurs, et vérification de l'obfuscation du chemin WP-Admin pour rendre les tentatives d'accès moins évidentes. Cette checklist est née d'un vrai audit professionnel que j'ai mené, et je continue à l'enrichir mission après mission.
Pour l'élévation de privilèges sur un serveur compromis, je m'appuie systématiquement sur GTFOBins, qui répertorie les binaires Unix permettant un contournement d'isolation. C'est un raccourci efficace pour identifier rapidement si un binaire mal configuré permet une escalade. Sur la phase de post-exploitation, j'ai déjà utilisé Mimikatz et BloodHound pour cartographier des environnements compromis, mais c'est plus rare que la phase exploitation directe.
Récemment, j'ai eu à reproduire et démontrer l'exploitation de la faille CopyFail dans un cadre de validation et de pédagogie technique. Je n'ai pas développé l'exploit moi-même, mais le rejouer en conditions contrôlées m'a permis d'en comprendre finement le mécanisme et d'expliquer ses implications à des équipes non spécialistes.
Produire un livrable exploitable, pas une démonstration technique
La phase de restitution est la plus déterminante pour la valeur du livrable, et c'est sans doute là que se joue la différence entre un bon et un mauvais auditeur. Trouver des failles n'est qu'une étape : il faut les expliquer clairement à un public dont le niveau technique varie, les prioriser intelligemment via la grille CVSS définie au cadrage, et proposer des correctifs réalistes et adaptés au contexte.
Mes rapports d'audit suivent une structure stable : un executive summary pour les décideurs, un inventaire détaillé des vulnérabilités identifiées avec leur score CVSS, une explication pédagogique de chaque faille trouvée (qu'est-ce que c'est, comment elle a été identifiée, quel est son impact concret), et surtout une section recommandations précise et actionnable. Pour chaque vulnérabilité, je propose une remédiation détaillée et applicable rapidement par les équipes IT du client.
Sur l'audit WordPress aux Mousquetaires, j'ai ainsi produit en parallèle du rapport une documentation interne sur "comment auditer un WordPress" qui sert encore aujourd'hui de référence pour les missions similaires. Transformer un audit ponctuel en référence méthodologique réutilisable est probablement la forme la plus aboutie de valeur ajoutée qu'un junior puisse apporter.
Valider que les recommandations ont été appliquées correctement
Une recommandation appliquée à moitié ou mal interprétée peut donner une fausse sensation de sécurité pire que l'absence de correctif. Quand le contexte de la mission le permet, j'inclus donc une phase de vérification des correctifs appliqués par le client. Concrètement, je reproduis les attaques qui avaient réussi pour vérifier qu'elles échouent désormais, et je teste également les vecteurs adjacents pour m'assurer que la correction n'a pas été contournable d'une autre façon.
Cette phase n'est pas toujours possible (selon le budget client, le périmètre contractuel, le délai), mais quand elle l'est, elle apporte au client une assurance qu'aucun rapport seul ne peut donner.
Ma boîte à outils
Outils utilisés en mission, par catégorie : reconnaissance, exploitation, post-exploitation et environnement de travail.
Organisation et acteurs
En cadre professionnel, j'interviens en coordination étroite avec les équipes internes du client ou de l'organisation : les responsables du système d'information pour la définition du scope et la validation des autorisations, les équipes techniques pour la restitution des résultats et la planification des correctifs, et parfois les équipes métiers pour comprendre les usages réels des applications auditées. Ces interactions sont structurantes : un audit isolé de ses bénéficiaires n'a aucune valeur durable.
En cadre personnel (CTF, bug bounty), je travaille seul. Je m'appuie sur les communautés en ligne pour confronter mes raisonnements et sur les échanges réguliers avec ma communauté de pentesters sur Keybase pour partager des techniques, discuter de méthodologies et débloquer des problèmes. Cette communauté est probablement le meilleur accélérateur d'apprentissage que j'ai eu sur le volet offensif, car elle confronte la pratique théorique des challenges à la réalité du terrain de profils plus expérimentés.
Résultats
En entreprise, les audits que j'ai menés ont permis d'identifier des vulnérabilités concrètes et d'apporter des recommandations exploitables, avec une priorisation claire basée sur les scores CVSS. Certaines failles identifiées ont conduit à des corrections immédiates sur des services exposés. La documentation WordPress produite chez Les Mousquetaires sert toujours de référence pour les audits similaires, ce qui est probablement le résultat le plus durable d'une mission de quelques semaines.
Sur les CTF et le bug bounty, les résultats sont avant tout personnels. Mon parcours Root-Me actuel (place 7168, 1890 points, 115 challenges) reflète une pratique soutenue, mais les chiffres sont moins importants que la progression dans la compréhension des vecteurs d'attaque, la meilleure lecture des environnements cibles, et la capacité d'analyse qui s'affine à chaque challenge. Sur le bug bounty, j'ai identifié 4 à 5 XSS côté client (DOM-based) sur différentes plateformes, mais aucune n'a donné lieu à rémunération car cette catégorie est explicitement exclue par la majorité des programmes que j'ai pratiqués (YesWeHack, Bugcrowd). J'ai néanmoins rédigé un rapport complet sur l'une d'entre elles pour me constituer un template réutilisable, et ne pas reporter ces XSS est devenu chez moi un automatisme par manque de retour sur investissement.
Lendemains du projet
Chaque audit a alimenté directement mes compétences en administration réseau et en configuration système, en me forçant à comprendre les failles de l'intérieur. La documentation WordPress produite chez Les Mousquetaires a immédiatement servi de référence pour les missions similaires qui ont suivi, ce qui prouve que les retours d'expérience écrits ont une vraie utilité opérationnelle au-delà du livrable initial. Sur les CTF, chaque challenge résolu vient enrichir mes notes Obsidian structurées pour pouvoir réutiliser les techniques apprises sur des contextes équivalents plus tard.
Ces expériences ont profondément structuré ma façon d'aborder n'importe quel projet technique. Je pense désormais naturellement à la sécurité dès la conception, pas après coup, parce que j'ai passé du temps à exploiter des infrastructures où elle avait été pensée en dernier. C'est exactement ce principe qui a structuré le déploiement de l'infrastructure Valesys et qui me sert quotidiennement dans la définition des règles firewall chez Paritel.
Chez Paritel, je continue à pratiquer l'audit dans une logique plus défensive : analyse des remontées de CrowdStrike, des sondes IDS, et investigation des anomalies signalées. Les scans réguliers d'Active Directory avec PingCastle, BloodHound et Purple Knight m'apportent une continuité de pratique sur des outils dédiés à cet écosystème. La compétence offensive devient ici un complément direct à mon approche défensive, et les deux se renforcent mutuellement.
À horizon post-études (juillet 2026), je prévois plusieurs axes de développement. Reprendre activement les CTF en reconstituant une équipe pour bénéficier de la dynamique collective. Reprendre le bug bounty avec un objectif clair : trouver et reporter des vulnérabilités hors de la catégorie XSS DOM, sur des classes mieux rémunérées. À plus long terme, viser une certification offensive de référence comme OSCP (Offensive Security Certified Professional) ou PNPT (Practical Network Penetration Tester), qui valideraient formellement la compétence et apporteraient une crédibilité supplémentaire dans des contextes professionnels où ces certifications sont attendues.
Regard critique
Mes apports concrets sur les missions d'audit sont triples. D'abord la capacité à expliquer clairement à un public dont le niveau technique varie : trouver une faille technique sophistiquée mais ne pas savoir l'expliquer à un dirigeant rend l'audit inutile. Ensuite la priorisation intelligente via la grille CVSS, qui transforme une liste brute de vulnérabilités en feuille de route corrective réaliste. Enfin la proposition de correctifs adaptés au contexte : "appliquez le dernier patch" n'est pas une recommandation, "désactivez tel module et restreignez l'accès à telle interface en attendant la migration vers la version N+1" en est une.
Ma valeur ajoutée mesurable est de faire passer un audit du statut d'exercice technique à celui de livrable exploitable par les équipes IT. La documentation WordPress produite chez Les Mousquetaires est l'exemple le plus clair : un audit ponctuel a généré une référence méthodologique durable, qui survit à la mission elle-même et apporte de la valeur sur les audits suivants. C'est cette transformation du ponctuel en pérenne qui distingue un auditeur efficace d'un simple exécutant.
Mes enseignements personnels sont profonds. Le plus marquant est la récurrence des mêmes erreurs d'un environnement à l'autre : mots de passe par défaut jamais changés, mises à jour non appliquées sur des CVE pourtant publiques depuis des mois, services exposés sans nécessité fonctionnelle, certificats expirés. Ces problèmes sont simples, connus, documentés, et pourtant omniprésents. Cela m'a convaincu que la sécurité n'est pas qu'une question de compétence technique : c'est aussi et surtout une question de rigueur opérationnelle et de culture organisationnelle. Le second enseignement, plus personnel, est la conviction profonde que l'attaque sert la défense : on conçoit objectivement mieux quand on a vu de l'intérieur comment ça casse.
Avec le recul, je vois aussi les limites de mon expérience actuelle. Les XSS côté client trouvées en bug bounty ne sont pas reportées par défaut faute de retour sur investissement, ce qui veut dire que je ne contribue pas à la sécurité de ces plateformes. C'est un compromis assumé mais discutable éthiquement, et que je veux corriger en m'orientant vers des vulnérabilités mieux rémunérées plutôt qu'en abandonnant cette pratique. Par ailleurs, ma pratique offensive reste celle d'un junior, sans certification de référence à ce jour. C'est exactement la raison pour laquelle je vise OSCP ou PNPT à moyen terme, pour ancrer cette pratique dans une validation externe formelle.
Compétences rattachées
Cette réalisation mobilise une combinaison de compétences techniques et humaines. Sur le volet technique, elle illustre l'Administration Réseau par la maîtrise des protocoles et des architectures attaquées, la Configuration Système par la compréhension fine des systèmes audités et le Tooling & Scripting par l'usage et l'enchaînement de nombreux outils. Sur le volet humain, elle met en avant l'Esprit d'analyse indispensable pour décomposer un environnement complexe et l'Autonomie nécessaire pour mener des CTF et investigations offensives sans encadrement.