{ "id": "31838a50-a7b6-443a-9bf3-2666709f8b04", "created_at": "2026-04-06T01:32:40.153283Z", "updated_at": "2026-04-10T13:11:53.424229Z", "deleted_at": null, "sha1_hash": "9460e0d74244e4e1a7d72c82f86892eb23ca92a0", "title": "How Attackers Use Kerberos Silver Tickets to Exploit Systems", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1794040, "plain_text": "How Attackers Use Kerberos Silver Tickets to Exploit Systems\r\nBy Sean Metcalf\r\nPublished: 2015-11-17 · Archived: 2026-04-06 00:22:51 UTC\r\nUsually Golden Tickets (forged Kerberos TGTs) get all the press, but this post is about Silver Tickets and how\r\nattackers use them to exploit systems.\r\nI have talked about how Silver Tickets can be used to persist and even re-exploit an Active Directory enterprise in\r\npresentations at security conferences this year. This post continues this research.\r\nTypical Kerberos Authentication Flow:\r\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\nSilver Ticket Overview:\r\nSilver Tickets are forged Kerberos Ticket Granting Service (TGS) 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 (steps\r\n3 \u0026 4) communication with the Domain Controller. Since a Silver Ticket is a forged TGS, there is no communication\r\nwith a Domain Controller.\r\nhttps://adsecurity.org/?p=2011\r\nPage 1 of 12\n\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 a\r\nforged TGS. This means the Silver Ticket scope is limited to whatever service is targeted on a specific server.\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 computer’s\r\nlocal 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\nCreating Silver Tickets:\r\nIn order to create or forge a Silver Ticket, the attacker has to gain knowledge of the password data (password hash)\r\nfor the target service. If the target service is running under the context of a user account, like MS SQL, then the\r\nService Account’ password hash is required in order to create a Silver Ticket.\r\nhttps://adsecurity.org/?p=2011\r\nPage 2 of 12\n\nCracking Service Account passwords with Kerberoast is one potential method for identifying a target service’s\r\nassociated password data.\r\nComputers host services as well with the most common one being the Windows file share which leverages the “cifs”\r\nservice. Since the computer itself hosts this service, the password data required to create a Silver Ticket is the\r\nassociated computer account’s password hash. When a computer is joined to Active Directory, a new computer\r\naccount object is created and linked to the computer. The password and associated hash is stored on the computer\r\nthat owns the account and the NTLM password hash is stored in the Active Directory database on the Domain\r\nControllers for the domain.\r\nIf an attacker can gain admin rights to the computer (to gain debug access) or be able to run code as local System, the\r\nattacker can dump the AD computer account password hash from the system using Mimikatz (the NTLM password\r\nhash is used to encrypt RC4 Kerberos tickets):\r\nMimikatz “privilege::debug” “sekurlsa::logonpasswords” exit\r\nMimikatz Silver Ticket Command Reference\r\nThe Mimikatz command to create a golden or silver ticket is “kerberos::golden”\r\nhttps://adsecurity.org/?p=2011\r\nPage 3 of 12\n\n/domain – the fully qualified domain name. In this example: “lab.adsecurity.org”.\r\n/sid – the SID of the domain. In this example: “S-1-5-21-1473643419-774954089-2222329127”.\r\n/user – username to impersonate\r\n/groups (optional) – group RIDs the user is a member of (the first is the primary group)\r\ndefault: 513,512,520,518,519 for the well-known Administrator’s groups (listed below).\r\n/ticket (optional) – provide a path and name for saving the Golden Ticket file to for later use or use /ptt to\r\nimmediately inject the golden ticket into memory for use.\r\n/ptt – as an alternate to /ticket – use this to immediately inject the forged ticket into memory for use.\r\n/id (optional) – user RID. Mimikatz default is 500 (the default Administrator account RID).\r\n/startoffset (optional) – the start offset when the ticket is available (generally set to –10 or 0 if this option is\r\nused). Mimikatz Default value is 0.\r\n/endin (optional) – ticket lifetime. Mimikatz Default value is 10 years (~5,262,480 minutes). Active Directory\r\ndefault Kerberos policy setting is 10 hours (600 minutes).\r\n/renewmax (optional) – maximum ticket lifetime with renewal. Mimikatz Default value is 10 years\r\n(~5,262,480 minutes). Active Directory default Kerberos policy setting is 7 days (10,080 minutes).\r\nSilver Ticket Required Parameters:\r\n/target – the target server’s FQDN.\r\n/service – the kerberos service running on the target server. This is the Service Principal Name class (or type)\r\nsuch as cifs, http, mssql.\r\n/rc4 – the NTLM hash for the service (computer account or user account)\r\nSilver Ticket Default Groups:\r\nDomain Users SID: S-1-5-21\u003cDOMAINID\u003e-513\r\nDomain Admins SID: S-1-5-21\u003cDOMAINID\u003e-512\r\nSchema Admins SID: S-1-5-21\u003cDOMAINID\u003e-518\r\nEnterprise Admins SID: S-1-5-21\u003cDOMAINID\u003e-519\r\nGroup Policy Creator Owners SID: S-1-5-21\u003cDOMAINID\u003e-520\r\nExample Mimikatz Command to Create a Silver Ticket:\r\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 type\r\nalso needs to be identified in the /service parameter. Finally, the target computer’s fully-qualified domain name needs\r\nto 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-1473643419-\r\n774954089-2222329127 /target:adsmswin2k8r2.lab.adsecurity.org /rc4:d7e2b80507ea074ad59f152a1ba20458\r\n/service:cifs /ptt” exit\r\nPersistence With Computer Accounts\r\nhttps://adsecurity.org/?p=2011\r\nPage 4 of 12\n\nOnce the attacker has access to the computer account password hash, the account can be used as a “user” account to\r\nquery Active Directory, but the more interesting use case is to create Silver Tickets to access computer hosted\r\nservices with admin rights. Since the Domain computer account password change policies are more of a guideline\r\nsince they aren’t forced to change by the Domain Controllers (set to 30 days by default but up to the computer to\r\nactually change the password), it’s possible that once an attacker gains knowledge of the computer account\r\npassword, it could be used for a long time. Active Directory does not prevent a computer account from accessing AD\r\nresources even if the computer account password hasn’t changed in years.\r\nThe attacker could also prevent the computer account password from changing:\r\n1. the following registry key:\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Netlogon\\Parameters\\DisablePasswordChange\r\n= 1.\r\n2. There’s a client Group Policy setting to prevent the computer from changing the password most often used to\r\nsupport VDI (virtual desktops). Enabling the group policy setting “Domain member: Disable machine account\r\npassword changes” stops computers applying this GPO from changing their AD computer account password.\r\n“The Domain member: Disable machine account password changes policy setting determines whether a\r\ndomain member periodically changes its computer account password. Setting its value to Enabled prevents\r\nthe domain member from changing the computer account password. Setting it to Disabled allows the domain\r\nmember to change the computer account password as specified by the value of the Domain member:\r\nMaximum machine account password age policy setting, which is every 30 days by default.”\r\n3. The domain Group Policy “Domain member: Maximum machine account password age” which tells the\r\ndomain joined computers how often they should change their computer account password (though this is\r\nmore of a guideline, than a rule). By default, this value is set to “30”, but if it is set to “0”, computers are\r\nunable to change their passwords.\r\n4.  There’s a Domain Controller Group Policy setting “Domain controller: Refuse machine account password\r\nchanges” that sets the Domain Controller to prevent clients from updating their computer account password in\r\nAD.\r\n“This security setting determines whether domain controllers will refuse requests from member computers to\r\nchange computer account passwords. By default, member computers change their computer account\r\npasswords every 30 days. If enabled, the domain controller will refuse computer account password change\r\nrequests.\r\nIf it is enabled, this setting does not allow a domain controller to accept any changes to a computer account’s\r\npassword.”\r\nThis is a valid (and current) method for an attacker to persist access even after all the user, admin, and service\r\naccount passwords are changed.\r\nIn normal Kerberos operations, the authentication ticket (TGT) is used to request service tickets (TGS) for each\r\nKerberos enabled service. Silver Tickets bypass this normal process by injecting the forged Kerberos TGS tickets\r\ndirectly. Multiple Silver Tickets may be required to access the target service(s).\r\nThe most useful computer-hosted services and the associated silver ticket services required is in the table below.\r\nDetecting Silver Tickets:\r\nhttps://adsecurity.org/?p=2011\r\nPage 5 of 12\n\nThe best chance of detecting Silver Tickets is to monitor Windows security events on workstations, servers, and\r\nDomain Controllers for logon/logoff events with anomalies in the domain field including the field being blank or\r\nnull.\r\nService to Silver Ticket Reference:\r\nService Type Service Silver Tickets\r\nWMI\r\nHOST\r\nRPCSS\r\nPowerShell Remoting\r\nHOST\r\nHTTP\r\nDepending on OS version may also need:\r\nWSMAN\r\nRPCSS\r\nWinRM\r\nHOST\r\nHTTP\r\nScheduled Tasks HOST\r\nWindows File Share (CIFS) CIFS\r\nLDAP operations including Mimikatz DCSync LDAP\r\nWindows Remote Server Administration Tools\r\nRPCSS\r\nLDAP\r\nCIFS\r\nSilver Ticket Exploit Examples:\r\nIn these examples, the attacker has gained knowledge of the computer account’s password hash and uses it to create a\r\nSilver Ticket to gain admin rights to different services hosted by the computer. If the attacker has dumped the Active\r\nDirectory database or gained knowledge of a Domain Controller’s computer account password, the attacker can use\r\nSilver Tickets to target the DC’s services as an admin and persist in Active Directory.\r\nSilver Ticket for Windows Share (CIFS) Admin Access\r\nCreate a Silver Ticket for the “cifs” service to gain admin rights to any Windows share on the target computer.\r\nhttps://adsecurity.org/?p=2011\r\nPage 6 of 12\n\nAfter injecting the CIFS Silver Ticket, we can now access any share on the target computer including the c$ share\r\nenabling us to copy files to or from the share. If we use a fake name in the Silver Ticket, we can make it look like\r\nsomeone else accessed the data.\r\nSilver Ticket for the Windows computer (HOST) with Admin Access\r\nCreate a Silver Ticket to gain admin rights to any Windows service covered by “host” on the target computer. This\r\nincludes the ability to modify and create scheduled tasks.\r\nLeveraging the HOST Silver Ticket, we can create a new scheduled task.\r\nhttps://adsecurity.org/?p=2011\r\nPage 7 of 12\n\nOr by leveraging the HOST Silver Ticket, we can modify an exist scheduled task.\r\nCheck to see if the scheduled task was set. Yes, it’s there!\r\nSilver Ticket to Connect to PowerShell Remoting on Windows Computer with Admin Access\r\nCreate a Silver Ticket for the “http” service and “wsman” service to gain admin rights to WinRM and/or PowerShell\r\nRemoting on the target system.\r\nAfter injecting the two Silver Tickets, http \u0026 wsman, we can use PowerShell Remoting (or WinRM) to open a a shell\r\nto the target system (assuming it’s configured with PowerShell Remoting and/or WinRM). New-PSSession is the\r\nPowerShell cmdlet for creating a session to a remote system using PowerShell and Enter-PSSession opens the\r\nremote shell.\r\nhttps://adsecurity.org/?p=2011\r\nPage 8 of 12\n\nSilver Ticket to Connect to LDAP on Windows Computer with Admin Access\r\nCreate a Silver Ticket for the “ldap” service to gain admin rights to LDAP services on the target system (including\r\nActive Directory).\r\nhttps://adsecurity.org/?p=2011\r\nPage 9 of 12\n\nLeveraging the LDAP Silver Ticket, we can use Mimikatz and run DCSync to “replicate” credentials from the DC.\r\nSilver Ticket to Run Commands Remotely on a Windows Computer with WMI as an admin\r\nCreate a Silver Ticket for the “host” service and “rpcss” service to remotely execute commands on the target system\r\nusing WMI.\r\nhttps://adsecurity.org/?p=2011\r\nPage 10 of 12\n\nAfter injecting these Silver Tickets, we can confirm that the Kerberos TGS tickets are in memory by running “klist”\r\nhttps://adsecurity.org/?p=2011\r\nPage 11 of 12\n\nAfter injecting the Silver Tickets, we can call WMIC or Invoke-WmiMethod by “passing the ticket” to run a\r\ncommand on the target system.\r\nInvoke-WmiMethod win32_process -ComputerName $Computer -Credential $Creds -name create -argumentlist\r\n“$RunCommand”\r\nReferences:\r\nAbusing Microsoft Kerberos Sorry You Guys Don’t Get It  (aka the Mimikatz Golden Ticket Presentation) –\r\nSkip Duckwall \u0026 Benjamin Delpy\r\nPAC Validation issue aka the Silver Ticket description from the Passing the Hash Blog\r\nKerberoast: Tim Medin’s Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades” presentation at\r\nDerbyCon 2014. [Slides: https://www.dropbox.com/s/1j6v6zbtsdg1kam/Kerberoast.pdf?dl=0 ]\r\nMimikatz and Active Directory Kerberos Attacks\r\nDetecting Forged Kerberos Ticket (Golden Ticket \u0026 Silver Ticket) Use in Active Directory\r\nService Principal Name Reference (SPN) Guide\r\n(Visited 104,533 times, 19 visits today)\r\nSource: https://adsecurity.org/?p=2011\r\nhttps://adsecurity.org/?p=2011\r\nPage 12 of 12", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://adsecurity.org/?p=2011" ], "report_names": [ "?p=2011" ], "threat_actors": [ { "id": "8670f370-1865-4264-9a1b-0dfe7617c329", "created_at": "2022-10-25T16:07:23.69953Z", "updated_at": "2026-04-10T02:00:04.716126Z", "deleted_at": null, "main_name": "Hades", "aliases": [ "Operation TrickyMouse" ], "source_name": "ETDA:Hades", "tools": [ "Brave Prince", "Gold Dragon", "GoldDragon", "Lovexxx", "Olympic Destroyer", "Running RAT", "RunningRAT", "SOURGRAPE", "running_rat" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775439160, "ts_updated_at": 1775826713, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/9460e0d74244e4e1a7d72c82f86892eb23ca92a0.pdf", "text": "https://archive.orkl.eu/9460e0d74244e4e1a7d72c82f86892eb23ca92a0.txt", "img": "https://archive.orkl.eu/9460e0d74244e4e1a7d72c82f86892eb23ca92a0.jpg" } }