This article will explain how Kerberos works just enough to understand the risks, what attackers typically try, how to spot that activity in your logs, and, most importantly, practical steps you can take to prevent and remediate problems.
This article will explain how Kerberos works just enough to understand the risks, what attackers typically try, how to spot that activity in your logs, and, most importantly, practical steps you can take to prevent and remediate problems.
Mechanism
You don’t need to be a cryptographer to protect Kerberos - just understand the parts that attackers abuse.
- Clients and services - users or machines (clients) want to access services (file shares, web apps, LDAP).
- KDC (Key Distribution Center) - the domain controllers. They issue tickets. Two logical services run here:
- AS (Authentication Service) - hands out the initial ticket (TGT) after the user proves who they are.
- TGS (Ticket Granting Service) - gives service tickets for specific services when presented with a valid TGT.
- TGT (Ticket Granting Ticket) - the “wristband.” Good for requesting service tickets without resending your password.
- Service ticket - proof you can access a specific service. The KDC encrypts it with the service account’s key.
- SPN (Service Principal Name) - the label that ties a service to an account (e.g., HTTP/www.example.local).
- KRBTGT account - the domain account whose keys the KDC uses to sign TGTs. If an attacker gets this account’s key (hash), they can forge TGTs - the worst-case scenario.
Two practical takeaways from that: first, anything that lets an attacker crack a password offline (like pre-auth disabled or weak service account passwords) gives them quiet power. Second, stealing ticket material from a machine (memory, caches) lets attackers impersonate users without touching passwords.
What the attackers will look for
Attackers tend to follow a predictable sequence because it works:
- Find accounts with weak or special settings: accounts with pre-auth disabled, service accounts with SPNs, or accounts that have delegation enabled.
- Harvest tickets or secrets: dump LSASS memory, pull NT hashes, or request service tickets for SPNs to crack offline.
- Use or forge tickets: present stolen tickets (pass-the-ticket), or forge them if they have the KRBTGT key (Golden Ticket) or a service account hash (Silver Ticket).
- Move laterally, escalate, persist: use the access gained to reach higher-value systems or create backdoors.
If you're defending, your job is to make each of those steps harder and to spot the signs when someone tries.
After an attack, there are usually traces that can be investigate to find more clues about the attack vectors to prevent future attacks. This TMA Insight article provide some extra details about Digital Forensics.
Attack patterns
Below I list each major Kerberos-related attack pattern
AS-REP roasting - the offline cracking trick
Some accounts are allowed to authenticate without “pre-authentication”. That means if you ask the KDC for an authentication response for that account, the KDC will give you a blob that you can try to crack offline to recover the account’s password. It’s like asking the bouncer for proof that a specific guest was checked and then using that to brute-force their ID at your leisure.
Why defenders should care: Attackers can quietly request these blobs without generating noisy failed login attempts. It’s an offline cracking problem - once they have the blob they don’t need to touch your network again to keep trying.
How to detect:
- Monitor for AS requests for accounts that have “Do not require Kerberos preauthentication” set.
- Watch for unusual spikes in AS-REQ events coming from a single host or account.
What to do about it:
- Audit accounts with pre-auth disabled; turn pre-auth back on unless there is a documented, unavoidable dependency.
- If you must have an account with pre-auth disabled (legacy apps, etc.), treat it like an emergency: use a very strong, long password; restrict where it can authenticate from; and document it.
Kerberoasting - crack me some service tickets
When somebody asks for a service ticket (for a service tied to a service account), the KDC hands back an encrypted blob protected by that service account’s key. An attacker can request lots of service tickets for targeted SPNs and then offline-crack those blobs to extract the service account password if it’s weak.
Why defenders should care: Service accounts often have powerful privileges or are shared across machines; a cracked service account is a fast path to escalation.
How to detect:
- Look for a single user or computer requesting tickets for many different SPNs in a short time.
- Baseline normal behavior and alert when a workstation is requesting tickets it usually doesn’t.
What to do about it:
- Use gMSAs for services that support them - gMSAs remove manual passwords entirely.
- Where gMSAs aren’t possible, enforce long, randomly generated passwords for service accounts and rotate them regularly.
- Disable legacy algorithms like RC4 and DES at the domain level - they make ticket blobs easier to attack.
- Keep an SPN inventory and remove forgotten or duplicate SPNs.
Golden Ticket - the worst-case forged ticket
If someone steals the KRBTGT account hash (the master key the KDC uses), they can forge TGTs for any account and essentially impersonate anyone in your domain forever (or until you change the KRBTGT key). That’s like stealing the bouncer’s stamp and making wristbands that the doorman will accept without questioning.
Why defenders should care: It’s domain-wide compromise. It’s stealthy and gives the attacker near-total control. Detecting a Golden Ticket is hard; preventing it is vital.
How to detect:
- Unusual authentication patterns that make no sense for that account (impossible ticket lifetimes, or accounts used from places they never used before).
- Sudden access by administrative accounts that were dormant.
- Watch for DCSync activity and unusual domain replication requests.
What to do about it:
- Protect and restrict who can replicate or extract secrets from AD. Limit which accounts can perform domain replication.
- Use tiered admin models and Privileged Access Workstations (PAWs) to reduce risk of credential theft.
- If KRBTGT is suspected to be compromised, rotate the KRBTGT password twice (there’s a specific procedure) to invalidate forged TGTs - but plan this carefully because it can have side effects.
Silver Ticket - forged for a single service
If an attacker learns a service account’s NT hash, they can forge tickets that the service will accept - allowing them to access that specific service without talking to the KDC. It’s less dramatic than a Golden Ticket, but still serious.
Why defenders should care: It’s a stealthy way to impersonate users to specific services, and it doesn’t leave obvious traces at the KDC.
How to detect:
- Odd behavior logged by the service: authentications where the TGS never touched the KDC, or tickets accepted with strange encryption types or lifetimes.
- Correlate service access logs with normal KDC ticket issuance.
What to do about it:
- Use managed accounts (gMSA) or virtual accounts so there’s no long-lived human-managed password to steal.
- Keep service accounts isolated, use strong passwords, and rotate them when needed.
- Harden services so they don’t accept weaker encryption types or unaudited tickets.
Defense & Mitigation
Below are concrete configuration actions you can apply in Active Directory and Windows to harden Kerberos. Short, human, and focused on settings - not timelines or SIEM rules.
To know more about SIEM TMA Insight provides you these very useful and detailed article:
Accounts & passwords
- Re-enable Kerberos pre-auth for every user/service account unless there's a documented, unavoidable dependency. (In ADUC: Account → uncheck Do not require Kerberos preauthentication.)
- Use gMSA / Managed Service Accounts for services that support them (creates no human-managed password to steal). Create with New-ADServiceAccount and install with Install-ADServiceAccount.
- Enforce strong, unique passwords for any remaining service accounts; rotate them automatically where possible.
Kerberos policy & encryption
- Allow only AES (AES128/256) encryption types: set Network security: Configure encryption types allowed for Kerberos to AES only. Remove RC4/DES.
- Shorten ticket lifetimes (Kerberos Policy in GPO → Account Policies → Kerberos Policy): reduce Maximum lifetime for user ticket and Maximum lifetime for user ticket renewal to sensible values for your org
- Tighten clock skew tolerance so tickets expire predictably (Maximum tolerance for computer clock synchronization).
SPNs & service accounts
- Inventory and tidy SPNs. Remove stale/duplicate SPNs; map each SPN to one managed account. (Use setspn -L <account> or PowerShell.)
- Avoid using privileged domain accounts for services. Prefer local virtual accounts, gMSAs, or least-privilege domain accounts.
Delegation
- Disable unconstrained delegation everywhere. In ADUC, clear Trust this computer for delegation and Trust this user for delegation unless explicitly required.
- Use constrained or resource-based constrained delegation (RBCD) where necessary and restrict allowed target services tightly.
- Document and review any delegation entries quarterly.
Domain controller & KRBTGT protections
- Restrict replication and DCSync privileges. Remove unnecessary accounts from roles that can replicate or read secrets; limit who can request directory replication.
- Plan KRBTGT rotation only if compromise is suspected - rotate the KRBTGT password twice following Microsoft guidance to invalidate forged TGTs.
Endpoint & OS hardening
- Enable Windows Defender Credential Guard (or equivalent) to block LSASS credential-dumping techniques on Windows 10/11 Enterprise.
- Deploy LAPS (Local Administrator Password Solution) so local admin credentials are unique and rotated automatically.
- Reduce local admin use: prevent privileged accounts from signing into non-trusted endpoints.
Legacy auth & NTLM
- Disable or restrict NTLM via Group Policy (Network security: Restrict NTLM) - audit first, then block where safe.
- Bock weak ciphers in systems and apps; update legacy applications that require RC4/DES.
Conclusion
Kerberos can feel intimidating because it touches identity, cryptography, and legacy systems. But the reality is straightforward: most real-world compromises start with credential exposure, weak service account management, or careless permissions - not some mysterious protocol flaw.
If you take a few concrete steps - inventory SPNs, fix pre-auth exceptions, adopt gMSAs and LAPS, harden endpoints, collect Kerberos telemetry, and aim to remove legacy crypto - you’ll cut the practical attack surface dramatically. Combine that with short ticket lifetimes, PAWs for administrators, and a plan to respond (including the painful but necessary KRBTGT rotation if needed), and you’ll have a resilient posture.
TMA Solutions provide security testing and pen testing service, which will audit and make sure your organization is safe from kerberos-based attack.
