Home > Projects > Mimikatz 2.0 - Silver Ticket Walkthrough

Mimikatz 2.0 - Silver Ticket Walkthrough

Ben Lincoln

Table of contents

1. Silver Tickets: Why You Should Care
2. Silver Ticket Basics
3. Silver Tickets and Service Accounts
4. Finding Service Accounts
5. Edge Case: Changing Domain Group Membership via IIS Running on a Domain Controller
6. Accounts Which Have been Trusted For Delegation
7. Built-in Windows® Kerberos Service Names
8. Silver Ticket Technical Details
9. Sources
10. Downloads

Silver Tickets: Why You Should Care

Understanding the implications of the Silver Ticket functionality is not as straightforward as for Golden Tickets. The details are below, but this is the key difference: Golden Tickets allow an attacker who has already compromised a domain to have so much power that they will probably never be removed from that domain. Silver Tickets potentially allow an attacker to quickly escalate from "non-privileged domain user" to "I have the Golden Ticket now!", as long as they can obtain access to a non-privileged domain account and local admin access to a single Windows® workstation or server.

Silver Ticket Basics

As in the writeup on Golden Tickets (see Mimikatz 2.0 - Golden Ticket Walkthrough), I'm going to gloss over a lot of the detail here. To make a long story short, Silver Tickets act similarly to Golden Tickets, but can potentially be obtained more easily because generating them requires knowledge of the encryption key(s)/NTLM hash for a computer or service account, not the krbtgt account. The trade-off is that their scope of use is much more narrow — they can generally only be used to effect changes on a particular target system, not across an entire Windows® domain. However, there are some very important exceptions to that statement which will be discussed below.

Silver Tickets take advantage of a less-secure default configuration in newer versions of Windows® network services will only validate the part of a Kerberos ticket which is signed using the encryption key for the account under which that service is running. The part which is signed using the krbtgt account (the "PAC") is ignored, because validating it would require that the service communicate with a domain controller (a performance penalty).

The same information that was necessary to obtain a Golden Ticket is necessary for a Silver Ticket, except that instead of the encryption keys/NTLM hash for the krbtgt account, you need one of the keys for the account under which the target service is running. E.g. if it is running as LocalSystem, you need the keys/hash for the computer account's password. If it is running as a service account, you need the keys/hash for that account's password, et cetera.

In addition, you will also need the DNS name under which the SPN for the service is registered, and the service type. E.g. if you are accessing a Kerberos-authenticated web application at http://sharepoint.vln2012.local/, the former would be sharepoint.vln2012.local, and the latter would be http. If you will be accessing \\sharepoint.vln2012.local\shared_content as a fileshare, the target name would be the same, but the service would be cifs. See the Built-in Windows® Kerberos Service Names section below for a complete list. If you are accessing the remote system by its actual Windows® machine name, then its fully-qualified domain name is what you will use for the DNS name (the target parameter, below).

The focus of the presentation I attended in the Autumn of 2014 was on using computer accounts to generate Silver Tickets. This is certainly a very useful approach, but it requires obtaining the encryption keys for those accounts, which generally requires local admin access to the target system at some point in the recent past. I believe that Silver Tickets based on service accounts with explicitly-registered SPNs are a much more easily-misused option for pen-testers. For more details, see Silver Tickets and Service Accounts, below.

Silver Tickets can be used in much the same way Golden Tickets can — to cause woe to forensic investigators looking at event/IIS log entries by spoofing usernames and RIDs/SIDs, injecting additional groups (or users-as-groups) into the ticket that are not actually present in the group membership for the account they're spoofing, et cetera.

The following series of commands will purge the current Kerberos tickets, inject a new one for that example web application, and then open a command prompt in the context of that spoofed ticket:

 

privilege::debug

kerberos::purge

kerberos::golden /domain:vln2012.local /sid:S-1-5-21-3871786346-2057636518-1625323419 /rc4:1f283650874056bee92c7d9d5e6d860c /user:"Administrator" /id:500 /groups:500,501,513,512,520,518,519 /target:sharepoint.vln2012.local /service:http /ptt

