Atelier : scénario de bout en bout

Le scénario : Norvinia Industries

Les onze chapitres précédents ont traité chaque brique séparément : cartographie, énumération, Kerberos, mouvement latéral, escalade, BloodHound, persistance, détection, rapport. Sur une mission réelle, ces briques ne s'exécutent jamais en silo — elles s'enchaînent, chacune ouvrant la porte à la suivante, et c'est cet enchaînement qui constitue le véritable objet du pentest. Ce chapitre reconstitue une mission fictive de bout en bout, sur un client composite construit à partir de schémas récurrents observés en environnement PME et ETI françaises : Norvinia Industries, groupe industriel de 600 salariés, domaine corp.norvinia.local, deux contrôleurs de domaine (DC01, DC02) et un parc hétérogène accumulé sur quinze ans de croissance par acquisitions.

L'objectif n'est pas d'introduire de nouvelles techniques, mais de montrer comment les relier dans un récit cohérent — celui qui, au final, constitue la colonne vertébrale du rapport. Chaque étape ci-dessous renvoie explicitement à la technique détaillée dans le chapitre correspondant du parcours.

Mandat écrit signé par la DSI de Norvinia Industries, scope limité au domaine corp.norvinia.local et à ses ressources associées, fenêtre de test d'une semaine, méthode en boîte grise différée : démarrage en boîte noire (aucun identifiant fourni), avec bascule en boîte grise si aucun point d'entrée n'est trouvé après deux jours. Interdiction contractuelle de toute action destructive (pas de ransomware simulé, pas de modification GPO en production) et obligation de neutraliser toute persistance créée avant la fin de mission. Ce cadre, posé dès le chapitre d'introduction du parcours, conditionne chaque décision technique qui suit.

Étape 1 — Reconnaissance et OSINT

La mission démarre sans identifiant, comme le ferait un attaquant externe. La reconnaissance passive identifie le nom de domaine public norvinia.fr, un portail Exchange exposé en OWA, et surtout une convention de nommage des comptes déduite de plusieurs adresses e-mail publiées sur le site institutionnel et sur LinkedIn : prenom.nom@norvinia.fr, très probablement identique au format de logon interne. Cette information, anodine en apparence, sert plus tard de base à la construction de listes de comptes candidats pour les phases d'énumération.

Un accès physique n'étant pas dans le scope, l'équipe obtient un point d'entrée réseau via un poste de test fourni par le client, branché sur le VLANVLANRéseauxRéseau local virtuel qui segmente logiquement un LAN Ethernet sans exiger un câblage physique séparé.Voir dans le glossaire utilisateur standard — configuration représentative d'un attaquant ayant compromis un poste par phishing, scénario jugé plus réaliste par la DSI qu'un test purement externe face à un pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire correctement configuré.

Étape 2 — Énumération LDAP et SMB

Depuis ce point d'entrée réseau, l'énumération commence par une session anonyme LDAP contre DC01 : refusée, signe d'un durcissement correct. En revanche, une énumération SMB des partages accessibles sans authentification révèle un partage NETLOGON en lecture pour le groupe Domain Users, accessible dès qu'un identifiant de domaine à privilèges minimaux est disponible. Faute d'identifiant, l'équipe teste d'abord le kerberoasting anonyme et l'AS-REP roasting sur la liste de comptes candidats déduite de l'OSINT — sans succès, aucun compte pré-authentification désactivé n'est trouvé.

C'est en explorant plus largement l'infrastructure réseau accessible depuis le VLAN utilisateur qu'un partage applicatif mal isolé, hors du périmètre AD strict mais dans le scope réseau autorisé, expose une archive de scripts de déploiement historiques — vestige d'une migration Windows Server datant de plusieurs années.

Étape 3 — Le point d'entrée : une préférence de stratégie de groupe oubliée

