Protéger les sauvegardes Active Directory des rançongiciels

Les opérateurs de rançongiciels modernes ne commencent pas par chiffrer les serveurs de fichiers. Ils prennent le contrôle d'Active Directory, s'en servent pour atteindre la console de sauvegarde, suppriment ou chiffrent les sauvegardes, et seulement ensuite déploient la charge utile par stratégie de groupe ou exécution à distance. Si les sauvegardes de vos contrôleurs de domaine sont accessibles avec un identifiant Domain Admin, elles auront disparu avant que vous ne remarquiez l'attaque. Sans sauvegarde saine d'un DC, la restauration signifie reconstruire la forêt à partir de rien.

Ce guide conçoit des sauvegardes AD adaptées à ce modèle de menace : quoi sauvegarder, où placer le système de sauvegarde dans le modèle de tiers, comment rendre les copies immuables et hors ligne, et comment prouver chaque semaine que vous pourriez restaurer. L'article pilier sur l'évaluation, la sauvegarde et la restauration couvre les bases de la sauvegarde de l'état du système. La procédure de restauration elle-même est décrite dans la rédaction et la répétition d'un plan de restauration de forêt.

Mesurer : ce que vous pouvez réellement restaurer aujourd'hui

Partez des faits, pas du tableau de bord du produit de sauvegarde. Dans chaque domaine, vérifiez la date de dernière sauvegarde de chaque contexte de nommage, telle qu'enregistrée par AD lui-même :

# Date de dernière sauvegarde par partition, vue par le DC
repadmin /showbackup *

# Versions Windows Server Backup disponibles sur un DC
wbadmin get versions

AD vous avertit aussi. L'événement 2089 du journal Directory Service apparaît lorsqu'une partition n'a pas été sauvegardée dans le seuil de latence de sauvegarde, fixé par défaut à la moitié de la durée de vie des objets tombstone. Si vous voyez un 2089 quelque part, votre produit de sauvegarde ne réalise pas de sauvegardes qu'AD reconnaît.

Répondez ensuite par écrit à cinq questions pour chaque domaine :