misc::cmd

 

As long as the domain Administrator account has full access to that SharePoint system, it should now be possible to launch Internet Explorer from that command prompt (see the Golden Ticket writeup if this is unclear), and do whatever you like.

Important! — just as with Golden Tickets, depending on the client and server configurations as well as Windows® own whims, you may need to try either the unqualified or fully-qualified name of the target system in order to get a successful authentication. For example, if accessing http://sharepoint.vln2012.local/ gives you an authentication popup, try http://sharepoint/ instead (or vice-versa). The same goes for UNC paths (\\server2012dc\c$ versus \\server2012dc.vln2012.local\c$).

Silver Tickets and Service Accounts

Windows computer account passwords are randomly-generated, extremely long, and automatically rotate. Attempting to guess one would be foolish. However, if a network service is listening as a domain service account, the encryption key/hash used will be the one for that domain account. This is this interesting because service accounts often have much weaker passwords than computer accounts, and they are often changed infrequently. If even one of these accounts can be discovered, it can become a gateway to operating as any account on the domain — at least as far as the network services in question are concerned.

Finding Service Accounts

Under normal conditions, finding every domain network service account on a Windows® domain is a bit of a headache. Fortunately, I've saved you the trouble by writing a VBScript (also available at the bottom of this page in the Silver Ticket Tools package). I used VBScript so that even if run on a stock Server 2003 system, it would still operate (PowerShell would not). This script will output a tab-delimited text report of all accounts on the target domain which are likely to be misusable for Silver Ticket purposes, and whether they're unconstrained or their constraints if there are any.

Accounts are listed if they are trusted for delegation (constrained or unconstrained), or if they have SPNs registered. This will, of course, include all of the computer accounts in the domain. If you'd like to filter those out, use something like grep -F -v "$".

It operates against the default Active Directory domain where it is run. If you'd like it to operate against a different domain, you'll need to edit it a little bit. The syntax for running it against the default domain is easy:

 

cscript -nologo FindTrustedAndSPNAccounts.vbs > accounts.txt

 

The output includes the various names by which the account is known, as well as its trust level (Constrained or Unconstrained), a list of services it is trusted to impersonate users against (which only applies if it its trust level is Constrained), any SPNs associated with the account, and a list of systems that the account is allowed to log on to (if it is limited in such a way)^[2]. Reading the flag that indicates unconstrained delegation requires a logical AND against a field in each account, so all user and computer accounts in the domain must be enumerated and processed before filtering. This means that on a sizeable real-world domain, the script can take awhile to run.

You may be surprised at what you find in the output of this script when run against your own domain at work.

If an account is used for an application pool in IIS, its password can be easily obtained by making a few simple changes to the adsutil.vbs script that is included with IIS:

1. If you are running a version of Windows® newer than 2003, you will need to explicitly install the IIS6 compatibility features if you don't already have an unmodified copy of adsutil.vbs (see screenshot below).
2. If all of your settings are the default for Windows®, you should now have a copy of adsutil.vbs in C:\inetpub\AdminScripts.
3. Make a copy of adsutil.vbs and open it in your favourite text editor.
4. Search for the text IsSecureProperty. You should find three If statements that need to be commented out, except for the block that would normally occupy the Else clause (see screenshots below).
5. Search for the text IsSecureProperty one more time. This should take you to the function that actually determines if a property is "secure" or not. Modify it as shown in the screenshots below to make it always return false.
6. Save the file and exit.

(note: the steps above are somewhat redundant, but should ensure that you will end up with a re-fanged version of the script no matter which version of IIS you are working with).

The modified script (which I named adsutilNMS.vbs) can now be used the same as the normal version, except it will show "secure" values in plaintext instead of redacting them. For example, to enumerate all application pools and then view the password for the service account used for the pool named UDWebApp1:

 