Dans cette archive, un script .xml de préférence de stratégie de groupe (GPP) contient un attribut cpassword — un mot de passe local chiffré selon le schéma AES statique documenté par Microsoft depuis la divulgation de la clé en 2012, et jamais purgé malgré le correctif MS14-025 appliqué depuis sur les GPO actives. Le déchiffrement (gpp-decrypt ou équivalent) restitue un mot de passe en clair — celui d'un compte de domaine à faible privilège, s.durand, réutilisé lors d'une campagne de déploiement de postes plusieurs années auparavant et jamais changé depuis.

MS14-025 empêche la création de nouvelles préférences GPP contenant un cpassword, mais ne supprime pas les fichiers déjà déposés sur SYSVOL ni les copies archivées ailleurs sur le réseau. Norvinia avait appliqué le correctif sur ses GPO actives des trois dernières années — sans jamais auditer les archives de scripts plus anciennes, ni faire tourner le compte de service concerné. Un correctif technique sans purge des artefacts historiques laisse une porte ouverte identique à celle qu'il était censé fermer.

Ce compte s.durand donne un premier accès authentifié au domaine — modeste, sans privilège particulier, mais suffisant pour relancer l'énumération LDAP en mode authentifié et obtenir une vue complète des utilisateurs, groupes et objets de service. C'est le pivot classique entre reconnaissance et exploitation active décrit au chapitre 2.

Étape 4 — Kerberoasting : le premier compte à privilèges

Une fois authentifié, une requête LDAP filtrée sur servicePrincipalName renvoie une douzaine de comptes de service, dont svc-sql, associé à une instance SQL Server de production. Une demande de ticket de service pour ce compte, suivie d'une extraction du ticket chiffré avec la clé dérivée du mot de passe du compte, permet une attaque hors ligne classique : le mot de passe de svc-sql, Norvinia2019!, cède en moins de dix minutes face à une liste de mots enrichie du nom de l'entreprise et de l'année de création du compte — un schéma de mot de passe prévisible, typique des comptes de service créés lors d'un déploiement applicatif et jamais intégrés à une politique de rotation.

Reconstituer un chemin d'attaque de mémoire, une fois la mission terminée, est une source d'erreurs et d'oublis. Chaque commande, chaque horodatage et chaque résultat doivent être consignés au fil de l'eau — c'est ce journal qui alimente directement le standard de preuve attendu dans le rapport final, détaillé au chapitre 10.

svc-sql dispose de droits d'administration locale sur le serveur SRV-FILE01, dont il assurait historiquement la maintenance applicative — droit hérité d'un projet clos, jamais retiré. C'est le maillon suivant de la chaîne.

Étape 5 — Mouvement latéral vers le pivot serveur

Avec le hash NT de svc-sql récupéré via le cassage du ticket, une authentification pass-the-hash contre SRV-FILE01 réussit sans avoir besoin du mot de passe en clair. Ce serveur, contrairement au poste utilisateur initial, dispose d'une visibilité réseau plus large et héberge des sessions ouvertes d'administrateurs applicatifs — conditions idéales pour une collecte BloodHound complète, bien plus riche que ce qu'un simple poste utilisateur aurait permis de voir.

Étape 6 — Cartographier le chemin vers Domain Admins avec BloodHound

