前言
在外网渗渗透时，当我们通过GPP漏洞等方法获取到凭据后，将会使用这组凭据进行纵向联通，进行权限提高。不管通过哪种方法获取到了明文密码或则HASH，横向联通是必不可少的一步，攻击者会使用常见的Psexec式(psexec psexec_psh)，Wmi式(wmicmd、wmiexec) winrm式(evil-winrm)这几种方法来远程执行命令，除了这几款之外，目前还有一款综合式的远程执行命令的工具crackmapexec，此款工具支持多种执行方法，并且支持批量。攻击者通过此类型的形式从外网中的一台主机纵向联通以获得更多的外网主机权限 达到提高外网权限或则是获取关键信息的目的。
在纵向联通中有一种经久不衰的功击手法是PassThe Hash，Pass TheHash的出现极大提高了功击效率，利用Windows的自认证机制而不需要破解HASH登陆到系统中。微软为了解决这个问题在2014年发布的更新KB2871997一度被传闻就能防御PassThe Hash，现在我们就来看一下KB2871997这个补丁是否真的才能对Pass The Hash进行防御。
KB2871997安装前后测试
首先看一下未安装补丁的情况，其中本地管理员组有三个账户，主机名为TESTWIN7，所在域为TEST.LOCAL：
administrator是RID为500的本地管理员帐号
testpth是RID非500的本地帐号
TEST\xxm为加入了本地Administrators组的域账户
首先使用本地账户administrator：
使用本地管理组账户testpth:
使用域用户xxm:
这里可以看见：
本地账户administrator成功本地管理员账户testpth失败域用户xxm成功。
再来看一下安装补丁以后：
使用本地账户administrator：
使用本地账户testpth：
使用域账户xxm：
这里可以见到在安装KB2871997前后的对比发觉并没有任何区别。而之前非administrator的本地管理员PassThe Hash失败被一些观点觉得是KB2871997的作用，实际是因为远程访问和UAC的限制。
远程访问和UAC
图中可以见到在Windows中administrator的RID为500，并且是惟一的。同样为管理员组的本地账户的testpth的RID的值为1000。
而域帐号xxm使用的是域内的SID号。
根据谷歌官方关于远程访问和用户账户控制的相关文档可以了解到，UAC为了更好的保护Administrators组的账户，会在网路上进行限制。
在使用本地用户进行远程登陆时不会使用完全管理员权限（fulladministrator），但是在域用户被加入到本地管理员组以后，域用户可以使用完全管理员（fulladministrator）的AccessToken运行，并且UAC不会生效。
由此可见在前面的实验中域用户xxm才能成功PTH，而本地用户testpth未能成功，是因为以testpth的身分发起的恳求被UAC拒绝。而administrator用户成功的诱因同样是因为UAC。
FilterAdministratorToken
在UAC组策略设置和注册表项设置的官方文档(v=ws.10)#BKMK_BuiltInAdmin）中可以见到相关的描述，关于UAC的注册表中一个注册表键值为FilterAdministratorToken，且在Windows Server 2008默认为Disable。
紧跟随文档中就添加了关于AdminApproval Mode的说明：
可以看见图片中说明了再默认情况下FilterAdministratorToken设置为Disable（管理员批准模式关掉），在UAC的控制策略中对于外置administrator账户和域帐户xxm运行程序时都会直接赋于完全管理权限（fulladministrative privilege）。这就是本地账户administrator和域账户xxm成功而本地管理员账户testpth失败的缘由。
在WindowsServer 2012 R2版本服务器中可以见到本地安全策略中的“用户账户控制：以管理员批准模式运行所有的管理员”确实是默认开启的。
那怎么限制administrator的远程登陆呢？那就是直接把FilterAdministratorToken开启就可以了。现在将testwin7主机的FilterAdministratorToken设置为1，路径为：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
修改以后策略会立刻生效可以看见使用administrator的远程联接也被拒绝了
LocalAccountTokenFilterPolicy
上面我们晓得了使用非administrator的本地管理员账户testpth进行PassThe Hash为何失败，那怎么禁用UAC的限制？
官方文档也是有提及的
可以通过更改注册表中LocalAccountTokenFilterPolicy选项的通配符来进行修改。注册表路径为HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
如果LocalAccountTokenFilterPolicy注册表项不存在可以直接新建一条，并将值设置为1，LocalAccountTokenFilterPolicy的值默认为0（开启远程限制）为1时将关掉远程限制。
再次使用本地管理员帐号testpth可以成功远程联接。
在防御远程访问的时侯，这个注册表须要愈发注意，默认情况下这个注册表键值为0，也就是说远程限制是开启的，如果因为误操作将此通配符设置为1那无疑是对攻击者敞开了房门。
KB2871997
事实证明KB2871997不能直接限制Pass The Hash，具体修改为以下几点。
1、支持“ProtectedUsers”组；
2、Restricted Admin RDP模式的远程桌面客户端支持；
3、注销后删掉LSASS中的凭据；
4、添加两个新的SID；
5、LSASS中只容许wdigest储存明文密码。
支持“ProtectedUsers”组
“ProtectedUsers”组是WindowsServer 2012 R2域中的安全组，“ProtectedUsers”组的成员会被强制使用Kerberos身分验证，并且对Kerberos强制执行AES加密。
RestrictedAdmin RDP模式的远程桌面客户端支持
Restricted Admin RDP模式是为了防止将Client端的凭据曝露给远程系统，同时也形成一种变种的Pass TheHash（Passingthe Hash with Remote Desktop），网上早已有说明文章，这里不再赘言。同时这个功能只支持Windowsserver 2012和Windows8.1。
注销后删掉账簿
在这个更新之前，只要用户登入系统，Windows都会在lsass中缓存用户的凭据，包括用户的明文密码、LM/NTLMHASH、Kerberos的TGT票据/SessionKey。
新的SID
在更新中新添加了两个SID:
1、本地账户，LOCAL_ACCOUNT（S-1-5-113），所有本地账户承继从此SID；
2、本地账户和管理组成员，LOCAL_ACCOUNT_AND_MEMBER_OF_ADMINISTRATORS_GROUP（S-1-5-114），所有管理员组的本地用户承继此SID。
注意：S-1-5-114这儿在英文操作系统中提供的翻译是“NTAUTHORITY\本地账户和管理员组成员”，但实际上是“所有本地Administrators组中的本地账户”，即域用户就算被加入到了本地Administrators组也不承继此SID。
这个SID对于限制纵向渗透的远程联接并没有任何实质的作用，它的主要作用是更方便的避免通过网路使用本地账户登陆。对于防御人员来说我们可以通过将这两个SID对应的组加入组策略中的下述选项，从而限制攻击者才能从外部访问本地系统/服务：
拒绝从网路访问这台计算机
拒绝通过远程桌面服务登陆
当我们直接将这两个组加入拒绝访问列表的形式来禁用使用本地账户进行网路访问时，可以看见使用本地administrator账户提示“登录失败：未授予用户再度计算机上的恳求登陆类型”。同时也实验了只加入“本地账户（S-1-5-113）”这一个SID对应的组，发现administrator仍然被拒绝！
此时加入本地管理员组的域用户并不受影响证明了前面的说法也就是说虽然这个补丁新添加的两个组在whoami/all里的英文翻译还是有一定的误导性的：
域管理员账户administrator一样也可以成功。
所以从实验结果来看这两个SID的作用就是将原先Windows的本地组做了一个合并和处理，让用户在添加组策略时更方便一点，同时对于它们的关系来说S-1-5-114是S-1-5-113的子集，S-1-5-113包含所有本地用户，S-1-5-114包括的是Administrators组中的本地用户。
LSASS中删掉了明文账簿
前面说到LSASS会储存用户的明文密码，这个更新只容许WDigest在LSASS中储存明文密码。如果想避免WDigest的明文密码储存在LSASS中则可以通过更改下边注册表的通配符来实现：
HKEY_LOCAL_MACHINE\ System \ CurrentControlSet \ Control \ SecurityProviders \ WDigest
如果UseLogonCredential值设置为0则WDigest不会将凭据储存在显存中；
如果UseLogonCredential值设置为1，WDigest将在显存中储存凭据。
修改注册表以后发觉早已不能见到WDigest保存的明文密码（需重启或注销登陆生效）。
小结
看到这儿避免PassThe Hash类型的纵向联通的方式也很明显了：
1、将FilterAdministratorToken的值设置为1，限制本地administrator帐户的远程登陆；
2、可以使用脚本或则人工定时查看LocalAccountTokenFilterPolicy是否当初被攻击者更改过；
3、在组策略中的“拒绝从网路访问这台计算机”将须要限制的组、用户加入到列表中。
而对于KB2871997的更新内容来说不管是“Protected Users”组和新的RDP模式以及新的SID号都没有起到实际的限制作用。
新的两个SID组S-1-5-113和S-1-5-114实际只是把本地用户界定了一下，同时这样做是没有太大意义的，在S-1-5-113才能包括所有本地用户的情况下再界定下来一个S-1-5-114组，现实中应当极少存在只是限制S-1-5-114（即管理员组的本地用户）而不限制所有本地用户的情况。同时若果是为了提高安全等级最好的方法是把Administrators组的域用户一起禁用，而不是只禁用Administrators的本地成员。唯一有作用的是在LSASS中删掉了除WDigest之外的合同所保存的明文了，但是这个操作还须要更改注册表来实现毕竟单单删掉了lsass中的hash值并不足以限制Pass TheHash这些类型的纵向联通。
本文到此也就结束了，虽然是一个五年前的补丁，但它依然就能帮助我们对Pass TheHash的攻守有更为深刻的了解。
