Service Account Attack #3: Silver Tickets
So far in this blog series, our first post showed us how to discover Active Directory service accounts and our second post explored how to crack their passwords using Kerberoasting. Now that we have compromised at least one service account and extracted its password, this post will explore how to further exploit that account using Silver Tickets.
Silver Tickets Overview
Silver Tickets enable an attacker to create forged service tickets (TGS tickets). These tickets can provide access to the service that was compromised with a Kerberoasting attack. For example, in our Kerberoasting attack, we compromised a service account with a registered Service Principal Name (SPN) of “MSSQLSvc/jefflab-sql02.jefflab.local:1433”. Now, we can use Silver Tickets to forge TGS tickets for the Microsoft SQL service on that host. This tactic by itself may not sound very valuable since we already have compromised the account associated with that SPN and wouldn’t need to forge tickets to act on its behalf. However, Silver Tickets do offer several benefits including:
- The attacker does not need to authenticate the account to the domain controller to obtain the forged TGS. This can be done without creating network traffic and event logs to avoid detection.
- The forged TGS ticket can be created on behalf of any user account, even fictitious accounts. This allows the access of the service account to be exploited without risking detection that the account has been compromised, which may result in a password reset.
- The Privileged Attribute Certificate (PAC) within the TGS ticket can also be manipulated, elevating the account’s access to that of a Domain Administrator. In most cases, the PAC is not validated against the domain controller when the TGS is provided.
In my case, I have compromised a SQL Service account, but that account does not have any access granted to the databases hosted on SQL and cannot log in interactively to the computer. In the end, there isn’t a whole lot I can easily do with this account. Silver Tickets allow me to take this account and elevate its privileges so I can use it to gain full control over all of the database hosted on the compromised SQL Server. Even better, I can do this while making it very difficult to detect.
Now that we understand what a Silver Ticket is and why an attacker may choose to use one, let’s look at how this attack is performed.
Silver Tickets: How They Work
Step 1 – Obtain Password Information for Service Account or Computer Account
In order to forge TGS tickets, we must have the NTLM password hash for either a service account running a service on a computer or the computer account itself. In the previous post, we focused on compromising a service account running the SQL service on a particular host. The benefit of using a service account is that these accounts can be compromised without any elevated domain privileges. In order to compromise a computer account’s NTLM hash, you must obtain Administrator rights to that computer. If you are able to obtain the computer NTLM hash, you can forge tickets for any service that runs as the local system account. This could include services such as Common Internet File System (CIFS), which would provide access to all files stored on the computer. Microsoft describes other services that run on Windows operating systems here.
For this post, we will continue to focus on the Microsoft SQL Server service account we have compromised.
Step 2 – Create Forged Service Tickets Using Mimikatz
Now that you have the NTLM hash of one or more service accounts, we can create Silver Tickets using Mimikatz. Some of the information we need to create this ticket includes:
- Domain SID – This can be obtained easily by issuing the command “Whoami /User” into a command prompt and copying the SID value without the Relative ID (RID) at the end.
- Target – This is the host, which can be copied from the SPN value. In my case, this is jefflab-sql02.jefflab.local:1433.
- Service – This will be the name of the service that we will create tickets for. This must be a service running as the service account we compromised. We will focus on the MSSQLSvc.
- User – This specifies the user that the ticket will be created for, and this can be any user account whatsoever, even user accounts that do not exist.
- Groups – This is the list of groups that will be added to the PAC for the account. By default, this will include Domain Admins but you can override it with custom groups if needed.
Here is the complete command issued to create a Silver Ticket for the MSSQLSvc with Domain Admin rights as a user with the name FakeUser.
Step 3 – Pass-the-Ticket
In the above command, I specified the /ptt flag that automatically injects the fake ticket into memory. By issuing a klist command you can see I now have a forged Kerberos ticket for my FakeUser account.
Now that I have that in memory, I just need a way to issue SQL commands against that target host, which will support passing through my ticket. To do that, I will use the Sqlcmd.exe utility provided by Microsoft.
You can see in the above command I am able to make a SQL connection to the target host, and it sees me as JEFFLABFakeUser. I now am connected to a SQL database with full admin rights as an account that doesn’t even exist. This makes it much harder to investigate any actions I perform and to understand how this access was compromised in the first place.
You can see by looking at the SQL server’s security logs that it will track logon events as FakeUser as well:
Protecting Yourself from Silver Tickets
Detecting Silver Tickets can be very difficult since this bypasses the entire TGT portion of authentication and cannot be monitored by looking at Domain Controller logs. The best way to prevent these attacks is to enforce proper security over service accounts to avoid having these accounts compromised to begin with. Monitoring for logon anomalies using local logon events, such as the one shown above, can also be effective in protecting your organization.
Here are the other blogs in the series:
Service Account Attack #1 – Discovering Service Accounts without using Privileges Read Now
Service Account Attack #2 – Extracting Service Account Passwords with Kerberoasting Read Now
Service Account Attack #4 – Exploiting the KRBTGT service account for Golden Tickets Read Now
Don’t miss a post! Subscribe to The Insider Threat Security Blog here:
Jeff Warren is Stealthbits’ General Manager of Products. Jeff has held multiple roles within the Technical Product Management group since joining the organization in 2010, initially building Stealthbits’ SharePoint management offerings before shifting focus to the organization’s Data Access Governance solution portfolio as a whole. Before joining Stealthbits – now part of Netwrix, Jeff was a Software Engineer at Wall Street Network, a solutions provider specializing in GIS software and custom SharePoint development.
With deep knowledge and experience in technology, product and project management, Jeff and his teams are responsible for designing and delivering Stealthbits’ high quality, innovative solutions.
Jeff holds a Bachelor of Science degree in Information Systems from the University of Delaware.
Related Posts
- Understanding Lateral Movement and Privilege Escalation
- SERVER (UN)TRUST ACCOUNT
- Making Internal Reconnaissance Harder Using NetCease and SAMRi10
- Setup, Configuration, and Task Execution with Covenant: The Complete Guide
- Protecting Against DCShadow
- What is a DCShadow Attack and How to Defend Against it
- Next-Gen Open Source C2 Frameworks in a Post PSEmpire World: Covenant
- Detecting Persistence through Active Directory Extended Rights
- Lateral Movement Through Pass-the-Cache
- Resource-Based Constrained Delegation Abuse
hi great article. one question/observation from my own experiments. it appears that when you use a “fake” account the SQL server has to be configured in a particular way i.e. authenticate against a catch all AD group like Authenticated Users. Can you confirm?
If this is not the case (like a lot of large organisations and only AD usernames are present) you have to specify a known MSSQL username.
Once again great article and thanks for sharing
Hi Mark – Glad you liked the article!
In this approach, we are forging a TGS service ticket with a fake user name, RID, and group membership which is stored in the PAC. The name is not used for authentication, so I fake the RID to be an administrator (1103 is a domain admin in my case but 500 works), and by default, Mimikatz puts privileged groups into my PAC (513,512,520,518,519). Then when using this TGS ticket against SQL it uses the RID and group membership to evaluate and grant access. This should let you in pretty quickly, and if you need to try different access groups you can specify them with the /groups option in the Kerberos::golden command. Hope that answers your question!
Hi Jeff, thank you for the reply. Yes this matches exactly what i’m seeing. Great set of articles around attacking kerberos, something I have now added to my Red Team skills 🙂
Hi Jeff.
Thanks for your articles; they are awesome!
May I ask for your sources of this knowledge? I’ve been looking for such sources for some time, but can’t seem to find them, before I came across your article.
I’m looking forward hearing from you 🙂
-Nicolas
Hello Nicolas, I’m glad you’re enjoying the articles! The Silver Ticket information I used for this post came from a few sources. Sean Metcalf has a great comprehensive article on the Silver Ticket here and the SANS Institute has a very useful article as well here. Doing the Pass-the-Ticket and gaining access using Sqlcmd.exe came through trial and error so if you’re looking for a good way to evaluate the Silver Ticket attack and how to detect it I found that to be very effective.
Hi Jeff, great article. Would you mind explaining how you would perform the same attack against HTTP. Namely what client would use you in the final step to pass the forged ticket? Could you just fire chrome or firefox from the command line and would it automatically pass the forged ticket? Or is there some way to explicitly use the forged ticket?
Hi Jonathan,
In short the answer is yes. Open a browser from the command line after you have injected the silver ticket into your session and then go to the page that does Integrated Windows Authentication that is setup for Kerberos and it should authenticate you.
In my setup I used the service account hash that was running as the application pool which also had the SPN Configured for the web service.
Here is just a small snippet of the IIS log showing that its the fake user entering the website.
2019-11-15 17:38:34 192.168.0.6 GET /v2/login – 81 PROD\FakeUser 192.168.0.4
As for the other question you posted below, I don’t think it’s possible to validate the NTLM hash without doing some level of authentication unless you have already reached DA levels of access. I believe both errors (Wrong group / wrong hash) would just be access denied.
Hope this helps!
Joe
Also is there some way to verify the NTLM hash you have is valid (incase the PTT attack fails, id like to know if its because my group is not accepted, or the hash is invalid)