TP — Audit AD & mise en conformité (PingCastle)

2h30 Acte 3 · Audit Avancé Purple · AD · Conformité ANSSI · PingCastle

Auteur : Thibaut Fontaine — Kodetis Institution : Université de la Réunion Date : 2026 Position dans le parcours : Acte 3 (Audit & Purple Team) — miroir « identité » du TP conformité Linux.

---

Table des matières

• Objectifs et contexte
• Prérequis
• Phase 1 — Audit initial (posture « avant »)
• Phase 2 — Corrélation avec la kill chain
• Phase 3 — Remédiation (conformité ANSSI)
• Phase 4 — Ré-audit (posture « après »)
• Bonus — BloodHound (Purple complet)
• Livrables & validation
• Questions de validation
• Annexe enseignant — corrigé

---

1. Objectifs et contexte

📡 Poste SOC · La Réunion — Acte 3, Prouver : vous auditez le hub d’identité après l’incident. Poste avancé : Dumont d’Urville (Terre Adélie), ~6 000 km, SATCOM dégradée.

🎯 Objectif métier — mesurer la posture de sécurité de l’AD, la corriger, et prouver l’amélioration avec un score avant/après.

L’AD TAAF-AD-001 est désormais le hub d’identité des TAAF (il protège NextCloud via SSO — cf. TP SSO). C’est aussi l’axe que l’attaquant a pivoté au jour J (svc_backup ajouté à Domain Admins à 09:45Z). On va l’auditer comme un RSSI le ferait.

Objectifs pédagogiques

• Auditer l’AD avec PingCastle Health Check (score + règles priorisées).
• Corréler chaque finding à une étape de la kill chain reconstituée au Module 1 (LotL).
• Remédier selon les recommandations ANSSI (tiering, retrait DA, LAPS, LDAPS).
• Prouver : ré-auditer et démontrer la baisse du score (posture avant → après).
• (Bonus) Compléter par BloodHound pour visualiser les chemins d’attaque.

🔴 Au fil de l’enquête

PingCastle aurait flaggé la faiblesse exploitée à 09:45Z (compte de service en Domain Admins, délégation Kerberos). L’audit valide le chemin d’attaque — c’est le cœur de la démarche Purple : Red exploite → Blue détecte → l’audit prouve et durcit. Aujourd’hui, vous jouez le rôle de l’auditeur post-incident.

Architecture du TP

graph LR
 subgraph "Avant"
 AD1[(AD TAAF
vulnérable)]
 PC1[PingCastle scan]
 SCORE1[Score initial
~70-80/100]
 end

 subgraph "Corrélation"
 CHAIN[Kill chain Module 1]
 MAP[Mapping findings ↔ étapes]
 end

 subgraph "Remédiation ANSSI"
 R1[Retrait svc_backup
de Domain Admins]
 R2[LAPS]
 R3[Délégation contrainte]
 R4[LDAP signing
+ LDAPS]
 R5[Tiering Tier 0/1/2]
 end

 subgraph "Après"
 AD2[(AD TAAF
durci)]
 PC2[PingCastle re-scan]
 SCORE2[Score final
~25-40/100]
 end

 AD1 --> PC1
 PC1 --> SCORE1
 SCORE1 --> MAP
 CHAIN --> MAP
 MAP --> R1
 MAP --> R2
 MAP --> R3
 MAP --> R4
 MAP --> R5
 R1 --> AD2
 R2 --> AD2
 R3 --> AD2
 R4 --> AD2
 R5 --> AD2
 AD2 --> PC2
 PC2 --> SCORE2

 classDef bad fill:#ff9999,stroke:#333,stroke-width:2px
 classDef good fill:#99ff99,stroke:#333,stroke-width:2px
 classDef neutral fill:#ffcc99,stroke:#333,stroke-width:2px

 class AD1,SCORE1 bad
 class AD2,SCORE2 good
 class CHAIN,MAP,R1,R2,R3,R4,R5 neutral

---

2. Prérequis

Côté Windows (poste audit)

Vous avez besoin d’une machine membre du domaine univ-taaf.internal (typiquement TAAF-W-PAF07 du lab, ou la VM audit jointe au domaine).

