Durcir Active Directory (4/4) : supervision, détection et reprise.

Les trois parties précédentes réduisent le risque. Aucune ne l'annule. Cette partie traite de ce qui reste quand une mesure a échoué : voir que quelque chose se passe, et pouvoir reconstruire. C'est la moins gratifiante des quatre - elle ne se voit pas tant qu'elle ne sert pas - et c'est celle dont l'absence transforme un incident en sinistre.

Ce qu'il vous faut

• Des droits d'administration du domaine, et l'accès à la stratégie des contrôleurs de domaine.
• Une destination pour les journaux, en dehors du domaine : collecteur d'événements Windows, SIEM, ou à défaut un serveur syslog isolé.
• Une solution de sauvegarde capable de traiter l'état système d'un contrôleur de domaine.
• Un créneau pour un exercice réel de restauration. Sans lui, cette page reste théorique.

1. Activer l'audit avancé

La stratégie d'audit par défaut d'un domaine Windows ne journalise pas grand-chose d'exploitable. L'audit avancé permet de choisir catégorie par catégorie, ce qui évite le double écueil habituel : soit trop peu d'événements pour détecter quoi que ce soit, soit un volume tel que personne ne les regarde et que la rétention est trop courte.

Configuration ordinateur → Stratégies → Paramètres Windows → Paramètres de sécurité → Configuration avancée de la stratégie d'audit

Les catégories à activer sur les contrôleurs de domaine : Connexion de compte, Gestion des comptes, Accès DS, Ouverture/fermeture de session, Accès aux objets, Changement de stratégie, Utilisation de privilèges, Système, et Suivi détaillé.

