Microsoft Defender for Identity Recommended Actions: Change password for KRBTGT account

by thalpius

Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The twenty-fifth  one in the series is the “Change password for krbtgt account” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Change password for krbtgt account.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Active Directory KRBTGT account

The KRBTGT account in Active Directory is a built-in account that serves as the foundation of Kerberos authentication within your domain. This special account is responsible for encrypting and signing all Kerberos tickets, which enables secure authentication across your entire Active Directory environment. Unlike regular user accounts, the KRBTGT account cannot be deleted, making it a permanent fixture in your domain’s security infrastructure.

Understanding the critical role of the KRBTGT account is essential for maintaining a secure Active Directory environment. Every time a user authenticates to your domain, they receive a Ticket Granting Ticket (TGT) that is encrypted and signed using the KRBTGT account’s password hash. This means that the KRBTGT account essentially holds the keys to your entire authentication system. If an attacker compromises the KRBTGT account’s password, they can forge valid Kerberos tickets at will, granting themselves access to any resource in your domain through what is known as a Golden Ticket attack.

The security implications of a compromised KRBTGT account are severe. Because Kerberos relies entirely on the KRBTGT password to sign all authentication tickets, an attacker with access to this password hash can create tickets that appear completely legitimate to your domain controllers and other systems. These forged tickets can grant administrative access to any resource, persist even after passwords are changed, and remain valid until the KRBTGT password is properly rotated. This is precisely why closely monitoring the KRBTGT account and regularly rotating its password is one of the most critical security practices for Active Directory environments.

The Risk of Neglecting KRBTGT Password Rotation

Failing to regularly change the KRBTGT account password creates a significant and persistent security vulnerability in your Active Directory environment. When the KRBTGT password remains unchanged for extended periods, particularly beyond 180 days, you are essentially leaving a master key exposed that could grant attackers unlimited access to your entire domain.

The primary threat associated with an outdated KRBTGT password is the Golden Ticket attack. If an attacker manages to compromise the KRBTGT account’s password hash through methods such as domain controller compromise, credential dumping, or other attack vectors, they gain the ability to forge Kerberos Ticket Granting Tickets that your domain will accept as legitimate. These forged tickets are extraordinarily dangerous because they allow attackers to impersonate any user in your domain, including domain administrators, and access any resource without restriction.

What makes this threat particularly insidious is its persistence and stealth. Golden Tickets created with a compromised KRBTGT password hash remain valid until that password is changed, meaning an attacker could maintain access to your environment for months or even years if the password is never rotated. These forged tickets do not require the attacker to maintain a foothold on compromised systems, they do not trigger typical authentication alerts, and they bypass most conventional security monitoring because they appear to be legitimate authentication tokens issued by your domain controllers.

The extended validity period of an unchanged KRBTGT password also means that even if you detect and remediate an initial compromise, attackers may have already extracted the KRBTGT hash and created Golden Tickets during their access. Without rotating the KRBTGT password, you cannot be certain that you have truly removed their ability to authenticate, as those previously created tickets will continue to work. This creates a scenario where organizations may believe they have successfully expelled attackers from their network when in reality, those attackers retain a backdoor into the environment through valid-looking authentication tickets.

By allowing the KRBTGT password to age beyond 180 days, you are expanding the window of opportunity for attackers and increasing the potential damage from any security incident. Regular password rotation for this critical account is not just a best practice, it is an essential component of limiting the blast radius of potential compromises and ensuring that your domain’s authentication system maintains its integrity over time.

Image 1: The KRBTGT account in Active Directory

Mitigating the Risk Through Proper KRBTGT Password Management

Protecting your Active Directory environment from Golden Ticket attacks requires a systematic approach to KRBTGT password rotation. The recommended practice is to reset the KRBTGT account password at least every 180 days, though many security-conscious organizations opt for more frequent rotations, particularly in high-security environments or following any suspected security incident.