# Vérifier l'appartenance au domaine
(Get-WmiObject Win32_ComputerSystem).Domain
# → univ-taaf.internal

Télécharger PingCastle

# Sur la machine d'audit
mkdir C:\Tools\PingCastle ; cd C:\Tools\PingCastle
Invoke-WebRequest -Uri "https://github.com/vletoux/pingcastle/releases/download/3.3.0.1/PingCastle.zip" `
  -OutFile PingCastle.zip
Expand-Archive PingCastle.zip -DestinationPath . -Force
.\PingCastle.exe --version
# → PingCastle 3.3.0.1

État AD volontairement vulnérable au départ

Pour que le score initial soit « parlant » et reproductible, l’AD de TP démarre avec des faiblesses intentionnelles (provisionnées par script) :

• svc_backup membre de Domain Admins
• Délégation Kerberos non contrainte sur TAAF-FS-001
• 3 comptes obsolètes activés (old_admin, tmp_user1, tmp_user2)
• Politique de mot de passe par défaut (8 caractères, pas d’expiration)
• LDAP signing non requis, LDAPS pas configuré
• AdminCount=1 hérité sur des objets inactifs

---

3. Phase 1 — Audit initial (posture « avant »)

3.1 — Lancer PingCastle Health Check

Depuis une machine membre du domaine :

cd C:\Tools\PingCastle
.\PingCastle.exe --healthcheck --server univ-taaf.internal

Sortie attendue (extrait console) :

PingCastle (Version 3.3.0.1)
Connecting to univ-taaf.internal as <current user>...
Domain Functional Level: 2016
Forest Functional Level: 2016
Domain SID: S-1-5-21-1234567890-...

Performing checks... Done.
Generating reports... Done.

Report saved to: ad_hc_univ-taaf.internal.html
Report saved to: ad_hc_univ-taaf.internal.xml

Global Score: 75/100
- Stale Objects: 30
- Privileged Accounts: 50
- Trusts: 0
- Anomalies: 40

→ Score global initial attendu : 70-80/100 (plus c’est haut, plus c’est mauvais — barème inversé de PingCastle).

📸 Capture obligatoire #1 : page d’accueil du rapport HTML avec le radar 4-catégories visible.

3.2 — Lire le rapport HTML

Ouvrez ad_hc_univ-taaf.internal.html dans un navigateur.

Sections clés à examiner :

Section	Ce que vous y trouvez
Risk model (radar)	Vue 4-catégories Stale/Privileged/Trusts/Anomalies
Rules matched	Liste des règles déclenchées triées par points
Privileged Accounts → admin compromise	Liste des chemins d’accès au DA
Active Directory information	Inventaire des comptes, GPO, OU
Domain stale	Comptes obsolètes, mots de passe non rotés

3.3 — Top 5 findings à corréler

Identifiez les 5 règles avec le plus de points (risque le plus élevé). Tableau attendu :

Rang	Règle PingCastle	Points	Catégorie
1	S-PrivilegeEveryone — svc_backup dans Domain Admins	50	Privileged Accounts
2	S-UnconstrainedDelegation — délégation non contrainte sur TAAF-FS-001	25	Privileged Accounts
3	A-LDAPSigningDisabled — LDAP signing non requis	20	Anomalies
4	P-Inactive — 3 comptes obsolètes activés	15	Stale Objects
5	S-AdminPwdLAPS — LAPS non déployé	15	Privileged Accounts

Livrable : score initial + tableau top 5 priorisé.

---

4. Phase 2 — Corrélation avec la kill chain

Relier chaque finding PingCastle à une étape de la kill chain du Module 1 LotL :

Finding PingCastle	Étape kill chain (jour J)	EventID	ATT&CK
Compte de service dans Domain Admins	09:45Z — svc_backup → DA par e.bernard	4728	T1098 / T1078.002
Délégation Kerberos non contrainte (TAAF-FS-001)	Mouvement latéral 10:05Z WMI vers FS-001	4624	T1550 / T1187
LDAP signing non requis	(latent — pas exploité jour J mais ouvre MitM creds)	—	T1557.002
Comptes obsolètes activés	Réutilisation possible (non observée jour J)	—	T1078
LAPS non déployé	Pivot inter-postes via password reuse local admin	—	T1078.003
AdminCount=1 hérité	Comptes ex-admin gardent des permissions	—	T1078.002

Lecture critique : 3 findings sur 5 ont été directement exploités au jour J. Les 2 autres sont des opportunités latentes — l’attaquant aurait pu les utiliser s’il avait été plus persévérant.

Livrable : tableau de corrélation + paragraphe « comment cet AD a rendu l’attaque possible ».

---

5. Phase 3 — Remédiation (conformité ANSSI)

Avant tout durcissement

1. Vérifier qu’un compte break-glass AD existe et fonctionne (sinon risque de lockout en cas de mauvaise config).
2. Faire un snapshot du DC TAAF-AD-001 (Vagrant ou snapshot Hyper-V/QEMU).
3. Documenter chaque action avant de l’appliquer.

5.1 — Retrait des comptes de service de Domain Admins (Reco ANSSI R1)

# Vérifier les membres actuels
Get-ADGroupMember -Identity "Domain Admins" | Select-Object Name, SamAccountName, objectClass

# Retirer svc_backup
Remove-ADGroupMember -Identity "Domain Admins" -Members "svc_backup" -Confirm:$false

# Lui créer un groupe dédié avec uniquement les permissions Backup nécessaires
New-ADGroup -Name "G-TAAF-BackupOps" -GroupScope Global -GroupCategory Security `
  -Path "OU=TAAF-Groups,DC=univ-taaf,DC=internal"
