高级域渗透技术之传递哈希已死-LocalAccountTokenFilterPolicy万岁

高级域渗透技术之传递哈希已死-LocalAccountTokenFilterPolicy万岁

大约三年前，我写了一篇名为" 传递哈希已死: 长久的哈希传递方法介绍 "的文章，详细阐述了 微软 KB2871997补丁 的一些操作含义。 在安全建议中有一句特别的话," 这个功能的改变包括: 防止网络登录和使用本地帐户远程交互登录到加入域的机器… … "使我相信(在过去3年中)补丁修改了 Windows 7和 Server 2008的行为，以防止通过非 rid 500的本地管理员帐户传递哈希的能力。 我的同事 Lee Christensen 最近指出，尽管微软的措辞如此，但这种说法实际上是不正确的，而且情况比我们最初认为的要微妙得多。 值得注意的是，pwnag3的开创性文章" 微软刚刚发布的KB2871997和 KB2928120打破了什么？ "也遭受了和我最初发表的文章一样的误解。

我们现在对这些话题有了更好的理解，并希望尽可能地澄清事实。 这是我对最终认识到 KB2871997 在大多数情况下与阻止 Windows 企业使用 pass-the-hash"复杂化"毫无关系的道歉。 对于近3年来传播错误信息的道歉-我希望弥补我的过错:)一如既往，如果在这篇文章中有错误，请让我知道，我会更新！

澄清 KB2871997 补丁的误解

那么，如果这个补丁不能自动"防止网络登录和远程交互式登录到使用本地帐户加入域的机器"，那它实际上做了什么呢？ 正如 Aaron Margosis 所描述的 ，该补丁引入了两个新的安全标识符(sid) : S-1-5-113(NT AUTHORITY Local account)和 S-1-5-114(NT AUTHORITY Administrators 用户组的本地账户和成员)。 正如 微软官方的文章中详细介绍的那样 ，可以通过组策略使用这些 sid 来有效地阻止远程登录使用所有本地管理帐户。 请注意，虽然 KB2871997将这些 sid 反向移植到 Windows 7和 Server 2008 / 2012，但它们在 Windows 8.1和 Server 2012 R2 + 的操作系统中默认合并了。 这是Sean Metcalf 之前提到过的 ， Araon在微软文章的评论中特别阐明了这一点 。

旁注: 幸运的是，这也意味着在域上经过身份验证的任何用户都可以枚举这些策略并查看哪些机器设置了这些限制。 我将在以后的文章中介绍如何执行这种类型的枚举和相关性。

我错误地认为，这个补丁修改了 Windows 7机器上的现有行为。 自从 Windows Vista 以来，攻击者一直无法将哈希传递给非内置的 RID 500 Administrator 的本地管理员帐户(在大多数情况下，请参阅下面给出的更多内容)。 在这里我们可以看到 KB2871997 没有安装在基本的 Windows 7上:

然而，使用本地管理员成员的非 rid 500的admin帐户执行 哈希传递攻击会失败:

因此，这种行为甚至在 KB2871997发布之前就存在了。 造成这种混淆的部分原因是安全警告中使用的语言，但我对没有经过充分测试情况和转达正确的信息负有责任。 虽然我们强烈推荐 Aaron 的建议，即在这些新的 sid 中部署 gpo， 以帮助缓解内网渗透，但我们仍然对保留了KB的原始标题的权利感到得意;)

远程访问和用户帐户控制

那么，如果补丁不影响这种行为，那又是什么阻止了我们使用本地管理员帐户传递哈希呢？ 为什么 RID 500帐户可以作为特殊情况运作？ 此外，为什么作为本地管理员用户组成员的域帐户也不受这种阻止行为的影响？ 此外，在过去的几年中，我们还注意到在一些约定，传递-哈希攻击仍然可以在非 rid 500的本地管理员帐户上工作，尽管补丁正在应用。 这种行为一直困扰着我们，但我们认为我们最终可以解释所有这些矛盾。