Attention : certaines catégories très verbeuses (l'accès aux objets, en particulier) doivent être ciblées, sinon elles noient tout le reste. Commencez large en observation, mesurez le volume produit, puis affinez.

2. Les événements qui comptent vraiment

Une longue liste d'identifiants d'événements ne sert à rien si personne ne l'exploite. Voici ceux qui, pris ensemble, couvrent l'essentiel des scénarios d'attaque sur un annuaire - avec ce qu'ils veulent dire, parce qu'un numéro sans interprétation ne devient jamais une alerte.

3. Centraliser, en dehors du domaine

C'est la condition sans laquelle tout ce qui précède ne vaut rien. Un attaquant qui contrôle le domaine efface les journaux locaux : c'est même la première chose qu'il fait, et l'événement 1102 qui en témoigne disparaît avec le reste.

Deux exigences, dans cet ordre d'importance :

• Hors du domaine. Un collecteur joint au domaine, administré avec les mêmes comptes, tombe avec lui. Si ce n'est pas possible à court terme, au minimum : un compte d'administration distinct, une authentification différente, et une rétention que les administrateurs du domaine ne peuvent pas raccourcir.
• En temps réel, ou presque. Une collecte quotidienne laisse à un attaquant une journée pour effacer ses traces avant qu'elles ne partent.

La collecte d'événements Windows (WEF) suffit pour commencer et ne coûte rien : contrôleurs de domaine, serveurs, postes et postes d'administration poussent vers un collecteur, qui alimente ensuite le SIEM. Mieux vaut un WEF en place qu'un projet de SIEM en attente de budget.

4. Les alertes à écrire en premier

Une règle qui se déclenche cinquante fois par jour est une règle que l'équipe désactivera. Commencez par celles dont le taux de faux positifs est structurellement bas parce qu'elles décrivent des événements qui ne devraient pas arriver :

• ajout d'un membre à Domain Admins, Enterprise Admins ou Schema Admins ;
• réplication d'annuaire demandée par une machine qui n'est pas un contrôleur de domaine ;
• modification de la liste de contrôle d'accès d'AdminSDHolder ;
• modification ou liaison d'une GPO en dehors d'une fenêtre de changement ;
• modification d'un modèle de certificat ;
• effacement du journal de sécurité ;
• installation d'un service sur un contrôleur de domaine ;
• authentification d'un compte de palier 0 depuis une machine qui n'est pas un poste d'administration ;
• réactivation d'un compte désactivé.

Chacune de ces alertes doit avoir, écrit à l'avance : qui la reçoit, quoi vérifier, et qui appeler si elle est confirmée. Une alerte sans procédure produit une notification que personne ne sait traiter.

5. EDR, exclusions et réduction de la surface d'attaque

La couverture EDR doit inclure les contrôleurs de domaine, les serveurs, les postes, les postes d'administration et les serveurs de PKI. Ce sont souvent ces deux derniers qui manquent, précisément parce qu'ils sont « à part ».

Get-MpComputerStatus |
    Select-Object AMServiceEnabled, AntivirusEnabled,
                  RealTimeProtectionEnabled, BehaviorMonitorEnabled

Les exclusions antivirus méritent un audit à elles seules. Elles s'accumulent au fil des demandes applicatives, sont rarement retirées, et finissent par former une zone où plus rien n'est inspecté - transformant l'EDR en protection décorative. Chaque exclusion doit être documentée, justifiée, limitée au plus étroit (un chemin, pas un disque ; une extension, pas toutes) et revue périodiquement.

Les règles de réduction de la surface d'attaque (ASR) bloquent des comportements plutôt que des fichiers : vol d'identifiants, exécution depuis une pièce jointe bureautique, script obscurci. Déployez-les toujours en mode Audit d'abord, mesurez les faux positifs sur un cycle complet, puis passez en Bloc règle par règle.

Enfin, activez la journalisation des blocs de script PowerShell et collectez-la : c'est ce qui permet de savoir ce qui a été exécuté, y compris quand la commande était obscurcie.

6. Sauvegarder l'annuaire - et le mettre hors de portée

Sauvegardez l'état système des contrôleurs de domaine régulièrement. C'est ce qui contient la base de l'annuaire, le registre, SYSVOL et les composants nécessaires à une restauration.

Mais l'essentiel n'est pas la fréquence, c'est l'isolation. Un rançongiciel qui chiffre l'annuaire chiffre aussi les sauvegardes accessibles depuis la production avec les mêmes identifiants : une sauvegarde jointe au domaine, administrée par un compte du domaine, disparaît avec lui. La progression à viser :

production  ->  sauvegarde  ->  copie isolée, idéalement immuable
                                (identifiants distincts, réseau séparé,
                                 rétention non modifiable)

Deux points de vigilance que l'on découvre en général au mauvais moment : sauvegardez au moins deux contrôleurs de domaine, et vérifiez que la sauvegarde est plus récente que la durée de vie des tombstones du domaine - une sauvegarde plus ancienne n'est pas restaurable dans un domaine encore vivant.

7. La corbeille Active Directory

Sans elle, un objet supprimé perd ses attributs : on peut le « réanimer », mais il revient vide de ses appartenances à des groupes et de ses permissions. Avec elle, la restauration est complète.

Get-ADOptionalFeature -Filter 'Name -like "Recycle Bin Feature"'

Enable-ADOptionalFeature -Identity "Recycle Bin Feature" `
    -Scope ForestOrConfigurationSet `
    -Target (Get-ADForest).Name

L'activation exige le niveau fonctionnel adéquat et elle est irréversible. Ce n'est pas un problème - il n'y a aucune raison de vouloir revenir en arrière - mais cela justifie de la planifier plutôt que de la lancer un après-midi.

8. DSRM : le compte dont on a besoin le jour où rien ne marche

Le mode restauration des services d'annuaire (DSRM) dispose de son propre mot de passe d'administrateur local, défini à la promotion du contrôleur de domaine. C'est le compte qui permet de démarrer un contrôleur de domaine quand l'annuaire ne fonctionne plus - donc quand aucune authentification de domaine n'est possible.

Dans la pratique, ce mot de passe a été saisi une fois, il y a des années, par quelqu'un qui a peut-être quitté l'entreprise. Il doit être : long, unique par contrôleur de domaine, stocké dans un coffre accessible aux personnes autorisées même en cas de panne du système d'information, et renouvelé.

ntdsutil
set dsrm password
reset password on server null
q
q

Les versions récentes de Windows LAPS savent également gérer et sauvegarder le mot de passe DSRM des contrôleurs de domaine compatibles : c'est la meilleure réponse au problème du mot de passe statique et oublié.

9. Savoir reconstruire

Deux scénarios très différents, qu'il ne faut pas confondre :

• Restaurer un contrôleur de domaine dans un domaine qui compte d'autres contrôleurs sains : c'est une restauration non autoritaire, et c'est le cas courant. L'annuaire se resynchronise depuis les autres.
• La reprise de forêt : quand tous les contrôleurs de domaine sont compromis ou détruits, ou que plusieurs domaines sont touchés. On repart d'une sauvegarde, sur un réseau isolé, en reconstruisant ensuite les autres contrôleurs de domaine. C'est une procédure longue, délicate, et qui ne s'improvise pas.

Documentez, avant d'en avoir besoin : la liste des contrôleurs de domaine et leurs rôles FSMO, la configuration DNS, les catalogues globaux, l'emplacement et les identifiants des sauvegardes, les mots de passe DSRM, les comptes de récupération, l'état de la PKI, les approbations, et les contacts d'urgence - y compris de nuit.

Puis faites l'exercice pour de vrai, sur un environnement de laboratoire, avec un scénario du type « deux contrôleurs de domaine compromis ». Chronométrez. Le temps mesuré est la seule donnée qui permette de répondre honnêtement à la question que la direction posera le jour venu : « dans combien de temps l'entreprise refonctionne ? »

10. Vérifier en continu

Une posture n'est jamais acquise : les délégations reviennent, les comptes de service se multiplient, les exceptions s'installent. Rejouez périodiquement - trimestriellement pour les plus sensibles :

• revue des ACL et des groupes à privilèges ;
• revue des modèles de certificats et des approbations ;
• mesure de l'usage résiduel de NTLM et de LDAP non signé ;
• contrôle du déploiement LAPS et des lecteurs autorisés ;
• test de restauration ;
• passage d'un outil d'audit d'annuaire (PingCastle, Purple Knight) et comparaison au relevé précédent - c'est la variation qui informe, plus que le score absolu.

Un cran au-dessus : rejouer en laboratoire les chemins d'attaque que vous avez coupés, pour vérifier trois choses distinctes que l'on confond souvent - que la mesure empêche, que la tentative est détectée, et en combien de temps quelqu'un le voit.

Vérifier que c'est en place

1. La collecte fonctionne : ajoutez un compte de test à un groupe à privilèges, puis retirez-le. L'événement doit apparaître dans le système central, et l'alerte partir. Si vous ne l'avez pas testé, vous ne savez pas.
2. Les deux journaux sont couverts : un événement 7045 (journal Système) remonte aussi bien qu'un 4728 (journal Sécurité).
3. Les journaux survivent : effacer le journal de sécurité local d'une machine de test ne fait pas disparaître les événements déjà collectés.
4. La sauvegarde est restaurable : pas « la sauvegarde s'est terminée sans erreur », mais un contrôleur de domaine réellement remonté depuis elle, dans un laboratoire.
5. La corbeille est active : Get-ADOptionalFeature montre la fonctionnalité activée, et un objet supprimé se restaure avec ses appartenances.
6. Le mot de passe DSRM est connu : quelqu'un peut le produire maintenant, sans accéder à un système authentifié par le domaine.

Sources

• ANSSI - Recommandations de sécurité relatives à Active Directory (ANSSI-PA-099)
• Microsoft Learn - Recommandations de stratégie d'audit
• Microsoft Learn - Guide de récupération de forêt Active Directory
• Microsoft Learn - Corbeille Active Directory
• Kenawek - Gestion des vulnérabilités : de la CVE à la remédiation