In the world of cybersecurity, the age-old practice of changing passwords after a suspected breach is often seen as a quick fix. However, as this article reveals, it's a far more complex process than meets the eye. The issue lies in the fact that password resets don't always immediately invalidate old credentials across every authentication path, leaving a window of opportunity for attackers to maintain access or re-establish a foothold. This is particularly true in Active Directory (AD) and hybrid Entra ID environments. In my opinion, this gap is a critical vulnerability that demands attention and action. The password reset gap is a real concern for security architects and IT administrators. Windows systems cache password hashes locally, and in hybrid environments, there can be a short delay before the new password syncs to Entra ID. This means that even after a password reset, there are three possible states where the old credential can still be used: if the user has logged in with the new credential while connected to AD, the cached credential store updates and invalidates the old hash; if the user has not logged in to a particular machine since the reset, the old cached credential may still be usable; and in hybrid deployments, the password has been reset in AD but the new hash has not yet synchronized to Entra ID, leaving the old password still authenticating during the password hash synchronization interval. What makes this particularly fascinating is that attackers can exploit these gaps using methods like pass-the-hash, where the hash itself is used instead of the plaintext password. If that hash was captured before the reset, changing the password doesn't immediately invalidate it everywhere. This is a critical issue that needs to be addressed, as it can leave systems vulnerable to attack. Limiting this exposure is crucial to defending AD environments. Solutions like Specops uReset enable secure self-service password resets by enforcing end-user ID verification to reduce the risk of reset abuse. When combined with the Specops Client, uReset can update the local cached credential store immediately on the device where the reset is performed, closing the window where the old hash remains usable on that endpoint. This doesn't remove identity drift entirely, but it does reduce exposure at the network edge, where corporate laptops and remote systems are frequently targeted. Another critical aspect is the issue of active sessions. AD authentication is primarily handled through Kerberos tickets, which are valid for a set period of time. If a user or attacker already has a valid ticket, they can continue accessing resources without re-entering a password. This means that an attacker with an active session remains authenticated even after the password has been changed. In some cases, this window is long enough to establish additional persistence or move laterally. From my perspective, this is a significant vulnerability that needs to be addressed. Service accounts also pose a risk, as they tend to have long-lived passwords with elevated privileges tied to critical systems. Attackers can expose those credentials through techniques like Kerberoasting or discover them when moving laterally through a network. Because these accounts are tied to running services, they're less likely to be reset quickly, especially if there's a risk of disruption. That makes them a reliable fallback for attackers after an initial access point is closed. Ticket attacks are another critical issue. In environments using the Kerberos authentication protocol, access is controlled through tickets rather than repeated password checks. If an attacker can forge those tickets, they don't need valid credentials at all. A Golden Ticket attack, made possible by compromising the Kerberos Ticket Granting Ticket account, allows attackers to create valid ticket-granting tickets for any user in the domain. Silver Tickets are more targeted, granting access to specific services without contacting a domain controller. In both cases, these attacks effectively bypass password changes. Resetting user passwords won't invalidate forged tickets, and access can continue until the underlying issue is addressed. Permissions are another critical aspect. AD is heavily driven by Access Control Lists (ACLs). If an attacker grants a compromised account (or a new one they control) rights like resetting passwords for other users, they've effectively created a backdoor. Even if the original password is changed, those permissions remain. Furthermore, accounts protected by AdminSDHolder (like Domain Admins) inherit permissions from a specific template. Attackers who modify the ACL on the AdminSDHolder object can ensure their permissions are re-applied every hour by SDProp. To ensure attackers are removed, defenders need to take a multi-pronged approach. The time between a password reset and it synching across AD and Entra ID is small, typically just a few minutes, which severely limits the opportunity attackers have to exploit the gap. Forcing more frequent synchronizations is also possible, for instance turning on AD Change Notification or manually initiating a Sync to the Entra ID tenant. However, the gap still exists, and by the time an account compromise is discovered, attackers may have been able to establish additional footholds. If password resets aren't enough on their own, defenders need to look at fully closing off access. That starts with invalidating anything already in play. Active sessions should be terminated, and Kerberos tickets cleared by forcing logoffs or reboots on affected systems. For more serious compromises, resetting the KRBTGT account (twice) is often necessary to invalidate forged tickets. Next comes credential hygiene beyond standard user accounts. Service account passwords should be rotated, especially those with elevated privileges, and any cached credentials on endpoints should be cleared as systems reconnect. Just as important is reviewing what’s changed in the directory itself. That means auditing group memberships, delegated rights and ACLs, and privileged accounts and roles. Look for anything that could allow access to be re-established without relying on a password. For serious breaches, there isn’t a single step that guarantees eviction. It’s a combination of cutting off sessions, rotating the right credentials, and verifying that no hidden access paths remain. In conclusion, while changing passwords is a necessary step in incident response, it's not enough on its own to prevent a breach. Defenders need to take a comprehensive approach that includes invalidating active sessions, rotating credentials, and auditing the directory to ensure that no hidden access paths remain. By doing so, they can minimize the risk of a breach and protect their systems from attack. Personally, I think that this article highlights the importance of a multi-layered security approach. While password resets are a critical component, they need to be complemented by other measures to ensure the security of Active Directory environments. By taking a holistic approach, defenders can minimize the risk of a breach and protect their systems from attack.
