Note: This post has created a bit of controversy among the security illuminati! A post on Still Passing the Hash Blog 15 Years Later explains the issues. I think a large part of their argument is that I’m saying vulnerabilities related to Silver Tickets are now once and for all resolved by Microsoft. Yes, I should have been a little clearer in this post but I’m referring to a very specific scenario. For those who live and breathe ticket-based attacks — my apologies. I’ve adjusted the title to reflect this. I’ve reached out to the author of the post to explain more about the specific attack I’m referring to. I’m hoping to relay back his deep knowledge as soon as possible.
The Kerberos Golden Ticket already had a mythic status in the hacking world even before this summer’s Black Hat conference rolled around. In theory, a hacker could create a universal authentication ticket and lurk forever in an organization’s IT system. The how-to-accomplish part, though, was always a little murky. At the conference a lot of buzz was generated by some very solid papers and presentations explaining the nitty-gritty details of minting Golden Tickets.
Over the summer more evidence also began to mount that Golden Tickets attacks had been seen in the wild, leading to CERT-EU’s prevention advisory.
Still Not That Easy
Even with all the new information and support from special grayware, it still ain’t that easy to obtain a Golden Ticket in a Kerberos-based Microsoft installation.
Hackers would have to move laterally or gain direct access to a Microsoft domain controller, and then find the password hash of a special account, krbtgt—the secret key that’s used by Kerberos to encrypt all ticket granting tickets or TGTs.
Once they’ve gotten that far, they could then handcraft the data fields of a raw ticket, specifying an expiration date far into the future and domain admin access.
And that’s what Golden Tickets are made of: TGTs with an elevated access and effectively unlimited lifetimes, encrypted with the hash of the krbtgt password. You can read more about them here.
The Silver Ticket
I recently learned about a slightly less ambitious, but I think a more realizable, attack against Kerberos. The hackers this time focus not on the TGT, but a secondary credential, known as a service ticket (ST).
For those who need a quick refresher course on Kerberos, I wrote about the whole shebang in these two posts, which compare this authentication system to the ticketing done once upon a time at Disney’s Magic Kingdom. Yes, I know, but there really were strong parallels.
In brief, the ST is the credential a client sends directly to an email, file, SQL, SharePoint, or any other Microsoft server in order to gain access. The ST was like the Disney ride ticket, whereas the TGT was similar to the general admission ticket.
What is a Silver Ticket? It’s just a forged ST. The reason why the attack is easier to pull off is that an ST in Kerberos is encrypted with the hash of each server’s password.
Unfortunately, these underlying server passwords are far too often weak. They’re entered manually by busy sys admins when they register the server’s name or SPN—e.g., email2015, sharepoint1234, <favorite beer>1235, etc. On the other hand, the krbtgt password, which is at the center of Kerberos authentication, is likely designed by security pros to be long, complex, and completely non-intuitive.
Microsoft Steps In
In the Silver Ticket attack, hackers passively collect STs on the network and then by using brute force techniques—very effective against obvious passwords– attempt to decrypt the data. If they’re successful, they’ll have the bit string of the server’s password hash.
Just as with the Golden Ticket, they now can mint STs to gain access to the specific server that they’ve cracked.
But not so fast!
Microsoft added a separate check on the STs to prevent this kind of attack. It’s technically another hash that’s applied to a part of the ST, known as the Privilege Attribute Certificate (PAC).
PACs were a Microsoft enhancement to Kerberos’s ST, containing identity details on the user, including group permissions. The idea was to save the servers some overhead in contacting Active Directory since the PAC would have all the necessary access rights for users.
Signed But Not Validated
So in the service ticket generated by Kerberos, Microsoft added a check on the PAC (see the graphic) itself: it hashed the PAC using the krbtgt password as a key, and then added the resulting hash value as a separate field.
This should in theory completely block the Silver Ticket attack. The hackers don’t have the hard-to-get krbtgt account in this exploit, and therefore are prevented from forging the ST. Unfortunately, for performance reasons, many administrators turn off this validation check, which would add a delay as the Kerberos server itself is contacted to calculate the krbtgt hash.
Worse yet, hackers discovered that even when this is enabled, Kerberos doesn’t properly validate the hash: you could enter a random string for the hash and still gain entry!
By the way, Tim Medin, a security researcher and pen tester, has a beautiful presentation and a fuller explanation of Silver Tickets.
You Should Update
Microsoft finally got the message that Silver Tickets are a real threat.
In November, they officially announced a vulnerability and issued a software update. The patch corrects the verification hole and is considered critical for Windows 2008R2 and below. For everything else, the patch should be done on, as Microsoft says, a “defense-in-depth” basis.
Sure the Silver Ticket can be stopped with strong passwords on all the servers—this attack assumes guessable passwords. And if you don’t want to do a patch just yet, you can still monitor for a Silver Ticket exploit by looking for a special privilege escalation—it’s event 4624. You can read more about it in this Microsoft technet bulletin.
Mission accomplished: this Silver Ticket threat is now over.
But have the hackers finished finding vulnerabilities in Kerberos? I doubt it.
Discover more hidden flaws in authentication systems. Our free ebook explains how to lower security risks.
Image credit: Geogitit