Active Directory ACL DPAPI Tombstone Schema Permissions Audit: 3 Rights Nobody Checks

What Is an Active Directory ACL, DPAPI, Tombstone, Schema Permissions Audit?

A complete active directory acl dpapi tombstone schema permissions audit checks far more than GenericAll and DCSync. A typical ACL audit — whether done manually with dsacls and PowerView, or with a tool like BloodHound — focuses on a well-known shortlist: GenericAll, GenericWrite, WriteDACL, WriteOwner, and the replication rights behind DCSync. That shortlist is correct, but it is not complete. Three other ACL-adjacent rights are just as dangerous and rarely make it into a checklist: non-default access to the DPAPI domain backup key, the Reanimate-Tombstones extended right, and non-standard permissions on the AD schema. They are dangerous for the same underlying reason as GenericAll — a principal outside the expected admin tier can use them to read secrets, resurrect stale objects, or plant a persistence mechanism that survives object deletion and password resets — but they don't show up in most ACL-abuse content because they aren't ordinary object ACEs on user or computer objects. This article covers what each right actually grants, how it gets abused, and how to detect and remediate it.

For the more commonly audited paths, see ACL Abuse and DCSync: The Silent Paths to Domain Admin.

Right #1 — Non-Default Access to the DPAPI Domain Backup Key

Windows' Data Protection API (DPAPI) protects secrets at rest — saved browser passwords, Wi-Fi profiles, RDP credentials, EFS certificates, Credential Manager entries — by encrypting them with a key derived from the user's password. In a domain, every user's DPAPI master key is also encrypted with a domain-wide DPAPI backup key, so that a lost or expired user password doesn't mean permanently lost data. That backup key is generated once, at domain creation, and stored as BCKUPKEY_* LSA secrets replicated to every domain controller (Microsoft Learn: DPAPI backup keys on AD domain controllers).

How Attackers Retrieve the Backup Key

By default, retrieving the backup key requires Domain Admin–equivalent rights over the LSA policy object. Tools like Mimikatz (lsadump::backupkeys) and SharpDPAPI pull it via the MS-LSAD/LSARPC LsaOpenPolicy / LsaRetrievePrivateData calls; DSInternals documents the same retrieval path with Get-LsaBackupKey (DSInternals: Retrieving DPAPI Backup Keys from Active Directory). The audit question isn't "does the backup key exist" — it always does — it's "which principals, beyond Domain Admins, currently hold rights that let them read it." That access is usually granted indirectly: delegated LSA secret rights, an over-broad GPO, or a service account added to a privileged group for an unrelated reason.

Right #2 — The Reanimate-Tombstones Extended Right

Active Directory extends the standard ACE model with control access rights — permissions that aren't tied to a specific attribute or bit in an access mask, but identified by a GUID and checked against the whole object. Reanimate-Tombstones (GUID 45ec5156-db7e-47bb-b53f-dbeb2d03c40f) is one of them: it lets its holder restore a deleted (tombstoned) object anywhere in a naming context, and by default it is granted only at the naming-context root to Domain Admins / Enterprise Admins (Microsoft: Reanimate-Tombstones extended right, Microsoft: Restoring Deleted Objects).

Why a Delegated Grant Is a Privilege-Escalation Path