Add-ADGroupMember -Identity "G-TAAF-BackupOps" -Members "svc_backup"

# Déléguer uniquement le droit Backup Files & Restore Files via GPO (à faire dans GPMC)

5.2 — Délégation Kerberos contrainte (Reco ANSSI R3)

# Voir les comptes en délégation non contrainte
Get-ADComputer -Filter {TrustedForDelegation -eq $true} | Select Name, DistinguishedName

# Retirer la délégation non contrainte sur TAAF-FS-001
Set-ADComputer -Identity "TAAF-FS-001" -TrustedForDelegation $false

# Si une délégation est vraiment nécessaire, la passer en CONTRAINTE
# Set-ADComputer TAAF-FS-001 -PrincipalsAllowedToDelegateToAccount svc_backup

5.3 — LAPS (Local Administrator Password Solution)

Déployez Windows LAPS (intégré depuis Windows Server 2019) :

# Activer Windows LAPS
Install-WindowsFeature LAPS -IncludeManagementTools

# Configurer la GPO LAPS (via GPMC)
# → Computer Configuration → Policies → Admin Templates → System → LAPS
# → "Enable local admin password management" = Enabled
# → "Password complexity" = upper + lower + digits + specials, length 14
# → "Password expiration time" = 30 days

# Vérifier la prise en compte
gpupdate /force
Get-LapsADPassword -Identity "TAAF-W-PAF07"
# → mot de passe unique 14 chars

5.4 — LDAP signing + LDAPS (Reco ANSSI R5)

# Forcer LDAP signing côté DC
# Via GPO : Default Domain Controllers Policy → Computer Config → Policies → Windows Settings →
# Security Settings → Local Policies → Security Options
# → "Domain controller: LDAP server signing requirements" = "Require signing"

