I am old enough to remember that it was not always possible to get domain admin within the first hour of a test via Active Directory Certificate Services (ADCS) misconfigurations or over permissioned SCCM NAA accounts. At present we are spoilt for choice in regards to privilege escalation vectors within the on-premise AD environment’s, but I wanted to take a look at some of the other misconfigurations that proved to be fruitful before the advent of ADCS and SCCM and continue to land me quick wins on engagements, such as:
我年纪大了，还记得在测试的第一个小时内，通过 Active Directory 证书服务 （ADCS） 错误配置或过度许可的 SCCM NAA 帐户并不总是能够获得域管理员。目前，在本地 AD 环境中，关于权限提升向量，我们有很多选择，但我想看看其他一些错误配置，这些错误配置在 ADCS 和 SCCM 出现之前被证明是卓有成效的，并继续让我在参与中快速获胜，例如：
- Lack of SMB signing 缺少 SMB 签名
- Lack of LDAP signing and/or channel binding
缺少 LDAP 签名和/或通道绑定 - Machine Account Quota > 0
计算机帐户配额 > 0 - NTLM relaying NTLM 中继
The undelaying exploits are not new here, only the old revisited, but just maybe some of the modern techniques for abusing them have slipped your mind in the rush to abuse ESC1. These techniques should be part of your on-premise AD toolkit, so let’s jump into the details.
毫不拖延的漏洞在这里并不新鲜，只是重新审视了旧的漏洞，但也许一些滥用它们的现代技术已经让您在匆忙滥用 ESC1 时忘记了。这些技术应该是您的本地 AD 工具包的一部分，因此让我们深入了解细节。
Below is a diagram of my very basic KENNEDY.local home domain setup consisting of:
下面是我非常基本的 KENNEDY.local 主域设置图，包括：
- 1x Windows Server acting as Domain Controller: KENNEDY-DC (192.168.0.137)
1 个充当域控制器的 Windows Server：KENNEDY-DC （192.168.0.137） - 1x Windows Server acting as Certificate Authority: KENNEDY-CA (192.168.0.84)
1 个充当证书颁发机构的 Windows Server：KENNEDY-CA （192.168.0.84） - 1x Windows 10 Workstation: ELISH (192.168.0.99)
1 个 Windows 10 工作站：ELISH （192.168.0.99） - 1x Kali VM acting as Attacker (192.168.0.203)
1 个 Kali VM 充当攻击者 （192.168.0.203）
The users will be: 用户将是：
- jkennedy (standard domain user)
jkennedy（标准域用户） - ekennedy (administrative user)
Ekennedy（管理用户）
Lack of SMB Signing 缺少 SMB 签名
Nothing illustrates the power of the SMB signing vulnerability quite like LNK files placed on shares. My favourite tool for demonstrating this, is the ‘slinky’ module on ‘nxc’.
没有什么比共享上的 LNK 文件更能说明 SMB 签名漏洞的威力了。我最喜欢的演示工具是 ‘nxc‘ 上的 ‘slinky’ 模块。
You can build up a list of all the machines with SMB signing as ‘false’ with the following command:
您可以使用以下命令构建 SMB 签名为“false”的所有计算机的列表：
nxc smb targets.txt --gen-relay-list nosigning.txtBut in my small lab I can just manually check the machines like so:
但在我的小实验室中，我可以像这样手动检查机器：
We can see above that the ELISH machine has no signing so it won’t be able to identify for sure who is authenticating to it over the SMB protocol.
我们可以在上面看到，ELISH 机器没有签名，因此它无法确定谁在 SMB 协议上对它进行身份验证。
With that in mind we first use nxc to analyse the KENNEDY-CA machine to see if we have any available writable directories for us to place our LNK file and it identifies the ‘share’ directory:
考虑到这一点，我们首先使用 nxc 来分析 KENNEDY-CA 机器，看看我们是否有任何可用的可写目录供我们放置 LNK 文件，它识别了 ‘share’ 目录：
We then use slinky to create a LNK file on this share which points back to our Kali VM 192.168.0.203. Now when anyone enters that share via file explorer (not command line) and without even clicking it the LNK file will be triggered and their authentication will be sent back to the attackers Kali machine.
然后，我们使用 slinky 在此共享上创建一个 LNK 文件，该文件指向我们的 Kali VM 192.168.0.203。现在，当任何人通过文件资源管理器（不是命令行）进入该共享时，甚至无需单击它，就会触发 LNK 文件，并且他们的身份验证将被发送回攻击者的 Kali 机器。
Back at the attackers Kali machine we set up a ntlmrelayx listener for any authentications coming in and, if any are received, we target the 192.168.0.99 machine where we know signing is disabled. At that point ntlmrelayx can automatically open a socks connection with that machine as the user who entered the share using their authentication. We are essentially carrying out a man in the middle attack.
回到攻击者的 Kali 计算机，我们为传入的任何身份验证设置了一个 ntlmrelayx 侦听器，如果收到任何身份验证，我们将目标对准我们知道签名已禁用的 192.168.0.99 计算机。此时，ntlmrelayx 可以自动打开与该计算机的 socks 连接，作为使用其身份验证进入共享的用户。我们本质上是在进行中间人攻击。
When the authentication comes in after ‘ekennedy’ enters the share, we get a hit, and a socks connection is opened with the 192.168.0.99 machine that has no signing as shown:
当身份验证在 ‘ekennedy’ 进入共享后传入时，我们得到一个命中，并且使用没有签名的 192.168.0.99 计算机打开 socks 连接，如下所示：
A persistent socks connection is then maintained within ntlmrelayx which is visible when you enter the ‘socks’ command as shown:
然后，在 ntlmrelayx 中维护一个持久的 socks 连接，当您输入“socks”命令时，可以看到该连接，如下所示：
We can then edit our proxychains configuration file to allow us to access this socks connection to the remote machine, which uses port 1080 by default:
然后，我们可以编辑我们的 proxychains 配置文件，以允许我们访问这个到远程机器的 socks 连接，默认情况下使用端口 1080：
In ‘/etc/proxychains4.conf’ add the line “socks4 127.0.0.1 1080”
在 ‘/etc/proxychains4.conf’ 中添加一行 “socks4 127.0.0.1 1080”
Now using proxychains we can dump the sam data given that the ‘ekennedy’ authentication was of an Administrator. It should be noted we don’t need a password at this point using nxc, given we are using a live socks tunnel which has already been authenticated over NTLM.
现在使用 proxychains，我们可以转储 sam 数据，因为 ‘ekennedy’ 身份验证是 Administrator 的。应该注意的是，此时使用 nxc 时我们不需要密码，因为我们使用的是已经通过 NTLM 进行身份验证的 live socks 隧道。
Taking complete control of this machine is now trivial with the hashes received. In the above scenario, ntlmrelayx was used to relay the ‘ekennedy’ admin authentication to just 1 machine but in practice it could relay it to 50 machines with SMB signing off, therefore opening up 50 admin socks connections to pick and choose from.
现在，对于收到的哈希值，完全控制这台机器是微不足道的。在上述场景中，ntlmrelayx 用于将“ekennedy”管理员身份验证中继到仅 1 台计算机，但实际上，它可以将其中继到 50 台计算机，并关闭 SMB 签名，从而打开 50 个管理员袜子连接以供挑选。
This most certainly has happened to me on a real test.
这肯定发生在我身上的真实测试中。
Next up are 2 techniques that rely less on luck, especially if you are impatient waiting for someone to trigger a LNK file.
接下来是 2 种不太依赖运气的技术，特别是当您不耐烦等待某人触发 LNK 文件时。
LDAP Signing – RBCD LDAP 签名 – RBCD
Similar to SMB signing, LDAP signing – or the lack there of – allows attackers to send HTTP authentication to the LDAP service available on a Domain Controller (DC) but, because signing is disabled, the DC is unable to verify that the authentication coming in is from the actual machine that sent it. This, once again, opens up the possibility of MiTM attacks.
与 SMB 签名类似，LDAP 签名（或缺少 LDAP 签名）允许攻击者将 HTTP 身份验证发送到域控制器 （DC） 上可用的 LDAP 服务，但由于签名被禁用，DC 无法验证传入的身份验证是否来自发送身份验证的实际计算机。这再次开启了 MiTM 攻击的可能性。
First we check the ‘KENNEDY-DC’ machine to see if LDAP signing or channel binding is enforced, which it isn’t.
首先，我们检查 ‘KENNEDY-DC’ 机器，看看是否强制执行了 LDAP 签名或通道绑定，但实际上没有。
We then search for a machine that has a WebClient running on the network using nxc’s ‘webdav’ module as shown below, and we can see that the ‘KENNEDY-CA’ machine has it enabled. Why are we interested in webdav? Well, we can coerce the WebClient service to authenticate back to us over HTTP:
然后，我们使用 nxc 的 ‘webdav’ 模块搜索在网络上运行 WebClient 的机器，如下所示，我们可以看到 ‘KENNEDY-CA’ 机器启用了它。为什么我们对 webdav 感兴趣？好吧，我们可以强制 WebClient 服务通过 HTTP 向我们进行身份验证：
From our attacker’s Kali machine, we now launch ntlmrelayx to target LDAPS of ‘KENNEDY-DC’ and when doing so to use the the ‘delegate access’ flag to launch a RBCD attack on that machine.
现在，我们从攻击者的 Kali 机器上启动 ntlmrelayx 来瞄准“KENNEDY-DC”的 LDAPS，并在这样做时使用“delegate access”标志在该机器上发起 RBCD 攻击。
In simple terms what delegate access does is create a new machine on the network and gives the new machine permissions over the machine whose authentication we have passed to the DC. These permissions allow us, as the attacker, to impersonate anyone else on the machine (e.g. an administrator).
简单来说，委托访问的作用是在网络上创建新计算机，并授予新计算机对我们已将其身份验证传递给 DC 的计算机的权限。这些权限允许我们作为攻击者冒充计算机上的任何其他人（例如管理员）。
To now force the WebClient to authenticate to ntlmrelayx, we first launch Responder. Ensure its HTTP and SMB servers are turned off, as we don’t want to catch the authentication with this tool but instead using ntlmrelayx.
现在，要强制 WebClient 向 ntlmrelayx 进行身份验证，我们首先启动 Responder。确保其 HTTP 和 SMB 服务器已关闭，因为我们不想使用此工具捕获身份验证，而是使用 ntlmrelayx。
The only reason we use Responder is to provide us with a ‘Machine Name’ on the network that we can use to advertise itself and receive authentications into our Kali machine. This machine name can be seen below:
我们使用 Responder 的唯一原因是在网络上为我们提供一个“机器名称”，我们可以使用它来通告自身并将身份验证接收到我们的 Kali 机器中。此机器名称如下所示：
We now coerce the ‘KENNEDY-CA’ (192.168.0.84) machine to authenticate to our attacker Kali Responder machine over HTTP, then relay that authentication to ‘KENNEDY-DC’, which will be unable to verify who is authenticating to it. The call back to our Responder machine instead hits our ntlmrelayx server, listening on port 80:
我们现在强制“KENNEDY-CA”（192.168.0.84）计算机通过 HTTP 向攻击者 Kali Responder 计算机进行身份验证，然后将该身份验证中继到“KENNEDY-DC”，后者将无法验证谁在对其进行身份验证。对响应方计算机的回调会命中我们的 ntlmrelayx 服务器，侦听端口 80：
After executing that command, ntlmrelayx forwards the authentication to ‘KENNEDY-DC’ with LDAP signing disabled, and we receive a new machine on the network with a random name, called ‘KQCLXPVT$’. This new machine will also present added information required to impersonate users on the ‘KENNEDY-CA’ server.
执行该命令后，ntlmrelayx 将身份验证转发到禁用 LDAP 签名的“KENNEDY-DC”，我们在网络上收到一台具有随机名称的新计算机，称为“KQCLXPVT$”。这台新计算机还将提供在“KENNEDY-CA”服务器上模拟用户所需的附加信息。
This new machine can now be seen in Active Directory as shown:
现在可以在 Active Directory 中看到这台新计算机，如下所示：
Using the module named ‘group-mem’ that I wrote for nxc we can now see who we would like to impersonate by looking up the privileged ‘Domain Admins’ members:
使用我为 nxc 编写的名为 ‘group-mem’ 的模块，我们现在可以通过查找特权 ‘Domain Admins’ 成员来了解我们想要模拟的人：
After choosing ‘ekennedy’ we can now impersonate them by using our new machine account username and password via the getST.py command from impacket.
选择 ‘ekennedy’ 后，我们现在可以通过 impacket 中的 getST.py 命令使用我们的新机器帐户用户名和密码来模拟他们。
This will provide us an ‘ekennedy’ service ticket (a.k.a. silver ticket) for the cifs service on that specific machine, which can’t be used elsewhere.
这将为我们提供该特定计算机上的 cifs 服务的 ‘ekennedy’ 服务票证（也称为 silver 票证），该票证不能在其他地方使用。
We can import this into our Kali memory as so:
我们可以将其导入到我们的 Kali 内存中，如下所示：
We can then use this ticket in various tools by specifying the ‘-k’ flag on the command line, so it will grab the ticket directly from that KRB5CCNAME variable we set.
然后，我们可以通过在命令行上指定 ‘-k’ 标志在各种工具中使用此票据，这样它就可以直接从我们设置的 KRB5CCNAME 变量中获取票据。
Here I use secretsdump to now dump the hashes from the machines memory which, like passwords, we can use to access the machine as an Administrator, for example:
在这里，我使用 secretsdump 现在从机器内存中转储哈希值，就像密码一样，我们可以用它来以管理员身份访问机器，例如：
LDAP Signing – Shadow Credentials
LDAP 签名 – 影子凭证
This technique is very very similar to the previous one so I will cover it in less detail. The key benefit to using this one is that it isn’t reliant on creating a new machine on the network, which can be useful when some organisations have the ‘Machine Account Quota’ set to zero. Remember that, by default, regular AD users are allowed to add 10, which is crazy!
这种技术与前一种技术非常相似，因此我将不详细地介绍它。使用此功能的主要好处是它不依赖于在网络上创建新计算机，当某些组织将“计算机帐户配额”设置为零时，这可能很有用。请记住，默认情况下，普通 AD 用户被允许添加 10 个，这太疯狂了！
This technique allows an attacker to take over an AD computer account if we can modify the computer’s attribute ‘msDS-KeyCredentialLink’ and append it with alternate credentials in the form of a certificate which we have control over. This certificate will then allow us to have control over that machine.
如果我们可以修改计算机的属性“msDS-KeyCredentialLink”，并以我们可以控制的证书形式为其附加备用凭据，则此技术允许攻击者接管 AD 计算机帐户。然后，此证书将允许我们控制该计算机。
So once again we set up our trusty ntlmrelayx to target ‘KENNEDY-DC’ with no LDAP signing in place but specifying two different flags. They are shadow credentials to tell it what attack we are doing, then a shadow-target to specify the machine we are targeting. The machine we are targeting in this case is again the ‘KENNEDY-CA’ machine with the WebClient running, so we can coerce it towards us as shown previously.
因此，我们再次将可靠的 ntlmrelayx 设置为以“KENNEDY-DC”为目标，没有 LDAP 签名，但指定了两个不同的标志。它们是影子凭证，用于告诉它我们正在进行什么攻击，然后是用于指定我们目标的计算机的影子目标。在本例中，我们针对的计算机再次是运行 WebClient 的 ‘KENNEDY-CA’ 计算机，因此我们可以像前面所示将其强制向我们移动。
We again use Responder to provide a machine name and PetitPotam to carry out the coercion back to us as shown:
我们再次使用 Responder 提供机器名称，并使用 PetitPotam 执行强制转换，如下所示：
Once again ntlmrelayx gets a hit but this time instead of being able to impersonate anybody else on the victim machine we receive a certificate for the machine account.
ntlmrelayx 再次受到攻击，但这一次，我们不是能够模拟受害者计算机上的任何其他人，而是收到计算机帐户的证书。
Quite handily above, ntlmrelayx provides the command to use next with the tool gettgtpkinit.py to convert the certificate into a TGT (Ticket Granting Ticket) for the machine. A TGT is just as good as a username and password in the Kerberos world so we can use that to act as the machine we are attacking.
在上面非常方便的情况下，ntlmrelayx 提供了 next 与工具一起使用的命令 gettgtpkinit.py 将证书转换为计算机的 TGT（票证授予票证）。在 Kerberos 世界中，TGT 与用户名和密码一样好，因此我们可以使用它来充当我们正在攻击的机器。
After running that command the TGT is saved to file:
运行该命令后，TGT 将保存到文件中：
Once again we import it into our variable to be used by our tools:
我们再次将其导入到我们的变量中，以供我们的工具使用：
Then once again run secretsdump with the ‘-k’ flag to use the TGT to dump all the hashes of the machine, allowing us a complete takeover.
然后再次运行带有 ‘-k’ 标志的 secretsdump 以使用 TGT 转储机器的所有哈希值，从而允许我们完全接管。
Well, that completes my little foray into some of the older adversary techniques that have helped me compromise countless Active Directory environments. Whilst older, these are still very real-world and usable attack paths so hopefully this provides the testers out there with some added insights and the defenders with some visibility over attack paths adversaries may take in their Active Directory domains.
好了，我对一些较旧的对手技术进行了小小的尝试，这些技术帮助我破坏了无数的 Active Directory 环境。虽然较旧，但这些仍然是非常真实且可用的攻击路径，因此希望这能为测试人员提供一些额外的见解，并使防御者对攻击者在其 Active Directory 域中可能采用的攻击路径有一定的了解。
Some remediation steps that you can take to hinder these attacks in your domain are:
您可以采取一些补救措施来阻止域中的这些攻击，包括：
- Enabling SMB signing 启用 SMB 签名
- Enabling LDAP signing 启用 LDAP 签名
- Set the ‘Machine Account Quota’ to zero
将 ‘Machine Account Quota’ （计算机帐户配额） 设置为零 - Try to move away from NTLM to Kerberos
尝试从 NTLM 迁移到 Kerberos
Until next time. 下次再见。
原文始发于JUMPSEC LABS：NTLM Relaying – Making the Old New Again
相关文章
