Forge a service-scoped ticket from the correct service key

Needs: Correct service key/encryption type, domain SID, principal/SPN data and service validation behavior; modern PAC/KDC validation can constrain use

Linux/Impacket

Prerequisite: key/hash of the account encrypting the target SPN's tickets, domain SID, exact SPN/service/host, a plausible existing domain identity and compatible target-service validation behavior.

# Linux/Impacket
impacket-ticketer -nthash SERVICE_NT_HASH -domain-sid DOMAIN_SID \
  -domain DOMAIN -spn cifs/TARGET_HOST AUTHORIZED_TEST_USER
export KRB5CCNAME="$PWD/AUTHORIZED_TEST_USER.ccache"
klist

Windows/Mimikatz

# Windows/Mimikatz
kerberos::golden /sid:DOMAIN_SID /domain:DOMAIN /target:TARGET_HOST /service:cifs /rc4:SERVICE_NT_HASH /user:AUTHORIZED_TEST_USER /ptt

the key must belong to the account that owns the SPN; machine-account keys commonly protect host services;

the ticket is limited to the named service/host and whichever services share the same account key;

current PAC enforcement means using a nonexistent identity can fail; use a real authorized test identity and validate behavior;

a service may perform KDC/PAC validation or additional authorization;

a successfully imported ticket is not successful service access.

Golden tickets require the KRBTGT key and domain SID and create a forged TGT. They are a high-impact persistence concept covered in the conditional domain-compromise section, not a default Block 11 action.

Verify → Prove the intended service action and ticket context; ticket creation/import success alone is insufficient.

If it fails → Wrong key/SPN/SID or modern validation can reject the ticket. Prefer an existing valid credential/TGT route when enabled. More detail ↓

If → then

A password, actual NT hash, AES/NT long-term key or ticket is available → Select password, NT hash, key-to-ticket or ticket authentication
Needs: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization
SMB/RPC endpoints, domain clues or new credentials → Enumerate SMB/RPC shares, files and identities
Needs: Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter
A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
Needs: Artifact provenance and format; possible local/domain/application identity and compatible protocol

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Forge a service-scoped ticket from the correct service key

USE WHEN: A service account key and a concrete compatible service/SPN objective
STARTING ACCESS: A domain identity, appropriate host privilege, or a validated effective directory-object right
RESULT: A verified authentication effect limited to the compatible service context

Recognize the clue

Classify a verified service key and correlate its account/SPN with the specific target service and domain SID.

setspn -Q SERVICE/TARGET_HOST
whoami /user
klist

SYNTHETIC EXAMPLE OUTPUT

SERVICE/TARGET_HOST belongs to SERVICE_ACCOUNT
Available key source: that service account
Domain SID: recorded separately

Means: The key must protect the intended service ticket; an arbitrary user's NT hash is not sufficient.

Confirm: Verify key type/current value, domain SID, principal/SPN, validation behavior and accepted target action.

After validation: A correctly scoped ticket is accepted by the intended service: use only that verified service effect.
Ruled out in this context: The key belongs to a different account/SPN or is outdated: reject the forgery.
Still inconclusive: Ticket creation alone does not settle modern PAC/service validation.

Troubleshooting: Wrong key/SPN/SID or modern validation can reject the ticket. Prefer an existing valid credential/TGT route when enabled.

Additional prerequisite checks

whoami /user
klist
setspn -Q SERVICE/TARGET_HOST

Prerequisite: key/hash of the account encrypting the target SPN's tickets, domain SID, exact SPN/service/host, a plausible existing domain identity and compatible target-service validation behavior.

Linux/Impacket:

Windows/Mimikatz:

Despite the Mimikatz module name, supplying a service/target key produces a silver/service ticket, not a krbtgt-signed TGT.

Important boundaries:

the key must belong to the account that owns the SPN; machine-account keys commonly protect host services;
the ticket is limited to the named service/host and whichever services share the same account key;
current PAC enforcement means using a nonexistent identity can fail; use a real authorized test identity and validate behavior;
a service may perform KDC/PAC validation or additional authorization;
a successfully imported ticket is not successful service access.

Golden tickets require the KRBTGT key and domain SID and create a forged TGT. They are a high-impact persistence concept covered in the conditional domain-compromise section, not a default Block 11 action.

Why it works

A silver ticket is encrypted for a service account rather than issued through a new domain TGT. Its acceptance depends on service/PAC validation; it is not universal domain-administrator authority.

Worked example · hypothetical

Observation: a known service key and domain SID are available. Test: match the intended SPN and documented acceptance conditions. Illustrative output: a CIFS operation succeeds under the crafted ticket while WinRM does not. Interpretation: retain the exact service scope.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