{ "id": "3322a591-2ef9-4e45-883f-7f62b94623f2", "created_at": "2026-04-06T01:32:05.043521Z", "updated_at": "2026-04-10T03:22:49.916592Z", "deleted_at": null, "sha1_hash": "7856ac12af1494f09df6a5d6fb52d006d7af32ab", "title": "Kerberos Golden Tickets are Now More Golden", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 285138, "plain_text": "Kerberos Golden Tickets are Now More Golden\r\nBy Sean Metcalf\r\nPublished: 2015-08-07 · Archived: 2026-04-06 00:37:28 UTC\r\nAt my talk at Black Hat USA 2015, I highlighted new Golden Ticket capability in Mimikatz (“Enhanced Golden\r\nTickets”). This post provides additional detailed on “enhanced” Golden Tickets.\r\nOver the past few months, I researched how SID History can be abused in modern enterprises. As part of this\r\nresearch, I reached out to Benjamin Delpy, author of Mimkatz, and requested he add “SID History” to Mimikatz\r\nforged Kerberos tickets. The June 28th version of Mimikatz now includes the capability to include arbitrary SIDs\r\nin SID History on forged tickets.\r\nSID History is a legacy feature that enables reach-back across Active Directory trusts. This functionality was put\r\nin place when Active Directory was first released to support migration scenarios. When a user is authenticated, the\r\nSIDs of every security group the user is a member of is added to the user’s Kerberos ticket, as well as any SIDs in\r\nthe user’s SID History. Since SID History is meant to work across trusts, it provides cross-trust “impersonation”.\r\nBefore we dig into this further, let’s recap what Golden Tickets are and how they work.\r\nGolden Tickets\r\nGolden Tickets are forged Ticket-Granting Tickets (TGTs), also called authentication tickets.\r\nAs shown in the following graphic, there is no AS-REQ or AS-REP (steps 1 \u0026 2) communication with the Domain\r\nController. Since a Golden Ticket is a forged TGT, it is sent to the Domain Controller as part of the TGS-REQ to\r\nget a service ticket.\r\nhttps://adsecurity.org/?p=1640\r\nPage 1 of 4\n\nThe Kerberos Golden Ticket is a valid TGT Kerberos ticket since it is encrypted/signed by the domain Kerberos\r\naccount (KRBTGT). The TGT is only used to prove to the KDC service on the Domain Controller that the user\r\nwas authenticated by another Domain Controller. The fact that the TGT is encrypted by the KRBTGT password\r\nhash and can be decrypted by any KDC service in the domain proves it is valid (along with PAC validation, but\r\nthat’s another story 🙂 ).\r\nGolden Ticket Requirements:\r\n* Domain Name [AD PowerShell module: (Get-ADDomain).DNSRoot]\r\n* Domain SID  [AD PowerShell module: (Get-ADDomain).DomainSID.Value]\r\n* Domain KRBTGT Account NTLM password hash\r\n* UserID for impersonation.\r\nOnce an attacker has admin access to a Domain Controller, the KRBTGT account password hashes can be\r\nextracted using Mimikatz.\r\nGolden Ticket “Limitation”\r\nAs incredible as Golden Tickets are, they have been “limited” to spoofing Admin rights to the current domain. The\r\nlimitation exists when the KRBTGT account password hash is exposed in a child domain that is part of a multi-domain AD forest. The issue is that the parent (root) domain contains the forest-wide admin group, Enterprise\r\nAdmins. Since Mimikatz adds group membership by the Relative IDentifiers (RIDs) to the ticket, the 519\r\n(Enterprise Admin) RID is identified in the Kerberos ticket as being local to the domain it was created in (based\r\non the KRBTGT account domain). If the domain Security IDentifier (SID) created by taking the domain SID and\r\nappending the RID doesn’t exist, then the holder of the Kerberos ticket doesn’t receive that level of access.\r\nIn other words, in a mult-domain AD forest, if the domain the Golden Ticket was created in doesn’t contain the\r\nEnterprise Admins group, the Golden Ticket won’t provide admin rights to other domains in the forest.\r\nIn a single domain Active Directory forest, this limitation doesn’t exist since the Enterprise Admins group is\r\nhosted in this domain (and this is where the Golden Tickets would be created).\r\nGraphic: Golden Ticket doesn’t work across trusts unless in EA domain.\r\nhttps://adsecurity.org/?p=1640\r\nPage 2 of 4\n\nThe standard Golden Ticket is limited to the child domain it was created in, so now we add SID History to the\r\nequation…\r\nGolden Ticket + SID History = WINNING!\r\nIn a migration scenario, a user who is migrated from DomainA to DomainB has the original DomainA user SID\r\nadded to the new DomainB SIDHistory attribute. When the user logs onto DomainB with the new account, the\r\nDomainA SID is evaluated along with the DomainB user’s groups which determines access. This means that a\r\nSID can be added to SID History to expand access.\r\nThings get more interesting once Mimikatz supports SID History in Golden Tickets (and Silver Tickets) since any\r\ngroup in the AD Forest can be included and used for authorization decisions. In order to support my research into\r\nhow to expand access using SID History in Kerberos tickets across trusts (both intra-forest and external), I\r\nreached out to Benjamin Delpy in late June and requested SID History be added.\r\nUsing the latest version of Mimikatz, we can now add SID History to the Golden Ticket for the Forest Enterprise\r\nAdmins group. This enables forest-wide compromise once a single domain’s KRBTGT account password hash is\r\nexposed.\r\n In summary, Golden Tickets can now be used to compromise any domain in the AD Forest once a single\r\none is compromised.\r\nhttps://adsecurity.org/?p=1640\r\nPage 3 of 4\n\nUpdate:\r\nIt has been noted that enabling SID Filtering between trusts in an Active Directory forest would mitigate this since\r\nSID History wouldn’t work. That may be true, though there’s a couple of potential issues with this approach: 1) I\r\nhave never seen this configured in a production environment, 2) I’m not sure of Microsoft’s support posture on\r\nthis, and 3) enabling SID filtering on trusts within an AD forest may break applications that rely on universal\r\ngroup membership across domains (this could be a pretty big deal since universal groups are typically used\r\nfrequently in multi-domain AD forests). These may seem like minor issues, but I have seen several large enterprise\r\nAD environments that break when non-standard approaches are taken since the developers didn’t take the config\r\ninto account when testing.\r\nMore on Active Directory trust security.\r\nNote that the Active Directory domain is not the security boundary; the AD forest is. This means that if you need\r\naccount isolation, you need AD forests, not domains in an AD forest.\r\nSource: https://adsecurity.org/?p=1640\r\nhttps://adsecurity.org/?p=1640\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://adsecurity.org/?p=1640" ], "report_names": [ "?p=1640" ], "threat_actors": [ { "id": "b740943a-da51-4133-855b-df29822531ea", "created_at": "2022-10-25T15:50:23.604126Z", "updated_at": "2026-04-10T02:00:05.259593Z", "deleted_at": null, "main_name": "Equation", "aliases": [ "Equation" ], "source_name": "MITRE:Equation", "tools": null, "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775439125, "ts_updated_at": 1775791369, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/7856ac12af1494f09df6a5d6fb52d006d7af32ab.pdf", "text": "https://archive.orkl.eu/7856ac12af1494f09df6a5d6fb52d006d7af32ab.txt", "img": "https://archive.orkl.eu/7856ac12af1494f09df6a5d6fb52d006d7af32ab.jpg" } }