在进行模拟攻击时，测试员总会试图隐蔽自己的攻击行为，通常他们都会先提前列举一些隐蔽策略，这种提前列举的办法不但可以避免在无法获取的攻击路径上浪费时间，而且还在一定程度上降低了被检测到的风险。

其中一个常用的策略就是获得本地管理员密码哈希或纯文本凭据，以进行不同安检环境中的身份验证，我们通常将其称为远程访问策略。在Windows中就有两个值得注意的远程访问策略，它们都会对隐藏攻击行为产生影响。这两个远程访问策略分别是用户帐户控制(UAC)和用户权限分配(URA)。由于它们的配置不同，所以如果操作不当，模拟攻击就会被检测到，这种远程访问策略可以在本地执行或远程执行中被用到。

如果你对UAC和URA以及如何利用组策略将其设置映射到特定计算机对象，你可以先找一些资料预热一下。

远程访问策略的用例：UAC和URA

本节会重点介绍一些UAC和URA配置选项，这些选项可以通过组策略设置。另外，我还会介绍它们影响远程身份验证的整个过程，我将稍后讨论它们的存储位置以及如何枚举它们。

UAC的目的是提供一种隔离进程的方法，使其能够在不同的完整性级别或可信任级别运行。影响UAC行为的设置将被作为注册表项属性被存储在HKEY_LOCAL_MACHINE注册表配置单元的以下位置：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

在远程身份验证中，有三个显著的属性会影响UAC行为，这些设置都决定了如何为本地管理员组内的用户的远程连接筛选访问令牌。在实际操作中，这些设置会控制是否可以执行远程身份验证并获得一个高完整性访问令牌，或者是否将其过滤为较低的完整性级别。从安全性评估的角度来看，你需要一个高完整性访问令牌来建立远程管理访问。

EnableLUA用于启用计算机的(1，默认)或禁用(0)“Admin Approval”模式。不够在目前的安全文献中，很少诱人提到这种设置的效果，然而，这对于UAC的运行是不可或缺的。如果禁用，所有UAC策略也将被禁用。禁用时，可以使用纯文本凭据或密码哈希对本地管理员组的任何成员执行远程身份验证权限。在远程身份验证过程中，本地管理员的所有访问令牌均会被设置为高完整性。启用时,享有远程身份验证功能权限是由LocalAccountTokenFilterPolicy和FilterAdministratorToken的设置确定的。

LocalAccountTokenFilterPolicy是用于控制过滤本地管理员组中所有本地用户的远程连接访问令牌的策略。当设置为0(默认值)时，具有高完整性访问令牌的远程连接只能使用RID 500本地管理员的纯文本凭据或密码哈希并且仅依赖于filteradminstratortoken的设置。而对于非RID 500本地管理员，可以对远程连接的访问令牌进行过滤即中等完整性。如果设置为1，则策略允许使用明文凭据或密码哈希，从本地管理员组的任何成员获得高完整性访问令牌的远程连接。Will Schroeder（@ harmj0y）在他的博客文章中提供了LocalAccountTokenFilterPolicy角色的进一步细节，阐明了KB2871997对传递哈希（passing-the-hash）或缺少哈希的影响。

要注意的是，即使LocalAccountTokenFilterPolicy设置为0，如果EnableLUA被禁用（0），那么没有UAC强制过滤，EnableLUA同样会优先。

filteradminstratortoken用于为RID 500本地管理员启用（1）或禁用（0，默认）“Admin Approval”模式。启用后，RID 500本地管理员的访问令牌将被过滤即中等完整性，此时，明文凭证或密码哈希就无法使用，这意味着RID 500本地管理员执行远程身份验证权限是不可能的。在标准Windows版本中，LocalAccountTokenFilterPolicy和FilterAdministratorToken的默认设置解释了为什么只能使用RID 500本地管理员帐户来执行特权远程验证。虽然默认情况下是禁用的，但也有例外，比如通过黄金映像启用FilterAdministratorToken，然后通过对特定计算机对象的组策略选择性地禁用此功能。这种情况下，测试人员就可以在不被检测到的情况下，使用RID 500本地管理员的任何识别凭证来发起攻击。

