Shadow Credentials or AdminSDHolder Persistence Response (Medium–High Impact)
Steps to dismantle the persistence mechanism and close the authentication backdoor when msDS-KeyCredentialLink addition (Shadow Credentials) or AdminSDHolder DACL modification is detected.
msDS-KeyCredentialLink attribute to a target computer or user object, enabling authentication via Kerberos PKINIT without requiring PKI infrastructure. In AdminSDHolder modification, because the SDProp mechanism reapplies permissions at regular intervals, rogue ACEs may return after being cleaned up. In both cases, identify the source privileged account and conduct a comprehensive AD object audit before remediation.Prepare
5 steps- Audit policy
On DCs, `Audit Directory Service Changes` (Success) must be enabled; a SACL "Write" audit for the `msDS-KeyCredentialLink` attribute on user and computer objects must be configured.
- AdminSDHolder snapshot
The output of `Get-Acl "AD:CN=AdminSDHolder,CN=System,DC=domain,DC=com"` must be stored as an encrypted, immutable reference file; restore is not possible without this file.
- Know the SDProp cycle
The value of `HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\AdminSDProtectFrequency` must be known (default 3600 seconds / 60 minutes); the last SDProp run time must be assessed.
- Tool readiness
DSInternals (`Get-ADKeyCredential`, `Remove-ADKeyCredential`), Whisker or pyWhisker must be ready for IR analysis; BloodHound must be accessible.
- Escalation
AD administrator (T0) + CISO; if a TGT has been obtained via Shadow Credentials, the IR lead is engaged.