Sauvegarde Active Directory : préparer une restauration de forêt avant d'en avoir besoin
Lors d'une attaque par rançongiciel, Active Directory est souvent à la fois la cible et le prérequis de toute reconstruction. Sans annuaire, pas d'authentification, et souvent pas de console de sauvegarde. Un plan de restauration de forêt se prépare à froid, et se teste.
Ce qu'il faut sauvegarder
La restauration d'un contrôleur de domaine repose sur une sauvegarde de l'état système (system state), qui contient la base NTDS, SYSVOL, le registre et les fichiers de démarrage. Une sauvegarde de machine virtuelle complète peut convenir si l'outil gère correctement les contrôleurs de domaine (prise en charge du VM-GenerationID notamment), mais l'état système reste la référence dans la procédure de Microsoft.
- Au moins deux contrôleurs par domaine sauvegardés, idéalement ceux qui détiennent les rôles FSMO.
- Une fréquence au moins quotidienne pour ces contrôleurs.
- Tous les domaines de la forêt, y compris le domaine racine souvent « vide » mais indispensable.
wbadmin start systemstatebackup -backupTarget:E: -quiet
Des copies que l'attaquant ne peut pas atteindre
Les groupes de rançongiciels ciblent explicitement les sauvegardes. Une copie accessible avec un compte du domaine compromis doit être considérée comme perdue. Il faut donc au moins une copie hors ligne ou immuable, et une infrastructure de sauvegarde qui ne dépend pas de l'annuaire qu'elle protège : comptes d'administration locaux ou dans un annuaire distinct, MFA sur la console, réseau d'administration séparé.
La durée de vie des tombstones
Un objet supprimé est conservé sous forme de tombstone pendant la tombstone lifetime, 180 jours par défaut dans les forêts récentes (60 jours dans des forêts plus anciennes n'ayant jamais été modifiées). Une sauvegarde plus ancienne que cette valeur n'est pas utilisable pour une restauration : elle réintroduirait des objets déjà purgés ailleurs. Vérifiez la valeur réelle de votre forêt (attribut tombstoneLifetime) et la rétention de vos sauvegardes.
Les mots de passe DSRM
La restauration d'un contrôleur passe par le mode de restauration des services d'annuaire, qui utilise un compte administrateur local propre à chaque contrôleur. Ce mot de passe est défini à la promotion puis souvent oublié. Il doit être connu, stocké dans un coffre hors du domaine, et changé régulièrement avec ntdsutil (« set dsrm password »).
Question simple. Si tous vos contrôleurs étaient chiffrés ce soir, qui connaît le mot de passe DSRM, où se trouve la sauvegarde saine la plus récente, et avec quel compte y accède-t-on ?
Tester en environnement isolé
Le guide de restauration de forêt de Microsoft décrit une procédure longue : restauration d'un contrôleur accessible en écriture par domaine, restauration faisant autorité de SYSVOL, nettoyage des métadonnées des autres contrôleurs, prise des rôles FSMO, double rotation du mot de passe krbtgt, augmentation du pool de RID, réinitialisation de comptes sensibles. Ces étapes ne s'improvisent pas en pleine crise.
Un test annuel dans un réseau totalement isolé permet de valider les sauvegardes, de mesurer le temps réel de restauration et de mettre à jour une procédure écrite, imprimable, utilisable sans accès au système d'information.
Le scénario rançongiciel
Dans ce scénario, la sauvegarde la plus récente peut contenir la persistance de l'attaquant : comptes ajoutés, GPO modifiées, droits de réplication accordés. La restauration doit donc être suivie d'une revue des objets et des ACL sensibles avant toute reconnexion au réseau de production.
Ce qu'un audit vérifie
- L'âge de la dernière sauvegarde d'état système de chaque domaine.
- La valeur de la tombstone lifetime et la rétention des sauvegardes.
- L'indépendance de l'infrastructure de sauvegarde vis-à-vis du domaine.
- La date de changement des mots de passe DSRM et l'existence d'un test de restauration documenté.