5 月，微软在13日发布月度安全更新，其中 有KB2871997和 KB2928120 两个知识库文章Knowledgeased（而KB2871997甚至不是Security Bulletin）。对于无论是作为攻击的渗透测试人员还是作为防守的管理员都不容忽视这两个更新。 KB2871997针对大名鼎鼎的PTH（pass the hash攻击方式）。下面看看安全研究人员Craig对此分析。
KB2871997
这 个被称为“PTH杀手”的更新，将使本地帐号不再可以用于远程接入系统，不管是 network logon 还是 interactive login，这就包括像使用 PSEXEC工具甚至IPC远程浏览 C$ ，从表面上看这就有效的降低了一些攻击场景下的威胁。例如一台机器被攻陷后，dump出所有hash，找到本地管理员的hash，再拿着去攻击网络内其他 使用相同密码的机器，往往整个网络就这样被控制下来了。
然而，在 Craig 的测试中发现，所有以上的情况都是没说错，但是唯独默认的 Administrator (SID 500)帐号例外，请注意把administrator改名了，它的SID仍然是500，只要它还是 SID 500那么以前的攻击方法还是有效。
所 以作为防守方的管理员应该要禁用默认的 local admin帐号，然后重新新建常规的 local user帐号，再把它加进去管理员组。如果管理员做到这样了，那么黑客dump到的本地hash将不再在网络重放中有效，不管是hash还是实际的 credentials。Windows 7默认是禁用 Administrator帐号的，但是 Craig 发现往往在有些企业环境里，这个 Administrator帐号又会被启用起来，只是改了个名字， 也就是说仍然是SID 500，那么这个补丁将帮不了你。
Craig 在MSF和powershell里用WMI和psexec_command测试过，都有同样的结果——所有 local account访问都被deny了，除了 SID 500。 Domain hashes和SID 500 的hash仍然可以 pass the hash。
在下图可以看到仍然可以在测试的域环境里一个成员中执行PSEXEC，使用的就是一个SID还是500的帐号，虽然它已经名为renamedAdmin，
如下图所示针对 renamedAdmin， pass the hash攻击仍然有效，但是rdptest就不行了。
下图你可以看到rdptest在本地管理员组，但是已经不是SID 500了。
=
mimikatz
提 到 KB2871997不得不说的还有 mimikatz，它通常已经攻陷了管理员用RDP连接过系统后，就可以用 mimikatz拿到管理员的明文密码了。在 KB2871997补丁以前，即便管理员是正确的退出RDP连接，而不只是关掉连接窗口，仍然可以随时使用mimikatz拿到明文密码。 KB2871997补丁以后，只要你是正常的log off你的RDP连接，那么就会清除内存中的 credentials，但是如果比只是关掉连接的窗口，那么mimikatz的攻击仍然是有效的。 Craig的测试发现，系统并不会立即清除内存中的 credentials，但是大约30秒左右credentials就没有了。
针对Craig的这个说法，小编发现在Craig测试几天后， mimikatz就发布了一个更新的版本mimikatz 2.0 alpha https://github.com/gentilkiwi/mimikatz/releases/ ，并且更新里说明可以应对 KB2871997。 “Pass-The-eKeys now also working on Windows 7/8 if KB2871997 installed” 是不是生活顿时又充满了希望呢！
KB2928120
再说说GPP，来自官方说法是”某些组策略首选项可以存储密码。此功能将被删除，因为通过这种方式存储的密码不安全“。
以下组策略首选项将不再允许保存用户名和密码：
1，驱动器映射 2，本地用户和组 3，计划任务 4，服务 5，数据源
这将影响环境中依赖于这些首选项中包含的密码的任何现有组策略对象 (GPO) 的行为。此外，它还会阻止通过使用此功能创建新的组策略首选项。
对于“驱动器映射”、“本地用户和组”和“服务”，您也许能够通过 Windows 中其他更加安全的功能实现相似的目标。
对于“计划任务”和“数据源”，您将无法达到通过不安全的组策略首选项密码功能所能实现的目标。
Craig测试发现如果打完这个补丁后，再去之前创建的 admin account，双击他就会出行一个警告消息
点继续就会看到密码仍然在那里，但是已经不能被修改了。密码部分已经灰了。
当再新建帐号时，已经不能再设置密码了。
参考文献：
http://www.pwnag3.com/2014/05/what-did-microsoft-just-break-with.html
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.