Key takeaway
Constrain and govern service accounts, inventory and reduce NTLM where possible, protect privileged credentials, and correlate Kerberos and Windows events. Rotate the KRBTGT key through an incident plan after confirming domain-controller replication.
Understand Kerberos and NTLM roles
In Windows Active Directory, Kerberos is the primary protocol: a client obtains a TGT from the KDC, then a service ticket to access a service. NTLM (NT LAN Manager) is an older challenge-response protocol retained for some compatibility cases. An NTLM password hash is not a plaintext password, but its use in a compatible authentication flow creates Pass-the-Hash risk. Keep these distinctions in protocol and log reviews.
Compare the attack types
These techniques target different credentials and Kerberos ticket stages. Identifying the compromised account or system helps set response scope and priority.
| Technique | Target and prerequisite | Defensive focus |
|---|---|---|
| Kerberoasting | The encrypted portion of a Kerberos service ticket requested for a service SPN can be used to guess the service account password offline. | Long unique service-account passwords, group managed service accounts (gMSAs) where supported, least privilege and monitoring of unusual service-ticket requests. |
| Pass-the-Hash | A stolen NTLM hash is reused for authentication without recovering the password. | Limit local admin rights, separate privileged sessions, assess suitable Windows controls such as Protected Users and Credential Guard, and reduce legacy NTLM use. |
| Silver Ticket | A Kerberos service ticket for a specific service is forged with that service account’s key and may be presented without contacting the KDC. | Protect service accounts, keep Kerberos signature validation enabled, and review service and domain-controller telemetry together. |
| Golden Ticket | A forged TGT is created after the KRBTGT key is obtained; the impact can span the domain. | Protect domain controllers and tier-0 accounts; after compromise, use the forest-recovery procedure for a two-stage KRBTGT reset and replication checks. |
Investigate indicators in context
Review bursts of TGS requests for many SPNs in a short period, especially from one user or source; consider legacy encryption and unexpected service-account activity. Correlate ticket times, user, source device and service across domain-controller and service logs. Investigate when successful authentication coincides with privileged-group changes, unusual remote access or service-configuration changes. A single event ID does not confirm an attack.
Plan response and recovery
During an incident, restrict suspected user and service accounts, change related passwords and keys from a clean administrative workstation, account for session and ticket lifetimes, preserve logs and check domain-controller health. A two-stage KRBTGT reset belongs to an appropriate incident and recovery procedure: Microsoft guidance calls for waiting longer than the configured maximum ticket lifetime after the first reset and checking domain replication. Coordinate resets with a domain specialist under an approved recovery plan.