# Activer LDAPS (port 636) — nécessite un certificat
# 1. Demander un cert au CA TAAF (ou auto-signé pour le lab)
$cert = New-SelfSignedCertificate -DnsName "TAAF-AD-001.univ-taaf.internal" `
  -CertStoreLocation "Cert:\LocalMachine\My" `
  -KeyUsage DigitalSignature, KeyEncipherment `
  -EnhancedKeyUsage "Server Authentication"

# 2. Restart Active Directory Domain Services service
Restart-Service NTDS

# Tester depuis un client
Test-NetConnection TAAF-AD-001.univ-taaf.internal -Port 636

→ Revenez dans le TP SSO et mettez à jour le bind NextCloud → AD pour utiliser ldaps:// au lieu de ldap://. C’est la boucle « raccourci de l’Acte 2 corrigé à l’Acte 3 » annoncée.

5.5 — Désactivation des comptes obsolètes

# Lister les comptes inactifs > 90 jours
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly |
  Select Name, SamAccountName, LastLogonDate

# Les désactiver (pas supprimer — au cas où)
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly |
  Set-ADUser -Enabled $false

5.6 — Amorce de tiering (Tier 0 / Tier 1 / Tier 2)

Modèle simplifié pour le lab (1 DC) :

Tier	Périmètre	Comptes	Exemple
0	DC, AD CS, AD FS	Admins DC (tier0_admin) — login uniquement sur DC	Domain Admins
1	Serveurs métier (PostgreSQL, NextCloud, file servers)	Admins serveurs (tier1_admin) — login uniquement sur serveurs	G-TAAF-ServerAdmins
2	Postes utilisateurs	Helpdesk (tier2_admin) — login uniquement sur postes	G-TAAF-Helpdesk

# Créer les groupes
New-ADGroup -Name "G-TAAF-Tier0-Admins" -GroupScope Global -GroupCategory Security `
  -Path "OU=TAAF-Tier0,DC=univ-taaf,DC=internal"
New-ADGroup -Name "G-TAAF-Tier1-Admins" -GroupScope Global -GroupCategory Security `
  -Path "OU=TAAF-Tier1,DC=univ-taaf,DC=internal"

# GPO "Deny Logon Locally" pour Tier 0 sur les machines Tier 1/2
# → un Tier 0 admin ne peut pas ouvrir de session sur un poste user

Tiering dans un lab 1 DC

Le tiering complet (3 tiers physiquement séparés) demande au moins 3 DC et plusieurs OUs séparées par GPO. Dans ce lab, on amorce le tiering au niveau des groupes et des GPO — la séparation physique est conceptuelle. À mentionner dans le rapport : « tiering partiellement appliqué, limites du lab ».

Livrable : journal de remédiation avec une entrée par action :

Action	Justification (kill chain)	Preuve d’application
Retrait svc_backup de DA	Empêche réplication du 4728 jour J	Capture Get-ADGroupMember "Domain Admins"
Délégation contrainte TAAF-FS-001	Coupe le pivot WMI 10:05Z	Capture Get-ADComputer -Filter {TrustedForDelegation -eq $true} vide
…	…	…

---

6. Phase 4 — Ré-audit (posture « après »)

6.1 — Relancer le scan

cd C:\Tools\PingCastle
.\PingCastle.exe --healthcheck --server univ-taaf.internal
# → nouveau rapport ad_hc_univ-taaf.internal.html (écrase l'ancien)

Sortie attendue :

Global Score: 30/100   (avant : 75/100, delta = -45)
- Stale Objects: 10    (avant : 30)
- Privileged Accounts: 15  (avant : 50)
- Trusts: 0            (avant : 0)
- Anomalies: 20        (avant : 40)

📸 Capture obligatoire #2 : radar du rapport HTML avant/après côte à côte.

6.2 — Analyse des findings résiduels

Findings qui restent typiquement après remédiation lab (à documenter) :

Finding résiduel	Pourquoi non corrigé	Plan
Score Anomalies 20 (vs 0 idéal)	Anciens objets AD résiduels, kerberoasting AS-REP roastable	Audit profond hors lab
Score Stale Objects 10	Cleanup historique des objets supprimés	Rotation périodique
Tiering partiel	Lab à 1 DC, séparation physique impossible	À faire en prod multi-DC

→ Le rapport doit montrer ces limites en transparence. PingCastle n’est pas un score à atteindre à zéro — c’est un guide de priorisation.

Livrable : capture comparée + commentaire des findings résiduels.

---

7. Bonus — BloodHound (Purple complet)

PingCastle donne la posture (vue Blue). BloodHound donne le chemin d’attaque (vue Red). Les deux = Purple.

7.1 — Collecter avec SharpHound

# Sur la machine d'audit (membre du domaine)
Invoke-WebRequest "https://github.com/BloodHoundAD/SharpHound/releases/download/v2.5.7/SharpHound-v2.5.7.zip" `
  -OutFile sh.zip
Expand-Archive sh.zip ; cd SharpHound-v2.5.7

