Module 16: Domain Privilege Escalation and Kerberos Abuse

← Return to the Red Team Course #

Domain privilege escalation combines identity, ticket, directory, and authorization evidence. Kerberoasting is one possible path. A service principal name (SPN) identifies a service account for Kerberos, but it does not grant administrative authority to the account.

This module builds a ticket and privilege review. You will distinguish a ticket request from offline password analysis, compare service-account designs, and produce a defensible decision about the next approved test.

Allow 40–55 minutes. Difficulty: intermediate. Examples use synthetic account names and expected evidence.

Learning Outcomes #

• Define KDC, TGT, TGS, SPN, service account, and delegation.
• Explain why ticket encryption and account privilege are separate questions.
• Inspect ticket-cache and directory evidence in an approved lab.
• Compare traditional service accounts with managed service accounts.
• Create a domain escalation review with evidence and limits.

Before You Begin #

Use the domain lab and collection agreement from networking and Active Directory . Record the requesting principal, domain controller, account names, SPNs, encryption types, and the purpose of each service. Do not request tickets for customer accounts outside the approved scope.

Map Kerberos Roles #

Kerberos uses a key distribution center (KDC) to issue tickets. A ticket-granting ticket (TGT) represents an authenticated session. A ticket-granting service ticket (TGS) authorizes access to a named service and is issued for an SPN.

An SPN is a directory mapping, not an access-control decision. A service account might have no elevated groups, or it might run a critical application with delegated rights. Review both the account and the service it supports.

Separate Request and Crack #

Kerberoasting describes requesting service tickets for SPN-associated accounts and analyzing the ticket material offline. The KDC request is a network event. The password-guessing phase runs against a captured representation and does not contact the KDC for each guess.

An offline result is uncertain. Long random passwords, AES keys, account rotation, and managed service accounts change the feasibility of guessing. A failed guess does not prove the account is safe, while a recovered password still requires an authorization review before any use.

Compass Security’s Kerberos presentation supplements the ticket flow. Track which claims describe protocol behavior and which depend on an account’s password, groups, or delegation settings. Watch the presentation on YouTube .

Review Encryption Evidence #

RC4-HMAC and AES are different Kerberos encryption choices. Hashcat mode 13100 is commonly associated with Kerberoastable RC4 ticket material. It is not a universal mode for every ticket representation or encryption type. Confirm the format and encryption field before selecting an analysis method.

Event 4769 records a Kerberos service-ticket request on a domain controller when auditing is enabled. Current Windows documentation includes fields for the requesting account, service name, ticket encryption type, client address, and status. The event shows a request, not a password crack or successful service use. Microsoft’s event 4769 reference .

Compare Account Designs #

Traditional user service accounts often keep long-lived secrets managed by a team. Group Managed Service Accounts (gMSAs) allow Windows to manage password retrieval and rotation for approved hosts. Neither design removes the need to review SPNs, delegation, groups, or service scope. Microsoft’s gMSA overview .

SPN ownership also needs review. Duplicate SPNs, stale registrations, and undocumented services create confusing ticket evidence. Resolve the directory object and application owner before assigning impact.

Examine Delegation Carefully #

Delegation permits one service or computer to act toward another service under defined conditions. Unconstrained, constrained, and resource-based constrained delegation use different directory attributes and trust assumptions. A delegation flag alone does not identify which users or services are impersonated in the observed scenario.

Use the MITRE ATT&CK Kerberoasting reference as a taxonomy aid, then validate the actual domain configuration. Record the relevant attribute, object owner, allowed principals, target service, and time of observation. Avoid treating a technique label as evidence of successful abuse.

Inspect a Lab Ticket Cache #

klist.exe
klist.exe get cifs/fileserver.corp.example

klist.exe displays and requests tickets for the current logon session. Use the second command only against the named lab service and within the approved window. Preserve the output without publishing ticket blobs or secrets. Microsoft’s klist reference .

Expected result: The lab either shows a TGS for the requested SPN or returns an error because the service, DNS record, or policy is unavailable. Either result needs the requesting identity, target SPN, time, and controller evidence. This command was documentation-reviewed and not executed on the macOS authoring host.

Analyze a Synthetic Case #

Assume analyst.user requests a TGS for HTTP/reporting.corp.example. Event 4769 records success with AES encryption. The service account is a gMSA allowed on two application hosts and has no privileged group membership. No offline candidate matches the captured lab fixture.

The defensible conclusion is a successful service-ticket request for a managed account. The evidence does not show password recovery, domain privilege, or unauthorized service use. A follow-up should review the gMSA host scope and SPN ownership rather than escalate the severity solely because a ticket exists.

Choose the Next Test #

A bounded next test should resolve one uncertainty. If the question is SPN ownership, query directory metadata. If it is ticket monitoring, correlate event 4769 with the requesting host. If it is service authorization, inspect the application’s access control. Do not combine password analysis, delegation changes, and remote access in one unexplained action.

Create the Review Record #

Produce a ticket and privilege review for the synthetic case. Include the request event, account design, group and delegation evidence, offline result, and one condition able to change your conclusion.

Requesting principal and host:
Domain controller and event reference:
Target SPN and owning object:
Ticket type and encryption evidence:
Account design, groups, and delegation:
Offline analysis scope and result:
Authorization impact established / untested:
Next approved observation and stopping condition:
Owner, timestamp, and retention location:

Completion standard: A reviewer sees which fact came from the KDC, directory, endpoint, or offline analysis. The record states what remains untested.

Self-Check and Answers #

Next Steps #

Carry the ticket and privilege review into Module 17: Lateral Movement and Expanding Access . The next module uses it to test path prerequisites without assuming every credential reaches every host.

Return to the Red Team Course for the complete sequence.