The process of resetting the KRBTGT password requires careful execution to avoid disrupting authentication services across your domain. Microsoft recommends using their official PowerShell script, which has been specifically designed to handle the complexities of KRBTGT password rotation safely. This script can be found in the Microsoft GitHub repository at https://github.com/microsoft/New-KrbtgtKeys.ps1 and incorporates recommended practices that have been refined through extensive testing and real-world implementation.

A critical aspect of proper KRBTGT password rotation is that the password must be reset twice to fully invalidate any potential Golden Tickets. This dual-reset approach is necessary because Active Directory maintains both the current and previous password hashes for the KRBTGT account to ensure backward compatibility with existing Kerberos tickets. Simply resetting the password once would leave the previous hash functional, meaning any Golden Tickets created with that hash would continue to work. Only after the second reset is the original compromised hash fully removed from active use.

However, you cannot perform both resets in rapid succession without risking authentication failures across your domain. The Microsoft-provided script enforces a mandatory waiting period of at least 10 hours between the first and second password resets. This waiting period aligns with Kerberos best practices and allows sufficient time for all domain controllers to replicate the password change and for existing legitimate tickets to be renewed with the new password hash. Attempting to rush this process by resetting the password twice in quick succession can result in widespread authentication issues, service disruptions, and user lockouts.

When planning your KRBTGT password rotation, coordinate with your IT operations team to schedule the activity during a maintenance window or period of lower activity. The first reset should be performed with adequate time for monitoring before the second reset occurs. Between resets, monitor your domain controllers and authentication services for any unusual behavior or error patterns. Once both resets are complete and the 10-hour window has elapsed, you can be confident that any previously created Golden Tickets based on the old password hashes have been invalidated.

For organizations that discover their KRBTGT password has not been changed in significantly longer than 180 days, this rotation becomes an urgent security priority. In cases where you suspect your environment may have been compromised or if you are remediating after a known security incident, the KRBTGT password reset should be part of your immediate incident response procedures. Remember that until you complete both password resets with the appropriate waiting period, you cannot be certain that attackers have been fully removed from your authentication infrastructure.

Regular KRBTGT password rotation should be incorporated into your organization’s routine security maintenance procedures, tracked through change management systems, and documented as part of your overall Active Directory hardening strategy. By maintaining this discipline, you significantly reduce the window of opportunity for Golden Ticket attacks and ensure that even if the KRBTGT hash is compromised, its useful lifetime to attackers is strictly limited.

Conclusion

The KRBTGT account represents one of the most critical security components in your Active Directory infrastructure, yet it is often overlooked in routine security maintenance. As the foundation of Kerberos authentication across your domain, this built-in account requires vigilant protection and regular password rotation to prevent catastrophic security breaches through Golden Ticket attacks.

Microsoft Defender for Identity’s recommendation to change the KRBTGT password every 180 days is not merely a suggestion, but a fundamental security control that directly impacts your organization’s ability to defend against persistent threats. When this account’s password remains unchanged for extended periods, you are essentially allowing attackers an unlimited timeframe to leverage any compromised credentials, forge authentication tickets, and maintain undetected access to your most sensitive resources.

The good news is that remediation is straightforward when approached methodically. By using Microsoft’s official PowerShell script and following the proper dual-reset procedure with the required 10-hour waiting period between resets, you can safely invalidate any potential Golden Tickets without disrupting your authentication services. This process should become a standard component of your security maintenance calendar, ensuring that your domain’s authentication integrity is regularly refreshed and that the window of opportunity for attackers is kept to an absolute minimum.

Do not wait for a security incident to prioritize KRBTGT password rotation. If your Defender for Identity assessment reveals that your KRBTGT password has not been changed in over 180 days, treat this as a high-priority remediation task. The effort required to properly rotate this password is minimal compared to the devastating impact of a successful Golden Ticket attack that could compromise your entire domain. By maintaining this discipline and incorporating KRBTGT password rotation into your regular security practices, you are taking a crucial step toward hardening your Active Directory environment against one of the most dangerous attack vectors facing modern organizations.