所有这些问题的真正罪魁祸首是远程访问上下文中的用户帐户控制(UAC)令牌过滤。 我一般总是在本地主机操作的上下文中会考虑 UAC，但是这对于远程情况也有各种各样的含义。 微软官方的 "Windows Vista 应用程序开发对用户帐户控制兼容性的要求" 文档中的"用户帐户控制和远程场景"部分以及 "Windows Vista 中用户帐户控制和远程限制的描述" 部分都多次解释了这种行为，并为我个人澄清了几点。

对于任何非 rid 500的本地管理员帐户远程连接到 Windows Vista+ 的计算机，无论是通过 WMI、 PSEXEC 还是其他方法，返回的令牌都是"已过滤的"(即中等完整性) ，即使用户是本地管理员。 由于没有方法可以远程升级到高完整性的上下文，除非通过 RDP (除非启用" 受限管理 "模式，否则需要明文密码) ，令牌才会保持中等完整性。 因此，当用户试图远程访问一个特权资源(例如 admin$)时，他们会收到一条"Access is Denied"消息，尽管从技术上讲他们确实拥有管理访问权限。 不过，我马上就会得到 RID 500的例外案例;)

对于本地"管理员"组中的本地用户帐户," Windows Vista 用户帐户控制兼容性应用程序开发要求 "文档描述了以下行为:

在 Windows Vista 计算机的本地安全帐户管理器(SAM)数据库中拥有管理员帐户的用户远程连接到 Windows Vista 计算机时，该用户在远程计算机上没有特权提升的潜力，不能执行管理任务。

微软官方发布的" 描述 Windows Vista 中的用户帐户控制和远程限制 "的文章中用另一种方式描述了这一点:

当目标远程计算机上的本地管理员用户组的成员的用户建立远程管理连接时… … 他们将不会以完全的管理员身份连接。 用户在远程计算机上没有特权提升潜力，并且用户无法执行管理任务。 如果用户希望使用安全帐户管理器(SAM)帐户管理工作站，则用户必须交互式地登录到要使用远程协助或远程桌面管理的计算机。

对于本地"管理员"用户组中的域用户帐户，文档中有如下声明:

当拥有域用户帐户的用户远程登录到 Windows Vista 计算机，并且该用户是 Administrators 用户组的成员时，域用户将使用远程计算机上的完全管理员访问令牌运行，并且远程计算机上的用户在该会话期间会禁用 UAC。

这就解释了为什么本地管理帐户在远程访问时会失败(除了通过 RDP) ，以及为什么域帐户却是成功的。 但是，为什么内置的500 RID 管理员帐户会作为一个特殊情况呢？ 因为默认情况下，内置管理员帐户(即使重命名)使用了完全的管理特权("完全令牌模式")运行了所有的应用程序，这意味着用户帐户控制没有得到有效应用。 因此，当使用此帐户启动远程操作时，将授予完全高完整性(即未过滤的)的令牌，允许正确的管理访问！

只有一个例外——" 管理批准模式 "。 指定此选项的注册表键位于 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken，默认情况下是禁用的。 但是，如果启用此密钥，RID 500帐户(即使已重命名)将被注册为 UAC 保护。 这意味着使用该帐户的机器的远程 PTH 将会失败。 但是对于攻击者来说，还有一线希望——这个密钥通常是 通过组策略设置 的，这意味着任何经过域身份验证的用户都可以通过 GPO应用程序枚举机器所做的事情以及不设置 FilterAdministratorToken键值。 虽然这会忽略在标准"gold"镜像上设置键值的情况，但是从攻击者登陆的初始机器上执行这个键值枚举，结合 GPO 枚举，应该可以覆盖大多数情况。

请记住，尽管 Windows 默认禁用了内置的500 Administrator 帐户，但在企业中启用该帐户的情况仍然相当普遍。 我最初发表的 关于 pass-the-hash 的文章 涵盖了这些信息的基本远程枚举， 这篇文章 将进一步详细介绍这些信息。

LocalAccountTokenFilterPolicy