1. Quels DC sont sauvegardés, et dans quel format (état du système Windows Server Backup, sauvegarde de VM compatible VSS, agent AD d'un fournisseur) ?
2. Où les copies sont-elles stockées, et quelles identités peuvent les supprimer ?
3. Existe-t-il une copie qu'aucun identifiant en ligne ne peut supprimer ni modifier avant la fin de sa rétention ?
4. Où se trouvent les mots de passe DSRM de ces DC, et pouvez-vous les obtenir si AD est indisponible ?
5. Quand une restauration a-t-elle été testée pour la dernière fois, et combien de temps a-t-elle pris ?

La plupart des organisations découvrent que la réponse à la question 2 inclut les Domain Admins, le compte de service de sauvegarde et tous les membres de Backup Operators.

Quoi sauvegarder

Pour chaque domaine de la forêt :

• L'état du système d'au moins deux DC accessibles en écriture, chaque jour. Privilégiez l'émulateur PDC et un catalogue global. Deux DC vous protègent contre une sauvegarde corrompue ou réalisée après la compromission.
• Le DNS intégré à AD se trouve dans les partitions de l'annuaire et est inclus dans l'état du système. Ce n'est pas forcément le cas des redirecteurs conditionnels et des paramètres au niveau du serveur : exportez-les aussi.
• Les objets de stratégie de groupe, comme chemin de restauration distinct et rapide pour les erreurs de GPO qui ne justifient pas une restauration de DC.
• AD CS : base de données et clé privée de l'autorité de certification, car une restauration de forêt sans la PKI laisse hors service l'ouverture de session par carte à puce, le 802.1X et de nombreuses applications. Voir le durcissement d'AD CS.
• La configuration d'Entra Connect, exportée, afin de pouvoir reconstruire l'identité hybride.

Install-WindowsFeature Windows-Server-Backup

# État du système vers un volume dédié et non critique du DC
wbadmin start systemstatebackup -backupTarget:F: -quiet

# GPO et AD CS
Backup-GPO -All -Path 'F:\GPO' | Out-Null
Backup-CARoleService -Path 'F:\CA' -Password (Read-Host -AsSecureString 'CA key backup password')

Une sauvegarde de l'état du système contient ntds.dit et la ruche SYSTEM, c'est-à-dire chaque hash de mot de passe du domaine et les clés krbtgt. Une copie est aussi sensible qu'un DC. Chiffrez-la au repos et en transit, et ne la laissez jamais sur un partage lisible par des administrateurs Tier 1 ou Tier 2.

Appliquer : sortir le système de sauvegarde du rayon d'impact

Une identité séparée

La console de sauvegarde, les serveurs de référentiel et l'interface de gestion du stockage sont Tier 0. Quiconque les contrôle peut lire tous les hashs ou détruire votre capacité de restauration. Ajoutez-les à votre inventaire Tier 0 et choisissez l'un de ces modèles :

• Une forêt de gestion ou un groupe de travail distinct pour l'infrastructure de sauvegarde, avec des comptes locaux ou dédiés, une MFA résistante au phishing sur la console et aucune approbation vers la production.
• Une appliance durcie disposant de son propre annuaire d'identités, par exemple des référentiels immuables sous Linux, sur laquelle le domaine de production n'a aucun chemin d'administration.

Quel que soit votre choix, le compte de service de l'agent de sauvegarde sur les DC ne doit détenir que les droits nécessaires et ne doit être réutilisé nulle part ailleurs. Traitez Backup Operators et tout principal disposant de SeBackupPrivilege sur les DC comme Tier 0. Laissez ce groupe vide sauf besoin documenté.

Copies immuables et hors ligne

Suivez le schéma 3-2-1-1-0 : trois copies, sur deux types de supports, dont une hors site, une immuable ou hors ligne, et zéro erreur lors des tests de restauration.

• Immuable : stockage objet avec verrouillage de rétention en mode conformité (par exemple S3 Object Lock), ou référentiels durcis qui imposent l'immuabilité au niveau de la couche de stockage. En mode conformité, même l'administrateur du stockage ne peut pas raccourcir la rétention.
• Hors ligne : bandes ou supports amovibles physiquement déconnectés, avec une rotation planifiée. Lent, mais hors d'atteinte de tout ce qui se trouve sur le réseau.
• Rétention : suffisamment longue pour remonter avant une durée de présence probable de l'attaquant. Quelques semaines au minimum, avec des copies mensuelles, mais les restaurations doivent rester dans la durée de vie des objets tombstone de la forêt, ou être réalisées sous forme de restauration complète de forêt.

Isolation réseau

Le stockage de sauvegarde ne doit accepter de connexions que depuis les proxys de sauvegarde, et non depuis le réseau des serveurs en général ni directement depuis les DC. Les interfaces de gestion du stockage et de la sauvegarde ne doivent être accessibles que depuis des postes d'administration dédiés, en cohérence avec les règles de pare-feu de vos contrôleurs de domaine.

Mots de passe DSRM

Chaque DC possède un administrateur local du mode de restauration des services d'annuaire (DSRM). Son mot de passe est indispensable pour restaurer. Définissez-le par DC, stockez-le dans un coffre hors ligne (enveloppe scellée ou gestionnaire de mots de passe qui ne dépend pas d'AD) et renouvelez-le selon un calendrier. Vous pouvez aussi le synchroniser depuis un compte de domaine désactivé :

# Synchronise le mot de passe DSRM de ce DC à partir d'un compte de domaine dédié (désactivé)
ntdsutil "set dsrm password" "sync from domain account DSRMSync" q q

L'événement 4794 enregistre chaque tentative de modification du mot de passe DSRM. Déclenchez une alerte en dehors des fenêtres de changement.

Détecter les attaques contre les sauvegardes

