Learn Kerberos - Security Best Practices

#Introduction

In episode 20 you saw the two sides of delegation: a service's ability to impersonate users, and the Golden Ticket and Silver Ticket risks lurking behind careless configuration. If episode 20 was about "features", episode 21 is about "fortress": how to make Kerberos authentication as hard as possible, dissect the most common attacks, and prepare a defense worthy of the name.

This episode is the heart of Phase 6. Everything you've learned — from the MIT realm to AD integration — only proves its value when it can survive an attack. We'll start with basic hardening, move up to KDC security, then dissect the six most common Kerberos attacks along with how to detect and prevent them.

#Hardening Kerberos Authentication

#Strong Encryption Only (AES)

Encryption is the foundation of Kerberos security. Keys are derived from passwords, and all tickets are protected by encryption. Use only AES — aes256-cts-hmac-sha1-96 as the primary choice and aes128-cts-hmac-sha1-96 as a backup. On the MIT client side, set it in krb5.conf:

/etc/krb5.conf - force AES

[libdefaults]
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes   = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    rdns = false

#Disable Weak Encryption

Weak encryption like RC4 and DES must be turned off across the entire stack — on the KDC, on clients, and in AD. RC4 is still used in legacy scenarios, but RC4 keys can be derived from NT hashes and become Kerberoasting material. In AD, set the service account's msDS-SupportedEncryptionTypes to only contain AES, and remove rc4-hmac from the enctype list in the client configuration. Encryption downgrade is one of the attack signals (covered in the detection section).

#Require Preauthentication

Preauthentication ensures the client proves it knows the password before the KDC issues a TGT. Without preauth, the KDC sends a ticket that can be cracked offline — the basis of the AS-REP roasting attack. Enforce it with kadmin:

sudo kadmin.local -q "modprinc -requires_preauth false alice@EXAMPLE.COM"

In AD, make sure the "Do not require Kerberos preauthentication" property on every account stays unchecked.

#Short Ticket Lifetimes

Tickets that live too long widen the abuse window when a ticket is stolen. Limit user ticket lifetimes with the AD domain policy and a reasonable renewal period:

sudo kadmin.local -q "modprinc -maxlife 8h -maxrenewlife 7d alice@EXAMPLE.COM"

The principle: a TGT lasts just long enough to finish the work, no longer. Service tickets are also bounded by the same policy.

#Keytab Protection

A keytab is equivalent to a plaintext password. Give it the smallest permissions possible and make sure only root owns it:

sudo chown root:root /etc/krb5.keytab
sudo chmod 600 /etc/krb5.keytab

A keytab readable by ordinary users is an invitation to steal service keys.

#KDC Security

The KDC is the realm's foundation — if the krbtgt key leaks, the entire domain falls. Pay attention to these areas:

Back up the KDC database with kdb5_util dump, then encrypt the result before moving it:

sudo kdb5_util dump /var/backup/kdb
sudo gpg -c /var/backup/kdb

#Common Attacks on Kerberos

Here's a map of the attacks that appear most often in the real world, along with their mechanisms and defenses:

• Golden Ticket: an attacker holding the krbtgt key (e.g. from DC memory or a database backup) can forge a TGT for anyone. Detection is hard because the ticket looks valid; focus on behavior, not ticket contents.
• Silver Ticket: more hidden — the service ticket is forged directly, never touching the KDC. Protecting the service key is the answer.
• Kerberoasting: an attacker requests service tickets for SPN-bearing service accounts, then tries passwords offline. A service account with a weak password falls within minutes.
• Pass-the-Ticket: a ticket stolen from a cache is reused on another machine. AES encryption makes tickets hard to dissect, but tickets can still be reused.
• Overpass-the-Hash: an NT hash is converted into a Kerberos ticket — combining Pass-the-Hash's advantages with Kerberos's capabilities. Disabling RC4 cuts the chain.
• AS-REP roasting: accounts that don't require preauth allow ticket requests without password proof, opening the door to offline cracking.

#Detection Strategies

Detecting Kerberos attacks is often easier than you'd think, because the attacks produce anomalies visible in logs and tickets:

• Unusual ticket requests: unreasonable AS_REQ or TGS_REQ patterns, e.g. from one user to many services in a short time — a sign of mass Kerberoasting.
• Abnormal ticket lifetimes: tickets whose validity far exceeds policy, or a TGT reused multiple times on different hosts — signs of Golden Ticket and Pass-the-Ticket.
• Service ticket anomalies: service ticket requests for accounts that are never usually accessed, or from hosts that never requested them before.
• Encryption downgrade attempts: requests that suddenly drop to RC4 or DES even though AES is available — an indication the attacker is exploiting weak keys.

In AD, events 4768 (TGT requested) and 4769 (service ticket requested) are the main sources; in MIT Kerberos, the KDC logs give the same signals. Good detection is a mix of SIEM rules and metric observation — the topic of episode 22.

#Defense Mechanisms

Once you know the attacks, it's time to build layered defense:

• Protected Users group (AD): members of this group can't be delegated, don't use NTLM or RC4, and have no cached credentials. Put all admin and sensitive service accounts in it.
• Credential Guard (Windows): isolates credentials outside the OS process with Virtualization-Based Security, so credential-stealing tools can't read them.
• FAST armoring: protects Kerberos preauthentication with armor. In MIT, enable it via krb5.conf:

/etc/krb5.conf - enable FAST armoring

[libdefaults]
    fast_armoring = required

• Regular password rotation: regular rotation for the krbtgt key (with a double reset), and for all service accounts. The longer a key is in use, the greater the chance it leaks.
• Service account hardening: use long random passwords (140 characters or more), accounts never used for interactive login, and SPNs that never move between accounts.
• Monitoring and alerting: enable alerts for delegation changes, unusual ticket requests, and encryption downgrades. Monitoring is your eyes after every gate is closed.

#Conclusion

Episode 21 turned Kerberos from just a protocol into a defense that must be maintained. You saw hardening on the encryption, preauth, ticket lifetime, and keytab sides; KDC security from isolation, firewall, to encrypted backups; a map of six common attacks; detection strategies through ticket anomalies; and defense mechanisms like Protected Users, Credential Guard, and FAST armoring.

Key takeaways:

• AES only, require preauth, shorten ticket lifetimes, and protect the keytab with strict permissions.
• The KDC is the realm's foundation: isolate it, restrict ports, protect the stash file, and encrypt database backups.
• Golden Ticket attacks the krbtgt key, Silver Ticket attacks service keys; both need disciplined key protection.
• Kerberoasting and AS-REP roasting can only be countered with strongly secured service accounts and ticket request monitoring.

In episode 22 you'll build the realm's eyes: Kerberos Monitoring & Logging — configuring KDC and client logging, analyzing logs to detect failures, and the metrics monitored with Grafana and SIEM. See you there!