Resetting a compromised Active Directory password does not automatically remove an attacker’s access. Previously issued Kerberos tickets, application sessions, separately compromised service accounts and altered directory permissions can provide access after the affected user’s password changes.
These mechanisms differ from offline cached logons, which support local access to a device. Cached logon verifiers are not interchangeable with the password hashes used to authenticate to other computers.
Tickets and application sessions can outlast a password change
Kerberos uses tickets to authenticate access without requiring a password for every request. Microsoft’s security guidance states that resetting an affected account’s password prevents an attacker from obtaining new Kerberos tickets with its stolen password hash, while previously issued tickets can remain usable until they expire. Microsoft’s emergency-revocation guidance also identifies delayed on-premises password replication as a limitation when addressing pass-the-hash exposure.
Application sessions present a separate issue in Microsoft Entra ID environments. Microsoft’s emergency access-revocation guidance distinguishes disabling accounts and revoking refresh tokens from ending access already granted through access tokens or application-issued session cookies.
Microsoft states that Entra ID cannot directly revoke a session token issued by an application. The application controls that session under its own authorization policies, so blocking new authentication does not necessarily terminate existing application access immediately.
Hybrid password synchronization adds another timing consideration. Microsoft says Entra Connect Sync’s password hash synchronization process runs every two minutes, with on-premises password changes most often reaching the cloud within minutes. Failed synchronization attempts are retried; the polling interval does not guarantee completion. Microsoft also states that synchronizing a password change does not itself interrupt a user’s current cloud-service session.
Cached logons have a different scope
Windows caches domain logon information so users can sign in locally when a domain controller is unavailable. An older password can remain usable for that local sign-in if the cached information has not been updated. Microsoft’s documentation specifically notes that a cloud password change does not update the local cached verifier.
That does not make the verifier a reusable network credential. Microsoft’s credential documentation states that cached domain logon verifiers can only validate a credential locally and cannot be presented to another computer for authentication. Pass-the-hash attacks instead use stolen NT password hashes.
A cached logon without domain-controller validation does not provide access to network resources that require domain validation. Local access and access to resources that do not require that validation remain separate concerns.
Service accounts retain separate credentials
Service accounts support applications, scheduled tasks, scripts and other automated processes. Their credentials are separate from those of an affected user, so resetting that user’s password does not rotate a compromised service account’s password.
Microsoft’s account-security assessments identify service accounts in privileged groups as a risk because compromising one can grant broad administrative access. The assessments also note that long-lived credentials and limited interactive monitoring can make malicious activity under these accounts harder to identify.
Changing service-account credentials can affect dependent applications and services. Group Managed Service Accounts provide Windows-managed passwords for supported services, but that account-management capability is distinct from terminating existing sessions or correcting directory permissions.
Forged tickets involve other account secrets
Golden Ticket attacks involve compromised KRBTGT credentials, which an attacker can use to forge Kerberos ticket-granting tickets. Resetting the password of an impersonated user does not change the KRBTGT credentials used to create those tickets.
In historical research, security researcher Sean Metcalf described Silver Tickets as forged Kerberos service tickets created using a compromised service or computer account’s password hash. His description limits their scope to the targeted service on a particular server. This is a separate credential compromise from theft of an individual user’s password.
Microsoft’s forest-recovery procedure calls for resetting the KRBTGT password twice. It specifies a 10-hour wait between resets under default ticket-lifetime settings and requires a waiting period greater than the configured maximum lifetime when those settings change. That domain-recovery procedure is distinct from an ordinary user password reset.
Directory permissions can preserve access
Active Directory permissions govern actions such as resetting passwords, modifying group membership and controlling directory objects. A password reset does not remove unauthorized permissions or privileged group memberships established during an intrusion. Those rights can allow an attacker-controlled account to re-establish access without knowing the affected user’s new password.
AdminSDHolder provides a specific persistence mechanism. Microsoft documents it as a permissions template for protected accounts and groups. By default, the Security Descriptor Propagator process, known as SDProp, checks those objects every 60 minutes and resets mismatched permissions to match the template. This process is separate from ordinary permissions inheritance, which is disabled on protected objects.
If unauthorized rights remain on AdminSDHolder, they can be applied again to protected objects after permissions on those individual objects have been corrected. Changing the original compromised password does not alter that template or remove the rights it governs.
