Diamond Ticket ו־Bronze Bit

Modifying a real TGT under the radar and exploiting Constrained Delegation even on Protected Users.

Diamond Ticket — theory

In a the is built from scratch with the KRBTGT key and an invented PAC. The problem: the invented PAC lacks real details and is therefore easier to detect.

In a nothing is forged — a real legitimate of an existing user is taken, decrypted with the KRBTGT key, the PAC is modified (groups, SIDHistory, privileges are added) and it is re-encrypted. From the outside it looks exactly like a normal TGT — same fields, same signatures.

Result: the attacker escalates to Admin using the legitimate identity and of an ordinary user.

Two columns: left Golden Ticket — forging a TGT from scratch with an invented PAC, easier to detect. Right Diamond Ticket — decrypting a real TGT, modifying the PAC and re-encrypting, looks legitimate. Double KRBTGT rotation invalidates both.

Short and clear

Golden Ticket forges a TGT from scratch with an invented PAC; Diamond Ticket modifies a real existing TGT.
Diamond looks more legitimate — same fields, same signatures.
Bronze Bit bypasses the delegation restriction on Protected Users.
Double KRBTGT rotation invalidates both Golden and Diamond.

Real-life exampleAfter a suspected breach, rotate KRBTGT twice a few hours apart. Every TGT created or modified with the old key immediately becomes invalid.

Bronze Bit (CVE-2020-17049) — theory

The KDC is supposed to refuse S4U2Proxy for accounts marked "Account is sensitive and cannot be delegated" or belonging to Protected Users. The protection relies on the KDC checking the flag and on the PAC signature.

: the attacker extracts the hash of the receiving service account and skips the signature check — submits a request with a "fixed" signature, and the KDC accepts it even for a protected account. An account that should not be delegable becomes delegable in practice.

Practice — lab only

# Diamond Ticket with Rubeus (based on existing TGT)
Rubeus.exe diamond /krbkey:<KRBTGT_AES_KEY> /tgtdeleg /show /ptt

# Or with RC4 key
Rubeus.exe diamond /rc4:<KRBTGT_RC4> /user:victim /domain:corp.local /ptt

powershell

# Bronze Bit against Protected Users account
Rubeus.exe s4u /user:svc_web /rc4:<svc_web_hash> \
  /impersonateuser:Administrator \
  /msdsspn:http/app.corp.local /ptt /bronzebit

powershell

Detection

4768 / 4769 — compare lifetime and encryption type: a is sometimes created with RC4 instead of AES contrary to domain policy.
PAC anomaly: groups or SIDHistory not present in the original account — caught in application-side logs (4624 Type 3 with an expanded PAC).
S4U2Proxy for sensitive accounts — should be zero; any event = a suspicion.
Correlation: svc_web calls the KDC via S4U for Administrator minutes after requesting a hash — a suspicious pattern.

Mitigation

Double rotation of the KRBTGT key (on any compromise suspicion) — invalidates all Diamond/Golden Tickets.
Minimise the delegation attack surface: remove , switch to only.
Protect KRBTGT and DCs — full Tier 0.
Protected Users are still worth it: requires prior rights on the service; this narrows where it is possible.
Patch (November 2020 onward) + KrbtgtFullPacSignature policy.

Diamond Ticket and Bronze Bit

What you will learn here