尽管这三个注册表关键属性都位于Windows注册表中的同一个位置，但它们通过组策略配置的方式以及它们如何存储在组策略配置文件中的方式都有所不同，了解其中的区别对于理解如何枚举是至关重要的。

配置EnableLUA和FilterAdministratorToken

EnableLUA和filteradminstratortoken都在组策略管理编辑器中有明确的配置选项。对于EnableLUA来说，这是“用户帐户控制:运行管理审批模式的所有管理员”和filteradministrator的“用户帐户控制:内置管理员帐户的管理审批模式”。这些设置可以在以下位置找到：

->计算机配置

->政策

->窗口设置

->安全设置

->本地政策

->安全选项

->“用户账户控制：内置管理员账户管理审批模式”

->“用户帐户控制：管理审批模式下的所有管理员”

“安全选项”设置存储在一个名为“gpttmpl”的INF配置文件中，INF在每个域控制器托管的SYSVOL共享的相关组策略容器中。

\\<Domain>\Policies\{<GUID>}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf

下图显示了“EnableLUA”被禁用的情况。

配置LocalAccountTokenFilterPolicy

LocalAccountTokenFilterPolicy不能通过组策略管理编辑器中的显式配置选项（explicit configuration option ）进行设置。相反，它需要通过自定义注册表项属性的定义进行设置。在组策略管理编辑器中，设置可以在以下位置完成：

->计算机配置

->首选项

->窗口设置

->注册表

-><自定义键和属性定义>

这样做的结果是配置存储在组策略容器内的不同位置，这一次是一个名为Registry.xml的XML文档。

\\<Domain>\SYSVOL\<Domain>\Policies\{<GUID>}\Machine\Preferences\Registry\Registry.xml

下图就是启用LocalAccountTokenFilterPolicy（1）的Registry.xml配置的范例：

用户权限分配：SeDeny* ?

URA在规定了用户可以对系统进行身份验证的方式，同时也为用户使用某些特权提供了一些方法，不过影响URA行为的设置在Windows注册表中是无法查到的。

有两个显著的URA设置会影响远程身份验证，且每一个都以SeDeny*前缀开头，可以通过组策略进行配置。

SeDenyNetworkLogonRight用于拒绝某些用户或组执行网络身份验证的功能，例如，通过远程过程调用(RPC)端点映射器和服务器消息块(SMB)服务使用该身份验证。

SeDenyRemoteInteractiveLogonRight用于拒绝某些用户或组执行远程桌面协议（RDP）服务使用的远程交互式身份验证的功能。

如果用户或组与这些设置中的任何一个相关联，则通过相关协议随意使用所需的认证将不可能。也就是说，通过将它们与设置关联起来，它们就不能执行某些类型的身份验证。

你可能会认为防止本地凭据被滥用的一种方法是将这些设置与内置的“管理员”组相关联，但其实这是一个被误解的方法，因为这么做会影响该组内的所有对象，包括已包含在其中的域用户和组。例如，在默认情况下，“域管理员”组位于加入域的计算机对象的内置“管理员”组中，尽管其内部具有一些特别权限，但也不可能通过使用这些帐户的相关协议进行身份验证。

除上述URA设置之外，还应该注意的是，还有一些类似的SeDeny *设置可以拒绝用户或组执行本地身份验证或直接取消身份验证的功能。

配置SeDenyNetworkLogonRight和SeDenyRemoteInteractiveLogonRight

SeDenyNetworkLogonRight和SeDenyRemoteInteractiveLogonRight在组策略管理编辑器中有明确的配置选项，对于SeDenyNetworkLogonRight，是“拒绝从网络访问此计算机”，而对于SeDenyRemoteInteractiveLogonRight则是“拒绝通过远程桌面服务登录”。这些设置可以在以下位置找到：

->计算机配置

->政策

->窗口设置

->安全设置

->本地政策

->用户权限分配

->“拒绝从网络访问这台计算机”

->“拒绝通过远程桌面服务登录”

可以看出“用户权限分配”设置与UAC设置中的“安全选项”所使用的“gpttmpl.inf”SYSVOL文件相同。