cscript -nologo adsutilNMS.vbs ENUM W3SVC/AppPools

cscript -nologo adsutilNMS.vbs ENUM W3SVC/AppPools/UDWebApp1

 

Edge Case: Changing Domain Group Membership via IIS Running on a Domain Controller

Sadly, despite some promising early results in one lab, I was unable to develop a repeatable process to misuse accounts which were trusted for delegation to "upgrade" Silver Tickets to something more like a Golden Ticket. However, one of the proofs-of-concept does work reliably in an edge case scenario. It requires that all of the following are true:

1. A domain controller has IIS installed.
2. IIS has ASP.NET enabled (the example code could be rebuilt in "classic" ASP, of course, but I have not done this).
3. IIS is configured to use Kerberos authentication.
4. At least part of the IIS-served web content is running in the context of an account whose NTLM hash is known to the attacker.
5. The attacker has the ability to add a new .aspx page to the site/application. In most cases, this would imply that the attacker has some level of privileged access to the domain controller already, but assuming the add new page ability is the limit of that access...

Any code written in ASP.NET and accessed via the crafted page can be made to execute in the context of an account spoofed via a Silver Ticket. Note that trying to spawn an instance of cmd.exe or another executable will not inherit the spoofed account's identity using this method — all actions must be accomplished using .NET code (or the aforementioned "classic" ASP). It seems likely that someone with more low-level Windows® coding skill could overcome this limitation.

I made a barebones "add an arbitrary user to an arbitrary group" ASP.NET web page based on shell.aspx from the Laudanum Project. It's available at the bottom of this page in the Silver Ticket Tools package. adduser.aspx displays the ID that the web application considers to have authenticated to it (this can be used to verify that your Silver Ticket is working correctly). It accepts two parameters: the DN of a target group, and the DN of a user to add to that group. It is dropped onto an existing web server in the same way that e.g. shell.aspx would be.

