Generated Wednesday, October 7, 2026 · Depth: deep, defense-focused · PAC hardening and Credential Guard details checked against Microsoft's KB5008380, KB5020805, and the Credential Guard documentation.

Ticket theft and forgery, from the defender's chair

Plain English first

In Part 1 the attacker guessed a password. Here the password stage is over. The attacker already has a foothold and is working with Kerberos tickets directly. There are two moves, and keeping them separate is most of the battle.

• Theft: taking a real ticket that already exists, out of a machine's memory or off disk, and reusing it elsewhere. The ticket is genuine; it's just in the wrong hands.
• Forgery: making a ticket that the Key Distribution Center (KDC) never issued, by getting hold of a secret key. If the attacker has the right key, the KDC's signature can be reproduced, so the fake looks authentic.

The whole domain's trust rests on one key in particular: the key of the krbtgt account. Every Ticket Granting Ticket (TGT) is sealed and signed with it. Whoever holds that key can mint a TGT for anyone, which is why recovering from that single compromise is the hardest problem in this part.

The analogy: the master key and the engraving machine

Why it matters now

If you remember only 5 things

1. Theft and forgery are different problems. Theft is contained by resets and by protecting credentials in memory. Forgery is contained only by protecting, and rotating, the key that was used to sign the fake.
2. The krbtgt key is the domain. Its compromise means golden and diamond tickets. Recovery is a double password reset with a wait in between, not a single reset.
3. Forgery needs a stolen key first. Golden and diamond tickets both require the krbtgt key, which usually comes from DCSync or a Domain Controller (DC) compromise. Detecting that theft is often easier than detecting the forged ticket.
4. The 2021 to 2023 PAC hardening matters. PAC requestor (CVE-2021-42287) and full PAC signatures (CVE-2022-37967) are fully enforced on patched DCs and close specific forgery and privilege-escalation tricks. Confirm every DC is current.
5. Detect the key theft and the anomalies, not the ticket itself. A well-made forged ticket can look legitimate. Watch for DCSync from non-DCs, tickets with odd lifetimes, and Ticket-Granting-Service requests with no matching logon.

Core concepts

Thirteen ideas, ordered so each builds on the last. Open "Go deeper" for expert detail.

Visual map

Step through where each forged ticket inserts itself into the normal trust chain, and which key it needs. Each step names the defense that catches it.

The forged-ticket family at a glance

Theft versus forgery

What each defense actually stops

TechnicalUnder the hood

The PAC, and the signatures that protect it

The Privilege Attribute Certificate (PAC) is Microsoft's block of authorization data inside a ticket: the user's Security Identifier (SID), group SIDs, and more. Services build a Windows access token from it, so if an attacker can edit a PAC undetected, they can grant themselves any group membership. The defenses are a set of signatures.

The through-line for a defender: the strong signatures all use the krbtgt key. That is exactly why golden and diamond tickets need it, and why a forger who has it can still produce valid signatures. Services, by default, usually verify only the server signature and don't call back to the KDC for PAC validation, which is the gap silver tickets live in.

PAC requestor SID (CVE-2021-42287, KB5008380)

This update adds the requesting account's SID into the TGT's PAC, and the KDC checks that a service ticket's account matches the account that asked for it. It closed a path where an attacker created or renamed an account to resemble a DC and obtained an over-privileged ticket (often paired with CVE-2021-42278, the "noPac" / sAMAccountName spoofing chain).