# Collecte
.\SharpHound.exe -c All --zipfilename "taaf-ad-before-remediation.zip"

7.2 — Importer dans BloodHound CE

# Sur la VM audit (Linux)
docker run -d --name bloodhound \
  -p 8080:8080 \
  -e bhe_disable_cypher_complexity_limit=true \
  ghcr.io/specterops/bloodhound:latest

# Accès : http://IP_AUDIT:8080
# Importer le ZIP via l'UI → Explore

7.3 — Identifier le chemin jour J

Dans BloodHound → Pre-built queries → Find shortest paths to Domain Admins from user.

Sélectionnez e.bernard@univ-taaf.internal.

Résultat attendu (avant remédiation) :

e.bernard → MemberOf → G-TAAF-Biologie → ??? → svc_backup → MemberOf → Domain Admins

📸 Capture obligatoire #3 : le graphe BloodHound avec le chemin coloré.

7.4 — Re-collecter et démontrer la coupure

# Après remédiation
.\SharpHound.exe -c All --zipfilename "taaf-ad-after-remediation.zip"

Importer dans BloodHound. Relancez la même query : le chemin doit avoir disparu — svc_backup n’est plus DA, donc plus de route vers Domain Admins depuis e.bernard.

📸 Capture obligatoire #4 : query qui renvoie « no path found ».

Livrable bonus : 2 captures BloodHound avant/après + commentaire « ce qui était possible, ce qui ne l’est plus ».

---

8. Livrables & validation

Livrables

1. Rapport PingCastle initial (HTML/PDF) — score + radar.
2. Tableau top 5 findings priorisés.
3. Tableau de corrélation findings ↔ kill chain Module 1.
4. Journal de remédiation (action / justification / preuve).
5. Scripts PowerShell de remédiation versionnés dans un repo taaf-ad-hardening.
6. Rapport PingCastle final (delta de score).
7. Paragraphe d’analyse résiduel (~ 1/2 page).
8. (Bonus) Captures BloodHound avant/après.

Grille de validation

Critère	Pondération
Audit initial lancé et rapport HTML lu	10 %
Top 5 findings priorisés et justifiés	15 %
Corrélation findings ↔ kill chain (≥ 4 lignes)	20 %
Remédiations appliquées (≥ 4 actions de la phase 3)	30 %
Re-scan avec delta de score documenté	15 %
Analyse des findings résiduels	10 %
(Bonus) BloodHound avant/après	+10 % bonus

Format de rendu : PDF nom-prenom-promo.pdf sur Moodle.

---

9. Questions de validation

1. [Facile] Quel est le score initial de votre AD ? Quelle catégorie pèse le plus ?
2. [Facile] Pourquoi un compte de service ne doit-il jamais être Domain Admin ?
3. [Moyen] Quelle finding PingCastle correspond à l’escalade de 09:45Z ? Justifiez.
4. [Moyen] Qu’est-ce que la délégation Kerberos non contrainte, et pourquoi est-ce dangereux ?
5. [Avancé] Le score a baissé — est-ce une preuve suffisante de sécurité ? Que ne mesure pas PingCastle ?
6. [Avancé] Décrivez un modèle de tiering AD adapté aux contraintes TAAF (équipes réduites, 1 DC).
7. [Expert] Reliez vos remédiations aux recommandations de votre rapport d’audit IA.

---

10. Annexe enseignant — corrigé

Réponses attendues

1. Score 70-80/100, catégorie Privileged Accounts qui pèse le plus (~50 pts) — typique d’un AD jamais tiéré avec comptes de service en DA.

2. Compte de service ≠ DA : un service est un programme qui tourne sans interaction humaine ; ses mots de passe sont stockés (registre, vault, fichiers) → forte probabilité de fuite. Lui donner DA = donner DA à n’importe qui qui compromet le serveur où le service tourne. Principe de moindre privilège.

3. 09:45Z ↔ S-PrivilegeEveryone ou similaire : svc_backup est dans Domain Admins, et e.bernard (compte standard) a la permission de modifier ce groupe. PingCastle remonte les deux problèmes : composition anormale du groupe + délégation excessive.