As long as the account you are spoofing (or one of the groups you've included in the ticket) has permission to perform this action, you should be able to make any account a member of Domain Admins, Enterprise Admins, et cetera.

Here are the commands I used to create a ticket:

 

privilege::debug

kerberos::purge

kerberos::golden /domain:vln2012.local /sid:S-1-5-21-3871786346-2057636518-1625323419 /rc4:c105dce9c778f1907275710e5841a21d /user:"Administrator" /id:500 /groups:500,501,513,512,520,518,519 /target:dchostedwebapp.vln2012.local /service:http /ptt

kerberos::golden /domain:vln2012.local /sid:S-1-5-21-3871786346-2057636518-1625323419 /rc4:c105dce9c778f1907275710e5841a21d /user:"Administrator" /id:500 /groups:500,501,513,512,520,518,519 /target:dchostedwebapp /service:http /ptt

misc::cmd

 

In the spawned command prompt, I then executed the following commands (to make sure there were no existing IE windows around to interfere with the ticket manipulation):

 

pskill iexplore

"C:\Program Files\Internet Explorer\iexplore.exe"

 

I then accessed the URL where I'd dropped the file (http://dchostedwebapp/adduser.aspx), and verified that the page indicated I was authenticated as the Administrator account.

Finally, I pasted in the DNs of the user1 account and the Domain Admins group (you can look these up using dsquery, ADSIEdit or other tools^[1]), then clicked the Submit button.

Note: the web.config file included with adduser.aspx is specific to .NET 4.0. You'll need to update the System.DirectoryServices assembly reference if a different version of .NET is used for the website being misused.

Accounts Which Have been Trusted For Delegation

This is a bit off-topic from Mimikatz (at least for the moment...), but if an account is trusted for delegation, then with a few quick tweaks to adduser.aspx to make it operate automatically, an IIS application running as that account — and for which an SPN has been registered — can be used to build a minefield of e.g. hidden iframes waiting for someone logged on as a domain admin to run across them. For example, the Page Viewer web part in SharePoint. This would be fairly noisy in terms of failed attempts, so if this technique is used inside an attentive organization, it would be a good idea to also add pre-checks to ensure that the account being used is a member of e.g. Domain Admins, Account Operators, or another group with the necessary privileges. This is currently left as an exercise for the reader.

Built-in Windows® Kerberos Service Names

The following list is of all of the built-in service names available in Windows®. This is also the list which is implicitly present if a single SPN (host) exists for a given account.

• alerter
• appmgmt
• browser
• cifs
• cisvc
• clipsrv
• dcom
• dhcp
• dmserver
• dns
• dnscache
• eventlog
• eventsystem
• fax
• http
• ias
• iisad
• mcsvc
• messenger
• min
• msiserver
• netdde
• netddedsm
• netlogon
• netman
• nmagent
• oakley
• plugplay
• policyagent
• protectedstorage
• rasman
• remoteaccess
• replicator
• rpc
• rpclocator
• rpcss
• rsvp
• samss
• scardsvr
• scesrv
• schedule
• scm
• seclogon
• snmp
• spooler
• tapisrv
• time
• trksvr
• trkwks
• ups
• w3svc
• wins
• www

Other Kerberos-enabled software (including Microsoft® software beyond Windows® itself) may make use of additional service names. For example:

• MSClusterVirtualServer [ Windows Clustering ]
• MSServerCluster [ Windows Clustering ]
• MSServerClusterMgmtAPI [ Windows Clustering ]
• MSSQLSvc [ SQL Server ]

Silver Ticket Technical Details

For those with a technical interest who want a place to get started from for further research, as far as I can tell from the available documentation and from examination of packet captures, the use of Silver Tickets involves Mimikatz forging a TGS directly, without ever obtaining a valid TGT from a KDC. The forged TGS is then used to authenticate directly to the target service — no communication with an actual KDC is involved. This is possible because by default, Windows® Vista® and later do not validate the PAC (the part of the TGS which is signed by the KDC using the krbtgt encryption key), and only validate that the TGS has been signed using the key for the target service. This seems like a much easier hole for Microsoft® to patch out than the Golden Ticket functionality, so enjoy it while it lasts, I guess. If I've gotten any of that wrong, please let me know.

Sources

The information in this writeup is based on six primary sources:

1. Reality Bites: The Attacker's View of Windows Authentication and Post-exploitation [ SlideShare link ]. Chris Campbell, Benjamin Delpy, and Skip Duckwall, 2014. This was a presentation given by them at Microsoft's internal Blue Hat 2014 conference.
2. A similar follow-up presentation by Benjamin Delpy and Skip Duckwall that I saw in person at a secret conference shortly thereafter. If you were there, you have a set of Scrabble® blocks that spell out its name.
3. Mimikatz, a short journey inside the memory of the Windows Security service, Benjamin Delpy, 2014. This was a presentation given by Benjamin at RMLL Montpellier 2014.
4. Abusing Microsoft Kerberos: sorry you guys don't get it, Skip Duckwall and Benjamin Delpy, 2014. This was their BlackHat USA 2014 presentation. Beware — while the information in it is extremely valuable and interesting, some of the example syntax used is no longer correct.
5. How the Kerberos Version 5 Authentication Protocol Works, Microsoft Technet.
6. My own research using a couple of Windows 2012 R2/Windows 8.1 lab environments.

Download
File	Size	Version	Release Date	Author
Silver Ticket Tools	16 KiB	1.0	2014-11-09	Ben Lincoln and the Laudanum Project

Related Articles:
Mimikatz 2.0 - Golden Ticket Walkthrough
Mimikatz 2.0 - Brute-Forcing Service Account Passwords

Last updated: 18 December 2014

You have Javascript disabled in your browser. This website will look a bit nicer if you turn it back on.

Copyright 2009-2014 Ben Lincoln, except where explicitly noted.

Copyright Information - Privacy Policy - Download Policy - Advertising Policy