The Hidden dangers of Service Principal Names (SPN)

You have probably heard of Silver Ticket attacks and you are probably thinking that this problem was patched ages ago. Well, think again.

In this post, I will demonstrate the dangers of SPN and how they can be misused in what is called a Silver Ticket attack. In the first part of my blogpost, I will show how you can use this to attack an infrastructure and in the other part, I will provide tips on how to mitigate risks.

A Silver Ticket attack requires that the attacker have access to the domain with an account. The account can be an ordinary domain account. In this blogpost, I will be logged onto my lab computer that is joined to my lab domain with an ordinary user. All the tools will be installed directly on to the machine.

In my lab, I am running a Windows 7 X64 as a workstation and the domain controller is a 2012 R2 Server.

Download and install the following on the Windows 7 machine:

• Python from here: https://www.python.org/downloads/ (I use the 2.7.10 x64 version)
  • This is a next, next, finish installation
• PyCrypto from here: http://www.voidspace.org.uk/python/modules.shtml#pycrypto (pycrypto-2.6.win-amd64-py2.7 «the one without asc signature»)
  • This is a next, next, finish installation
• Add Path to python into path:
  
• PyASN1 from here: https://pypi.python.org/pypi/pyasn1 (pyasn1-0.1.8-py2.7.egg (https://pypi.python.org/packages/2.7/p/pyasn1/pyasn1-0.1.8-py2.7.egg#md5=59f23a2692b9b4bc7901d166eba69167 ))
  • To install pyasn1 start CMD and browse to c:\python27\scripts\ . Run the command «easy_install path2_pyasn.eggFile»
    
• Scapy module: https://github.com/Kondziowy/scapy_win64/tree/master/win64 (download and install all three: dnet-1.12.win-amd64-py2.7.exe, pcap-1.1.win-amd64-py2.7.exe, scapy-2.2.0.win-amd64.exe))
  • All three is next, next, finish installations
• Install Wireshark and Winpcap (https://www.wireshark.org/download.html)
• Download Kerberoast from Github: https://github.com/nidem/kerberoast (Download ZIP)
  • Extract into a folder somewhere.

Now you are all set to start the attack. First, we need to identify if there is something interesting to attack in the domain. This is done by searching for Service Principal Names (SPN). A good explanation on SPNs can be found here: https://technet.microsoft.com/en-us/library/cc961723.aspx. We are not looking for all SPNs, just the ones that links to a service or a user account. Why is that? Because, we are going to brute-force the password to these accounts and as we all know, computer accounts has very long passwords and are «impossible» to crack (at least with my laptop). It is more likely that either a service or a user account has a weak password. I use a variation of commands to find the ones I want to crack. I often list all SPNs to a text file and copy out the ones that are user accounts. Computer accounts are not interesting. To list all SPNs in the domain to a file: setspn -Q */* > allspns.txt

You could also use this script that has good filtering: https://raw.githubusercontent.com/nidem/kerberoast/master/GetUserSPNs.ps1

Either way you should pick out the ones, you want to try to crack. In my lab I have found the following SPN that is interesting:

As you can see from the screenshot the Dailyadmin is probably a user account and has the MSSQLSvc SPN associated to it. Now we need to start Wireshark to capture the traffic. After Wireshark capture has started, you will need to run the following two commands in Powershell:

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList “MSSQLSvc/dc01:1433”

This will contact the domain controller and request a kerberos ticket. The current kerberos tickets on the system can be listed with the klist command. Run it to verify that the ticket is in the system.

You can now stop the Wireshark capture and save it as PCAP. I have to point out that Wireshark defaults to PCAPNG so make sure you choose Wireshark/TCPDUMP/PCAP from the SAVE AS dialog or else the next step will fail:

I saved my PCAP file in the same folder as the Kerberoast script for convenience.

Our next step is to use one of the scripts from Kerberoast to extract information from the PCAP file that we can use to brute-force the password. To do this start a CMD and run the following command: «python c:\kerberoast-master\extracttgsrepfrompcap.py -f c:\kerberoast-master\MSSQLSVC.pcap -w c:\kerberoast-master\MSSQLSVC_Ticket.kirbi»

This command will output a file we can try to brute-force using the other script in the Kerberoast package. Our next step is to run the following command to start brute-forcing the ticket file: «python c:\kerberoast-master\tgsrepcrack.py -t 10 c:\kerberoast-master\wordlist.txt c:\kerberoast-master\MSSQLSVC_Ticket.kirbi»
(Note that you will have to either generate your own wordlist or find one on the internet.) Let the script run, if you are lucky you will find the password:

Help about the command can be found by just running the script without arguments. After you have found the password, you can move forward towards world domination (Loud evil laugh….).

This is a demonstration of Silver Ticket attack. There are several of great writeups and sources about this. Here are some links I find interesting about it:

• https://adsecurity.org/?p=556
• http://passing-the-hash.blogspot.no/
• http://www.beneaththewaves.net/Projects/Mimikatz_20_-_Brute-Forcing_Service_Account_Passwords.html
• Video of the Kerberoast author Tim Medin (great talk): http://www.irongeek.com/i.php?page=videos/derbycon4/t120-attacking-microsoft-kerberos-kicking-the-guard-dog-of-hades-tim-medin
• http://blog.gentilkiwi.com/downloads/Abusing-Microsoft-Kerberos-Sorry-You-Guys-Don-t-Get-It.pdf

I would like to add that it is possible to extract the Kerberos ticket files using Mimikatz from memory, instead of the python script to dump it from the PCAP.

Tip on how to mitigate

I would recommend removing unused SPNs. To remove an unused SPN you can run the following command:
«setspn –D MSSQLSvc/dc01:1433 Dailyadmin»

In my example the SPN is not in use. In real life the SPN has to be changed to reflect the correct configuration. Either to a machine account, a managed service account or an self made service account with an insane password.

Note that SPN is in use by design by Active Directory. You simply cannot delete every SPN to feel safe.

I hope this blogpost gave some information on how attackers can misuse Service Principal Names and that you as an IT-Pro can implement mitigations to prevent them from succeeding.