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 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:
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.
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.
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:
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.
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:
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
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.
Learn why Active Directory security should be a priority for your organization and ways to mitigate against a data breach with this free white paper!
Read more© 2022 Stealthbits Technologies, Inc.
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)