Audit ACL Active Directory DPAPI Tombstone Schema : 3 droits que personne ne vérifie

Qu'est-ce qu'un audit ACL Active Directory DPAPI, Tombstone, Schema ?

Un audit complet des droits ACL Active Directory DPAPI, Tombstone, Schema va bien au-delà de GenericAll et DCSync. Un audit ACL classique — qu'il soit réalisé manuellement avec dsacls et PowerView, ou avec un outil comme BloodHound — se concentre sur une liste bien connue : GenericAll, GenericWrite, WriteDACL, WriteOwner, et les droits de réplication derrière DCSync. Cette liste est correcte, mais incomplète. Trois autres droits proches des ACL sont tout aussi dangereux et figurent rarement dans une checklist : l'accès non standard à la clé de sauvegarde de domaine DPAPI, le droit étendu Reanimate-Tombstones, et des permissions non standard sur le schéma AD. Ils sont dangereux pour la même raison fondamentale que GenericAll — un principal en dehors du tier d'administration attendu peut s'en servir pour lire des secrets, ressusciter des objets obsolètes, ou implanter un mécanisme de persistance qui survit à la suppression d'objets et aux réinitialisations de mot de passe — mais ils n'apparaissent pas dans la plupart des contenus sur l'abus d'ACL car ce ne sont pas des ACE ordinaires sur des objets utilisateur ou ordinateur. Cet article détaille ce que chaque droit accorde réellement, comment il est exploité, et comment le détecter et le corriger.

Pour les chemins plus couramment audités, voir Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin.

Droit n°1 — Accès non standard à la clé de sauvegarde de domaine DPAPI

La Data Protection API (DPAPI) de Windows protège les secrets au repos — mots de passe de navigateur enregistrés, profils Wi-Fi, identifiants RDP, certificats EFS, entrées du Gestionnaire d'identification — en les chiffrant avec une clé dérivée du mot de passe de l'utilisateur. Dans un domaine, la clé maître DPAPI de chaque utilisateur est également chiffrée avec une clé de sauvegarde DPAPI propre au domaine, afin qu'un mot de passe utilisateur perdu ou expiré ne signifie pas une perte de données définitive. Cette clé de sauvegarde est générée une seule fois, à la création du domaine, et stockée comme secrets LSA BCKUPKEY_* répliqués vers chaque contrôleur de domaine (Microsoft Learn : clés de sauvegarde DPAPI sur les contrôleurs de domaine AD).

Comment les attaquants récupèrent la clé de sauvegarde

Par défaut, récupérer la clé de sauvegarde nécessite des droits équivalents à Domain Admin sur l'objet de stratégie LSA. Des outils comme Mimikatz (lsadump::backupkeys) et SharpDPAPI la récupèrent via les appels MS-LSAD/LSARPC LsaOpenPolicy / LsaRetrievePrivateData ; DSInternals documente le même chemin de récupération avec Get-LsaBackupKey (DSInternals : récupérer les clés de sauvegarde DPAPI depuis Active Directory). La question d'audit n'est pas « la clé de sauvegarde existe-t-elle » — elle existe toujours — mais « quels principaux, au-delà des Domain Admins, détiennent actuellement des droits leur permettant de la lire ». Cet accès est généralement accordé indirectement : droits LSA délégués, GPO trop permissive, ou compte de service ajouté à un groupe privilégié pour une raison sans rapport.

Droit n°2 — Le droit étendu Reanimate-Tombstones

Active Directory étend le modèle d'ACE standard avec des control access rights — des permissions qui ne sont pas liées à un attribut ou un bit spécifique du masque d'accès, mais identifiées par un GUID et vérifiées sur l'objet entier. Reanimate-Tombstones (GUID 45ec5156-db7e-47bb-b53f-dbeb2d03c40f) en fait partie : il permet à son détenteur de restaurer un objet supprimé (tombstoné) n'importe où dans un naming context, et par défaut il n'est accordé qu'à la racine du naming context aux Domain Admins / Enterprise Admins (Microsoft : droit étendu Reanimate-Tombstones, Microsoft : restaurer des objets supprimés).

Pourquoi une délégation de ce droit est un chemin d'escalade de privilèges

Le cas d'abus est subtil mais réel : un objet tombstoné ou recyclé peut conserver la plupart de ses attributs d'origine — SID history, appartenances à des groupes, SPN — pendant la durée de vie du tombstone (ou indéfiniment dans la Corbeille AD si elle est activée mais jamais vidée). Un principal ayant reçu une délégation de Reanimate-Tombstones en dehors du tier d'administration par défaut peut restaurer un compte ou groupe privilégié supprimé, ressuscitant effectivement un chemin d'accès censé être fermé. Les recherches de CravateRouge sur la Corbeille AD comme surface d'escalade de privilèges documentent des scénarios concrets (Have You Looked in the Trash? Unearthing Privilege Escalations from the AD Recycle Bin). Ce droit est facile à manquer précisément parce que les auditeurs examinent les ACL actuelles des objets et oublient de vérifier les droits étendus délégués à la racine de la partition, où celui-ci se trouve. Pour en savoir plus sur la façon dont ce type d'accès délégué s'accumule dans le temps, voir Dérive des Accès Privilégiés Active Directory.

Droit n°3 — Permissions non standard sur le schéma AD

