No, Microsoft Hasn't "Fixed" Silver Tickets

Contrary to what many folks might think, I don't wait around on the Internet for somebody to be wrong to blog about it.  However, when somebody misrepresents research that myself and others have worked on, there's something to talk about.  Especially if this "advice" leads to sweeping incorrect statements that could lead C-level folks to think that an entire class of problems has been fixed when they haven't.  This is a problem :/

The post is here: http://blog.varonis.com/microsoft-fixes-kerberos-silver-ticket-vulnerability/

It's also a bit old, from December of last year, but @Gentilkiwi (Ben / Author of Mimikatz) recently pointed it out.

And it makes enough mistakes and confuses enough concepts that I felt it necessary to make sure at least one source on the web corrects the misconceptions....

What He Got Right

The author did a decent job in previous blog entries (at least from a skim) of explaining the Kerberos process and has a decent grasp on Golden Ticket Attacks.  I'll also forgive him for not updating the post or referencing in a new post Microsoft's official KRBTGT changing script found here: (blog) http://blogs.microsoft.com/cybertrust/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/

(download) https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51

Where Things Go South

So things start getting a little misunderstood talking about Service Tickets.  There's a couple points I would like to make.  Generally speaking : 

1) Service tickets destined for something the target computer deals with (file shares, rpc calls, etc) use the target computer's AD account to sign the service ticket.  The computer account is (by default) changed every 30 days or so and has a long random unicode password.  You in all likelihood will never be able to guess this password.  However, with local admin on the box or physical access, they are trivial to recover.

2) Service tickets destined for a service running as a different account (SQL server, Exchange Server, etc) will use the service account password for that particular service as the signing key for Kerberos requests.  There is a chance you can guess these passwords, since they are service accounts.  Tim Medin's research focuses on getting something to crack offline by creating a fake SPN (service principal name) and requesting service ticket(s) ( https://github.com/nidem/kerberoast / http://www.irongeek.com/i.php?page=videos/derbycon4/t120-attacking-microsoft-kerberos-kicking-the-guard-dog-of-hades-tim-medin )

Silver tickets allow an attacker to generate arbitrary service tickets when the attacker has the service account hash / password.  PAC validation is disabled by default for accounts running as services.  For more details, refer to one of my previous posts which quotes the official MS specs : http://passing-the-hash.blogspot.com/2014/09/pac-validation-20-minute-rule-and.html

No, MS14-068 Did NOT Fix Silver Tickets

Joe Bialek from Microsoft did a great job of talking about the vulnerability fixed by MS14-068 here: http://blogs.technet.com/b/srd/archive/2014/11/18/additional-information-about-cve-2014-6324.aspx

The short version is that prior to this patch there was an edge case in the Kerberos spec that could allow an attacker with a user account password/hash to modify the PAC and then the KDC would validate it as legit. The end result was an elevated TGT account.  This is completely unrelated to silver tickets.  This was an exploit against Kerberos.

Silver tickets will continue to work with the MS14-048 patch installed.

A Note to the Author

Mr. Green, feel free to reach out to me, @gentilkiwi, or @josephbialek if you need any more clarification.

Microsoft Finally Releases Guidance and a Script to Change the KRBTGT Account

So Microsoft recently released a zipfile which contains both a document and a powershell script that can be used to change the KRBTGT in a domain.  Before doing anything, RTFM that comes with it and obviously run it in a test environment and make sure that it doesn't eat kittens in your environment...

The basic functionality of the powershell script is that it changes the KRBTGT and it will force replication to update the KRBTGT account and validate that it has replicated.

I haven't (and likely won't ) spend a lot of time on the script itself.  However, one of the things that came up on Twitter from @scriptjunkie1 was that the password being set wasn't using a decent random source, so the password wouldn't be as random as it could be.

However, based on conversations I've had with folks at Microsoft, this password doesn't matter.  This is of course undocumented and honestly, this could potentially lead to problems with clever administrators, however I will get to this a little later...

So, in this case I set up a throwaway Windows 2008 R2 domain controller.  I used Mimikatz to dump the KRBTGT hash.

So, by default, the KRBTGT account has a random 32 byte unicode password assigned to it that is completely unprintable, so it's easiest to just see the hash...

I am using this 8 character complex, yet terrible, password.  If an actual account was set to this, the NT hash would look like the above screen.

Using the 'net user' command, we can set the password for the KRBTGT account, but as you can see above, the hash from setting the password to '1qaz@WSX' is not the same hash from above.  Ok, what happens if we do it again? 

So, the hash changes again.  Even though we set it to the same password, it changes again to a random password / hash.

One thing to note, even though the password is completely ignored, it needs to clear whatever the password policy is in play on the domain.

So, why is this behavior a bad thing?  Well Microsoft's unofficial stance is that they want people to use strong passwords (even though it's completely ignored).  However, a clever administrator would INCORRECTLY believe that they could type in the same password on each DC and shortcut the replication process.

So would this completely brick your environment if you did this? Honestly I don't know.  Late last year @mubix talked about an environment where the KRBTGT was changed on a semi-constant manner and it didn't break the environment.  So (offline) myself and a few others fiddled with it a bit and it looks like that could work, but only because when the tickets are invalidated the credentials that are cached in memory are immediately resubmitted and new tickets are issued.

So what happens if you fsck up the KRBTGT across multiple domain controllers?  Honestly I don't know and don't really have a good way to easily test this. Do you really want to find out in your environment?


Correction 1:

Benjamin Delpy (@gentilkiwi) says that the KRBTGT password is a 32-byte random password (which would actually be 16 unicode chars).  Since he's poked around in memory on DC's far more than I have, I'm going with his answer :-)  Corrected in the post