{
	"id": "a2598c62-eb8b-454c-bf8b-0e4f7c311457",
	"created_at": "2026-04-06T00:13:42.153569Z",
	"updated_at": "2026-04-10T03:21:44.098302Z",
	"deleted_at": null,
	"sha1_hash": "fcbd442036a8416ccf84e756e72ac6584a332774",
	"title": "Detecting Forged Kerberos Ticket (Golden Ticket \u0026 Silver Ticket) Use in Active Directory",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 799769,
	"plain_text": "Detecting Forged Kerberos Ticket (Golden Ticket \u0026 Silver Ticket)\r\nUse in Active Directory\r\nBy Sean Metcalf\r\nPublished: 2015-05-03 · Archived: 2026-04-05 22:30:18 UTC\r\nOver the last 6 months, I have been researching forged Kerberos tickets, specifically Golden Tickets, Silver\r\nTickets, and TGTs generated by MS14-068 exploit code (a type of Golden Ticket). I generated forged Kerberos\r\ntickets using Mimikatz (Mimikatz Command Reference) and MS14-068 exploits and logged the results. Over the\r\ncourse of several weeks, I identified anomalies in the event logs that are clear indication of forged ticket use in an\r\nActive Directory environment.\r\nUpdate1/5/2016:\r\nAround this time last year (early January 2015), I shared with customers these indicators for detecting forged\r\nKerberos tickets and subsequently presented this information at BSides Charm 2015. Soon after, Mimikatz was\r\nupdated with a domain field that was set to static values, usually containing the string “eo.oe”. As of the Mimikatz\r\nupdate dated 1/5/2016, forged Kerberos tickets no longer include a domain anomaly since the netbios domain\r\nname is placed in the domain component of the Kerberos ticket.\r\nMimikatz code diff:\r\nMore information on the difficulty of detecting forged Kerberos tickets (Golden Tickets, Silver Tickets, etc) in the\r\nin the Detecting Forged Kerberos Tickets section below.\r\nKerberos Overview \u0026 Communication Process:\r\nhttps://adsecurity.org/?p=1515\r\nPage 1 of 12\n\nUser logs on with username \u0026 password.\r\n1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an\r\nauthenticator in the authentication ticket (TGT) request (AS-REQ).\r\n1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) \u0026 creates\r\nTicket-Granting Ticket (TGT).\r\n2. The TGT is encrypted, signed, \u0026 delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the\r\ndomain can open and read TGT data.\r\n3. The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The\r\nDC opens the TGT \u0026 validates PAC checksum – If the DC can open the ticket \u0026 the checksum check out, TGT =\r\nvalid. The data in the TGT is effectively copied to create the TGS ticket.\r\n4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).\r\n5.The user connects to the server hosting the service on the appropriate port \u0026 presents the TGS (AP-REQ). The\r\nservice opens the TGS ticket using its NTLM password hash.\r\n6. If mutual authentication is required by the client (think MS15-011: the Group Policy patch from February that\r\nadded UNC hardening).\r\nUnless PAC validation is required (rare), the service accepts all data in the TGS ticket with no communication to\r\nthe DC.\r\nActive Directory Kerberos Key Points:\r\nMicrosoft uses the NTLM password hash for Kerberos RC4 encryption.\r\nKerberos policy is only checked when the TGT is created \u0026 the TGT is the user authenticator to the DC.\r\nhttps://adsecurity.org/?p=1515\r\nPage 2 of 12\n\nThe DC only checks the user account after the TGT is 20 minutes old to verify the account is valid or\r\nenabled. TGS PAC Validation only occurs in specific circumstances. When it does, LSASS on the server\r\nsends the PAC Validation request to the DC’s netlogon service (using NRPC)\r\nIf it runs as a service, PAC validation is optional (disabled). If a service runs as System, it performs server\r\nsignature verification on the PAC (computer account long-term key).\r\nForging Kerberos Tickets:\r\nForging Kerberos tickets depends on the password hash available to the attacker\r\nGolden Ticket requires the KRBTGT password hash.\r\nSilver ticket requires the Service Account (either the computer account or user account) password hash.\r\nCreate anywhere and user anywhere on the network, without elevated rights.\r\nSpoof access without modifying AD groups.\r\nOnce the KRBTGT account password is disclosed, the only way to prevent Golden Tickets is to change the\r\nKRBTGT password twice, since the current and previous passwords are kept for this account.\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\nThe Kerberos Golden Ticket is a valid TGT Kerberos ticket since it is encrypted/signed by the domain\r\nKerberos account (KRBTGT). The TGT is only used to prove to the KDC service on the Domain\r\nController that the user was authenticated by another Domain Controller. The fact that the TGT is\r\nencrypted by the KRBTGT password hash and can be decrypted by any KDC service in the domain proves\r\nit is valid.\r\nhttps://adsecurity.org/?p=1515\r\nPage 3 of 12\n\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\nThe Domain Controller KDC service doesn’t validate the user account in the TGT until the TGT is older\r\nthan 20 minutes old, which means the attacker can use a disabled/deleted account or even a fictional\r\naccount that doesn’t exist in Active Directory.\r\nMicrosoft’s MS-KILE specification (section 5.1.3 ):\r\n    “Kerberos V5 does not provide account revocation checking for TGS requests, which allows TGT\r\nrenewals and service tickets to be issued as long as the TGT is valid even if the account has been revoked.\r\nKILE provides a check account policy (section 3.3.5.7.1) that limits the exposure to a shorter time. KILE\r\nKDCs in the account domain are required to check accounts when the TGT is older than 20 minutes. This\r\nlimits the period that a client can get a ticket with a revoked account while limiting the performance cost\r\nfor AD queries.”\r\nSince the domain Kerberos policy is set on the ticket when generated by the KDC service on the Domain\r\nController, when the ticket is provided, systems trust the ticket validity. This means that even if the domain\r\npolicy states a Kerberos logon ticket (TGT) is only valid for 10 hours, if the ticket states it is valid for 10\r\nyears, it is accepted as such.\r\nThe KRBTGT account password is never changed* and the attacker can create Golden Tickets until the\r\nKRBTGT password is changed (twice). Note that a Golden Ticket created to impersonate a user persists\r\neven if the impersonated user changes their password.\r\nIt bypasses SmartCard authentication requirement since it bypasses the usual checks the DC performs\r\nbefore creating the TGT.\r\nThis crafted TGT requires an attacker to have the Active Directory domain’s KRBTGT password hash\r\n(typically dumped from a Domain Controller).\r\nThe KRBTGT NTLM hash can be used to generate a valid TGT (using RC4) to impersonate any user with\r\naccess to any resource in Active Directory.\r\nThe Golden Ticket (TGT) be generated and used on any machine, even one not domain-joined.\r\nUsed to get valid TGS tickets from DCs in the AD forest and provides a great method of persisting on a\r\ndomain with access to EVERYTHING!\r\nMitigation:\r\nLimit Domain Admins from logging on to any other computers other than Domain Controllers and a handful of\r\nAdmin servers (don’t let other admins log on to these servers) Delegate all other rights to custom admin groups.\r\nThis greatly reduces the ability of an attacker to gain access to a Domain Controller’s Active Directory database.\r\nIf the attacker can’t access the AD database (ntds.dit file), they can’t get the KRBTGT account password data.\r\nThe KRBTGT account is disabled and stores the current password as well as the previous one. The KRBTGT\r\npassword hash is used to sign the PAC in Kerberos tickets as well as encrypt the TGT (Authentication ticket). If a\r\nhttps://adsecurity.org/?p=1515\r\nPage 4 of 12\n\nticket is signed/encrypted with a different key (password) then the DC (KDC) is expecting, it checks the KRBTGT\r\nprevious password to see if that is successful. This is the reason why both passwords are kept.\r\nIt’s advisable to regularly change the KRBTGT password (it is an admin account after all). Changing it once, then\r\nletting AD replicate, and changing it a second time about 12 to 24 hours later, will update both of the KRBTGT\r\npasswords (current and previous) in a manner that doesn’t invalidate every existing Kerberos ticket. This process\r\nshould have no negative impact on the environment (but as always, test first). This process should be the standard\r\nmethod for ensuring the KRBTGT password changes at least once a year (and when an AD admin leaves the\r\norganization, loss of control of AD backup media, etc).\r\nOnce an attacker has gained access to the KRBTGT account password hash(es), they can create Golden Tickets at\r\nwill. Invalidate any existing Golden Tickets (and all active Kerberos tickets) by changing the KRBTGT password\r\ntwice rapidly (aka “double-tap”). This invalidates all Kerberos tickets and removes the attacker ability to create\r\nvalid Golden Tickets with their KRBTGT (assuming they don’t have the ability to pull the updated KRBTGT pw\r\nhashes). This KRBTGT password “double-tap” is required when in a breach scenario and there’s an active attacker\r\noperating on the network. Contact an Incidence Response company if you are in this situation first.\r\nUsing Mimikatz to Forge Kerberos Tickets:\r\nThe Mimikatz command Kerberos:Golden is used to create the “Golden Ticket” (forged TGT authentication\r\nticket).\r\nMimikatz command example:\r\nkerberos::golden /admin:ADMIINACCOUNTNAME /domain:DOMAINFQDN /id:ACCOUNTRID\r\n/sid:DOMAINSID /krbtgt:KRBTGTPASSWORDHASH /ptt\r\nSilver Tickets:\r\nhttps://adsecurity.org/?p=1515\r\nPage 5 of 12\n\nSilver Tickets are forged Ticket Granting Service tickets, also called service tickets.\r\nAs shown in the following graphic, there is no AS-REQ / AS-REP (steps 1 \u0026 2) and no TGS-REQ / TGS-REP\r\n(steps 3 \u0026 4) communication with the Domain Controller. Since a Silver Ticket is a forged TGS, there is no\r\ncommunication with a Domain Controller.\r\nAlluded to at BlackHat during the “Golden Ticket” presentation (Duckwall/Delpy) and discussed partly\r\nduring Tim Medin’s DerbyCon 2014 talk. Skip \u0026 Benjamin have provided additional information on Silver\r\nTickets since, but confusion remains.\r\nThe Kerberos Silver Ticket is a valid Ticket Granting Service (TGS) Kerberos ticket since it is\r\nencrypted/signed by the service account configured with a Service Principal Name for each server the\r\nKerberos-authenticating service runs on.\r\nWhile a Golden ticket is a forged TGT valid for gaining access to any Kerberos service, the silver ticket is\r\na forged TGS. This means the Silver Ticket scope is limited to whatever service is targeted on a specific\r\nserver.\r\nWhile a Golden ticket is encrypted/signed with the domain Kerberos service account (KRBTGT), a Silver\r\nTicket is encrypted/signed by the service account (computer account credential extracted from the\r\ncomputer’s local SAM or service account credential).\r\nMost services don’t validate the PAC (by sending the PAC checksum to the Domain Controller for PAC\r\nvalidation), so a valid TGS generated with the service account password hash can include a PAC that is\r\nentirely fictitious – even claiming the user is a Domain Admin without challenge or correction.\r\nThe attacker needs the service account password hash\r\nTGS is forged, so no associated TGT, meaning the DC is never contacted.\r\nAny event logs are on the targeted server.\r\nIn my opinion, Silver Tickets can be more dangerous than Golden Tickets – while the scope is more limited than\r\nGolden Tickets, the required hash is easier to get and there is no communication with a DC when using them, so\r\ndetection is more difficult than Golden Tickets\r\nhttps://adsecurity.org/?p=1515\r\nPage 6 of 12\n\nThe following Mimikatz command creates a Silver Ticket for the CIFS service on the server\r\nadsmswin2k8r2.lab.adsecurity.org. In order for this Silver Ticket to be successfully created, the AD computer\r\naccount password hash for adsmswin2k8r2.lab.adsecurity.org needs to be discovered, either from an AD domain\r\ndump or by running Mimikatz on the local system as shown above (Mimikatz “privilege::debug”\r\n“sekurlsa::logonpasswords” exit). The NTLM password hash is used with the /rc4 paramteer. The service SPN\r\ntype also needs to be identified in the /service parameter. Finally, the target computer’s fully-qualified domain\r\nname needs to be provided in the /target parameter. Don’t forget the domain SID in the /sid parameter.\r\nmimikatz “kerberos::golden /admin:LukeSkywalker /id:1106 /domain:lab.adsecurity.org /sid:S-1-5-21-\r\n1473643419-774954089-2222329127 /target:adsmswin2k8r2.lab.adsecurity.org\r\n/rc4:d7e2b80507ea074ad59f152a1ba20458 /service:cifs /ptt” exit\r\nDetecting Forged Kerberos Tickets:\r\nMost logon \u0026 logoff events include the following detail. Normal, valid account logon event data structure:\r\nSecurity ID:  DOMAIN\\AccountID\r\nAccount Name:  AccountID\r\nAccount Domain:  DOMAIN\r\nI discovered that the domain field in many events in the Windows security event log are not properly populated\r\nwhen forged Kerberos tickets are used. The key indicator is that the domain field is blank or contains the FQDN\r\ninstead of the short (netbios) name and depending on the tool used to generate the Kerberos tickets, other domain\r\nfield anomalies may be present in the events.\r\nThe likely reason for the anomalies is that third party tools that create Kerberos tickets (TGT \u0026 TGS) don’t format\r\nthe tickets exactly the same way as Windows does.\r\nThe following includes some of the events I have identified that are logged when forged Kerberos tickets are used.\r\nNote that Silver Ticket events could be logged on any computer in the AD domain depending on what the target is,\r\nworkstations, member servers, or Domain Controllers. Golden Tickets and MS14-068 exploit tickets, all of which\r\nare TGTs, will have events logged on the Domain Controller.\r\nhttps://adsecurity.org/?p=1515\r\nPage 7 of 12\n\nNOTE: As of 4/16/2015: Mimikatz generated tickets may include the string “eo.oe.kiwi : ) ” in the domain field.\r\nNOTE: As of 6/29/2015: Mimikatz generated tickets may include the string “\u003c3 eo.oe – ANSSI E\u003e” in the domain\r\nfield.\r\nAs stated at the top of this post, as of January 5th, 2016, Mimikatz no longer includes static values in Kerberos\r\nticket domain fields which previously may have had anomalies from being blank to containing the string “eo.oe”.\r\nAs of the Mimikatz update dated 1/5/2016, forged Kerberos tickets no longer include a domain anomaly since the\r\nnetbios domain name is placed in the domain component of the Kerberos ticket. This means that attackers using\r\nthe Mimikatz version dated 1/5/2016 and/or Invoke-Mimikatz with this updated DLL will not trigger alerts based\r\non the invalid domain fields I identified in the past.\r\nOne method that is reliable is to look for RC4 encrypted Kerberos ticket usage.  These should be rare on a modern\r\nnetwork since Windows Vista \u0026 Windows Sever 2008 and newer support AES Kerberos encryption.\r\nNote that if the attacker uses the NTLM password hash when creating the Golden Ticket, the TGT ticket will have\r\nRC4 encryption. If the Golden Ticket is created using the AES string, the TGT ticket will use AES, and will be\r\nvery difficult to find. Read more about this in the Mimikatz guide.\r\nUser behavior analysis tools such as Microsoft Advanced Threat Analytics (ATA) is the best current method to\r\ndetect this and other attack types (though these methods also tend to involve ticket encryption type in the\r\ndetection techniques).\r\nThe best way to detect Golden Tickets is to correlate TGS requests to prior TGT requests. Since a TGT request\r\nshould always preceed a TGS request, if there’s no prior TGT request (within a threshold), then the TGS\r\nrequest may be related to a Golden Ticket.\r\nGolden Ticket event from using Mimikatz dated (11/2015): Has the an invalid domain value (“\u003c3 eo.oe –\r\nANSSI E\u003e“)\r\nhttps://adsecurity.org/?p=1515\r\nPage 8 of 12\n\nGolden Ticket event from using Mimikatz dated (1//05/2015):  Has the correct domain value (“RD”)\r\nhttps://adsecurity.org/?p=1515\r\nPage 9 of 12\n\nExpect that Mimikatz will continue to have different values in this field and that attackers may update this field to\r\nmatch the targeted environment. While these indicators may continue to have some value, they can’t be relied on\r\nas primary detection of forged Kerberos ticket use. With that noted, monitoring events for domain field\r\nanomalies may still be the best and easiest way to detect forged Kerberos tickets other than looking for “special\r\nlogon events” involving non-admins – these events are logged when accounts with admin rights log on.\r\nThe following is left here for historic purposes and may be removed at a later date.\r\nSILVER TICKET DETECTION\r\nSilver Ticket events may have one of these issues:\r\nThe Account Domain field is blank when it should be DOMAIN\r\nThe Account Domain field is DOMAIN FQDN when it should be DOMAIN.\r\nEvent ID: 4624 (Account Logon)\r\nAccount Domain is FQDN \u0026 should be short domain name\r\nAccount Domain:        LAB.ADSECURITY.ORG   [ADSECLAB]\r\nEvent ID: 4634 (Account Logoff)\r\nhttps://adsecurity.org/?p=1515\r\nPage 10 of 12\n\nAccount Domain is blank \u0026 should be short domain name\r\nAccount Domain:        _______________   [ADSECLAB]\r\nEvent ID: 4672 (Admin Logon)\r\nAccount Domain is blank \u0026 should be short domain name\r\nAccount Domain:        _______________   [ADSECLAB]\r\nGOLDEN TICKET DETECTION\r\nGolden Ticket events may have one of these issues:\r\nThe Account Domain field is blank when it should be DOMAIN\r\nThe Account Domain field is DOMAIN FQDN when it should be DOMAIN.\r\nEvent ID: 4624 (Account Logon)\r\nAccount Domain is FQDN \u0026 should be short domain name\r\nAccount Domain:        LAB.ADSECURITY.ORG   [ADSECLAB]\r\nEvent ID: 4672 (Admin Logon)\r\nAccount Domain is blank \u0026 should be short domain name\r\nAccount Domain:        _______________   [ADSECLAB]\r\nMS14-068 Exploit Ticket Detection\r\nMS14-068 events may have one of these issues:\r\nThe Account Domain field is blank when it should be DOMAIN\r\nThe Account Domain field is DOMAIN FQDN when it should be DOMAIN.\r\nAccount Name is a different account from the Security ID.\r\nPYKEK Events\r\nEvent ID: 4624 (Account Logon)\r\nThe Account Domain field is DOMAIN FQDN when it should be DOMAIN.\r\nAccount Name is a different account from the Security ID\r\n Event ID: 4672 (Admin Logon)\r\nThe Account Domain field is DOMAIN FQDN when it should be DOMAIN.\r\nAccount Name is a different account from the Security ID\r\nhttps://adsecurity.org/?p=1515\r\nPage 11 of 12\n\nEvent ID: 4768 (Kerberos TGS Request)\r\nThe Account Domain field is DOMAIN FQDN when it should be DOMAIN.\r\nKEKEO Events\r\nEvent ID: 4624 (Account Logon)\r\nThe Account Domain field is DOMAIN FQDN when it should be DOMAIN.\r\nEvent ID: 4672 (Admin Logon)\r\nAccount Domain is blank \u0026 should be DOMAIN.\r\nEvent ID: 4768 (Kerberos TGS Request)\r\nThe Account Domain field is DOMAIN FQDN when it should be DOMAIN.\r\n(Visited 149,672 times, 9 visits today)\r\nSource: https://adsecurity.org/?p=1515\r\nhttps://adsecurity.org/?p=1515\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://adsecurity.org/?p=1515"
	],
	"report_names": [
		"?p=1515"
	],
	"threat_actors": [],
	"ts_created_at": 1775434422,
	"ts_updated_at": 1775791304,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fcbd442036a8416ccf84e756e72ac6584a332774.pdf",
		"text": "https://archive.orkl.eu/fcbd442036a8416ccf84e756e72ac6584a332774.txt",
		"img": "https://archive.orkl.eu/fcbd442036a8416ccf84e756e72ac6584a332774.jpg"
	}
}