Active Directory Post-Breach Persistence: Why Password Resets Fail

The Persistence Myth: Why Passwords are Not Enough

A common misconception in incident response is that a domain-wide password reset is a silver bullet for evicting an APT or Ransomware actor. However, according to Bleeping Computer, resetting a user’s password does not necessarily terminate their active sessions or invalidate the tokens they have already harvested. When an attacker gains Privilege Escalation within an Active Directory (AD) environment, they often pivot from simple credential theft to more sophisticated TTP sets that bypass the standard authentication flow.

Traditional Phishing attacks might capture a password, but modern Lateral Movement relies on the exploitation of authentication protocols like Kerberos and the underlying MSV1_0 authentication package. If an organization does not address these architectural persistence mechanisms, an attacker can maintain a presence long after the initial entry point has been closed.

Mechanism of MSV1_0 Credential Caching

One often overlooked area of persistence is MSV1_0 credential caching. This authentication package is responsible for handling local logons and NT hash-based authentication. When a user logs into a workstation, Windows caches a derivative of their credentials to allow for subsequent logons even if the Domain Controller (DC) is unreachable.

During a breach, if an attacker has established a C2 channel on a compromised host, they can scrape these cached credentials from memory. Changing the user’s password in AD updates the central database but does not automatically clear the local cache on every endpoint. This allows for continued access if the attacker utilizes tools to simulate local logon or leverage existing session handles. This highlights the limitation of relying solely on password changes without implementing Zero Trust principles that require continuous verification of every access request.

How to Mitigate Kerberos Ticket Theft in Compromised Domains

Kerberos is the primary authentication protocol in AD, and it is the most frequent target for maintaining Active Directory post-breach persistence. When a user authenticates, they receive a Ticket Granting Ticket (TGT), which is then used to request Service Tickets (ST) for specific resources. By default, a TGT is valid for 10 hours and can be renewed for up to seven days.

If an attacker steals a TGT (a technique known as Pass-the-Ticket), simply changing the user’s password does not invalidate the stolen ticket. The DC will continue to honor the ticket until it expires because the ticket was encrypted with a key derived from the password at the time of issuance. To effectively mitigate this, SOC teams must force the expiration of all issued tickets, a process that is often disruptive but necessary for total eviction. This requires a coordinated effort to purge the Ticket Granting Service (TGS) cache on affected systems and potentially forcing a logoff for all active sessions.

The Role of the KRBTGT Account

The most critical component of Kerberos security is the krbtgt account. This account’s password hash is used to encrypt and sign all TGTs within the domain. If an attacker gains enough privilege to perform a “Golden Ticket” attack, they have essentially compromised the entire domain’s trust.

In this scenario, a password reset for individual users is entirely ineffective. The attacker can forge a TGT for any user, with any group membership, at any time. Security professionals must prioritize the double reset of the krbtgt account password. Because AD stores the current and the previous password for this account to prevent authentication breakage during the reset, a single reset is insufficient. A second reset must be performed after the first has replicated throughout the environment and after the 10-hour TGT lifetime has elapsed to ensure all forged tickets become invalid.

Actionable Recommendations for Incident Response

To ensure a successful eviction, defenders should align their response with the MITRE ATT&CK framework and follow these steps:

• Double Reset of KRBTGT: Perform two password resets for the krbtgt account, spaced at least 10 to 24 hours apart to allow for replication and ticket expiration.
• Session Invalidation: Beyond password resets, use administrative tools to force the termination of all active RDP and SMB sessions across the network.
• Purge Kerberos Tickets: Deploy scripts to run klist purge across all endpoints to clear potentially compromised Service Tickets from the local system context.
• Monitor for Anomalous Ticket Usage: Utilize SIEM and EDR tools to alert on TGTs with unusually long lifetimes or tickets issued for accounts that have recently undergone a password change.
• Audit Certificate Authorities: Attackers may also use AD Certificate Services to maintain persistence via forged certificates. Review all recently issued certificates for suspicious patterns or unauthorized templates.