Conditional: understand a realm-wide TGT forgery from KRBTGT material

Needs: Correct KRBTGT cryptographic material, realm/SID/principal data, valid ticket parameters and compatible service/KDC validation behavior

Authorized isolated-lab examples

Golden tickets require the domain SID and KRBTGT key. They are persistence/impact concepts, not a default Block 11 action. A forged ticket still depends on correct cryptographic material, realm, time and authorization. For the active service-scoped case, use Silver tickets.

# Authorized isolated-lab examples
# Golden: realm-wide TGT material
impacket-ticketer -nthash KRBTGT_NT_HASH -domain-sid DOMAIN_SID \
  -domain DOMAIN AUTHORIZED_TEST_USER

export KRB5CCNAME="$PWD/AUTHORIZED_TEST_USER.ccache"
klist

Use only against the approved service/host, record ticket metadata and remove generated credentials afterward. Domain recovery after KRBTGT exposure generally requires coordinated credential rotation and replication convergence; service-ticket exposure requires rotating the affected service/machine secret and reviewing access.

Verify → Verify cryptographic source, represented principal and exact service effect; protect the key and remove generated test credentials.

If it fails → Wrong key/version, realm, time or validation behavior can reject a forged ticket. Prefer legitimate current tickets for ordinary movement. More detail ↓

If → then

A valid ticket/cache or a long-term key that can request a TGT → Inventory, convert and import tickets in the correct logon context
Needs: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context
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
Access, privilege, identity or route changes, or a report will need reproduction → Capture state-transition, proof and exploit-adaptation evidence
Needs: Known destination/identity, observable effect and a private evidence destination; actual exam proof requirements must be read from current official guidance

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

Explanation & examples

Conditional: understand a realm-wide TGT forgery from KRBTGT material

USE WHEN: An already compromised domain exposes a KRBTGT key and domain SID
STARTING ACCESS: A domain identity, appropriate host privilege, or a validated effective directory-object right
RESULT: A realm-wide ticket capability whose acceptance and service authorization still require verification

Recognize the clue

Begin only after protected private evidence establishes the actual domain KRBTGT key and SID; inspect account/source metadata rather than assuming any domain hash suffices.

klist
whoami /user

SYNTHETIC EXAMPLE OUTPUT

Private source classification: KRBTGT key, not ordinary service key
Domain SID/realm: recorded
Test service: explicitly scoped

Means: KRBTGT key exposure is the enabling post-compromise condition; an ordinary NT hash or unrelated ticket cannot substitute.

Confirm: Verify current cryptographic material/version, realm/SID/principal, time and actual service validation; retain recovery/cleanup scope.

After validation: The authorized isolated-lab ticket is accepted for the intended action: document the domain-key impact.
Ruled out in this context: Only an ordinary service-account key is available: reject realm-wide TGT forgery.
Still inconclusive: A file labelled KRBTGT without source/version verification leaves the key claim unresolved.

Troubleshooting: Wrong key/version, realm, time or validation behavior can reject a forged ticket. Prefer legitimate current tickets for ordinary movement.

Golden tickets require the domain SID and KRBTGT key. They are persistence/impact concepts, not a default Block 11 action. A forged ticket still depends on correct cryptographic material, realm, time and authorization. For the active service-scoped case, use Silver tickets.

Authorized isolated-lab examples:

Use only against the approved service/host, record ticket metadata and remove generated credentials afterward. Domain recovery after KRBTGT exposure generally requires coordinated credential rotation and replication convergence; service-ticket exposure requires rotating the affected service/machine secret and reviewing access.

Why it works

Golden-ticket creation is a post-compromise impact/persistence concept here. Possession of the correct domain key is a much stronger starting condition than an ordinary service key; it is not an initial escalation default.

Worked example · hypothetical

Observation: authorized isolated-lab evidence already establishes KRBTGT exposure. Test: inspect the scope of a documented test ticket and its intended service use. Illustrative output: the service accepts the represented identity. Interpretation: record domain-key impact and recovery needs without treating the technique as a routine first path.

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

Study guide ↗Full procedure ↗Cheatsheet ↗