The abuse case is subtle but real: a tombstoned or recycled object can retain most of its original attributes — SID history, group memberships, SPNs — for the tombstone lifetime (or indefinitely in the Recycle Bin if it's enabled but not emptied). A principal who has been delegated Reanimate-Tombstones outside the default admin tier can restore a deleted privileged account or group, effectively resurrecting an access path that was believed to be closed. CravateRouge's research into the AD Recycle Bin as a privilege-escalation surface documents concrete scenarios for this (Have You Looked in the Trash? Unearthing Privilege Escalations from the AD Recycle Bin). The right is easy to miss precisely because auditors look at current object ACLs and forget to check extended rights delegated at the partition root, which is where this one lives. For more on how this kind of delegated access accumulates over time, see Privileged Access Drift Active Directory.

Right #3 — Non-Standard Permissions on the AD Schema

The schema naming context defines every class and attribute in the forest. By default, write access to it is restricted to the Schema Admins group (plus Enterprise Admins at the forest root); this is intentional, because schema changes are forest-wide and largely irreversible — attributes and classes can be deactivated but not deleted (Semperis: NSA Top Ten Cybersecurity Misconfigurations — An AD Perspective).

Why Schema Write Access Is a Forest-Wide Persistence Primitive

Write access to the schema is a bigger prize than it looks. One attribute in particular, defaultSecurityDescriptor on a classSchema object, defines the DACL template applied to every future object created of that class — meaning an attacker with schema write access can embed a backdoor ACE (for example, granting a low-privileged account WriteDACL) into the default security descriptor for the user or group class, so that every account or group created afterward inherits attacker-controlled permissions from the moment it's created. This is a well-documented persistence primitive, and it also crosses domain boundaries within a forest since the schema is forest-wide (itm8: Schema change trust attack — from child to parent), (BorderGate: Active Directory Schema Modification Attacks). In practice, non-standard schema ACEs are usually leftovers from third-party product installers (Exchange, certain backup/AD-management tools) that requested broader-than-needed schema rights during setup and were never walked back.

Detection

All three rights need the right audit-policy subcategories enabled on domain controllers before they generate anything useful in the Security event log.

Event 4662 auditing for the backup key needs Success auditing on Audit Other Object Access Events enabled on every DC — it is off by default (DSInternals: Detecting DPAPI Backup Key Theft). The Directory Service Changes subcategory generates 5136 (modified), 5137 (created), 5138 (undeleted), 5139 (moved) and 5141 (deleted) for any object that carries a matching SACL entry (Microsoft: Event 5136 — A directory service object was modified) — but only for objects and attributes you've explicitly put a SACL on, so the naming-context root and the Schema container both need one added manually (ADSI Edit → Properties → Security → Advanced → Auditing).

More event IDs worth wiring up alongside these three are covered in Active Directory Monitoring: Security Event IDs That Matter.

Remediation

Fix DPAPI Backup Key Exposure

There is no supported way to rotate the domain backup key (Microsoft Learn: DPAPI backup keys on AD domain controllers), so treat access to it as tightly as krbtgt. Review delegated LSA secret rights and privileged group membership regularly; if the key is confirmed compromised, Microsoft's own recovery guidance is limited enough that a full forest/domain recovery plan should already exist before you need it (SANS: Critical Confusion — Microsoft's Domain Compromise Recovery Guidance).

Fix Reanimate-Tombstones Delegation

Enumerate ACEs on each naming-context root for the control access right GUID 45ec5156-db7e-47bb-b53f-dbeb2d03c40f (dsacls or PowerView's Get-ObjectAcl -ResolveGUIDs). Remove any grant outside Domain Admins/Enterprise Admins, and require a documented change ticket for legitimate delegated restores.

Fix Non-Standard Schema Permissions

Run dsacls against CN=Schema,CN=Configuration,DC=<forest-root> and confirm write access is limited to Schema Admins (and Enterprise Admins at the forest root). Pay particular attention to any ACE touching defaultSecurityDescriptor on user, group, or computer classSchema objects — that's the highest-value target for a persistence backdoor.

Add SACLs for Future Drift Detection

Add SACLs on the naming-context root and the Schema container as described in Detection above, so future drift shows up in the Security log instead of being discovered during the next manual audit. For a broader hardening baseline beyond these three rights, see Hardening Active Directory: What to Lock Down First and How to Validate It and What Are the Most Common Active Directory Security Misconfigurations?.

How EtcSec Detects This

EtcSec checks all three of these during every Active Directory audit: DPAPI_KEY_NON_DEFAULT_ACCESS flags principals holding rights over the domain backup key outside the expected admin tier, REANIMATE_TOMBSTONES_RIGHT flags non-default grants of the control access right at the naming-context root, and SCHEMA_NON_STANDARD_PERMISSIONS flags ACEs on the schema naming context outside Schema Admins/Enterprise Admins. These sit alongside the more familiar ACL_GENERICALL check so the same audit pass covers both the well-known ACL-abuse paths and the ones most tooling skips.