Registry: HKLM\System\CurrentControlSet\Services\Kdc, value PacRequestorEnforcement. Events on the DC System log: 35 (a TGT from another KDC lacks the attributes field), 36 and 37 (ticket without a PAC or without requestor info; warning in deployment, error in enforcement), and 38 (the account in the ticket doesn't match AD, logging both SIDs, a possible exploit sign).

Full PAC signature (CVE-2022-37967, KB5020805)

Registry: HKLM\System\CurrentControlSet\Services\Kdc, value KrbtgtFullPacSignature (0 disabled, 1 add only, 2 audit, 3 enforce). Events from the Kerberos-Key-Distribution-Center source: 43 (full PAC signature failed) and 44 (full PAC signature missing). A related CVE-2022-37966 is covered by KB5021131 (event 42). If any DC lags on patches, these protections are inconsistent across the domain.

Credential Guard

Credential Guard uses Virtualization-Based Security (VBS) to isolate secrets, so NT hashes and Kerberos TGTs live in a protected process that even an administrator can't read. That blocks the memory-theft step behind pass-the-hash and pass-the-ticket.

• Default-on: Windows 11 22H2 and later, and Windows Server 2025 and later, on Enterprise or Education editions that meet the hardware and licensing requirements and aren't explicitly configured off. On Server 2025 it also requires the machine to be domain-joined and not a DC.
• Not on domain controllers. Microsoft doesn't recommend it there; it adds no protection on a DC and can cause compatibility issues. This matters because the DC is exactly where the krbtgt key lives.
• What it does not protect: the AD database (ntds.dit) and the Security Account Manager (SAM); forgery once a key is already stolen; attacks from a Hyper-V host against a guest. It also breaks features that need unconstrained delegation, Kerberos Data Encryption Standard (DES), TGT extraction, or NTLMv1.
• Default enablement doesn't use a Unified Extensible Firmware Interface (UEFI) lock, so it can be turned off remotely by an admin if an app genuinely needs one of those features.

krbtgt rotation, done correctly

The krbtgt account has a current and a previous key (it keeps the last two password generations so tickets signed just before a change still validate briefly). A single reset only rolls one generation, so a stolen key may still validate tickets. The correct eviction is two resets with a wait between them.

• Confirm AD replication is healthy first.
• Reset once. Wait at least 10 hours, longer if the maximum ticket lifetime policy is higher than default, so legitimate tickets expire and the first change replicates everywhere.
• Reset a second time. Now both key generations are new and every previously forged golden/diamond ticket is dead.
• Microsoft's New-KrbtgtKeys.ps1 script (from the microsoftarchive repository) handles read-write and read-only DCs; the manual path is Active Directory Users and Computers.
• Expect disruption: AD-integrated apps and non-Windows clients may need to re-authenticate as their tickets become invalid.

Common misconceptions

Troubleshooting and verification commands

klist                         # list cached tickets, lifetimes, etypes, and the KDC that issued them
klist purge                   # clear a host's ticket cache
nltest /dsgetdc:corp.example.com   # confirm which DC a host is using
repadmin /showrepl            # check AD replication health before a krbtgt reset
# After a krbtgt reset, watch for Kerberos errors on member servers as old tickets expire
Get-ADObject -Filter 'Name -eq "krbtgt"' -Properties whenChanged,pwdLastSet -SearchBase (Get-ADDomain).UsersContainer

AttackerAttacker's view, for defenders

Each technique is covered at the level needed to recognise it, test that your detections fire, and explain it in a report. The focus is prerequisites, what makes an environment vulnerable, the evidence left behind, and how it reads as a finding. Tools are named so you can build a detection lab, not as a how-to.

How these show up in an incident, in order

1. Credential or key access: LSASS memory access on a host, or DCSync-style replication from a machine that isn't a DC. This is usually the most detectable moment.
2. Forgery or theft: a ticket is created or copied, often offline, leaving little trace by itself.
3. Use: the ticket is presented. Golden and diamond tickets are used to request service tickets, so the TGS activity exists on a DC even though the initial logon (AS-REQ) never happened from that host.
4. Objective: access to a target service, data, or persistence that survives password resets.

DefenderDefender's playbook

Written for the sysadmins doing the work. The strategy: make the krbtgt key and DCs hard to reach, protect credentials in memory, enforce the PAC hardening, and alert on the key-theft step rather than hoping to spot a well-made ticket.

Quick wins (days)

1. Confirm every DC is fully patched and past the October 2022 and October 2023 enforcement dates for PAC requestor and full PAC signatures. A single lagging DC weakens the whole domain.

   Get-ADDomainController -Filter * | Select Name,OperatingSystem,OperatingSystemVersion
   # verify the latest cumulative update is installed on each

2. Restrict DCSync rights. Only DCs should have "Replicating Directory Changes All." Audit who else holds it on the domain head and remove stray grants.

   # Review replication rights on the domain object; remove any non-DC, non-service principal
   (Get-Acl "AD:$((Get-ADDomain).DistinguishedName)").Access |
     Where-Object {$_.ObjectType -match '1131f6ad|1131f6aa|89e95b76'} |
     Select IdentityReference,ActiveDirectoryRights,ObjectType

3. Check krbtgt age. If it has never been rotated, or not in over a year, schedule a healthy-state double reset.
4. Confirm Credential Guard status on workstations and member servers (not DCs).

   (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
   # a value of 1 in the list means Credential Guard is running

5. Populate the Protected Users group with high-value human accounts (never service accounts), and confirm no legacy app depends on RC4/DES for them first.
6. Turn on the right DC auditing: Account Logon and DS Access, so 4768/4769/4770 and the PAC events are captured and forwarded.

Longer-term fixes (weeks to months)

1. Tier the environment. DCs and anything that can control them are Tier 0. Tier 0 admins log on only to Tier 0 hosts, so their tickets never land in a workstation's memory to be stolen.
2. Use Privileged Access Workstations for domain administration, and a Privileged Access Management (PAM) solution to vault and check out Tier 0 credentials.
3. Reduce standing Domain Admins. Fewer powerful tickets in circulation means fewer worth stealing.
4. Enable Credential Guard by policy across the client and member-server fleet, after testing for the known breakages (unconstrained delegation, NTLMv1, DES).
5. Deploy identity detection such as Microsoft Defender for Identity (MDI) on DCs, which has built-in analytics for DCSync, golden tickets, and overpass-the-hash.
6. Adopt a krbtgt rotation schedule for hygiene (for example, twice a year, done as the correct double reset), separate from incident response.
7. Move services off user accounts to group Managed Service Accounts (gMSA), which also shrinks silver-ticket exposure since those keys are long, random, and rotated.

Detection signals

Verify the fix worked

1. After a double krbtgt reset, confirm pwdLastSet changed twice with the correct gap, replication is healthy, and member servers are issuing and accepting fresh tickets (no lingering Kerberos errors).
2. Confirm PAC enforcement by checking every DC is past the enforcement updates and that System logs are clean of events 37, 38, 43 and 44 under normal operation.
3. Confirm DCSync rights list only DCs and expected service principals.
4. Confirm Credential Guard is running on the sampled hosts (and correctly absent on DCs).
5. Ask the testers to re-run pass-the-ticket and DCSync against the hardened environment and confirm the alerts fire end to end.

Why remediation stalls, and workable compromises

ExecutiveExecutive brief

The risk in plain language

Once an attacker gets deep enough into our Windows network to reach a domain controller, which is one of the servers that vouches for every login, they can copy a single master secret. With it, they can manufacture valid-looking access passes for any employee, including administrators, and those passes keep working even after we change passwords and disable accounts.

This is the stage of a breach where the obvious response, resetting the compromised user's password, quietly fails. Evicting the attacker requires a specific, careful procedure, and skipping it has let intruders stay in networks for months.

Business impact

• Durable, hard-to-remove control of the entire Windows environment: the foothold ransomware crews use before encrypting everything at once.
• The ability to impersonate any employee, which undermines our logs and our ability to tell legitimate activity from the attacker's.
• A longer, more expensive incident, because incomplete eviction means the attacker comes back.

What drives likelihood

• Whether an attacker can reach a domain controller or its master secret at all. Strong separation of administrator accounts is the single biggest factor.
• Patch level. Microsoft closed specific tricks in 2021 to 2023; unpatched servers reopen them.
• Credential protection on everyday computers, which newer Windows versions provide by default.
• Whether we can detect the theft of the master secret, and whether we have a rehearsed recovery procedure.

Cost of inaction

The defenses are mostly process and configuration: separating administrator duties, keeping servers patched, turning on protections already built into Windows, and rehearsing one recovery procedure. The cost of not doing this is a breach that we cannot fully clean up on the first attempt, with the attacker retaining control while we believe we've recovered.

What good looks like

• Administrators of the most sensitive systems use separate, protected computers, so their access passes never sit on ordinary machines.
• All domain controllers are current on security updates.
• Credential protection is on across company laptops and servers.
• We get an alert if someone copies the master secret, and we have a tested procedure to rotate it.
• Recovery from a domain controller compromise is a documented, practised runbook, not an improvised scramble.

Questions executives ask

Presenting this finding to leadership

1. Headline: "We were able to reach the network's master login secret, which would let an attacker impersonate anyone and stay in even after password resets."
2. The point about eviction: stress that this is the finding where the normal clean-up doesn't work, so it changes how an incident must be handled, not just how it's prevented.
3. Tie to patch and privilege: name whether separation of admin duties and patching would have blocked the path we used.
4. The ask: admin-tiering, a patch-currency commitment for domain controllers, and a rehearsed recovery runbook.

Talk the talk

Jargon decoder

Smart questions to ask

Sysadmins

• When was krbtgt last rotated, and was it a proper double reset?
• Are all DCs past the October 2022 and October 2023 PAC enforcement updates?
• Who holds "Replicating Directory Changes All" besides the DCs?
• Is Credential Guard running on workstations and member servers, and deliberately off on DCs?
• Which accounts are in Protected Users, and did you check for RC4/DES dependencies first?
• Do you have a written, rehearsed procedure for recovering from a DC compromise?

Executives

• If an attacker reached a domain controller, how confident are we that we could fully remove them?
• Do our most privileged administrators use separate, protected machines?
• Have we rehearsed recovering from this kind of compromise?

Coworkers

• Does this engagement allow DCSync, and is the blue team watching for it?
• Are we demonstrating persistence, or just proving the key was reachable?
• What's the client's krbtgt rotation state; is the double reset part of our recommendations?

Say this, not that

Same point, two audiences

Acronyms

Every acronym used on this page. Four test modes are below the table.

Test yourself

Flashcards

Quiz

Fifteen questions, mostly scenarios. Feedback appears as soon as you choose.

Conversation drills

Say or type your answer first, then compare with the sample.

Export cards

Basic cards (Quizlet and Anki Basic)

Standard flashcards, acronym cards, and cloze cards turned into "sentence with ____" fronts. Tab separates front and back; one card per line.

• Quizlet: Create a set, choose Import, paste, set "Between term and definition" to Tab and "Between cards" to New line.
• Anki: Paste into a .txt file, then File, Import, choose the Basic note type with Tab as the field separator.

Anki cloze cards

Uses Anki's {{c1::answer}} syntax. Quizlet doesn't support cloze.

• Anki: Paste into a .txt file, then File, Import, choose the Cloze note type; the whole line maps to the Text field.

Keep going

What to learn next, in order

1. Part 3 of this series: delegation and trust. Unconstrained, constrained and resource-based constrained delegation, the S4U extensions (which underpin sapphire tickets), cross-domain referrals and SID history, Protected Users in depth, and FAST armoring.
2. Active Directory incident response and forest recovery. The runbook side of this page: containment sequencing, krbtgt rotation during an incident, and rebuilding trust.
3. Reading AD attack paths as graphs. BloodHound, to see which footholds reach Tier 0 and the krbtgt key.
4. Active Directory Certificate Services. Certificate-based paths to tickets and to the krbtgt equivalent of trust; a large surface of its own.
5. Detection engineering for identity. Writing and tuning the DCSync, lifetime-anomaly, and PAC-event rules in your SIEM.

Resources worth seeking out

• Microsoft Support: KB5008380 (CVE-2021-42287, PAC requestor), KB5020805 (CVE-2022-37967, full PAC signature), KB5021131 (CVE-2022-37966), and the Credential Guard documentation on Microsoft Learn.
• Specifications: [MS-PAC] for the PAC structure and signatures, and [MS-KILE] for the Windows Kerberos extensions.
• Incident response: Microsoft's AD forest recovery guidance, and CISA's eviction guidance, which cover the double krbtgt reset and New-KrbtgtKeys.ps1.
• MITRE ATT&CK: T1558 (Steal or Forge Kerberos Tickets) and its sub-techniques .001 Golden Ticket and .002 Silver Ticket; T1550.003 Pass the Ticket; T1003.006 OS Credential Dumping: DCSync.
• Research background: the TrustedSec and Semperis write-ups on diamond tickets by Charlie Clark and Andrew Schwartz, for why newer forgeries evade older detections.
• Hands-on labs: the GOAD project, to run DCSync and pass-the-ticket in a safe lab and then find the traces in DC logs.
• Defender reading: Sean Metcalf's ADSecurity.org for golden/silver ticket and krbtgt articles written for defenders.