Tim Beasley Consultant senior en gestion des incidents

Tous les groupes dangereux d'Active Directory ne semblent pas nécessairement présenter un risque.

Je travaille depuis suffisamment longtemps dans les domaines de la gestion des incidents, de l'analyse forensic des identités et de la restauration après compromission pour avoir dressé une liste des groupes Active Directory que l'on a tendance à considérer comme « sans grande importance ». Les opérateurs de sauvegarde. Les opérateurs d'impression. Les opérateurs de serveurs. Ceux dont personne ne se soucie, car ce ne sont pas des administrateurs de domaine.

Pourquoi cela devrait-il vous préoccuper ? Parce que les pirates n'ont pas besoin du rôle d'administrateur de domaine . En ce qui concerne ces groupes, il leur suffit de trouver un seul groupe négligé disposant des autorisations nécessaires — et dont personne ne surveille l'activité.

C'est justement ce schéma que cette série a pour but de briser.

Dans chaque article de cette série, nous examinerons de plus près un groupe de sécurité AD spécifique, et je vous expliquerai en détail :

  • Les droits spécifiques dont bénéficie ce groupe
  • Les risques qu'ils peuvent entraîner
  • Comment les pirates en tirent-ils réellement parti ?
  • Ce qu'il faut vérifier dès aujourd'hui dans votre propre environnement

À la fin de cette série, vous disposerez d'une véritable liste de groupes discrets qui méritent qu'on s'y attarde davantage.

Lisez ce premier article consacré aux opérateurs de sauvegarde : vous en ressortirez avec une liste de contrôle concrète pour l'audit et la surveillance, que vous pourrez mettre en œuvre dès cette semaine. Revenez ensuite pour découvrir le groupe suivant de la liste.

Plongeons dans le vif du sujet.


De quels droits disposent réellement les opérateurs de sauvegarde ?

C'est l'un de ces groupes Active Directory qui semblent ennuyeux… mais qui sont en réalité dangereux.

Les administrateurs de sécurité ont tendance à ne pas y prêter attention, car ce rôle n'est pas aussi spectaculaire que celui d'« administrateur de domaine ». C'est une erreur. En réalité, il dispose de droits pouvant donner lieu à des abus graves — voire catastrophiques s'ils tombent entre de mauvaises mains.

Les membres de Backup Operators disposent des avantages suivants :

  • SeBackupPrivilege: Lire n'importe quel fichier du système, en ignorant les listes de contrôle d'accès (ACL) NTFS
  • SeRestorePrivilege: Écrire ou réécrire n'importe quel fichier du système, en ignorant à nouveau les listes de contrôle d'accès (ACL)
  • SeShutdownPrivilege: Arrêter le système
  • Possibilité de se connecter localement par défaut sur les contrôleurs de domaine et les serveurs

Pourquoi les privilèges des opérateurs de sauvegarde posent rapidement un problème au niveau du domaine

Les droits de ce groupe sont techniquement des droits locaux, mais sur un contrôleur de domaine, ils ont rapidement des répercussions sur l'ensemble du domaine. Un opérateur de sauvegarde dont le compte a été compromis peut accéder à un contrôleur de domaine, l'arrêter, ou lire, écrire et écraser des fichiers critiques, quelles que soient les autorisations NTFS. Cela inclut notamment ntds.dit, les branches du registre, les fichiers binaires protégés, les chemins d'accès aux services et les cibles des tâches planifiées.

ntds.dit Il s'agit de la base de données AD ; c'est donc là que tout bascule. Si un pirate parvient à créer un clonage de ce fichier et à s'emparer du SYSTEM ruche, ils peuvent extrait les hachages NTLM des utilisateurs du domaine, les clés Kerberos, les secrets liés à DPAPI et les informations relatives aux comptes de service privilégiés, hors ligne.

Traduction : Ils te tiennent à leur merci.

Il s'agit en substance d'une attaque de typeDCSync… sanspasser par DCSync. Les équipes chargées de la surveillance de ce type d'attaques surveillent souvent les droits de réplication, l'activité sur le port 4662 ou d'autres indicateurs de réplication. Les opérateurs de sauvegarde peuvent contourner ces contrôles en copiant directement la base de données : le résultat final est le même, mais le chemin emprunté est différent, et cette méthode est bien plus difficile à détecter.

La restauration des droits d'accès est également importante. Un attaquant peut écraser des fichiers protégés, remplacer des binaires tels que sethc.exe ou utilman.exe, modifier les fichiers exécutables des services ou changer les cibles des tâches planifiées.

En d'autres termes, un opérateur de sauvegarde compromis peut voler les clés et installer une porte dérobée.


Même sans accès au contrôleur de domaine, le risque reste important

Sur tout serveur où le compte peut se connecter, les opérateurs de sauvegarde peuvent lire toutes les données, y compris les fichiers appartenant à SYSTEM. Cet accès peut exposer les données du registre, les répertoires d'applications, les référentiels de sauvegarde et tout autre élément enregistré sur le disque, en partant du principe que les autorisations NTFS le protégeront. (HA ! PAS DU TOUT !)

