Establishing Stealthy Persistence in Active Directory

Gaining Domain Admin privileges in an Active Directory (AD) environment is the primary objective of most Red Team operations. However, getting to the top is only half the battle; staying there is much harder.

Once the Blue Team realizes they are under attack, their immediate response is to initiate the incident response playbook: resetting administrator passwords, rotating service account credentials, and rebooting servers. If a Red Team relies solely on a stolen password or a single web shell, their access will be wiped out in minutes.

To survive remediation, Red Teams must establish stealthy, deeply embedded persistence within the architecture of Active Directory itself. In this post, we will explore advanced persistence techniques that go far beyond standard malware.

The Problem with the Golden Ticket

The most famous AD persistence mechanism is the Golden Ticket (forging a Ticket Granting Ticket using the stolen krbtgt hash). While highly effective, it has become well-known. A mature incident response team will initiate a double-reset of the krbtgt account password during an eviction, immediately invalidating any forged tickets.

Advanced attackers look for persistence mechanisms that survive global password resets and don't rely on easily monitored Kerberos anomalies.

Technique 1: The DSRM Administrator Backdoor

Every Domain Controller (DC) has a local administrator account known as the Directory Services Restore Mode (DSRM) account. It is created when the DC is first promoted and is intended strictly for disaster recovery.

By default, you can only log in with the DSRM account from the physical console of the Domain Controller. However, if an attacker achieves Domain Admin rights, they can change this behavior by modifying a single registry key on the DC:

New-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -Value 2 -PropertyType DWORD

Setting this value to 2 allows the DSRM account to log in over the network. The attacker then resets the DSRM password or extracts its NTLM hash. Even if the Blue Team resets every single domain user password (including the Domain Admins), the DSRM account remains untouched, allowing the attacker to seamlessly pass-the-hash and log straight back into the Domain Controller over the network.

Technique 2: Abusing AdminSDHolder and SDProp

Active Directory has a built-in mechanism designed to protect highly privileged accounts (like Domain Admins and Enterprise Admins). A background process called SDProp runs every 60 minutes. It takes the permissions (ACLs) defined on a special container called AdminSDHolder and automatically copies them to every privileged account in the domain.

Attackers can brilliantly abuse this defensive feature for persistence.

The attacker creates a seemingly harmless, low-privileged standard user account (e.g., Backup_Service_User). They then modify the Access Control List on the AdminSDHolder container, explicitly granting Backup_Service_User "Full Control" over the container.

When SDProp runs 60 minutes later, it stamps that "Full Control" permission onto every Domain Admin account. The Blue Team can delete the attacker's malware, reset passwords, and manually remove the attacker's rights from the Domain Admin group. But within an hour, SDProp will automatically reinstate the attacker's backdoor access.

Technique 3: Malicious Security Support Providers (SSP)

Windows uses Security Support Providers (SSPs) to handle authentication (like NTLM or Kerberos). Attackers with SYSTEM access on a Domain Controller can inject their own custom SSP into the Local Security Authority (LSA).

When a user types their password, the LSA passes it to the SSPs to authenticate. A malicious SSP intercepts the plaintext passwords as they are being typed in real-time and logs them to a hidden file on the disk (or sends them out over the network). As long as the malicious SSP DLL remains registered in the system registry, the attacker has a continuous, real-time feed of all Domain Admin passwords, regardless of how often the Blue Team resets them.

Defending Against AD Persistence

Rooting out deeply embedded AD persistence is incredibly difficult. It requires continuous monitoring of Active Directory ACLs.

1. Monitor the DSRM Account: Alert on any registry changes to DsrmAdminLogonBehavior and routinely rotate the DSRM password using LAPS (Local Administrator Password Solution).
2. Audit AdminSDHolder: Regularly audit the ACLs on the AdminSDHolder container to ensure only legitimate administrative groups have access to it.
3. Enforce Tiered Administration: Prevent Domain Admins from logging into standard workstations or internet-exposed servers. This drastically reduces the likelihood of an attacker scraping the high-privileged credentials needed to execute these persistence techniques in the first place.

Conclusion

True Active Directory persistence doesn't rely on malware executables; it relies on manipulating the very rules and processes the operating system uses to function. By understanding how attackers abuse DSRM, SDProp, and SSPs, defenders can implement the precise monitoring needed to ensure an eviction is truly final.