TP 3 - Audit AD & mise en conformité (PingCastle)

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

Position dans le parcours : Acte 3 (Audit & Purple Team) — miroir « identité » du TP conformité Linux.

---

Légende — les trois machines du TP

Placeholder	Machine	Ce qui tourne dessus
IP_APPS	Applications	PostgreSQL, NextCloud, Adminer — le SI audité
IP_VM1	Supervision	Grafana, Prometheus, Loki, Alertmanager
IP_VM2	SOC	Grafana de détection, règles Sigma, alerting
IP_VM3	Audit	Outillage offensif et de conformité

Relevez vos adresses avec hostname -I sur chaque VM. Les noms réels des machines sont dans Infrastructure — les énoncés n’en dépendent pas.

---

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 à 09h45). 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 TP4 (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 à 09h45 (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<br/>vulnérable)]
 PC1[PingCastle scan]
 SCORE1[Score initial<br/>~70-80/100]
 end

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

 subgraph "Remédiation ANSSI"
 R1[svc_backup hors<br/>Backup Operators]
 R2[LAPS]
 R3[Séparation DA/EA<br/>+ mots de passe rotatifs]
 R4[LDAP signing<br/>+ LDAPS]
 R5[Tiering Tier 0/1/2]
 end

 subgraph "Après"
 AD2[(AD TAAF<br/>durci)]
 PC2[PingCastle re-scan]
 SCORE2[Score final<br/>~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

Contexte d’exécution — sur le DC lui-même

PingCastle et SharpHound tournent sur TAAF-AD-001, pas sur la VM audit

La VM audit (TAAF-AUDIT-001) est une toolbox Linux (Debian : Nmap, Nikto, Lynis, Hydra, OpenSCAP, Syft/Grype conteneurisés) — elle ne fait tourner aucun binaire Windows. PingCastle.exe et SharpHound.exe sont des exécutables .NET Windows : ils s’exécutent en local sur le contrôleur de domaine TAAF-AD-001, via accès RDP ou console avec un compte AD non privilégié dédié à l’audit. Seul BloodHound CE (le serveur web/base de données du §7, un conteneur Docker) tourne côté Linux, sur la VM audit : vous y important le ZIP produit par SharpHound après l’avoir récupéré depuis le DC.

Connectez-vous en RDP (ou console Hyper-V/QEMU) sur TAAF-AD-001, avec le compte AD non privilégié prévu pour l’audit.

# Sur TAAF-AD-001, vérifier qu'on est bien sur le domaine
(Get-WmiObject Win32_ComputerSystem).Domain
# → univ-taaf.internal

Télécharger PingCastle

# Sur le DC TAAF-AD-001 (RDP/console)
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

Les faiblesses réelles de l’AD à relever

L’AD est provisionné par les scripts du dépôt active-directory. Il n’est pas dans un état « catastrophe » artificiel — il porte des faiblesses réelles et défendables, exactement celles que PingCastle et BloodHound doivent mettre au jour :

• LDAP en clair sur 389, pas de LDAPS ni de LDAP signing (choix assumé du déploiement — c’est à l’audit de le relever).
• svc_backup membre de Backup Operators, avec mot de passe non-expirant (PasswordNeverExpires) et non changeable (CannotChangePassword) : un compte de service au privilège de sauvegarde (SeBackupPrivilege = lecture de NTDS.dit) et immortel — un chemin d’escalade de premier plan.
• Comptes d’administration de domaine (d_*) membres à la fois de Domain Admins ET Enterprise Admins, eux aussi en PasswordNeverExpires.
• Pas de LAPS : les mots de passe administrateur locaux ne sont pas gérés/rotés.
• AdminCount=1 hérité sur des objets inactifs : à surveiller si présent (pas garanti sur un AD fraîchement provisionné — cet attribut ne subsiste que si des comptes ont un jour été retirés d’un groupe protégé).

Le pont avec l’incident (Acte 2)

Au repos, svc_backup n’est pas dans Domain Admins. L’attaque de l’incident l’y a ajouté (Event 4728, visible dans les logs) — mais votre audit ne cherche pas la trace de l’attaque, il cherche ce qui l’a rendue triviale : un compte de service déjà sur-privilégié (Backup Operators) et jamais renouvelé. C’est ça, la valeur d’un audit avant incident.

---

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

3.1 — Lancer PingCastle Health Check

Depuis TAAF-AD-001 (RDP/console) :

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 (indicative)	Catégorie	La faiblesse réelle
1	A-LDAPSigningDisabled / pas de LDAPS	Anomalies	LDAP en clair sur 389, signing non requis
2	P-DelegationLoginScript / Backup Operators	Privileged Accounts	svc_backup dans Backup Operators (lecture NTDS.dit)
3	P-AdminPwdNeverExpires	Privileged Accounts	Comptes Domain Admins/Enterprise Admins à mot de passe non-expirant
4	S-AdminPwdLAPS	Privileged Accounts	LAPS non déployé (admins locaux non gérés)
5	P-Delegated / cumul DA+EA	Privileged Accounts	Comptes d_* membres de Domain et Enterprise Admins

Les noms exacts de règles et le score dépendent de votre AD — ce qui compte, c’est de rattacher chaque point à une faiblesse réelle ci-dessus, pas de matcher un score cible.

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 TP4 LotL :

Finding PingCastle (réel)	Ce qu’il a rendu possible dans l’incident	EventID	ATT&CK
svc_backup sur-privilégié (Backup Operators, pwd immortel)	L’ajout à Domain Admins (4728) n’a été qu’une formalité : le compte était déjà une clé maîtresse	4728	T1098 / T1078.002
Comptes DA+EA à mot de passe non-expirant	Un secret volé reste valable indéfiniment — pas de rotation qui coupe l’accès	—	T1078
LDAP signing non requis / pas de LDAPS	Binds en clair → interception de credentials (MitM)	—	T1557.002
Pas de LAPS	Un mot de passe admin local identique partout = rebond trivial	—	T1078.001
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 — Dé-privilégier le compte de service svc_backup (Reco ANSSI R1)

Le compte est dans Backup Operators (droit de lecture de NTDS.dit) avec un mot de passe non-expirant et non-changeable — c’est le chemin d’escalade que l’incident a exploité.

# Constat
Get-ADGroupMember -Identity "Backup Operators" | Select Name, SamAccountName
Get-ADUser svc_backup -Properties PasswordNeverExpires, CannotChangePassword |
  Select SamAccountName, PasswordNeverExpires, CannotChangePassword

# 1. Sortir svc_backup de Backup Operators (privilège trop large pour une sauvegarde applicative)
Remove-ADGroupMember -Identity "Backup Operators" -Members "svc_backup" -Confirm:$false

# 2. Idéalement : remplacer le compte par un gMSA (mot de passe géré, roté par l'AD)
#    New-ADServiceAccount -Name gmsa_backup -DNSHostName ... -PrincipalsAllowedToRetrieveManagedPassword ...
# 3. À défaut : rendre le mot de passe rotatif
Set-ADUser svc_backup -PasswordNeverExpires $false -CannotChangePassword $false

5.2 — Séparer les rôles d’administration (Reco ANSSI R2)

Les comptes d_* cumulent Domain Admins ET Enterprise Admins avec un mot de passe immortel.

# Constat : les comptes doublement privilégiés à mot de passe non-expirant
Get-ADGroupMember "Domain Admins" | Get-ADUser -Properties PasswordNeverExpires, MemberOf |
  Where-Object { $_.PasswordNeverExpires -and ($_.MemberOf -match "Enterprise Admins") } |
  Select SamAccountName

# 1. Réserver Enterprise Admins aux rares opérations de forêt : en retirer les admins quotidiens
Remove-ADGroupMember -Identity "Enterprise Admins" -Members "d_thibaut.fontaine" -Confirm:$false
# 2. Mot de passe rotatif sur les comptes privilégiés
Get-ADGroupMember "Domain Admins" | Set-ADUser -PasswordNeverExpires $false
# 3. Appliquer le modèle en tiers (tiering) : un compte d'admin ≠ un compte bureautique

Délégation Kerberos

Si votre AD comporte des délégations non contraintes (Get-ADComputer -Filter {TrustedForDelegation -eq $true}), retirez-les ou passez-les en délégation contrainte. Sur cet AD de TP, aucun serveur de fichiers n’est joint au domaine — c’est un contrôle à connaître, pas un finding garanti ici.

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-AUDIT-001"
# → 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
svc_backup hors Backup Operators + mot de passe rotatif	Casse le chemin d’escalade que l’attaque a emprunté	Capture Get-ADGroupMember "Backup Operators" sans svc_backup
Séparation DA/EA + mots de passe rotatifs	Un secret volé expire ; l’admin quotidien n’est plus EA	Capture Get-ADUser -Filter {PasswordNeverExpires -eq $true} sur les admins
…	…	…

---

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 le DC TAAF-AD-001 (RDP/console), comme PingCastle
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"

Récupérez ensuite le ZIP produit sur TAAF-AD-001 (copie via RDP, partage réseau ou scp si OpenSSH est activé côté DC) pour l’importer côté toolbox Linux à l’étape suivante.

7.2 — Importer dans BloodHound CE

# Sur la VM audit (Linux) — seul le serveur BloodHound CE (conteneur) tourne ici,
# pas SharpHound (binaire Windows, exécuté au 7.1 sur le DC)
docker run -d --name bloodhound \
  -p 8080:8080 \
  -e bhe_disable_cypher_complexity_limit=true \
  ghcr.io/specterops/bloodhound:latest

# Accès : http://IP_VM3:8080
# Importer le ZIP récupéré depuis TAAF-AD-001 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 julie.moreau@univ-taaf.internal.

Résultat attendu (avant remédiation) : le chemin met en évidence la position sur-privilégiée de svc_backup :

svc_backup → MemberOf → Backup Operators   (SeBackupPrivilege → lecture NTDS.dit → escalade DA)

BloodHound marque Backup Operators comme groupe à fort impact. Repérez aussi les comptes d_* membres de Domain Admins et Enterprise Admins.

📸 Capture obligatoire #3 : le graphe BloodHound avec svc_backup et son appartenance à Backup Operators.

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 dans Backup Operators, donc plus de route d’escalade vers Domain Admins.

📸 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 TP4.
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 09h45 ? 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. Catégorie Privileged Accounts en tête — typique d’un AD jamais tiéré : comptes de service dans des groupes puissants et mots de passe qui n’expirent jamais.

2. Compte de service sur-privilégié : svc_backup est dans Backup Operators (droit de lire NTDS.dit, donc d’exfiltrer tous les hachages → escalade Domain Admins). Son mot de passe est en plus immortel et non-changeable. Un service ne devrait avoir que le strict droit de sauvegarde applicative, via un gMSA à mot de passe roté.

3. Le lien avec l’incident : au repos, svc_backup n’est pas DA — mais sa position (Backup Operators + pwd immortel) a fait de l’ajout à Domain Admins (4728) une simple formalité. L’audit trouve la cause structurelle, pas la trace de l’attaque.

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

• TP4 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 julie.moreau 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