Pages

Wednesday, May 14, 2014

What Did Microsoft Just Break with KB2871997 and KB2928120

Microsoft recently released two patches that will likely impact your future pentests. The first was KB2871997.  Some have dubbed this the "Pass the Hash Fix" but it is hardly that. The second patch that will likely impact your pentests is KB2928120. This is known as the Groups.xml GPO preferences bug that Chris Gates published here.  In this blog post, I'll walk through my testing and validation of these patches from my lab. Hopefully I am able to boil all the confusion down to "which of my old tricks did Microsoft just break?"

First lets dissect the "pass the hash killer", KB2871997. tl;dr => local accounts can no longer be used to access remote systems, either via simple network logon or interactive login. This includes using tools like PSEXEC or even browsing to C$ remotely. On the surface it would seem that this patch would effectively eliminate the attack vector where you compromise a system, dump the hashes and then find that the local admin hash is the same on all systems which usually results in total domination.

HOWEVER, in my testing, the above holds true for any local account on the system EXCEPT the default Administrator (SID 500) account. Keep in mind, a renamed administrator account is still a SID 500. As long as the account is of the SID 500 flavor, it appears to still work as it has in the past.

To recap, for the sync'd local admin password attack vector to be squashed by patch KB2871997, the network admin needs to disable the default local admin account, create a new regular local user and then add that user to the administrators group. If they do all that and you dump the local hash, it cannot be replayed across the network, either using the hash or the actual credentials. Windows 7 disables the Administrator account by default, but in many corporate environments I've found this account to be re-enabled and often just renamed.... which means SID 500 and the patch should not stop you.

I tested the above using WMI, psexec_command from MSF and powershell. Each one had the exact same results: access denied for all local accounts except SID 500. Another key point is that you can STILL pass the hash. Domain hashes and SID 500 hashes can all be passed.

Here you can see a PSEXEC to a member of my domain, using an account named "renamedAdmin" which is the original SID 500. PSEXEC works fine:


Same results with PTH. "renamedAdmin" works fine, "rdptest" does not:



As you can see, rdptest is a part of my local admin group but is not the SID 500:


KB2871997 also does sort of address the mimikatz issue of pulling clear text credentials out of memory. This is most commonly exploited by running mimikatz on systems where people have RDP'd to the system. Prior to the patch, even if a user logged off their RDP session properly, rather than just disconnecting, the credentials could be harvested at any time using mimikatz. KB2871997 now will cause the operating system to clear those credentials from memory only when the user properly uses the RDP log off function. If the user simply disconnects, i.e. "x'ing out" of the screen, mimikatz will still be able to pull clear text credentials. In my testing, Windows wouldn't immediately clear memory, but within 30 seconds or so the credentials are gone. Bottom line, most users just X out of their RDP session so your mimikatz tricks should still work.

Moving on to the GPO Preferences issue. tl;dr => the patch only disables the ability to store passwords for NEWLY added local accounts. If the network admin has ever used this functionality in the past to store a password, they would have had to MANUALLY remove the Groups.xml file from the SYSVOL share or delete and re-add their user post patch. Otherwise, simply browse to SYSVOL like normal and grab the Groups.xml file and decrypt away using Chris Gates script.

After adding the patch, when we go to our previously created admin account and double click it, we're presented with a new warning message:


 Next, you can see that the password appears to still be stored but we're unable to change it:


 When creating a new account, you can see we're unable to set a password, since those fields are greyed out:


Finally, the following screenshots show you that the Groups.xml file is still in SYSVOL and can still be decrypted:




This jives with what MS says here: "Note that Microsoft is not automatically disabling these Group Policies because we do not want to disrupt existing environments which rely on this feature."

The takeaway from both of these patches is that neither one completely fixed anything. Keep your eyes open for SID 500 and also keep checking for Groups.xml, it might still be there waiting for you :) Please let me know if your testing contradicts anything I have said... I want to make sure I have the exact details! 

Testing environment is Windows 7 client using a 2008 R2 DC.

5 comments:

doug macpherson said...

Can you test to see whether this update breaks the ability for domain users to change their passwords? In our environment, this update prevents users from changing their password with the error "The security database on the server does not have a computer account for this workstation trust relationship."

ZeroBits said...

Doug, I found it was KB2871997 while working with the IT team was the cause that prevented users from changing their password on their Windows 8 machine.

Although they had Windows 2003 Domain Controller so I think it may be the Windows 2003 domain cannot see interpret kerberos.

Anton Karlan said...

I just tested browsing C$ on WS 2008R2 with KB2871997 instslled from Win7 with that update intalled too. And I can say, that I can browse C$ with admin account, which is non standard admin with 500 SID.
What I do not right?

Adam Reece said...

For the record KB2871997 caused my server's LsaSrv (lsass.exe) to crash any time Kerberos was contacted by a RADIUS request (via Network Policy Server).

I've had to remove this update to stop my server rebooting any time a Wi-Fi device wanted to connect. :(

Source

SYNERGIX - said...

For the GP Preference issue take a look at what SYNERGIX has to offer.

SYNERGIX ( http://www.synergix.com) has a feature in their product Active Directory Client Extensions ( ADCE ) to manage built-in admin account password ...

Few links ...

http://www.synergix.com/
http://support.synergix.com/hc/en-us/articles/202927738-Test-Scenario-Managing-Built-In-Administrator-Account-Password
http://www.synergix.com/products/active-directory-client-extensions/
( scroll down to Built-In Admin Account Password section )