当试图保持隐蔽作为模拟攻击的一部分时,通常有用的是在尝试之前枚举将影响操作结果的策略。部分是为了避免在无法获得的攻击路径上浪费时间,部分是为了最大限度地降低检测风险。
这样的一个这样的示例是获得本地管理员密码哈希或纯文本凭证,并且希望使用它们来在环境中的其他地方进行认证。Windows中影响此类操作结果的两个值得注意的远程访问策略是用户帐户控制(UAC)和用户权限分配(URA)。取决于它们的配置,这些中的每一个都可能导致不能执行横向移动,这反过来可能产生导致检测可能性增加的假象。
这样的远程访问策略可以在本地(例如,作为黄金图像的一部分)或远程(例如,通过Active Directory中的组策略)实施。这篇文章将在后一个领域提供两个贡献:
- 它将为如何枚举特定策略设置的组策略提供参考,然后将这些策略设置与可以强制实施的计算机对象相关联。使用远程访问策略的用例。
- 它将引入一些概念验证PowerView扩展来实现这些活动。
对于红队而言,这篇文章将提供一些操作安全性考虑因素,并为您提供一些工具以帮助进行有针对性的横向移动。对于蓝队而言,这将为您的剧本提供针对攻击者行业的指导,以及为您的威胁搜寻团队生成妥协指标的新材料。如果您想跳到Github上提供的代码(https://github.com/mwrlabs/gists/blob/master/PowerView-with-RemoteAccessPolicyEnumeration.ps1)。或者,请继续阅读有关UAC和URA的入门知识,以及有关如何滥用组策略将其设置映射到特定计算机对象的详细信息。
远程访问策略的用例:用户帐户控制和用户权限分配
本节重点介绍可以通过组策略设置的一些UAC和URA配置选项,以及它们如何影响远程身份验证过程。存储它们的位置以及如何枚举它们将在本文后面进行探讨。
用户帐户控制:LocalAccountTokenFilterPolicy,FilterAdministratorToken和... EnableLUA?
UAC的目的是提供一种隔离进程的方法,使它们能够以不同的完整性级别(或可信度级别)运行。影响UAC行为的设置将作为注册表项属性存储在HKEY_LOCAL_MACHINE注册表配置单元中的以下位置:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
在远程身份验证期间,有三个值得注意的属性会影响UAC行为。这些设置中的每一个都确定本地管理员组内的用户如何过滤访问权限以进行远程连接。实际上,它控制是否可以执行远程验证并获得高完整性访问令牌,或者是否将其过滤到较低的完整性级别。从安全评估的角度来看,需要高完整性访问令牌来建立远程管理访问权限。
- EnableLUA - 用于为计算机启用(1,默认值)或禁用(0)“管理员批准”模式。在安全文献中很少提到这种设置的效果; 但是,它是UAC运作的一部分。如果禁用,则还会禁用所有UAC策略。禁用时,可以使用纯文本凭据或密码哈希对本地管理员组的任何成员执行特权远程身份验证。在远程身份验证期间,本地管理员的所有访问令牌都设置为高完整性。启用后,特权远程验证功能由LocalAccountTokenFilterPolicy和FilterAdministratorToken的设置决定。
- LocalAccountTokenFilterPolicy - 用于控制过滤本地管理员组内所有本地用户的远程连接访问令牌的策略。设置为0(默认值)时,只能使用RID 500本地管理员的明文凭证或密码哈希来进行具有高完整性访问令牌的远程连接(并且只能根据FilterAdministratorToken的设置)。对于非RID 500本地管理员,过滤用于远程连接的令牌(即,中等完整性)。如果设置为1,则策略允许使用其明文凭据或密码哈希值从本地管理员组的任何成员进行具有高完整性访问令牌的远程连接。Will Schroeder(@ harmj0y)在他的博客文章中提供了有关LocalAccountTokenFilterPolicy角色的更多详细信息这澄清了KB2871997对传递哈希(或缺少哈希)的影响。请注意,即使LocalAccountTokenFilterPolicy设置为0,如果禁用EnableLUA(0),EnableLUA优先,因为没有强制UAC提供过滤。
- FilterAdministratorToken - 用于为RID 500本地管理员启用(1)或禁用(0,默认值)“管理员批准”模式。启用后,将过滤RID 500本地管理员的访问令牌(即中等完整性),因此,无法使用明文凭据或密码哈希值使用RID 500本地管理员执行特权远程身份验证。在标准Windows版本中,LocalAccountTokenFilterPolicy和FilterAdministratorToken的默认设置解释了为什么只能使用RID 500本地管理员帐户执行特权远程验证。虽然默认情况下禁用此功能,但可能出现的一个示例情况是通过黄金映像启用FilterAdministratorToken,然后通过特定计算机对象的组策略选择性地禁用。
虽然这三个注册表项属性都位于Windows注册表中的同一位置,但它们通过组策略配置的方式以及它们在组策略配置文件中的存储方式有所不同。理解这一点对于理解如何枚举它们是不可或缺的。
配置EnableLUA和FilterAdministratorToken
EnableLUA和FilterAdministratorToken都在组策略管理编辑器中具有显式配置选项。对于EnableLUA,这是“用户帐户控制:以管理员批准模式运行所有管理员”和“FilterAdministratorToken”用户帐户控制:内置管理员帐户的管理员批准模式“。这些设置可在以下位置找到:
-> Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> “User Account Control: Admin Approval Mode for the built-in Administrator account” -> “User Account Control: Run all administrators in Admin Approval Mode”
“安全选项”设置存储在INF配置文件中,名称为“gpttmpl.inf”,位于由每个域控制器托管的SYSVOL共享上的相关组策略容器中。
\\<Domain>\Policies\{<GUID>}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf
下图显示禁用“EnableLUA”的情况。
配置LocalAccountTokenFilterPolicy
无法通过组策略管理编辑器中的显式配置选项设置LocalAccountTokenFilterPolicy。相反,它需要通过自定义注册表项属性的定义进行设置。在组策略管理编辑器中,可以在以下位置完成此操作:
-> Computer Configuration -> Preferences -> Windows Settings -> Registry -> <Custom Key and Property Definition>
其结果是配置存储在组策略容器内的不同位置。这次是一个名为Registry.xml的XML文档。
\\<Domain>\SYSVOL\<Domain>\Policies\{<GUID>}\Machine\Preferences\Registry\Registry.xml
下图显示了一个示例Registry.xml配置,其中启用了LocalAccountTokenFilterPolicy(1)。
用户权利分配:SeDeny *?
URA的目的是规定用户可以对系统进行身份验证的方式,同时还提供授予该用户某些权限的进一步方法。影响URA行为的设置无法在Windows注册表中查询。
有两个值得注意的URA设置会影响远程身份验证。其中每个都以SeDeny *前缀开头,可以通过组策略进行配置。
- SeDenyNetworkLogonRight - 用于拒绝某些用户或组执行网络身份验证的能力,例如,远程进程调用(RPC)端点映射器和服务器消息块(SMB)服务使用该身份验证。
- SeDenyRemoteInteractiveLogonRight - 用于拒绝某些用户或组执行远程桌面协议(RDP)服务使用的远程交互式身份验证的能力。
如果用户或组与这些设置中的任何一个相关联,则无法通过相关协议进行横向移动所需的身份验证。也就是说,通过将它们与设置(或右)相关联,它们被拒绝执行某些类型的认证。
防止滥用本地凭据材料的一种方法是将内置的“管理员”组与这些设置相关联。这确实具有次要影响,这通常被误解,值得一提。即,这会影响该组中的所有对象,包括域用户和已包含在其中的组。例如,由于“域管理员”组默认位于域加入的计算机对象上的内置“管理员”组中,因此无法使用这些帐户对相关协议进行身份验证,尽管它们具有特权性质更广泛的领域。
除了上述URA设置之外,还应注意,存在类似的SeDeny *设置,用于拒绝用户或组执行本地身份验证,身份验证作为服务以及身份验证作为批处理作业的能力。
配置SeDenyNetworkLogonRight和SeDenyRemoteInteractiveLogonRight
SeDenyNetworkLogonRight和SeDenyRemoteInteractiveLogonRight在组策略管理编辑器中具有显式配置选项。对于SeDenyNetworkLogonRight,这是“拒绝从网络访问此计算机”和SeDenyRemoteInteractiveLogonRight“拒绝通过远程桌面服务登录”。这些设置可在以下位置找到:
-> Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> “Deny access to this computer from the network” -> “Deny log on through Remote Desktop Services”
“用户权限分配”设置存储在与使用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(https://github.com/mwrlabs/gists/blob/master/PowerView-with-RemoteAccessPolicyEnumeration.ps1)将在下面简要介绍。
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执行类似的操作,但返回包含每个注册表修改的PSObject列表。
以下代码段显示了Get-DomainGPORemoteAccessPolicy执行上述操作的功能的子集; 即,通过将EnableLUA属性设置为0来检索每个GPO并检查它是否禁用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函数返回的对象包含描述链接GPO的“gplink”属性。
Find-ComputersWithRemoteAccessPolicies的代码片段如下所示,它执行上述过程。设置远程访问策略的计算机对象将添加到哈希表中,其中键是策略,值是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设置中,这些主机使用网络身份验证防止横向移动(例如,根据需要)与psexec)。这也可以防止使用RID 500“管理员”帐户进行横向移动。对于剩余的计算机对象(“DEV-COMPUTER-1”),通过重用任何本地管理凭证(RID 500和非RID 500)的横向移动仍然是可能的。对于所有计算机对象,如果可以获得内置“管理员”组中的用户的明文凭证,则这些凭证可以用于远程交互式认证(例如,RDP)。这是因为未通过SeDenyRemoteInteractiveLogonRight明确禁止此类身份验证。这些攻击路径的流程图可视化如下所示。
结论
这篇文章旨在描述为特定策略设置枚举组策略以及确定它们可能适用的计算机对象的过程。用例是远程访问策略之一。特别地,用于确定由于用于远程认证的UAC和URA设置而可以重用本地凭证材料的计算机对象。还生成了一组PowerView扩展以启用此类活动,这些活动已在MWR Labs Github上提供(https://github.com/mwrlabs/gists/blob/master/PowerView-with-RemoteAccessPolicyEnumeration.ps1)。
虽然远程访问策略是本文的核心焦点,但它提供了如何将相同方法应用于任何其他策略设置的简单说明。例如,如果通过组策略强制执行设置,攻击者可以使用此功能来识别正在运行(或在某些情况下可能未运行)某个软件的计算机对象。由于与SYSVOL交互的合法流量的数量,这种方法对于蓝色团队来说也是一个挑战。
当前实施有两个主要限制,未来工作机会如下:
- 组织单位和GPO之间的关联是一种简单的关联关系,而不是PowerShell重新实现策略的结果集(RSoP); 因此,它不考虑组策略层次结构(例如,一个GPO覆盖另一个GPO的设置)。这进一步暗示了有针对性的搜索(例如,通过“-SearchBase <组织单位>”)将不会捕获在其他组织单位中建立的设置。
- 它也不考虑GPO上的安全过滤,GPO用于将GPO配置为仅应用于应用它的组织单位内的对象子集。
尽管有这些限制,该方法确实提供了一种快速分类潜在计算机对象的方法,其具有用于横向移动的有趣的远程访问策略
本文作者为Mr.Bai,转载请注明。