Kerberos Attacks: Exploiting Windows Authentication Vulnerabilities for Network Domination

To understand how Kerberos is attacked, we must deeply understand how the protocol functions in a healthy state. Kerberos relies on a "ticket-granting" system, analogous to a carnival. You don't pay cash at every ride; you buy tickets at the main booth and present those tickets to the ride operators.

The authentication flow involves three key entities: the Client, the Application Server (the service the client wants to access, like a file share), and the Key Distribution Center (KDC), which acts as the trusted ticket booth.

1. The AS-REQ / AS-REP (Authentication Service): When a user logs in, the client encrypts a timestamp using the user's password hash and sends an Authentication Service Request (AS-REQ) to the KDC. The KDC looks up the user's hash in its database, decrypts the timestamp, and verifies the identity. If successful, the KDC replies (AS-REP) with a Ticket Granting Ticket (TGT). The TGT is encrypted with the password hash of the krbtgt account (the master service account for the KDC). The TGT is essentially a VIP wristband proving the user is authenticated.
2. The TGS-REQ / TGS-REP (Ticket Granting Service): When the user wants to access a specific file server, the client sends a Ticket Granting Service Request (TGS-REQ) to the KDC, presenting their TGT as proof of identity. The KDC verifies the TGT, and if valid, replies (TGS-REP) with a Service Ticket (TGS). This Service Ticket is encrypted with the password hash of the target file server's computer account.
3. The AP-REQ (Application Request): Finally, the client sends the Service Ticket to the file server. The file server uses its own password hash to decrypt the ticket, verifies the user's identity and permissions, and grants access. Crucially, the file server never speaks directly to the Domain Controller; it trusts the cryptographic integrity of the ticket.

Kerberos attacks generally focus on stealing or forging these tickets to bypass the initial Authentication Service phase entirely. Once an attacker has a valid ticket, they no longer need the user's plaintext password.

1. Pass-the-Ticket (PtT) Pass-the-Ticket is a fundamental lateral movement technique. When a user authenticates to a Windows machine (even if they just access a file share on that machine), their TGT and Service Tickets are temporarily cached in the memory of the Local Security Authority Subsystem Service (LSASS) process. If an attacker compromises a workstation and gains local administrative privileges, they can use post-exploitation tools like Mimikatz or Rubeus to dump the LSASS memory and extract these cached Kerberos tickets. The attacker can then inject a stolen TGT into their own current session. From that moment on, when the attacker attempts to access network resources, the system presents the stolen TGT. The Domain Controller accepts it, believing the attacker is the legitimate user. This allows the attacker to impersonate highly privileged users (like Domain Admins) who happened to have a session cached on the compromised machine, moving laterally without triggering password-based alerts or MFA.

2. The Golden Ticket Attack The Golden Ticket is the holy grail of Active Directory exploitation. It represents total, unmitigated domain compromise. To execute this attack, the threat actor must first compromise a Domain Controller and extract the NTLM password hash of the krbtgt account. The krbtgt account is the central authority that encrypts every single TGT in the domain.

Once the attacker possesses the krbtgt hash, they own the ticket booth. They can use Mimikatz to forge their own custom Ticket Granting Tickets (TGTs) entirely offline. They can create a TGT for a non-existent user, assign that user to the "Domain Admins" and "Enterprise Admins" groups, and set the ticket to be valid for 10 years. When the attacker injects this "Golden Ticket" and requests a Service Ticket, the Domain Controller accepts it without question because it is perfectly encrypted with the correct krbtgt hash. A Golden Ticket bypasses all normal authentication checks, including smartcards and MFA, and provides persistent, undetectable administrative access to the entire forest, even if the legitimate Domain Admin passwords are changed.