Cela signifie souvent que les identifiants des comptes de service, les identifiants de domaine enregistrés utilisés par les applications ou les tâches de sauvegarde, les chaînes de connexion aux bases de données, les jetons API, les données Kerberos et les clés privées des certificats sont accessibles.

Les opérateurs de sauvegarde constituent souvent un tremplin lors des attaques, et non l'objectif final.


Procédures d'escalade des opérateurs de sauvegarde

Les pirates peuvent également abuser des droits de restauration pour écrire des DLL malveillantes dans des chemins d'accès protégés, remplacer des binaires de service, modifier les paramètres de démarrage ou de récupération, et forcer l'exécution en tant que SYSTEM.

Les comptes du groupe « Backup Operators » étant souvent considérés comme fiables, ils peuvent se retrouver sur des serveurs de sauvegarde, échapper à certaines mesures de sécurisation ou faire l'objet d'une surveillance moins stricte que les groupes d'administrateurs plus évidents.


Pourquoi les gens sous-estiment-ils les risques liés au groupe des opérateurs de sauvegarde ?

J'entends ça tout le temps :

  • « Ce ne sont pas des administrateurs. »
  • « Ils ne peuvent pas modifier les objets AD. »
  • « Les comptes de secours doivent disposer d'un accès étendu. »
  • « Nos outils surveillent déjà les abus en matière de duplication. »

Tout cela s'effondre dès qu'un pirate copie le ntds.dit et le registre.


« Alors, qu'est-ce qu'on fait ? »

C'est simple : videz le groupe, surveillez les changements d'appartenance et veillez à ce qu'il reste vide. Si personne ne fait partie du groupe « Backup Operators », personne ne pourra en abuser.

C'est la meilleure réponse possible et, franchement, celle que j'aimerais voir davantage d'équipes adopter avant qu'un fournisseur ne les persuade de se lancer dans une démarche imprudente.

Mais c'est rarement aussi simple. Dans le domaine de la gestion des incidents, je constate cela sans cesse :

  • Un fournisseur affirme que son application « nécessite » des opérateurs de sauvegarde.
  • Les comptes sont ajoutés au groupe.
  • Tout le monde passe à autre chose.

Si vous êtes dans cette situation, l'objectif est de réduire le risque de manière aussi radicale que possible et de cesser de considérer ces comptes comme ayant un faible impact.


Premièrement : mettre en place un système de niveaux

Les comptes des opérateurs de sauvegarde doivent être considérés comme des identités proches du niveau 0. Si un compte permet à un pirate d'accéder à votre base de données Active Directory, à vos secrets privilégiés ou à vos serveurs les plus sensibles, il s'agit d'un compte de niveau 0.

  1. Veillez à ce que le groupe reste vide, surveillez les changements dans la composition du groupe et considérez toute exception comme présentant un risque élevé.
  2. Ne permettez jamais aux opérateurs de sauvegarde de se connecter aux contrôleurs de domaine à moins qu'il n'y ait pas d'autre solution viable. Utilisez Deny log on locally et Deny log on through Remote Desktop Services. Et limitez l'accès de ces comptes aux seuls serveurs de sauvegarde spécifiques.
  3. Surveillez les connexions interactives. Les comptes des opérateurs de sauvegarde doivent se comporter comme des identités de service, et non comme des personnes devant leur clavier.
  4. Activer l'audit avancé de l'accès aux fichiers sur ntds.dit, le SYSTEM Hive, les référentiels de sauvegarde et les emplacements de configuration des applications. Générer une alerte en cas de « lectures impossibles », telles que 4663—pour les fichiers auxquels le compte ne devrait pas avoir accès via le système NTFS seul.
  5. Faites attention aux outils tels que diskshadow.exe, vssadmin.exe, wbadmin.exe, ntdsutil.exeet esentutl.exe, notamment sur les serveurs de domaine, en dehors des créneaux de sauvegarde ou à partir de sessions interactives.
  6. Réduisez l'ampleur des répercussions grâce aux gMSA, aux API spécifiques à chaque application, à des outils de sauvegarde modernes fonctionnant avec des privilèges réduits, ainsi qu'à une infrastructure de sauvegarde dédiée ou isolée lorsque cela est possible.

Comment détecter les abus liés à SeBackupPrivilege

Audit SeBackupPrivilege Son utilisation est délicate, car Windows n'enregistre pas ces informations SeBackupPrivilege was used directement.

Vous pouvez voir quand des privilèges spéciaux sont attribués à une connexion, mais pas d'événement clair indiquant que ce privilège a été exercé sur un fichier spécifique. La détection repose sur le contexte, l'accès aux fichiers, le comportement des processus et la corrélation.

Commencer par un événement 4672, qui indique à quel moment un utilisateur se connecte et reçoit SeBackupPrivilege ou SeRestorePrivilege. Cela vous indique quand la session a débuté et permet de restreindre la plage de recherche. Les opérateurs de sauvegarde sur les contrôleurs de domaine, sur les serveurs non dédiés à la sauvegarde ou dans des sessions interactives devraient immédiatement se démarquer.