\\<Domain>\Policies\{<GUID>}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf

下图就是SeDenyNetworkLogonRight和SeDenyRemoteInteractiveLogonRight配置为包含内置“管理员”组的情况，该组在配置中是通过其众所周知的SID“S-1-5-32-544” 自动表示而不是组名称。

使用PowerView枚举远程访问策略

通过了解UAC和URA策略以及它们是如何影响远程身份验证，以及这些策略如何存储在组策略容器中，我就可以开始枚举它们了。为此，PowerSploit框架内的PowerView将会被大量使用。此外，我还创建了三个函数来帮助枚举远程访问策略，分别是：Find-ComputersWithRemoteAccessPolicies ，Get-DomainGPORemoteAccessPolicy和Get-RegistryXML。这些函数的代码可以在MWR Labs的Github找到。

Get-DomainGPORemoteAccessPolicy是包含了许多附加功能的核心功能，并标识建立感兴趣的远程访问策略的GPO。该功能与现有的Get-DomainGPOLocalGroup非常相似，即使用PowerView的Get-DomainGPO检索每个GPO的详细信息，并检查每个组策略容器的内容以查找GptTmpl.inf和Registry.xml文件。如下图所示，PowerView通过在每个GPO对象的“gpcfilesyspath”属性中提供对组策略容器的路径，来使此过程变得容易。

由于PowerView已经提供了解析Get-GptTmpl中的GptTmpl.inf文件的功能，因此，Get-DomainGPORemoteAccessPolicy只需检查感兴趣的注册表项的返回对象。但是，Registry.xml不存在这样的现有函数。尽管如此，所需的功能也会关闭PowerView的Get-GroupsXML。 Get-RegistryXML虽然会对Registry.xml执行类似的操作，但返回的却是包含经过注册表修改的PSObjects列表。

以下代码片段显示了执行上述操作的Get-DomainGPORemoteAccessPolicy功能的一个子集，即检索每个GPO，并通过将EnableLUA属性设置为0来检查是否禁用UAC。