3. The Silver Ticket Attack While a Golden Ticket requires compromising the Domain Controller, a Silver Ticket only requires compromising a specific target server (like a massive SQL database or a critical file server). In this attack, the threat actor extracts the NTLM password hash of the target server's computer account (or the service account running the application). Remember step 3 of the Kerberos flow: the application server trusts the Service Ticket because it is encrypted with its own hash. Using the extracted computer account hash, the attacker forges a Service Ticket (TGS) entirely offline. They inject this "Silver Ticket" and present it directly to the target SQL server. Because the ticket is perfectly encrypted with the server's own hash, the server accepts it and grants the attacker administrator-level access. The Silver Ticket is incredibly stealthy because the attack completely bypasses the Domain Controller. The KDC never sees the request, meaning there are zero authentication logs generated on the Domain Controller, making detection exceedingly difficult.

4. AS-REP Roasting While Kerberoasting targets Service Tickets, AS-REP Roasting targets the initial Authentication Service (AS) phase. By default, Kerberos requires "Pre-Authentication," meaning the user must encrypt a timestamp with their password hash to prove they know the password before the KDC will issue a TGT. However, administrators occasionally disable Pre-Authentication for specific user accounts (often for compatibility with legacy applications). If an attacker identifies an account with Pre-Authentication disabled, they can simply send an AS-REQ for that user. The KDC will immediately reply with an AS-REP containing the TGT. Crucially, a portion of this AS-REP is encrypted with the user's password hash. The attacker captures this packet, takes it offline, and uses Hashcat to brute-force the user's password, completely bypassing network lockouts.

Defending against advanced Kerberos attacks requires a mature security architecture, stringent privilege management, and advanced endpoint monitoring. You cannot patch away the design of Kerberos; you must restrict an attacker's ability to abuse it.

1. Secure the krbtgt Account The defense against Golden Tickets relies entirely on protecting the krbtgt password hash. The krbtgt account's password should be reset regularly (e.g., every 180 days). Because the KDC retains the previous password to validate older tickets, the password must be reset twice to completely invalidate any stolen Golden Tickets. Furthermore, Domain Controllers must be treated as Tier 0 assets—the most heavily guarded servers in the organization—accessible only from dedicated, highly secure administrative jump servers to prevent the initial compromise required to steal the hash.

2. Implement the Tiered Administrative Model The most effective defense against Pass-the-Ticket and credential theft is implementing Microsoft's Tiered Administrative Model. This architecture logically separates high-privilege accounts from high-risk workstations. Domain Admins (Tier 0) must never log into standard user workstations (Tier 2). If a Domain Admin never logs into a Tier 2 machine, their TGT is never cached in LSASS on that machine, rendering it impossible for an attacker compromising a standard workstation to steal a Domain Admin ticket. Administrators must use separate, dedicated accounts for reading email and performing daily tasks versus managing Domain Controllers.

3. Enable Credential Guard To defend against LSASS memory dumping and Pass-the-Ticket attacks, organizations must deploy Windows Defender Credential Guard. Credential Guard utilizes virtualization-based security (VBS) to isolate the LSASS process within a secure, virtualized container. Even if an attacker gains local SYSTEM privileges on the workstation, they cannot easily read the memory of the isolated container to extract the cached Kerberos tickets, severely hindering lateral movement capabilities.

4. Audit Pre-Authentication and Enforce AES Encryption Organizations must actively audit Active Directory for any user accounts that have "Do not require Kerberos preauthentication" enabled. This setting should be strictly prohibited for all human users and highly restricted for service accounts to prevent AS-REP roasting. Additionally, similar to defending against Kerberoasting, the domain should be configured to reject the weak RC4 encryption algorithm, forcing all Kerberos tickets to utilize robust AES-256 encryption.

5. Advanced Threat Analytics and Behavioral Monitoring Detecting forged tickets requires moving beyond traditional signature-based antivirus. Organizations must deploy advanced behavioral analytics and identity monitoring solutions (such as Microsoft Defender for Identity). These systems analyze Kerberos traffic in real-time, learning the normal behavior of the network. They can detect anomalies, such as a user requesting a Service Ticket without first requesting a TGT (a strong indicator of a Silver Ticket attack), or a user presenting a TGT with an expiration date of 10 years (a clear indicator of a Golden Ticket).