Le naming context du schéma définit toutes les classes et attributs de la forêt. Par défaut, l'accès en écriture y est restreint au groupe Schema Admins (plus les Enterprise Admins à la racine de la forêt) ; c'est intentionnel, car les modifications de schéma sont valables pour toute la forêt et largement irréversibles — les attributs et classes peuvent être désactivés mais pas supprimés (Semperis : NSA Top Ten Cybersecurity Misconfigurations — An AD Perspective).

Pourquoi l'écriture sur le schéma est une primitive de persistance à l'échelle de la forêt

L'accès en écriture au schéma est un enjeu plus important qu'il n'y paraît. Un attribut en particulier, defaultSecurityDescriptor sur un objet classSchema, définit le modèle de DACL appliqué à tout objet futur créé de cette classe — ce qui signifie qu'un attaquant disposant d'un accès en écriture au schéma peut implanter une ACE de porte dérobée (par exemple, accorder WriteDACL à un compte peu privilégié) dans le security descriptor par défaut de la classe user ou group, de sorte que chaque compte ou groupe créé par la suite hérite de permissions contrôlées par l'attaquant dès sa création. C'est une primitive de persistance bien documentée, qui traverse aussi les frontières de domaine au sein d'une forêt puisque le schéma est valable pour toute la forêt (itm8 : Schema change trust attack — from child to parent), (BorderGate : Active Directory Schema Modification Attacks). En pratique, des ACE non standard sur le schéma sont généralement des restes d'installateurs de produits tiers (Exchange, certains outils de sauvegarde/gestion AD) qui ont demandé des droits de schéma plus larges que nécessaire lors de l'installation, et qui n'ont jamais été retirés.

Détection

Ces trois droits nécessitent d'activer les bonnes sous-catégories de la stratégie d'audit sur les contrôleurs de domaine avant de générer quoi que ce soit d'exploitable dans le journal de sécurité.

L'audit de l'événement 4662 pour la clé de sauvegarde nécessite l'audit des succès sur Audit Other Object Access Events activé sur chaque DC — il est désactivé par défaut (DSInternals : détecter le vol de la clé de sauvegarde DPAPI). La sous-catégorie Directory Service Changes génère les événements 5136 (modifié), 5137 (créé), 5138 (non supprimé), 5139 (déplacé) et 5141 (supprimé) pour tout objet portant une entrée SACL correspondante (Microsoft : événement 5136 — A directory service object was modified) — mais uniquement pour les objets et attributs sur lesquels vous avez explicitement placé une SACL, donc la racine du naming context et le conteneur Schema doivent tous deux en recevoir une manuellement (ADSI Edit → Properties → Security → Advanced → Auditing).

D'autres Event IDs à surveiller en complément de ces trois-là sont couverts dans Supervision Active Directory : les Event IDs de sécurité qui comptent.

Remédiation

Corriger l'exposition de la clé de sauvegarde DPAPI

Il n'existe aucun moyen supporté de faire tourner la clé de sauvegarde du domaine (Microsoft Learn : clés de sauvegarde DPAPI sur les contrôleurs de domaine AD), traitez donc son accès aussi strictement que le krbtgt. Revoyez régulièrement les droits LSA délégués et l'appartenance aux groupes privilégiés ; si la clé est confirmée compromise, les recommandations de récupération de Microsoft sont suffisamment limitées pour qu'un plan complet de récupération de forêt/domaine doive déjà exister avant que vous en ayez besoin (SANS : Critical Confusion — Microsoft's Domain Compromise Recovery Guidance).

Corriger la délégation de Reanimate-Tombstones

Recensez les ACE sur chaque racine de naming context pour le control access right GUID 45ec5156-db7e-47bb-b53f-dbeb2d03c40f (dsacls ou Get-ObjectAcl -ResolveGUIDs de PowerView). Retirez tout octroi en dehors de Domain Admins/Enterprise Admins, et exigez un ticket de changement documenté pour toute restauration déléguée légitime.

Corriger les permissions non standard du schéma

Exécutez dsacls contre CN=Schema,CN=Configuration,DC=<forest-root> et confirmez que l'accès en écriture est limité à Schema Admins (et Enterprise Admins à la racine de la forêt). Portez une attention particulière à toute ACE touchant defaultSecurityDescriptor sur les objets classSchema user, group ou computer — c'est la cible la plus intéressante pour une porte dérobée de persistance.

Ajouter des SACL pour détecter la dérive future

Ajoutez des SACL sur la racine du naming context et sur le conteneur Schema comme décrit dans la section Détection ci-dessus, afin que toute dérive future apparaisse dans le journal de sécurité au lieu d'être découverte lors du prochain audit manuel. Pour une base de durcissement plus large au-delà de ces trois droits, voir Durcissement Active Directory : que verrouiller en premier et comment le valider et Quelles sont les mauvaises configurations de sécurité Active Directory les plus courantes ?.

Comment EtcSec détecte cela

EtcSec vérifie ces trois éléments lors de chaque audit Active Directory : DPAPI_KEY_NON_DEFAULT_ACCESS signale les principaux détenant des droits sur la clé de sauvegarde de domaine en dehors du tier d'administration attendu, REANIMATE_TOMBSTONES_RIGHT signale les octrois non standard du control access right à la racine du naming context, et SCHEMA_NON_STANDARD_PERMISSIONS signale les ACE sur le naming context du schéma en dehors de Schema Admins/Enterprise Admins. Ces contrôles s'ajoutent au contrôle plus familier ACL_GENERICALL, afin que le même audit couvre à la fois les chemins d'abus d'ACL bien connus et ceux que la plupart des outils ignorent.