L'ingestion SharpHound depuis SRV-FILE01, avec le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire du compte svc-sql, collecte les ACL, les appartenances de groupes imbriquées et les sessions actives sur l'ensemble du domaine visible. L'analyse du graphe révèle un chemin en trois sauts, invisible à l'inspection manuelle des groupes AD standard : le compte s.durand (celui obtenu à l'étape 3) est membre du groupe GRP-Helpdesk-EU, lui-même titulaire d'un droit GenericAll sur le groupe GRP-SRV-Admins — hérité d'un ticket de support ancien jamais révoqué — et GRP-SRV-Admins est membre imbriqué du groupe Domain Admins.

Ce chemin illustre un constat récurrent traité au chapitre 7 : aucune de ces trois relations n'est, prise isolément, une vulnérabilité au sens classique. C'est leur composition qui transforme un compte de support de premier niveau en chemin direct vers l'administration du domaine.

Étape 7 — Exploiter l'abus d'ACL

L'exploitation consiste simplement à utiliser le droit GenericAll détenu par GRP-Helpdesk-EU — via l'appartenance de s.durand — pour s'ajouter soi-même au groupe GRP-SRV-Admins. Aucune technique offensive sophistiquée n'est nécessaire ici : une simple modification d'attribut LDAP, rendue possible par une délégation de droits mal cloisonnée, suffit à franchir le dernier saut vers l'appartenance effective à Domain Admins, après réplication du groupe.

Rejoindre effectivement le groupe Domain Admins, même à des fins de démonstration, modifie l'état réel du domaine du client — ce n'est pas anodin en dehors d'un scope explicitement validé. Sur cette mission, la modification a été appliquée en présence d'un correspondant technique du client, documentée avec horodatage exact, puis annulée dans l'heure suivant la démonstration. Toute action de ce type doit être réversible, tracée, et limitée strictement à ce qui prouve l'exploitabilité — jamais laissée en l'état au-delà de la fenêtre de preuve.

Étape 8 — Preuve finale et question de la persistance

Pour établir la preuve définitive de compromission complète du domaine sans laisser de porte dérobée, l'équipe réalise une attaque DCSync ciblée : une seule requête de réplication portant sur le hash NT du compte krbtgt, suffisante pour démontrer la capacité à forger des tickets Kerberos falsifiés, sans jamais le faire réellement. Le chapitre 8 du parcours détaille pourquoi la persistance — golden ticket, DSRM, skeleton key — n'a volontairement pas été mise en œuvre ici au-delà de cette preuve technique : le mandat interdit toute modification durable de l'infrastructure d'authentification, et la valeur démonstrative d'un golden ticket réellement forgé n'ajoute rien à celle d'une requête DCSync documentée.

La requête DCSync a généré l'Event ID 4662 attendu sur DC01, mais aucune alerte n'a été levée : la règle de détection existante ciblait uniquement les comptes hors du groupe Domain Admins, alors que la démonstration a précisément été menée depuis un compte fraîchement ajouté à ce groupe. Le kerberoasting de svc-sql, en revanche, a bien déclenché une alerte SIEM sur volume anormal de demandes de tickets de service — mais transmise en notification différée, non traitée avant la fin de la fenêtre de test. Ces deux constats, détaillés au chapitre 9, nourrissent directement les recommandations de détection du rapport final.

Des findings au rapport : synthèse et priorisation

En appliquant la méthode du chapitre 10, les cinq findings majeurs de la mission se cotent ainsi :

Le finding critique — le chemin ACL vers Domain Admins — devient le fil conducteur du rapport, exactement comme recommandé au chapitre 10 : les autres findings sont présentés comme les maillons qui permettent d'atteindre ce chemin, plutôt que comme une liste plate sans hiérarchie. Trois quick wins immédiats en découlent : purger les archives de scripts contenant des cpassword, retirer le droit GenericAll orphelin de GRP-Helpdesk-EU, et faire tourner le mot de passe de svc-sql. Le chantier structurel qui suit — révision complète des délégations et mise en place d'un tiering d'administration — occupe la fenêtre J+90, avec un re-test ciblé sur le chemin ACL démontré, seul moyen pour Norvinia de vérifier que la remédiation a effectivement neutralisé ce chemin plutôt que déplacé le problème.

Ce qu'il faut retenir de cet atelier

Aucune étape de ce scénario, prise isolément, n'est spectaculaire : un script oublié, un mot de passe de service prévisible, une délégation support jamais révoquée. C'est leur enchaînement, sans rupture entre la reconnaissance et la compromission complète du domaine, qui constitue la véritable leçon de ce parcours. Un pentester efficace n'est pas celui qui maîtrise la technique la plus sophistiquée, mais celui qui sait relier des faiblesses individuellement mineures en un chemin d'attaque cohérent — et qui sait ensuite traduire ce chemin en un rapport qui donne au client les moyens concrets de le couper. C'est cette double compétence, offensive et rédactionnelle, que ce parcours a cherché à construire chapitre après chapitre.