Les attaquants préparent le terrain plusieurs jours avant le chiffrement. Plusieurs signaux apparaissent dans des journaux que vous transférez déjà :

• Suppression des clichés instantanés et du catalogue. Événements de création de processus (4688 avec ligne de commande) pour vssadmin delete shadows, wbadmin delete catalog ou wbadmin delete systemstatebackup sur n'importe quel serveur, et surtout sur les DC.
• Connexions à la console de sauvegarde depuis des hôtes ou des comptes inhabituels, et modifications des stratégies de rétention, des référentiels ou des clés de chiffrement. Transférez le journal d'audit du produit de sauvegarde vers le SIEM et déclenchez une alerte sur les modifications de configuration hors fenêtres de maintenance.
• Modifications de l'appartenance à Backup Operators (4732 sur le groupe intégré) et nouveaux détenteurs de SeBackupPrivilege.
• Sauvegardes manquées. Un travail de sauvegarde qui s'arrête silencieusement est aussi dangereux qu'une sauvegarde supprimée. Déclenchez une alerte en l'absence de travail réussi depuis plus d'une journée.

Vérifier

Un travail de sauvegarde au vert prouve que des données ont été écrites, pas qu'elles se restaurent. Vérifiez à trois niveaux :

1. Chaque semaine, de manière automatisée. repadmin /showbackup montre que chaque partition a été sauvegardée dans les 24 à 48 dernières heures. Aucun événement 2089. La copie immuable existe avec son verrouillage de rétention en place. Contrôlez ce dernier point via l'API de stockage depuis un système extérieur à l'AD de production.
2. Chaque trimestre, un test de restauration. Restaurez un DC par domaine à partir de la copie immuable dans un réseau isolé, sans route vers la production. Démarrez en DSRM et effectuez une restauration ne faisant pas autorité avec wbadmin start systemstaterecovery -version:<version>. Confirmez qu'AD DS démarre et que les objets sont présents. Ne connectez jamais un DC restauré à la production : il réintroduirait d'anciennes données et d'anciens mots de passe.
3. Chaque année, un exercice complet. Déroulez le plan de restauration de forêt de bout en bout et chronométrez-le.

Testez aussi la résistance à l'altération. Avec un compte Domain Admin, essayez de supprimer une sauvegarde ou de raccourcir la rétention dans la copie de laboratoire de votre architecture. La tentative doit échouer, et elle doit déclencher une alerte.

Ce que cela casse

• Le confort opérationnel. Les administrateurs de sauvegarde ne peuvent plus utiliser leur compte de domaine habituel. Des identifiants séparés et la MFA ajoutent de la friction, et certaines équipes résisteront jusqu'au premier incident.
• La vitesse de restauration. Les copies hors ligne et immuables dans une autre région se restaurent plus lentement que des instantanés locaux. Conservez une copie locale, rapide et en ligne pour les restaurations courantes, et la copie immuable pour les sinistres.
• Le coût du stockage. Une rétention en mode conformité ne peut pas être raccourcie, même par vous. Dimensionnez-la soigneusement : une rétention de plusieurs années mal configurée sur un gros bucket est une facture que vous ne pourrez pas annuler.
• Les intégrations des fournisseurs. Certains produits de sauvegarde attendent des proxys joints au domaine ou un contrôle d'accès basé sur les rôles intégré à AD. Les déplacer vers un plan d'identité séparé peut imposer de réinstaller des composants ou de modifier les licences.
• Le nettoyage de Backup Operators. Retirer des membres peut casser d'anciens scripts qui utilisaient ce groupe pour des sauvegardes au niveau fichier sur les DC. Identifiez ces scripts avant de vider le groupe.

Pour aller plus loin : rédiger et répéter un plan de restauration de forêt s'appuie sur ces sauvegardes, la rotation du mot de passe krbtgt couvre la réinitialisation de clé qui conclut toute restauration, et la thématique évaluation, sauvegarde et restauration liste l'ensemble de la série.