{
	"id": "fa3d404b-43dd-4c69-9bcd-2ec0472dd41d",
	"created_at": "2026-04-06T00:10:23.547041Z",
	"updated_at": "2026-04-10T03:20:26.935291Z",
	"deleted_at": null,
	"sha1_hash": "e2b284be5c2c8576576f7af63825fc32987ab5b5",
	"title": "It’s All About Trust – Forging Kerberos Trust Tickets to Spoof Access across Active Directory Trusts",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 810477,
	"plain_text": "It’s All About Trust – Forging Kerberos Trust Tickets to Spoof\r\nAccess across Active Directory Trusts\r\nBy Sean Metcalf\r\nPublished: 2015-07-15 · Archived: 2026-04-05 16:37:21 UTC\r\nIn early 2015, I theorized that it’s possible to forge inter-realm (inter-trust) Kerberos tickets in a similar manner to\r\nhow intra-domain TGTs (Golden Tickets) and TGSs (Silver Tickets) are forged. Around the same time, Benjamin\r\nDelpy updated Mimikatz to dump trust keys from a Domain Controller. Soon after, Mimikatz gained capability to\r\nforge inter-realm trust tickets. Benjamin Delpy added “Kekeo” to Github which includes “AskTGS” which\r\nprovides the capability to request TGS service tickets for targeted services in the destination domain and save\r\nthem to file. With the tools enabling further research, I was able to explore what is possible with forged cross-trust\r\nKerberos tickets.\r\nNote that forging a Kerberos Trust Ticket is similar to forging a Golden Ticket or a Silver Ticket.\r\nThe key to the power of a Kerberos Trust Ticket within a multi-domain Active Directory forest is Enterprise\r\nAdmins membership which easily crosses domain boundaries providing effective Domain Admin rights in every\r\ndomain in the AD forest.\r\nI presented on “Trust Tickets” at Shakacon in Hawaii last week. Simply put, Trust Tickets are forged inter-realm\r\nKerberos tickets. When there are two Active Directory domains connected via trust, there is a password which is\r\nshared between them used to keep the trust active. This trust password is also used as the shared secret in\r\nKerberos.\r\nI also presented at Black Hat USA 2015 how I enabled Golden Tickets to work across domains in the same forest\r\n(aka Enhanced Golden Tickets).\r\nUpdate 9/2/2015: I updated the screenshots to accurately show how the intra-forest trust is exploited using\r\nthe current version of Mimikatz.\r\nhttps://adsecurity.org/?p=1588\r\nPage 1 of 9\n\nKerberos Across Trusts\r\nKerberos communication within a domain is pretty straightforward – the domain Kerberos service account is used\r\nto sign and encrypt every authentication ticket (TGT). This enables the TGT to be used throughout the domain and\r\npresented to any DC in the domain. This works since the Kerberos service account (KRBTGT) is effectively the\r\ntrust anchor used for the domain and is why losing control of the KRBTGT account password hash equates to\r\nlosing control of the domain.\r\nWhen a user authenticates to Active Directory, the authenticating Domain Controller creates a TGT\r\n(authentication ticket) for the user that contains the groups the user is a member of (including groups from other\r\ndomains in the forest, such as universal groups), signs, and encrypts the ticket using the KRBTGT password hash.\r\nWhen presented later to the DC for a service ticket (TGS), the TGT ticket and its contents are validated. The DC\r\neffectively copies the contents of the TGT into a TGS (service ticket) that the user presents to the target service.\r\nOne component of the TGS is encrypted with the target service’s password hash and the other with the user’s\r\npassword hash. If the target service can open the TGS, it is accepted. This means that the user’s TGT can be\r\nreused to get service tickets during the TGT’s lifetime (10 hours by default). The TGT is also portable, so if an\r\nattacker can steal a user’s TGT, it can be reused on any other computer on the network, at the same time, to access\r\nany resource to which the user has access.\r\nWhen an attacker gains access to the KRBTGT password hash on the domain, it is possible for them to generate\r\ntheir own TGTs (called “Golden Tickets”) that are accepted by all the Domain Controllers in the domain since\r\nthey are signed and encrypted with the domain Kerberos service account data. Simply put, a Golden Ticket is a\r\nvalid TGT.\r\nIn order for the user to access resources in another domain in the same forest, the Kerberos process involves\r\nanother layer since the Kerberos service (KDC) in one domain can’t issue a service ticket (TGS) in another. Since\r\nthe TGS can only be built using the target service’s password data and Domain Controllers (DCs) only contain\r\npassword data for security principals (users, computers, etc) in their own domain, the DC does not have the target\r\nservices password data and can’t create the TGS. In order to resolve this issue, there is a trust password between\r\ntwo domains in the same AD forest used as a bridge enabling Kerberos authentication across domains.\r\nhttps://adsecurity.org/?p=1588\r\nPage 2 of 9\n\nOnce there is a trust between two domains, (domain BLUE and domain GREEN both are in the same AD forest\r\nfor this example), the ticket-granting service of each domain (“realm” in Kerberos speak) is registered as a\r\nsecurity principal with the other domain’s Kerberos service (KDC). This enables the ticket-granting service in\r\neach domain to treat the one in the other domain as just another service providing cross-domain service access for\r\nresources in the other domain.\r\nThe Kerberos flow is the same as described earlier for all resources accessed within the domain. When the user\r\nrequests a service ticket for a resource in another domain, the DC in the user’s domain (BLUE) sends the user a\r\nTGS referral message as part of the normal service ticket response message (TGS_REP) from the DC to the user.\r\nThis message includes a TGT for the other domain where the desired resource is located (GREEN) and indicates it\r\nis a referral to another TGS. The TGT for the other domain is not signed by the GREEN domain’s KRBTGT\r\naccount since the BLUE domain DCs don’t know the password for that account. Instead, the TGT for the other\r\ndomain is signed and encrypted using the inter-realm key which is derived from the trust password. Since this\r\ninter-realm ticket is a TGT, it contains the user’s credentials and group membership though its signed with the\r\ninter-realm key, not the DC’s KRBTGT service account. The user needs to have access to the resource in the other\r\ndomain in order for access to be granted.\r\nInter-realm trust communication becomes more complicated in an Active Directory forest with multiple domains,\r\nincluding parent (root) and child domains.\r\nImagine an AD forest with three domains, ROOT, CHILD1, \u0026 CHILD2.\r\n1. ROOT is the root domain with the other two configured as child domains, so ROOT has automatic two-way transitive trusts with both CHILD1 \u0026 CHILD2.\r\n2. In order for a CHILD1 user to access a resource in CHILD2, the following occurs:\r\n3. CHILD1 user authenticates and gets the user’s TGT for the CHILD1 domain.\r\n4. The user requests a service ticket for a share in CHILD2.\r\nhttps://adsecurity.org/?p=1588\r\nPage 3 of 9\n\n5. The CHILD1 DC copies the CHILD1 TGT into a new inter-realm TGT (using the ROOT-CHILD1 inter-realm key) and sends it to the user along with a referral to the ROOT domain.\r\n6. The user sends the (ROOT-CHILD1) IR-TGT to a ROOT DC along with the TGS_REQ for the resource.\r\n7. The ROOT DC copies the IR-TGT into a new inter-realm TGT (using the ROOT-CHILD2 inter-realm key)\r\nand sends it to the user along with a referral to the CHILD2 domain.\r\n8. The user sends the (ROOT-CHILD2) IR-TGT to a CHILD2 DC along with the TGS_REQ for the resource.\r\n9. The CHILD2 DC copies the IR-TGT into a TGS used to access the resource.\r\nNote that the original referral message the user gets includes a session key for communicating with the ROOT\r\nDC. The ROOT DC then provides a new session key for the user to use to communicate with the CHILD2 DC.\r\nForging Kerberos “Trust Tickets”\r\nIn a scenario where an attacker compromised a single domain in an AD forest and dumped all the credentials, the\r\nattacker would naturally use Golden Tickets since they enable full access to the domain and the AD forest (Golden\r\nTickets include Enterprise Admin group membership by default). The well-known remediation of Golden Ticket\r\ncreation and use is to change the compromised KRBTGT account password twice. After this action is complete,\r\nthe attacker can’t create any more Golden Tickets. However, there is another avenue for an attacker that has\r\ndumped all credentials from a Domain Controller to re-exploit the multi-domain AD forest. Since every domain in\r\nan AD forest has an implicit trust (and associated trust password) with at least one other domain, the attacker can\r\nforge a different type of Kerberos ticket to spoof Enterprise Admin rights in the target domain. Enterprise Admins\r\nare members of the Administrators group in every domain in an AD forest, this level of access enables the attacker\r\nto compromise all domains. This is kind of like a Golden Ticket across trusts.\r\nForging the Inter-Realm TGT (IR-TGT) for access isn’t necessary if you have the KRBTGT account password,\r\nbut if that has changed twice, the forged IR-TGT (Trust Ticket) can be used to impersonate an EA and regain full\r\ndomain/forest admin rights. Since there’s an automatic, two-way transitive trust for every domain in the forest,\r\ngetting the trust key for one trust, enables access to the others (though I’m not sure if the tools support this right\r\nnow). This is due to the trust flow.\r\nIt’s not a Silver Ticket since it’s not a forged TGS and it’s not exactly a Golden Ticket since it’s not using the\r\nKRBTGT account to forge a TGT. Forge the inter-realm TGT for a user in Domain A for the TGS_REQ to the\r\nDomain B DC to get a valid TGS to the Domain B resource.\r\nWhile forging trust keys should work really well in a multi-domain AD forest, there are a variety of trust options\r\nbetween domains/forests that could cause problems with attempting to extend compromise of one to another. With\r\nthat said, if a user in Domain A has elevated rights to resources in Domain B, the forged IR-TGT should provide\r\nan attacker the same access as a Golden Ticket (since it would be used as the basis for the IR-TGT). One brilliant\r\nway to exploit this is to add admin groups for Domain B in the user’s forged IR-TGT in SID History (assuming\r\nthe trust has it enabled), though this is theoretical at this point.\r\nNote:\r\nTwo-way trusts are actually 2 one-way trusts, each of which has a different password which only change every 30\r\ndays (default). The TrustING domain PDC performs the password change for the trust.\r\nhttps://adsecurity.org/?p=1588\r\nPage 4 of 9\n\nHarmJ0y has additional detail on this issue including great trust recon tools in PowerView.\r\nForging External Trust Tickets\r\nThere are essentially two different types of trust in Active Directory: one external to the AD forest and one\r\ninternal. In this first section, we cover forging external trusts.\r\nStep 1: Dumping trust passwords (trust keys)\r\nThe trust password is in a domain credential dump, just look for the trust name with a dollar ($) sign at the end.\r\nMost of the accounts with a trailing “$” are computer accounts, but some are trust accounts.\r\nStep 2: Create a forged trust ticket (inter-realm TGT) using Mimikatz\r\nNote that the trust password, aka trust key, was extracted along with all user data when dumping AD credentials.\r\nEach trust has an associated user account which contains that NTLM password hash. This data can be used to\r\nforge “Trust Tickets”. We use the trust password for the external trust to create the Trust Ticket file. The trust\r\npassword is the same as what I used to create it. To create a trust with another forest, an admin on one side enters\r\nthe trust password and the other admin uses the same trust password which may be sent via email to ensure it is\r\nentered correctly. This means that when a trust is first created, any one with knowledge of the trust password can\r\ncreate Trust Tickets. Creating a Trust Ticket is similar to creating a Golden Ticket., in fact it’s the same Mimikatz\r\ncommand, just with different options. The service key is the trust NTLM password hash and the target is the target\r\ndomain FQDN.\r\nSave this ticket to a file for step 2\r\nStep 3: Use the Trust Ticket file created in Step 2 to get a TGS for the targeted service in the destination\r\ndomain. Save the TGS to a file.\r\nhttps://adsecurity.org/?p=1588\r\nPage 5 of 9\n\nStep 4: Inject the TGS file created in Step 3 and then access the targeted service with the spoofed rights.\r\nForging Internal AD Forest Trust Tickets\r\nStep 1: Dumping trust passwords (trust keys)\r\nCurrent Mimikatz versions can extract the trust keys (passwords).\r\nhttps://adsecurity.org/?p=1588\r\nPage 6 of 9\n\nStep 2: Create a forged trust ticket (inter-realm TGT) using Mimikatz\r\nForge the trust ticket which states the ticket holder is an Enterprise Admin in the AD Forest (leveraging\r\nSIDHistory, “sids”, across trusts in Mimikatz, my “contribution” to Mimikatz). This enables full administrative\r\naccess from a child domain to the parent domain. Note that this account doesn’t have to exist anywhere as it is\r\neffectively a Golden Ticket across the trust.\r\nhttps://adsecurity.org/?p=1588\r\nPage 7 of 9\n\nStep 3: Use the Trust Ticket file created in Step 2 to get a TGS for the targeted service in the destination\r\ndomain. Save the TGS to a file.\r\nThe resulting TGS provides EA access to the parent (root) domain’s Domain Controller.\r\nStep 4: Inject the TGS file created in Step 3 and then access the targeted service with the spoofed rights.\r\nOnce the ticket is passed the user is an Enterprise Admin for the AD forest and has DA rights to the DC in the\r\ntarget domain. This is a great way to escalate rights across other domains in the forest. Note that unless an attacker\r\ngets the KRBTGT account in the domain that hosts the EA group, the Golden Ticket only grants DA rights to the\r\ncurrent domain (the one the Golden Ticket was created in). Once the attacker dumps the credentials for the current\r\ndomain, the trust password is used to create a Trust Key that states the holder of the ticket is EA. Then the target\r\ndomain can be exploited. This can be repeated to move through every domain in the forest quite easily since every\r\nchild domain inherently trusts the parent aka root domain. So, using a Trust Ticket to become EA in the AD forest\r\ninvolves compromising a single domain.\r\nConclusion\r\nIn a multi-domain AD forest, each domain has a trust with at least one other domain. Each trust has an associated\r\npassword which can be used to forge trust tickets. Compromise one domain to potentially compromise another.\r\nReducing the AD computer account policy mitigates this attack since Trust passwords are changed on this\r\nschedule (TrustING domain).\r\nRegarding Trust Tickets within an Active Directory Forest:\r\n1. Using a Kerberos trust ticket from Child domain impersonating a Child domain user provides the level of\r\naccess that Child domain user has at the Parent domain. If the Child domain user is a member of Enterprise\r\nAdmins or a group that has admin rights on the parent, the forged Trust Ticket provides admin access to the\r\nparent.\r\nhttps://adsecurity.org/?p=1588\r\nPage 8 of 9\n\n2. Using the /sids parameter in Mimikatz to add the Enterprise Admins group in the Parent domain to the\r\nChild domain user account in the Trust Ticket provides EA rights to the Parent domain without the Child\r\ndomain user account actually having these rights. Note that this is similar behavior to “enhanced” Golden\r\nTickets since they use SID History to spoof access across domains.\r\n3. Even if the KRBTGT account password is rotated on a regular basis, the attacker may still have the trust\r\nkey (password) and can use that to regain full Enterprise Admin rights.\r\nMitigating factor: Changing the domain machine password policy to be a low number in the TrustING domain\r\nensures the trust password changes more quickly (along with the domain computer account passwords).\r\nBest Mitigation: Don’t let attackers run code on DCs – Protect Domain Admins!\r\nReferences:\r\nKerberos, Active Directory’s Secret Decoder Ring\r\nhttp://adsecurity.org/?p=227\r\nKerberos, Kerberos across trusts, and trust passwords\r\nhttps://technet.microsoft.com/en-us/library/cc772815%28v=ws.10%29.aspx\r\nMimikatz and Active Directory Kerberos Attacks\r\nhttp://adsecurity.org/?p=556\r\nKerberos \u0026 KRBTGT: Active Directory’s Domain Kerberos Account\r\nhttp://adsecurity.org/?p=483\r\nBlack Hat USA 2014 – Windows: Abusing Microsoft Kerberos Sorry You Guys Don’t Get It\r\nhttps://www.youtube.com/watch?v=-IMrNGPZTl0\u0026index=4\u0026list=UUbbgnifxfH-nqx6z9XQ963Q\r\nMimikatz and Golden Tickets… What’s the BFD? BlackHat USA 2014 Redux part 1\r\nhttp://passing-the-hash.blogspot.com/2014/08/mimikatz-and-golden-tickets-whats-bfd.html\r\nMimikatz Golden Ticket blog entry by Benjamin Delpy (Mimikatz author)\r\nhttp://blog.gentilkiwi.com/securite/mimikatz/golden-ticket-kerberos\r\nProtection from Kerberos Golden Ticket: Mitigating pass the ticket on Active Directory (CERT-EU\r\nSecurity White Paper 2014-07)\r\nhttp://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_07_PassTheGolden_Ticket_v1_1.pdf\r\n(Visited 61,464 times, 4 visits today)\r\nSource: https://adsecurity.org/?p=1588\r\nhttps://adsecurity.org/?p=1588\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://adsecurity.org/?p=1588"
	],
	"report_names": [
		"?p=1588"
	],
	"threat_actors": [],
	"ts_created_at": 1775434223,
	"ts_updated_at": 1775791226,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e2b284be5c2c8576576f7af63825fc32987ab5b5.pdf",
		"text": "https://archive.orkl.eu/e2b284be5c2c8576576f7af63825fc32987ab5b5.txt",
		"img": "https://archive.orkl.eu/e2b284be5c2c8576576f7af63825fc32987ab5b5.jpg"
	}
}