Detecting Persistence

Less Trust, Less Damage

Attack paths shrink once permissions, segments, and management channels are consistently configured.

In Detecting Persistence, value emerges when detection is directly actionable for follow-up, not just for reporting.

This way, you not only reduce the likelihood of incidents, but especially the scope and duration when something does go wrong.

Immediate actions (15 minutes)

• Start with MFA, least privilege, and tiering for admin accounts.
• Enforce segmentation and explicit firewall rules on critical paths.
• Ensure logging, detection, and recovery tests are a structural operation.

Why this matters

The core of Detecting Persistence is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Detection and defense

Detection Matrix

Defense Layers

Layer 1: Prevention

# Enable LSA Protection
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
  -Name "RunAsPPL" -Value 1 -PropertyType DWORD

# Enable Credential Guard (via Group Policy)
# Computer Configuration > Administrative Templates > System > Device Guard
# > Turn On Virtualization Based Security > Credential Guard: Enabled

LSA Protection prevents Custom SSP and Skeleton Key. Credential Guard isolates credentials so that even a compromised kernel cannot access them.

Layer 2: Monitoring

The absolute minimum set of monitoring for persistence detection:

# Sysmon configuration (relevant excerpts)
- Event 13: Registry value changes
  Filter on: \Control\Lsa\Security Packages
  Filter on: \Control\Lsa\DsrmAdminLogonBehavior

# Windows Security Event Log
- Event 4780: ACL change on protected object (SDProp-related)
- Event 5136: Directory service object change
- Event 4794: DSRM password setting
- Event 4769: Kerberos TGS requests (filter on RC4 encryption)

Layer 3: Regular audits

# Check AdminSDHolder ACL
(Get-Acl "AD:\CN=AdminSDHolder,CN=System,DC=domain,DC=local").Access |
  Format-Table IdentityReference, ActiveDirectoryRights

# Check Security Packages registry
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\ `
  -Name 'Security Packages'

# Check DsrmAdminLogonBehavior
Get-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa\ `
  -Name "DsrmAdminLogonBehavior" -ErrorAction SilentlyContinue

Run these checks monthly. Better yet: automate them and alert on deviations.

Layer 4: Incident Response

When you discover persistence, the chain of actions depends on the method:

That last one -- Golden Certificate -- is reason enough to store your CA key in an HSM. A full PKI reissuance is an operation that takes weeks and affects the entire network.

The reality of "we have cleaned everything up"

Let us be honest about the incident response process at most organizations. The SOC discovers a compromise. A crisis team is assembled. Passwords are reset, workstations are reimaged, and VPN access is disabled. After two weeks of intensive work, management declares: "We have the situation under control. The attacker has been removed."

And maybe that is true. Maybe.

But have you checked the AdminSDHolder ACL? Have you inspected the Security Packages in the registry of every DC? Have you checked the DsrmAdminLogonBehavior on every DC? Have you audited the WMI security descriptors? Have you rotated the CA private key? Have you checked the SIDHistory of all accounts?

In the vast majority of cases, the answer is: no. Not out of unwillingness, but out of ignorance. Most incident response teams focus on workstations and servers -- files, processes, network connections. They look for malware. For C2 channels. For indicators of compromise that are in their SIEM rules.

But the persistence mechanisms in this chapter do not live on workstations. They live in Active Directory itself. In ACLs. In security descriptors. In registry keys on the DC. In the memory of LSASS. Places where the incident response team does not look, because it does not know it should look there.

It is like a hospital team treating a patient for a broken leg while a tumor is growing that nobody has noticed. The leg heals. The patient goes home. And three months later things go wrong again, and nobody understands why.

The lesson is simple but uncomfortable: an incident response is only complete when you have actively searched for -- and ruled out -- every persistence method the attacker could have implemented. Not the methods you know. All methods. And that requires knowledge that most teams do not have, time that management does not want to give, and tools that most organizations do not possess.

"We have patched everything." No, you have repaired the front door. The attacker is still in the basement.

The cleanup problem

There is another dimension that makes all of this more complex: even when you know which persistence mechanisms exist, removing them is not trivial. Take the AdminSDHolder backdoor. You find the malicious ACE, you remove it. But have you also checked all protected groups? SDProp has already copied the ACE to Domain Admins, Enterprise Admins, and all other protected groups. You must remove the ACE from AdminSDHolder and from every group it has been copied to. Miss one, and the backdoor still works.

Or take the Custom SSP. You find the DLL in System32 and the registry entry. You remove both. But have you checked the log file? C:\Windows\system32\mimilsa.log is full of cleartext passwords. If the attacker has already exfiltrated that file, all those passwords are compromised -- even after removing the SSP. You must then reset all passwords of everyone who logged in since the SSP was active.

And with the Golden Certificate: if the CA private key has been stolen, there is really only one solution that provides guarantees: a full PKI reinstallation. New CA. New root key. New certificates for everyone. In an environment with thousands of systems, that is a project of months.

The hard truth is that some persistence mechanisms go so deep that the only reliable solution is a full domain rebuild: a new forest, new DCs, new accounts, controlled data migration. That is the nuclear option. But sometimes it is the only option.

Persistence audit checklist

As a pen tester or as a defender: use this checklist after every compromise to systematically rule out persistence:

Active Directory level:
[ ] AdminSDHolder ACL checked for unauthorized ACEs
[ ] SIDHistory of all accounts checked (no suspicious SIDs)
[ ] All GP links and GPOs checked for malicious scripts
[ ] All certificate templates checked for modifications
[ ] CA configuration checked (EDITF_ATTRIBUTESUBJECTALTNAME2)
[ ] Kerberos krbtgt password reset twice (golden ticket invalidation)
[ ] Replication metadata checked for DCShadow traces

Domain Controller level (per DC):
[ ] Security Packages registry key checked
[ ] DsrmAdminLogonBehavior registry key checked
[ ] WMI namespace security descriptors checked
[ ] WinRM endpoint security descriptors checked
[ ] Remote Registry security descriptors checked
[ ] Scheduled tasks checked
[ ] Services checked
[ ] DLLs in System32 checked against baseline
[ ] LSASS memory analyzed (Skeleton Key, custom SSP)

PKI level:
[ ] CA private key integrity verified
[ ] All issued certificates reviewed
[ ] Unexpected certificates revoked

Account level:
[ ] All passwords reset (including service accounts)
[ ] DSRM passwords reset on every DC
[ ] All Kerberos tickets invalidated

Persistence prioritization

Not all persistence methods are equal. As an attacker, you choose based on your situation:

The most robust strategy combines multiple methods across different categories: an ACL-based method (AdminSDHolder), a credential-harvest method (Custom SSP), and an authentication backdoor (DSRM or Golden Certificate). Redundancy is key -- if the incident response team finds one method, you still have two left.

In the next chapter, we cover tunneling control -- how to prevent, detect, and block unwanted hidden connections in production environments.