The KRBTGT account is the cryptographic core of a Kerberos domain. Its NTLM hash is used to sign and encrypt all Kerberos tickets, making its compromise the ultimate objective for an attacker seeking domain dominance. A compromised KRBTGT account allows for the forging of Ticket Granting Tickets (TGTs), the infamous "Golden Ticket" attack. This provides indefinite, stealthy persistence with any desired privilege level.

To remediate a known or suspected KRBTGT compromise, a double-password rotation is non-negotiable. A single password change is insufficient because the Key Distribution Center (KDC) maintains both the current and previous KRBTGT password hash. This is by design, allowing existing TGTs signed with the old key to remain valid until they expire. An attacker's Golden Ticket, also signed with that old key, would thus remain valid.

The correct procedure involves resetting the KRBTGT password twice. The first reset moves the compromised key to the "previous" slot. You must then wait for a period longer than the maximum TGT lifetime defined in your domain policy. This ensures all legitimate tickets issued with the compromised key have expired. Only then should the second reset be performed, which purges the compromised key from the KDC's memory entirely, invalidating any remaining forged tickets.

Legacy cryptographic support in Kerberos, particularly for RC4-HMAC, is a significant liability. These weaker ciphers are susceptible to offline brute-forcing. Enforcing AES256-only encryption for all Kerberos exchanges is a critical hardening step that eliminates downgrade attacks.

This is enforced via Group Policy. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. The key policies are:

• Network security: Configure encryption types allowed for Kerberos - This should be set exclusively to AES256_HMAC_SHA1 and Future encryption types.
• Enable the policy Support for Kerberos AES 256 bit encryption on all clients and servers.

Deploying this change also necessitates enabling AES support on all accounts, especially service accounts. Critically, this also enhances the security of the Privilege Attribute Certificate (PAC), which is embedded within tickets. Proper PAC validation on application servers, which was strengthened following the MS14-068 vulnerability, ensures that the authorization data within a ticket hasn't been tampered with. Stronger encryption makes PAC tampering computationally infeasible.

The Protected Users security group, introduced in Windows Server 2012 R2, provides significant, non-configurable protections for its members. When a privileged account is added to this group, several legacy authentication vectors are disabled, dramatically reducing the account's attack surface.

Key constraints include:

1. No NTLM Fallback: The account can only authenticate using Kerberos. If Kerberos fails, authentication fails. This prevents NTLM relay and pass-the-hash attacks.
2. No Credential Caching: The user's plaintext password and long-term Kerberos keys are not cached in memory (LSASS) after logon. This neuters tools like Mimikatz that attempt to harvest credentials from memory.
3. No RC4: The KDC will only issue AES tickets for members of this group.
4. Short-Lived TGTs: TGTs issued for Protected Users have a default lifetime of four hours, severely limiting the window for an attacker to abuse a stolen ticket.

Kerberoasting and AS-REP Roasting are two common attacks that target service accounts to crack their passwords offline.

• Kerberoasting targets accounts with a Service Principal Name (SPN) set. Any authenticated user can request a Kerberos ticket (TGS) for a service. The ticket is encrypted with the service account's NTLM hash. An attacker can request these tickets for multiple services and then attempt to crack the hashes offline to reveal the plaintext passwords.
• AS-REP Roasting targets user accounts that have the property Do not require Kerberos preauthentication enabled. This allows an attacker to request an Authentication Service Reply (AS-REP) for a user without providing any credentials. This reply contains a portion encrypted with the user's password hash, which can also be taken offline for cracking.

Mitigation requires strict operational hygiene. Unnecessary SPNs on user accounts should be removed. For service accounts, the best practice is to migrate them to Group Managed Service Accounts (gMSAs). gMSAs use long, complex, 240-character passwords that are automatically managed and rotated by Active Directory, making offline brute-force attacks practically impossible. They also cannot be used for interactive logon.

For an added layer of defense, consider implementing Kerberos Armoring (Flexible Authentication Secure Tunneling - FAST). It creates a protected TLS-like tunnel for pre-authentication exchanges, making it harder to intercept and manipulate initial Kerberos traffic.

Time to test your knowledge on these advanced hardening techniques.

By implementing these layered defenses, you move beyond basic Kerberos configuration and into a proactive security posture that actively resists modern adversary tradecraft.