4. Délégation Kerberos non contrainte : un service avec cette propriété peut emprunter l’identité de n’importe quel utilisateur qui s’authentifie auprès de lui — vers n’importe quelle ressource. Si l’attaquant compromet ce service, il peut se faire passer pour un admin du domaine. Danger maximal.

5. Score ≠ sécurité : PingCastle mesure la posture statique (configuration, comptes, GPO). Il ne mesure pas : la sensibilisation des utilisateurs (phishing), la qualité du SIEM (détection runtime), les compromis déjà en place (un attaquant déjà infiltré reste invisible à PingCastle), la sécurité des applications hébergées sur les serveurs. Un score faible = posture saine ; ce n’est pas une preuve d’absence d’intrusion.

6. Tiering TAAF (1 DC) :

   • Tier 0 : Domain Admins, Schema Admins, comptes DC — login physique uniquement sur le DC, jamais sur un poste user, jamais via RDP depuis ailleurs.
   • Tier 1 : admins des serveurs métier (PG, NextCloud, FS) — login uniquement sur ces serveurs.
   • Tier 2 : helpdesk pour les postes utilisateurs.
   • GPO « Deny logon locally » entre tiers pour empêcher le rebond.
   • Adapté à TAAF : équipes réduites = un seul admin peut porter plusieurs tiers, mais doit avoir un compte par tier (jamais le même compte).

7. Rapport IA — corrélations à attendre :

   • PingCastle finding svc_backup DA ↔ recommandation Tiering AD + retrait DA pour service accounts (priorité 🔴).
   • PingCastle finding LDAP signing ↔ recommandation LDAPS sur tous les bind apps ↔ TP SSO (la dette technique de l’Acte 2 est éteinte ici).
   • PingCastle finding LAPS absent ↔ recommandation Déploiement LAPS sur tous les postes. → Le rapport IA fusionne PingCastle + Falco + Sigma + Purple en une vue unique RSSI.

Erreurs courantes à pénaliser

• Audit lancé avec un compte admin → fausse le score (PingCastle voit plus de choses qu’un attaquant lambda). -5 %.
• Remédiation sans snapshot DC préalable → potentiel lockout. -10 % (faute opérationnelle).
• Score final = 0 déclaré comme « sécurité atteinte » → -15 % (incompréhension du sens du score).
• Pas de findings résiduels documentés → -10 % (manque la lucidité du Purple).
• Délégation passée en contrainte sans réfléchir → si l’app a vraiment besoin de la délégation, contraindre vers le bon SPN ; sinon retirer. Pénaliser si l’étudiant a juste fait TrustedForDelegation $false sans analyser.

Pont avec les autres TPs

• Module 1 LotL Windows : les findings PingCastle 1 et 2 (svc_backup DA, délégation) sont exactement ce qui a permis les EventID 4728 et 4624 du jour J. La cohérence est forte.
• TP SSO AD↔NextCloud : LDAP signing non requis (finding 3) corrige la dette technique annoncée au § 3.2 du TP SSO.
• TP Purple Team : rejouer la kill chain après remédiation doit montrer que plusieurs étapes échouent maintenant (le 4728 par exemple, si e.bernard n’a plus les droits).
• TP Rapport Audit IA : ce rapport sera fusionné avec les autres audits (conformité Linux, scan vuln, downgrade PQC) en une vue unique.

---

Mapping MITRE ATT&CK / référentiels

Phase	Référence
Escalade via groupe privilégié	ATT&CK T1098, T1078.002
Abus de délégation Kerberos	ATT&CK T1550, T1187
Comptes valides	ATT&CK T1078
Bind LDAP en clair	ATT&CK T1557.002 (Adversary in the Middle)
Conformité / durcissement	Recommandations AD ANSSI · Guide d’hygiène ANSSI · NIS 2 Art. 21

Boucle bouclée : le TP SSO a fait de l’AD le gardien des fichiers classifiés ; ce TP prouve que ce gardien tient. Les findings alimentent le rapport d’audit final.

---

Références

• PingCastle — site officiel
• PingCastle — documentation des règles
• BloodHound CE — SpecterOps
• ANSSI — Recommandations AD
• Microsoft — Active Directory tiering
• Microsoft — Windows LAPS