Activez ensuite l'audit avancé du système de fichiers et appliquez les SACL aux éléments importants :

  • C:\Windows\NTDS\ntds.dit
  • Les SYSTEM ruche
  • SAM
  • Référentiels de sauvegarde
  • Répertoires de configuration des applications

Des événements tels que 4663 et, le cas échéant, 4656, indiquent ce qui a effectivement été modifié.

Le signal le plus fort est la « lecture impossible », c'est-à-dire une lecture réussie d'un fichier auquel l'utilisateur ne devrait pas pouvoir accéder en vertu des seules autorisations NTFS. Si le compte est celui d'un opérateur de sauvegarde, c'est le privilège de sauvegarde qui a rendu cela possible.

  • 4672 : Qui s'est connecté avec ce droit ?
  • 4663 : Quels fichiers protégés ou chemins d'accès aux instantanés ont été lus ?
  • 4688 : Quel processus ou outil a permis cela ?
  • Contexte : où cela s'est-il passé, quand cela s'est-il passé, s'agissait-il d'une interaction et cela avait-il un sens sur le plan opérationnel ?

La télémétrie de création de processus ajoute une couche supplémentaire. Activer 4688 avec la journalisation en ligne de commande et surveiller ntdsutil.exe, diskshadow.exe, wbadmin.exe, esentutl.exe, vssadmin.exe, ainsi que des commandes « copy » ou PowerShell ciblant des chemins d'accès sensibles. La combinaison de 4672, 4688et 4663 C'est là que commencent les détections à haut niveau de confiance.


Comment détecter les utilisations abusives des clichés d'ombre

L'utilisation abusive des clichés instantanés mérite une attention particulière, car il s'agit de l'un des moyens les plus discrets de contourner les verrous de fichiers et de copier en toute discrétion des données sensibles à partir d'un système en production. Sur un contrôleur de domaine, cela signifie généralement que ntds.dit et le SYSTEM ruche. Par ailleurs, ce terme peut désigner les ruches de registre, les secrets d'application et les données de sauvegarde.

Pour bien détecter ce type d'incident, vous devez disposer d'un audit de la création des processus, d'un audit du système de fichiers sur les chemins d'accès sensibles, ainsi que d'une visibilité sur les connexions privilégiées. La journalisation en ligne de commande est essentielle, car le nom du processus ne permet pas à lui seul de déterminer si un instantané a été créé, exposé ou copié.

Parmi les indicateurs à signal fort, on peut citer vssadmin.exe, diskshadow.exe, wbadmin.exe, ntdsutil.exeet esentutl.exe dirigé par un non-SYSTEM utilisateur, en particulier sur un serveur DC, en dehors des plages horaires de sauvegarde connues ou à partir d'une session interactive. Les scripts DiskShadow lancés à partir de répertoires temporaires méritent une attention particulière.

L'un des indicateurs les plus significatifs est l'accès à des sentiers comportant HarddiskVolumeShadowCopy. Effectue des lectures à partir de ces chemins — en ciblant notamment ntds.dit, SYSTEMou SAM—par un non-SYSTEM L'utilisateur doit être considéré comme ayant commis un abus jusqu'à preuve du contraire.

  • 4672 affichant SeBackupPrivilege attribué à un opérateur de sauvegarde ou à un compte disposant de privilèges équivalents
  • 4688 affichant l'exécution d'outils liés à VSS, tels que diskshadow, vssadmin, wbadmin, ntdsutilou esentutl
  • 4663 affichant les lectures provenant d'un chemin d'accès à un clonage, ntds.dit, le SYSTEM ruche, SAM, ou une autre cible protégée
  • Activité se produisant dans un laps de temps très court, en particulier sur un contrôleur de domaine ou un autre système de niveau 0
  • Une utilisation interactive, une exécution ponctuelle ou une exécution en dehors du calendrier de sauvegarde habituel renforcent encore davantage la confiance

En résumé : « Backup Operators » mérite qu'on s'y intéresse

La fonction « Backup Operators » semble inoffensive, mais dans la pratique, elle frôle dangereusement la compromission totale du domaine.

Une exploitation de ce groupe sur un contrôleur de domaine (DC) peut exposer la base de données d'annuaire, contourner les détections axées sur la réplication, collecter des identifiants hors ligne et établir une persistance par le remplacement de fichiers protégés. Même sans accès au DC, ces mêmes droits peuvent exposer les identifiants de service, les secrets d'application et les voies d'escalade au sein de l'infrastructure serveur.

La bonne approche consiste à traiter ces comptes comme hautement sensibles. Veillez à ce que le groupe reste vide dans la mesure du possible, limitez les emplacements où ces comptes peuvent se connecter, surveillez les connexions privilégiées et l'accès aux fichiers sensibles, surveillez l'activité liée aux clichés instantanés et partez du principe qu'une compromission est critique jusqu'à ce que vous puissiez exclure tout accès aux données critiques.

Suivez les discussions sur les opérateurs de sauvegarde sur LinkedIn.

Et si vous souhaitez bénéficier de l'aide d'experts pour identifier et combler les failles de sécurité de votre AD, n'hésitez pas à demander une évaluation de la sécurité d'Active Directory. Nous sommes là pour vous aider.

Pour en savoir plus