Get-DomainGPO @SearcherArguments | ForEach-Object {
     $GPOdisplayName = $_.displayname
     $GPOname = $_.name
     $GPOPath = $_.gpcfilesyspath
     # EnableLUA and FilterAdministratorToken check via GptTmpl.inf
     $ParseArgs =  @{ 'GptTmplPath' = "$GPOPath\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf" }
     if ($PSBoundParameters['Credential']) { $ParseArgs['Credential'] = $Credential }
     # parse the GptTmpl.inf file (if it exists) for this GPO
     $Inf = Get-GptTmpl @ParseArgs         
     if($Inf -and ($Inf.psbase.Keys -contains "Registry Values")) 
     {
          $EnableLUA = $Inf["Registry Values"]["MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA"]
          if ($EnableLUA -and ($EnableLUA[0] -eq 4) -and ($EnableLUA[1] -eq 0))
          {
               Write-Verbose "The following GPO enables pass-the-hash by disabling EnableLUA: $GPOdisplayName - $GPOname"
               # append to EnableLUA GPO list if it is not already there
               if ($RemoteAccessPolicies.EnableLUA -notcontains $GPOname) { $RemoteAccessPolicies.EnableLUA += $GPOname }
          }
<snip>

Get-DomainGPORemoteAccessPolicy会返回一个哈希表，其中就包含了要搜索的每个属性的名称（例如，EnableLUA），并且该哈希值是该属性被设置为感兴趣的值的GPO的列表。

Get-DomainGPORemoteAccessPolicy不是直接调用，而是作为Find-ComputersWithRemoteAccessPolicies的辅助函数。 Find-ComputersWithRemoteAccessPolicies会作为一个封装器接受Get-DomainGPORemoteAccessPolicy的输出, 先确定GPO链接到的组织单位，然后确定这些组织单位中的计算机对象。PowerView再次将组织单元和GPO之间的链接建立起来，因为Get-DomainOU函数返回的对象包含一个“gplink”属性，该属性描述了所链接的GPO。

下面显示了Find-ComputersWithRemoteAccessPolicies执行上述过程的代码片段，它将远程访问策略设置的计算机对象添加到哈希表中，其中密钥为policy，值为DNS主机名列表。

$RemoteAccessPolicies = Get-DomainGPORemoteAccessPolicy @gpoSearchArguments   
$RemoteAccessPolicies.PSObject.Properties | ForEach-Object {
     $policy = $_.Name # EnableLUA, etc
     foreach ($guid in $RemoteAccessPolicies.$policy) {
          # set arguments for OU search (readding $SearchBase to limit the scope)
          $ouSearchArguments = @{}
          $ouSearchArguments = $ouSearchArguments + $SearcherArguments
          $ouSearchArguments['GPLink'] = $guid
          Get-DomainOU @ouSearchArguments | ForEach-Object {
               $compSearchArguments = @{}
               $compSearchArguments = $compSearchArguments + $SearcherArguments
               $compSearchArguments['SearchBase'] = $_.distinguishedname
               $OUComputers = Get-DomainComputer @compSearchArguments
               $OUComputers | ForEach-Object {
                    if ($ComputerObjectsWithRemoteAccessPolicies.$policy -notcontains $_.dnshostname) { $ComputerObjectsWithRemoteAccessPolicies.$policy += $_.dnshostname }
<snip>

下图显示了由Find-ComputersWithRemoteAccessPolicies返回的这个对象，以及如何利用它来识别实施攻击的目标。

假设所有计算机对象都具有本地管理凭据重用的黄金映像，那么UAC就已经在三个计算机对象上通过EnableLUA被禁用了，这就为重新使用非rid 500凭据信息创造了机会。但是，由于“管理员”组包含在其中两台主机（“HR-COMPUTER-1”和“HR-COMPUTER-2”）的SeDenyNetworkLogonRight设置中，所以可防止使用虚假的网络认证发起攻击，这也将阻止使用RID 500“管理员”帐户被黑客利用。而对于其余的计算机对象（“DEV-COMPUTER-1”），则可以通过重用任何本地管理凭证（RID 500和非RID 500）发起攻击。对于所有计算机对象，如果可以获得内置“管理员”组中的用户的明文凭证，则可以将这些凭证用于远程交互式验证（例如RDP）。这是因为通过SeDenyRemoteInteractiveLogonRight这样的身份验证并没有被明确地禁止。下图就是这个攻击路径的流程示意图：

总结

这篇文章描述了为特定策略设置枚举组策略的过程，并确定了可以应用的计算机对象。具体来说，为了确定计算机对象，由于UAC和URA设置，可以将本地证书资料重新用于远程认证。为此，我还还制作了一组PowerView扩展，你可以在MWR Labs的Github上找到这些活动。

虽然远程访问策略是本文的重点，但通过简单的例子介绍，你也知道了如何将相同的方法应用到任何其他策略设置中。例如，如果通过组策略强制执行设置，则攻击者就可以使用它来识别正在运行的计算机对象。因为攻击者可以检测到与SYSVOL交互的合法流量的数量，这样的攻击方法对于安全防护人员来说无疑是一种挑战。 SYSVOL是指存储域公共文件服务器副本的共享文件夹，它们在域中所有的域控制器之间复制。 Sysvol文件夹是安装AD时创建的，它用来存放GPO、Script等信息。同时，存放在Sysvol文件夹中的信息，会复制到域中所有DC上。

目前通过 GPO 枚举远程访问策略的主要限制有两个:

1. 组织单元和GPO之间的关联是一个简单的关联关系，而不是PowerShell重新实现的策略的结果集 (Resultant Set of Policy, RSoP)，如果能实现RSoP，则允许黑客查看目标用户或计算机应用组策略后产生的效果。因此，就不会考虑到组策略层次结构（例如，一个GPO覆盖另一个GPO的设置）。另外，这还意味着无法机芯有针对性的搜索（例如通过-SearchBase <organisational unit>”）不会捕获在其他组织单元中建立的设置。

2.不会考虑对GPO进行安全性过滤。

尽管存在这些限制，但这种方法确实提供了一种有趣的远程访问策略来快速地对潜在的计算机对象进行攻击。