Detecting and Mitigating Kerberos Ticket Theft (T1558)

Kerberos is the sign-in system behind most Active Directory domains. Instead of sending a password to every server, you prove who you are once and receive tickets. Steal or forge a ticket and you can pass as someone else without knowing their password. MITRE tracks this as Steal or Forge Kerberos Tickets (T1558), a Credential Access technique that applies to Linux, macOS and Windows.

This page is the parent technique. The five subtechniques are covered in their own posts: Golden Ticket, Silver Ticket, Kerberoasting, AS-REP Roasting and Ccache Files.

How attackers use it

MITRE explains the cast of characters. In a Kerberos realm there are three participants: the client, the service, and the Key Distribution Center (KDC). The KDC both authenticates users and grants tickets. Clients ask for access to a service, and after authenticating they receive tickets originating from the KDC.

Adversaries subvert this by stealing or forging tickets, which enables Pass the Ticket (T1550.003). The subtechniques split along what the adversary has:

• With the KRBTGT account hash, they can forge ticket-granting tickets (Golden Ticket).
• With a service account hash, they can forge service tickets (Silver Ticket).
• With any valid ticket-granting ticket, they can request service tickets for offline cracking (Kerberoasting).
• With a list of accounts that skip preauthentication, they can collect crackable data (AS-REP Roasting).
• On Linux and macOS, they can copy tickets from credential caches (Ccache Files).

MITRE also notes that on Windows the built-in klist utility lists and analyzes cached tickets, which defenders and adversaries can both use.

How to detect it

MITRE's detection strategy for the parent technique combines several behaviors:

• Malformed fields in logon events, RC4-encrypted ticket-granting tickets, or service ticket requests with no matching ticket-granting ticket request.
• Suspicious processes accessing LSASS memory to extract tickets.
• On Linux, suspicious access to the SSSD secrets database and Kerberos key material.
• On macOS, anomalous use of the Kerberos tools in unified logs.

The common thread is baselines. A modern domain rarely needs RC4 for ticket encryption. A service ticket without a prior ticket-granting ticket is odd. A process that is not a security tool reading LSASS is odd. Each of these is a place to start a rule.

How to reduce the risk

MITRE lists these mitigations for the parent technique.

1. Active Directory configuration. To contain a golden ticket that may already exist, reset the KRBTGT account password twice. Change it once per domain, force replication, then change it a second time. This invalidates existing golden tickets and other tickets derived from the KRBTGT hash. MITRE adds that you should consider rotating the KRBTGT password regularly.
2. Password policies. Service accounts should have long passwords, ideally 25 characters or more, with complexity and periodic expiry. Consider Group Managed Service Accounts or a password vault.
3. Encrypt sensitive information. Enable AES Kerberos encryption, or another stronger algorithm, rather than RC4 where possible.
4. Credential access protection. On Linux, protect resources with SELinux by defining entry points, process types and file labels.
5. Audit. Scan systems, permissions, insecure software and insecure configurations to find weaknesses before an adversary does.

Which subtechnique are you dealing with?

It helps to sort the family by what the adversary already holds, because that tells you where the evidence will be.

• A valid ordinary ticket-granting ticket. The adversary asks the domain controller for service tickets and cracks them offline (Kerberoasting). Evidence sits on the domain controller as bursts of service ticket requests.
• No credentials at all, but a list of accounts. Accounts without preauthentication hand out crackable data (AS-REP Roasting). Evidence is ticket-granting ticket requests with Pre-Auth Type 0.
• A service account hash. The adversary forges a service ticket (Silver Ticket) and may never contact the domain controller. Evidence is on the target server.
• The KRBTGT hash. The adversary forges ticket-granting tickets for any account (Golden Ticket). Evidence is odd ticket properties and activity with no matching request.
• Local access to a Linux or macOS host. The adversary copies a cached ticket (Ccache Files). Evidence is file access to the cache.

The first two are about guessing passwords offline, so password strength is the control. The next two are about forged material, so protecting domain controllers and rotating KRBTGT is the control. The last is about local file protection.

A sensible order of work

If you have a week and nothing else, do these in order.

1. Turn on the logs. Make sure domain controllers record Kerberos authentication and service ticket events, which appear as event IDs 4768 and 4769, and that they reach a place you can search.
2. Inventory accounts with service principal names. Note their age, privileges and password length. These are the Kerberoasting targets.
3. Find accounts without preauthentication. Fix or isolate each one.
4. Check the age of the KRBTGT password. Write down who runs the double reset, and rehearse it.
5. Plan the move to AES. Find what still depends on RC4 so you can switch it off later without breaking things.

None of this requires new tools. It requires a person with directory access and a few hours.

Check your own environment

These checks read directory and ticket state only. The PowerShell commands need the Active Directory module and appropriate rights.

# Windows: when was the KRBTGT password last set?
Get-ADUser krbtgt -Properties PasswordLastSet | Select-Object Name,PasswordLastSet

# Windows: which user accounts have service principal names?
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName | Select-Object SamAccountName,ServicePrincipalName

# Windows, Linux or macOS: list the Kerberos tickets cached for the current session
klist

Then ask:

• Is the KRBTGT password older than your policy allows?
• Which service accounts are old, human-set, or members of privileged groups?
• Are RC4 tickets still being issued, and by which applications?
• Do your logs capture Kerberos events from domain controllers, and are they searchable?

Quick check

Sources

• MITRE ATT&CK T1558: Steal or Forge Kerberos Tickets