对于我们攻击者来说，还有一线希望，还有一些比我们最初意识到的更具防御意义的东西。 Jonathan Renard 在他的" *Puff* *Puff* PSExec "的文章中提到了其中一些东西(以及管理员批准模式) ，但是我想扩展一下关于整个 pass-the-hash 讨论的内容。

如果 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy 键存在(默认情况下不存在)并设置为了1，那么在协商期间，管理员用户组的所有本地成员的远程连接都被授予完全高完整性的令牌。 这意味着非 rid 500帐户连接不会被过滤，并且可以成功地传递哈希！

那么为什么要设置这个注册表条目呢？ 在谷歌上搜索这个关键名称会出现不同的情况。在我们现在所说的这种情况下，这是一种解决方案，但有一个常见的功能: Windows Remoting。 有大量的微软文档建议将 LocalAccountTokenFilterPolicy 设置为1，来作为解决各种问题的方法或解决方案:

·“ 不建议通过更改控制远程 UAC 的注册表项来禁用远程 UAC，但可能有必要.. ”

· “ Set-ItemProperty –Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System –Name LocalAccountTokenFilterPolicy –Value 1 –Type DWord ”

· “ 用户帐户控制(UAC)会影响对 WinRM 服务的访问 ”

· “ … 你可以使用 LocalAccountTokenFilterPolicy 注册表项来更改默认行为，并允许管理员用户组的成员的远程用户使用 Administrator 特权运行 ”

· “ 如何禁用 UAC 远程限制 ”

此外，我相信在某些情况下，WinRM 的quickconfig 命令甚至可以自动设置这个键，但是我不能可靠地重新创建这个场景。在微软的" 从远程计算机获取数据 "的文档中做了进一步的详细解释:

由于使用了用户帐户控制(UAC) ，远程帐户必须是域帐户和远程计算机 Administrators 用户组的成员。 如果帐户是 Administrators 用户组的本地计算机成员，则 UAC 不允许访问 WinRM 服务。 要访问工作组中的远程 WinRM 服务，必须通过创建以下 DWORD 注册表项并将其值设置为1来禁用针对本地帐户的 UAC 过滤: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] LocalAccountTokenFilterPolicy。

这是个坏建议，坏坏坏坏坏透了的建议！ 我意识到可能需要这个设置来帮助一些特定的 WinRM 部署场景，但是一旦 LocalAccountTokenFilterPolicy 被设置为1，那么就可以使用机器上的 任何（注意是任何！）本地管理员帐户来向目标传递-哈希。 我觉得大多数人，包括我自己，还没有意识到这个修改所隐含的实际安全含义。 我在所有的微软文档中看到的唯一真正的警告是" 注意: LocalAccountTokenFilterPolicy 条目将禁用所有受影响的计算机的所有用户的用户帐户控制(UAC)远程限制。 在改变策略之前，要仔细考虑这种背景的影响。 "。 由于这种设置会给企业环境带来巨大的风险，因此我希望从微软那里得到更好的明确指导和警告，而不仅仅是"考虑其影响"，但是¯\_(ツ)_/¯

从操作角度来说(从攻击性的角度来看) ，最好检查一下你的跳板机器上是否将 LocalAccountTokenFilterPolicy 键设置为了1，因为同一子网或OU中的其他机器也可能具有相同的设置。 你还可以列举组策略设置，看看这个注册表键是否是通过 GPO 设置的，这也是我将在以后的文章中讨论的内容。 最后，你可以使用 PowerView 列举任何启用了 Windows Remoting 的 Windows 7和 Service 2008机器，希望它们运行的 Windows Remoting 没有正确设置:

Get-DomainComputer -LDAPFilter "(|(operatingsystem=*7*)(operatingsystem=*2008*))" -SPN "wsman*" -Properties dnshostname,serviceprincipalname,operatingsystem,distinguishedname | fl

同样值得注意的是， 微软的 LAPS 实际上让这里的一切都变得毫无意义。 由于 LAPS 定期为计算机随机设置本地管理员密码，所以传递哈希仍然可以有效地工作，但它极大地限制了恢复和重用本地密钥的能力。 这使得传统的 PTH 攻击(至少是本地账户)基本上变得无效。