0x00 前言
早在2018年3月前，我就开始了一场毫无意义的争论，以证明TrustedToAuthForDelegation属性是无意义的，并且可以在没有该属性的情况下实现“协议转换”。我相信，只要一旦启用约束委派（msDS-AllowedToDelegateTo不为空），它是否配置为使用“仅Kerberos”或“任何身份验证协议”并起作用。
我在Benjamin Delpy（@gentilkiwi）的帮助下开始了这段研究过程，他帮助修改了kekekeo以支持一种特定的攻击，这种攻击涉及在没有PAC的情况下使用白银票据调用s4u2proxy，我们取得了部分成功，但最终的TGS却无法使用。从那时起，我就一直研究这个问题，试图用不同的方法来解决这个问题，但没有取得多大的成功。直到我最终接受了失败，具有讽刺意味的是，随后解决方案出现了，以及其他一些有趣的利用案例和新的攻击技术。
0x01 TL; DR
这篇文章篇幅很长，我很清楚很多人没有时间或毅力来阅读它，所以我将在下午中列出本文的重要点：
- 在调用S4U2Proxy时，基于资源的约束委派不需要可转发的TGS。
- 无论TrustedToAuthForDelegation属性的状态如何，S4U2Self都可以在任何具有SPN的帐户上运行。如果设置了TrustedToAuthForDelegation，则S4U2Self生成的TGS是可转发的，除非它对委派或受保护用户组的成员是信息敏感
- 以上几点意味着，如果攻击者可以控制Active Directory中的计算机对象，则可能会滥用该对象来破坏主机。
- 即使请求中提供的额外TGS不可转发，S4U2Proxy也能生成可转发的TGS。
- 以上几点意味着，如果攻击者利用SPN以及具有传统约束委派的账号来攻击其他任何账号，那么是否设置了TrustedToAuthForDelegation属性并不重要。
- 默认情况下，任何域用户都可以滥用MachineAccountQuota来创建一个计算机帐户并为其设置一个SPN，这使得滥用基于资源的约束委派模拟协议转换变得更为简单（为任意用户获取一个可转发的TGS到一个被破坏的服务）。
- S4U2Self允许为任意用户生成有效的TGS，包括那些标记为对委派敏感的用户或受保护用户组的成员。生成的TGS具有一个带有效KDC签名的PAC。所需要的只是计算机帐户凭据或TGT。
- 上述点与无约束委派和“打印错误”相结合可能导致远程代码执行（RCE）。
- krbtgt帐户上基于资源的约束委派允许为任意用户生成TGT，并且可以作为持久性技术恶意利用。
- 通过基于资源的受限委派的从HTTP到LDAP的NTLM中继配置可能有助于MSSQL服务器上的远程代码执行（RCE）或本地权限提升（LPE），Windows 10/2016/2019上的本地权限提升（LPE）。
- 计算机帐户变得更有趣。开始寻找更多利用点来触发攻击链
0x02 Kerberos委派101
如果您没有跟上滥用kerberos委派授权的分析进度，您应该先阅读will schroeder（@harmj0y）和lee christensen（@tifkin_uuu）的文章S4U2Pwnage。在那篇文章中，他们比我更好地阐述了它，但我也会尽量简洁概述它
首先，简要概述Kerberos：
- 当用户登录时，他们使用从其密码生成的加密密钥对一条信息（时间戳）进行加密，以向验证服务器证明他们知道密码。此步骤称为“预身份验证”。
- 在Active Directory环境中，身份验证服务器是域控制器。
- 预身份验证成功后，身份验证服务器将向用户提供一个有效期有限的票据授予票据（TGT）
- 当用户希望对某个服务进行身份验证时，用户将TGT发送给身份验证服务器。如果TGT有效，用户将从身份验证服务器接收一个票据授予服务（TGS），也称为“服务票据”。
- 然后，用户可以将TGS发送给他们想要访问的服务，服务可以对用户进行身份验证，并根据TGS中包含的数据做出授权决策。
关于Kerberos票据的一些重要说明：
- 每张票都有明文部分和一个加密部分
- 票据的明文部分包含票据所针对的服务的服务主体名称（SPN）
- 用于票据的加密部分的加密密钥是从目标服务的帐户的密码导出的
- TGT是为内置帐户“krbtgt”加密
- TGT上的SPN是krbtgt/domain
通常，服务需要模拟用户来访问另一个服务。为了便于实现这一点，在Kerberos协议中引入了以下委派特性：
- 无约束委派（TrustedForDelegation）：用户发送一个TGS来访问服务，连同他们的TGT，然后服务可以使用用户的TGT为用户向任何其他服务请求TGS并模拟用户
- 约束委派（S4U2Proxy）：用户发送一个TGS来访问该服务（“服务A”），如果允许该服务委派给另一个预定义的服务（“服务B”），那么服务A可以向认证服务提供用户提供的TGS，并为用户获得一个TGS到服务B。请注意，TGS提供了在s4u2proxy请求中，必须设置Forwardable标志。对于配置为“对委派敏感”（用户没有对委派属性设置为true）的帐户或受保护用户组的成员，从不设置为“可转发”标志。
- 协议转换（S4U2Self / TrustedToAuthForDelegation）：s4u2proxy要求服务在身份验证服务为用户生成一个TGS到另一个服务之前，为用户提供一个TGS。它通常被称为“附加票据”，但我喜欢将其称为用户确实已对调用S4U2Proxy的服务进行身份验证的“证据”。但是，有时用户通过其他协议（如NTLM或甚至基于表单的身份验证）对服务进行身份验证，因此他们不会向服务发送TGS。在这种情况下，服务可以调用s4u2self请求认证服务为任意用户生成一个TGS，然后在调用s4u2proxy时将其用作“证据”。此特性允许模拟用户，并且仅当为调用s4u2self的服务帐户设置TrustedToAuthForDelegation标志时才有可能有效。
0x03 其他受限制的委派
早在2018年10月前，我与Will Schroeder（@ harmj0y）合作，将为基于资源的约束委派的滥用提供了基于ACL的计算机标识的基础论证。威尔写了一篇关于这个主题的优秀文章，在继续之前你也应该阅读它。再一次，在那篇文章中，Will比我更好地阐述了它，但我会在这里非常简洁地概述它。
为了配置约束委派，必须具有SeEnableDelegation权限，该权限是敏感的，通常仅授予Domain Admins。为了使用户/资源更加独立，在Windows Server 2012中引入了基于资源的约束委派。基于资源的约束委派允许资源配置哪些帐户可信任委派给他们。
这种约束委派的风格与传统约束委派非常相似，但配置相反。从帐户A到帐户B的传统约束委派在msDS-AllowedToDelegateTo属性中的帐户A上配置，并定义从A到B的“传出”信任，而在msDS-AllowedToActOnBehalfOfOtherIdentity属性中的帐户B上配置基于资源的约束委派，并定义从A到B的“传入”信任。
一个重要的点是，每个资源都可以为自己配置基于资源的约束委派。在我看来，让资源自行决定谁是他们信任的是有意义的
Will和我想出了以下滥用案例来破坏特定的主机：
- 攻击者破坏设置了TrustedToAuthForDelegation标志（“服务A”）的帐户
- 攻击者还利用为目标主机（“服务B”）的计算机帐户配置基于资源的约束委派的权限来攻击帐户。
- 攻击者配置从服务A到服务B的基于资源的约束委派。
- 攻击者调用s4u2self和s4u2proxy作为服务A，以获取特权用户对服务B的TGS，以破坏目标主机。
下图说明了此滥用案例：
这是一个很好的技巧，但使用TrustedToAuthForDelegation标志设置来破坏帐户并非一件易事。如果我的研究TrustedToAuthForDelegation取得更大的成效的话，那么对于这种滥用案例它会派上用场。
0x04 滥用案例：Skipping S4U2Self
为了使用上面的基于ACL的计算机标识的原始论证，我稍微修改了Rubeus以允许攻击者在调用S4U2Proxy时为受害者提供“证据”TGS而跳过S4U2Self。Benjamin Delpy也于2018年4月对Kekeo进行了修改 ; 但是，在编写本文时，Kekeo不支持基于资源的约束委派。
更通用的滥用案例将按如下方式：
- 攻击者破坏服务A和DACL，并在服务B上配置基于资源的约束委派。
- 通过社会工程或水坑攻击，受害者向服务A进行身份验证以访问服务（例如CIFS或HTTP）
- 攻击者使用mimikatz sekurlsa:：tickets或其他方法将受害者的TGS转储到服务A
- 攻击者配置从服务A到服务B的基于资源的约束委派。
- 攻击者使用Rubeus执行S4U2Proxy，之前获得的TGS是受害者从服务A到服务B所需的“证据”。
- 攻击者可以通过票据并冒充受害者访问服务B.
下图说明了这种情况：
此场景的视频演示：(https://youtu.be/7odfALcmldo)
S4U2Proxy具有先前获得的TGS:
请注意，S4U2Proxy响应（到服务B）中生成的TGS似乎设置了FORWARDABLE标志，除非主体被标记为对委派敏感或者是受保护用户组的成员。
0x05 Serendipity（偶然性）
当我是在测试我的rubeus修改时，是为提交请求做准备，我重置了服务A上的trustedtoauthfordelegation useraccountcontrol标志，并希望在执行s4u2self时看到错误消息提示。然而，s4u2和S4U2Proxy都被执行，生成的TGS为我提供了访问服务B的权限。
我从S4U2Self获得的票据是不可转发的，但是，S4U2proxy依然接收了它，对服务B的用户进行了TGS响应
此时，我想知道我是否完全错误配置了我的实验室环境。
此场景的视频演示：(https://youtu.be/IZ6BJpr28r4)
在没有TrustedToAuthForDelegation的情况下为任意帐户获取可转发TGT:
0x05 被误解的特性
1.被误解的特性1
经过几个小时的测试，调试和阅读MS-SFU之后，我意识到对S4U2Self的理解是错误的。不管是否设置了TrustedToAuthForDelegation UserAccountControl标志，s4u2似乎都能正常工作。但是，如果未设置，则根据MS-SFU第3.2.5.1.2节，生成的TGS不可转发：
2.被误解的特性2
那么，S4U2Proxy仍然不应该使用不可转发的票据？
当我尝试使用具有传统（“传出”）约束委派的不可转发TGS调用S4U2Proxy时，它失败了。但是，基于资源的约束委派（“传入”）它始终有效。我认为这一定是一个bug，因此在2018年10月26日，我将它报告给了微软响应中心（MSRC）。
当我不耐烦地等待回复时，我再次阅读了MS-SFU，并找到了第3.2.5.2节
这似乎是一个设计缺陷，用微软的话来说，这也是一个“特性”。基于资源的受限委派的s4u2proxy在设计上提供不可转发的TGS！
请注意，根据上述文档，即使TGS不必为基于资源的约束委派进行转发，如果用户设置为“对委派敏感”，则S4U2Proxy将失败，这是预料的结果。
0x06 通用的DACL滥用
这两个被误解的“特性”意味着对基于ACL的计算机标的原始论证的唯一要求是DACL在计算机对象和另一个帐户上配置是基于资源的约束委派。任何拥有SPN的帐户都可以。即使只是其他帐户的TGT也可以。
需要SPN的原因是S4U2Self似乎不适用于没有SPN的帐户。但是，任何域用户都可以通过滥用MachineAccountQuota（默认设置为10）来获取具有SPN的帐户，并允许创建新的计算机帐户。创建新计算机帐户时，用户可以为其设置一个SPN，或在以后添加一个。Kevin Robertson（@NetSPI）提供了一个名为Powermad的工具，它允许通过LDAP实现这一点。
通用滥用案例的工作原理如下：
- 攻击者破坏具有SPN或创建一个（“服务A”）帐户，并使用DACL在计算机帐户（“服务B”）上配置基于资源的约束委派。
- 攻击者破坏具有SPN的帐户或创建一个（服务A），以配置计算机帐户（“服务B”）上基于资源的约束委派的DACL
- 攻击者配置从服务A到服务B的基于资源的约束委派。
- 攻击者使用rubes为有权访问服务B的用户执行从服务A到服务B的完整S4U攻击（s4u2self和s4u2proxy）。
- 攻击者可以传递票据并模拟用户以获得对服务B的访问权限。
下图说明了这种情况：
此场景的视频演示：(https://youtu.be/ayavtG7J_TQ)
RBCD作为基于ACL的计算机原始的对象接管：
注意，在步骤3中从S4U2Self获得的TGS不可转发，但在调用S4U2Proxy时,它被作为“证据”。
0x07 可转发的结果
当我在S4U2Proxy响应中检查生成的TGS时，它设置了FORWARDABLE标志。我为S4U2Proxy提供了一个不可转发的TGS作为“证据”，并获得了一个可转发的TGS。
这是一个bug还是一个特性？
我回到MS-SFU第3.2.5.2.2节，发现以下内容：
这似乎是另一个很好的特性：S4U2Proxy生产的每个TGS总是可转发的。
0x08 授权Active Directory对象和基于反射资源的约束委派
当Microsoft引入基于资源的约束委派时，它将用户和计算机转换为强大的独立AD对象，这些对象能够为自己配置这个新的“传入”委派。默认情况下，所有资源都有一个访问控制条目（ACE），允许它们为自己配置基于资源的约束委派。但是，如果攻击者拥有该帐户的登录凭据，那么他们可以伪造一张白银票据并获得对它的访问权限
白银票据的问题在于，当伪造时，他们没有具有有效KDC签名的PAC。如果目标主机配置为验证KDC PAC签名，则白银票据将不起作用。可能还有其他安全解决方案可以检测白银票据使用情况。
但是，如果我们拥有计算机帐户或甚至只是TGT的凭据，我们可以将该帐户的基于资源的约束委派配置为自身，然后使用S4U2Self和S4U2Proxy为任意用户获取TGS。
滥用案列的工作原理如下：
- 攻击者会破坏凭据或计算机帐户的TGT（“服务A”）。
- 攻击者将基于资源的约束委派从服务A配置为自身。
- 攻击者使用Rubeus执行完整的S4U攻击，并为有权访问服务A的用户获取TGS。
- 攻击者可以传递票据并模拟用户访问服务A.
下图说明了这种情况：
此场景的视频演示：（https://youtu.be/63RoJrDMUFg）
基于反射资源的约束委派：
事实上，当帐户设置了TrustedToAuthForDelegation标志（也称为“协议转换”）时，这种基于资源的反射约束委派相当于S4U2SELF，因为它允许帐户模拟用户为自己获取可转发的TGS。但是，如果使用“仅Kerberos”的传统约束委派配置了一个帐户（未设置TrustedToAuthForDelegation且msDS-AllowedToDelegateTo不为空），则传统条件优先于基于资源的条件，因此s4u2self使用不可转发的TGS响应和s4u2proxy失败。
请注意，此技术仅允许为用户获取TGS，前提是它未设置为“对委派敏感”，并且不是受保护用户组的成员，如下面的截图所示：
0x08 解决敏感问题
仔细检查上述的输出结果，则表明S4U2SELF适用于标记为对委派敏感的用户和受保护用户组的成员。
仔细检查该票据表明它没有有效的服务名称，并且不可转发：
但这很容易改变，因为服务名称不在票据的加密部分。
攻击者可以使用ASN.1编辑器修改，从S4U2Self获得的TGS上的SPN，并将其转换为有效的SPN。
完成后，攻击者拥有有效的TGS。它不可转发，但可以对服务进行身份验证：
此场景的视频演示：（https://youtu.be/caXFG_vAr-w）
滥用敏感用户的S4U2Self ：
因此，如果攻击者拥有计算机帐户的凭据或TGT，他们可以为任何用户（包括敏感/受保护的用户）获取该计算机的TGS，并在PAC中使用有效的KDC签名
这意味着获得一个计算机帐户的TGT就足以破坏主机。
0x09 无约束委派导致远程命令执行
正如Lee Christensen（@tifkin_）在DerbyCon 8中的“打印机错误”滥用案例中所展示的那样，通过调用RpcRemoteFindFirstPrinterChangeNotification（Opnum 62）方法，通过SMB连接回指定的IP /主机名来欺骗打印机后台处理程序。
如果攻击者以无约束委派方式破坏主机，则“打印机错误”滥用可能导致在Printer Spooler程序运行的任何加入域的Windows主机上导致远程命令执行。
滥用案列的工作原理如下：
- 攻击者以无受约束委派方式来攻击主机并进行权限提升。
- 攻击者运行rubes的monitor/harvest模块。
- 攻击者启动SpoolSample或dementor.py，以控制目标主机的打印机spooler，将其TGT委派给无约束委派的受攻击的主机。
- 攻击者可以使用抓取的TGT为任何用户获取目标主机的TGS，甚至是敏感的委派/受保护的用户。
- 攻击者为具有本地管理员权限的用户获取目标主机的TGS并对其进行攻击。
下图说明了这种情况：
此场景的视频演示：（https://youtu.be/XqxWHy9e_J8）
滥用无约束委托，打印机后台处理程序错误，以及S4U2Self来破坏主机：
正如Will Schroeder（@ harmj0y）在他的博客文章Not A Security Boundary：Breaking Forest Trusts中所阐述的那样，无约束委派的跨森林信任的安全边界，使得这种攻击跨双向森林信任是有效的。
0x10 账户设置 - TrustedToAuthForDelegation
多年来，Active Directory安全专家一直告诉我们，如果我们必须配置Kerberos委派，那么约束委派是可行的方法，我们应该使用“仅Kerberos”而不是“任何身份验证协议”（称为“协议转换”） “）。但也许“仅Kerberos”和“任何身份验证协议”之间的选择实际上并不重要。
我们现在知道，我们可以滥用基于资源约束委派来为任意用户获得可转发的TGS。因此，如果我们有一个具有SPN的帐户和一个具有传统约束委派但没有“协议转换”的帐户的凭据（或TGT），我们可以将这两个“特性”结合起来模拟“协议转换”。
此滥用案例的工作原理如下：
- 攻击者会破坏具有SPN的帐户或创建一个帐户（“服务A”）。
- 攻击者会破坏一个帐户（“服务B”），该帐户是为服务C上某个服务类的传统约束委派而设置的，仅使用Kerberos（TrustedToAuthForDelegation未在服务B上设置，并且服务B上的msds allowedToDelegateto包含服务C上的服务，例如“时间/服务C”）。
- 攻击者将基于资源的约束委派从服务A设置为服务B（将服务B上的msds allowedtoactonbehalf其他标识设置为使用服务B凭据或服务B的tgt包含“服务A”）。
- 攻击者使用服务A凭据和TGT执行完整的S4U2攻击，并获得服务B的受害者的一个可转发TGS。
- 攻击者使用服务B凭证和TGT调用。 S4U2Proxy使用前一步骤中的可转发的TGS，并获得受害者对时间和服务C的TGS。攻击者可以修改生成的TGS的服务类，例如从“时间”改为“cifs”，因为服务名称不受保护。
- 攻击者可以通过票据获得对服务C的访问权限。
下图说明了这种情况：
此场景的视频演示：（https://youtu.be/y37Eo9zHib8）
TrustedToAuthForDelegation Bypass：
0x11无约束域的持久性
一旦攻击者破坏了域，显然可以在策略对象（如域控制器）上配置基于资源的约束委派，并根据需要获得TGS。但是基于资源的约束委派也可以配置为按需生成TGT作为域持久性技术。
一旦域受到破坏，就可以将基于资源的受约束委派从一个受到破坏的帐户配置为krbtgt帐户以生成TGTs
滥用案例的工作原理如下：
- 攻击者会破坏域和具有SPN或创建一个SPN的帐户（“服务A”）
- 攻击者将基于资源的受约束委派从服务A配置为krbtgt
- 攻击者使用Rubeus执行完整的S4U攻击，并为任意用户获取krbtgt的TGS，实际上是一个TGT。
- 攻击者可以使用TGT向任意服务请求TGS。
下图说明了这种情况：
此场景的视频演示：（https://youtu.be/1BU2BflUHxA）
krbtgt帐户上通过RBCD进行域持久化：
在这种情况下，帐户服务A获得了某种程度上类似于KDC的功能，从某种意义上说，它可以为任意用户生成TGT。
可以说，通过新的访问控制（ACE）可以实现更细微的持久性，以允许基于资源的约束委派按需配置。
0x012 攻击方式：RCE / LPE
如上图所示，如果攻击者可以使用无约束委派来破坏主机，则可以使用“打印机错误”和S4U2Self 来实现RCE 。但是无约束委派并不是那么重要的条件，所以我试图想出一个不需要无约束委派的攻击链。
如上所述，每个资源都有权为自己配置基于资源的约束委派，这可以通过LDAP完成。如果攻击者能够成功执行对LDAP的计算机帐户身份验证的NTLM中继，则此论证为RCE/LPE提供了有力的依据。
滥用案例的工作原理如下：
- 攻击者会破坏具有SPN的帐户或创建一个帐户（“服务A”）。
- 攻击者使用诸如“打印机错误”之类等方式来触发计算机帐户身份验证。
- 攻击者在域控制器上对LDAP执行计算机帐户（“服务B”）身份验证的NTLM中继。
- 攻击者配置从服务A到服务B的基于资源的约束委派。
- 攻击者使用Rubeus执行完整的S4U攻击，并为在该主机上具有本地管理员权限的用户获取服务B的TGS。
- 攻击者可以传递票据并获得RCE/ LPE，具体取决于用于触发计算机帐户身份验证。
上面的场景很简单，很好。然而，现实情况是NTLM中继比看起来更复杂，可能有点不现实。
1.NTLM中继101
NetNTLM是一种由Microsoft为Windows环境设计的挑战--响应身份验证协议。在NetNTLM协议中，发送了三条消息：
- 客户端发送协商消息以请求身份验证和“通告功能”。
- 服务器发送包含随机8字节数的质询消息。
- 客户机发送一条包含对挑战的响应的身份验证消息。使用一个加密函数计算响应，加密函数具有从用户密码（NTLM哈希）生成的密钥。
服务器验证对挑战的响应。如果有效，则验证成功。否则，身份验证失败。
该协议容易受到以下中继攻击：
- 处于中间位置的人中的攻击者等待来自受害者的传入协商消息。
- 攻击者将协商消息转发给目标服务器。
- 目标服务器向攻击者发送挑战消息。
- 攻击者将挑战消息转发给受害者。
- 受害者生成有效的身份验证消息并将其发送给攻击者
- 攻击者将有效的身份验证消息转发到目标服务器。
- 目标服务器接受AUTHENTICATE消息，并且攻击者已成功通过身份验证。
下图说明了NTLM中继攻击：
NetNTLM协议不仅提供身份验证，还可以有利于会话密钥交换以进行加密（“密封”）和签名。客户端和服务器通过交换消息中的某些标志协商是否需要加密/签名。交换的会话密钥使用从客户端的NTLM哈希生成的密钥进行RC4加密。客户端显然拥有NTLM哈希并可以对其进行解密。但是，域成员服务器不保留域用户的NTLM哈希值，而只保留本地用户的NTLM哈希值。当域用户与成员服务器交换会话密钥时，成员服务器使用Netlogon RPC协议验证客户端对域控制器的挑战响应，如果交换了会话密钥则由域控制器计算解密密钥并提供给成员服务器。
如果客户端和服务器协商会话密钥以进行签名，则执行中继攻击的攻击者可以成功进行身份验证，但无法获取会话密钥以对后续消息进行签名，除非攻击者可以获取以下其中一项：
- 受害者的NTLM哈希值
- 目标服务器的计算机帐户的凭据
- 破坏域控制器
但是，如果攻击者获得上述任何一项，则他们不需要执行NTLM中继攻击来攻击目标主机或冒充受害者，这就是签名减轻NTLM中继攻击的原因。
2.NTLM中继102
目标是在不协商签名或加密的情况下，从任何协议到LDAP执行成功的中继。
我所知道的从计算机帐户引出连接的大多数都是由smb客户机或rpc客户机启动的，这两个客户机似乎总是协商签名。如果在NTLM交换中协商了签名，则域控制器上的LDAP服务将忽略所有未签名的消息（在Windows Server 2016和Windows Server 2012R2上测试）。
最明显的下一步是对NTLM中继期间协商签名的标志的重置。但是，微软在NTLM协议中引入了一个MIC（我相信是消息完整性代码）来防止这种情况发生。MIC由客户端在身份验证消息中发送，它使用HMAC-MD5和会话密钥保护所有三个NTLM消息的完整性。如果更改了一个NTLM消息，则MIC将无效，身份验证将失败。
并非所有客户端都支持MIC，例如Windows XP / 2003和更早版本，因此并非强制要求。所以尝试的另一件事是在NTLM中继期间忽略MIC。但是，有一个标志表示MIC是否存在，并且该标志是计算NetNTLM对挑战的响应时使用的“salt”的一部分。因此，如果删除MIC并重置相应的标志，则NetNTLM响应将无效，并且身份验证将失败。
3.反射式NTLM中继失效
传统上，计算机帐户的NTLM中继是反射性的，这意味着从某个主机返回到它自身。在MS08-068之前，通常通过从SMB转发到SMB来实现RCE。
在修补之后，反射式跨协议NTLM中继仍然是可能的，并且最常被滥用是在诸如Hot Potato之类的攻击中实现LPE 。反射式跨协议中继在MS16-075中进行了修补，从而永久地终止了反射中继攻击（或直到JamesForshaw将其修复）。 Rotten Potato/Juicy Potato仍然被一直利用，但它是一种不同于反射中继的方式，因为它滥用本地认证，忽略了挑战响应。
在MS16-075之后，许多安全研究人员停止了寻找能够引起计算机帐户身份验证的证据，因为没有存在反射中继的攻击，研究它们就不再有价值。
4.适用于RCE/LPE的可行NTLM中继论证
RCE/LPE论证需要以下之一：
- 不协商签名的客户端，例如所有Windows版本上的Web客户端，包括WebDAV客户端。
- 在NTLM消息中不支持MIC的客户端，例如Windows XP/2003及更早版本。
- 未忽略未签名消息或不验证支持基于资源的受约束委派的域控制器上的MIC的LDAP服务。
触发计算机帐户通过HTTP进行身份验证有不同的论证。其中一些人在Hot Potato中进行滥用。我选择研究那些采用任意UNC路径然后触发WebDAV客户端连接的路径。
请注意，在Windows服务器上，默认情况下不安装WebDAV客户端。在Windows Server 2012R2及更早版本上，需要桌面体验功能，在Windows Server 2016或更高版本中，需要WebDAV重定向器功能。但是，在桌面上，默认情况下会安装WebDAV客户端。
正如我上面提到的，似乎一些研究人员不再关心这些论证了。然而，正如Lee Christensen（@tifkin_）在“打印机错误”和无约束委派的组合演示的那样，也正如我将在下面演示的那样，这些论证仍然可以使用的，我鼓励大家继续研究它们（并在找到它们时告诉我所有相关信息）。
5.获取Intranet-Zoned
默认情况下，Web客户端将仅自动向Intranet区域中的主机进行身份验证，这意味着主机名中不能存在intranet zone。如果中继服务器已经有合适的DNS记录，那么这不是问题。但是，如果中继服务器是“恶意的”，IP地址将不会切断它。为了解决这个问题，可以滥用ADIDNS为中继服务器添加新的DNS记录，正如Kevin Robertson（@NetSPI）在他的博客文章ExploitActive Directory-Integrated DNS中所阐述的那样。
0x13典型案例研究
1.案例研究1：MSSQL RCE/LPE
MSSQL有一个名为xp_dirtree的未记录的存储过程，它列出了所提供路径的文件和文件夹。默认情况下，所有经过身份验证的用户（“公共”）都可以访问此存储过程。
在以下情况下，攻击者可以通过滥用xp_dirtree存储过程来实现RCE/LPE（主要取决于连接性）：
- 攻击者已破坏了允许调用xp_dirtree存储过程的用户。
- MSSQL服务作为网络服务，本地系统或虚拟帐户运行（默认）
- WebDAV客户端已在目标主机上安装并运行。
滥用案例的工作原理如下：
- 攻击者为具有SPN或创建一个SPN（“服务A”）的帐户攻击凭证或TGT，并且允许在目标MSSQL实例上连接并调用xp_dirtree的帐户。
- 如果需要，攻击者使用服务A使用ADIDNS添加DNS记录。
- 攻击者登录到目标主机（“服务B”）上的MSSQL服务，并调用xp_dirtree以触发与恶意WebDAV NTLM中继服务器的连接
- 攻击者将计算机帐户NTLM身份验证中继到域控制器上的LDAP服务，并将基于资源的约束委派从服务A配置到服务B.
- 攻击者使用Rubeus执行完整的S4U攻击，以便为在目标主机上具有本地管理员权限的用户获取服务B的TGS。
- 攻击者可以通过票证来破坏目标主机。
下图说明了这种情况：
此场景的视频演示：（https://youtu.be/nL2oa3URkCs）
MSSQL RCE通过xp_dirtree和NTLM中继来配置RBCD：
Matt Bush（@ 3xocyte）将“ Bad Sequel ”这种情况作为PoC利用：
2.案例研究2：Windows 10/2016/2019 LPE
一个深夜，Matt Bush（@ 3xocyte），Danyal Drew（@danyaldrew）和我一起思考如何找到合适的RCE/LPE论证，并决定研究用户在Windows 10/2016/2019中更改帐户图标时会发生什么。我们使用Process Monitor对其进行了分析，并很快发现在帐户图标更改过程中，以SYSTEM打开图片文件来读取其属性。这是一个小而毫无意义的操作; 不是任意的文件写/读/删除。
滥用案例的工作原理如下：
- 攻击者破坏具有SPN的帐户的凭据或TGT或创建一个帐户（“服务A”）
- 攻击者通过安装了WebDAV重定向器功能（“服务B”）获得对运行Windows 10或Windows Server 2016/2019的另一台计算机的非特权访问。
- 如果需要，攻击者使用服务A使用ADIDNS添加DNS记录。
- 攻击者将帐户配置文件图标更改为恶意WebDAV NTLM中继服务器上的路径。
- 攻击者将计算机帐户NTLM身份验证中继到域控制器上的LDAP服务，并将基于资源的约束委派从服务A配置到服务B.
- 攻击者使用Rubeus执行完整的S4U攻击，为拥有本地管理员权限的用户获取服务B的TGS
- 攻击者可以将票据传递来破坏服务B
下图说明这种情况：
此场景的视频演示：(https://youtu.be/741uz0ILxCA)
Windows 10/2016/2019 LPE通过NTLM中继来配置RBCD:
0x14 缓解措施
标记为对委派敏感的帐户或受保护用户组的成员不受此处显示的攻击的影响，除S4U2Self滥用除外。但是，计算机帐户会受到影响，根据我的经验，它们永远不会被标记为对委派敏感或添加到受保护用户组。我没有彻底测试将计算机帐户设置为对委派敏感或将其添加到受保护用户组的影响中，因此我不建议这样做，但我建议您可以进一步研究它。
正如Lee Christensen（@tifkin_）在DerbyCon 8中的“打印机错误”滥用案例中所展示的那样，获得域控制器的TGT / TGS允许执行“dcsync”并破坏域。如上述所示，在基于资源的约束委派下，，为任何计算机帐户获取TGT都允许对其模拟用户，并可能破坏主机。因此，重要的是不要将任何主机配置为无受约束的委派，因为它可以促进森林内和其他具有双向信任的林中的其他主机的危害。
使用通道绑定进行LDAP签名可以缓解上述案例研究中描述的RCE和LPE攻击链。
涉及到ntlm中继到ldap的rce/lpe攻击链滥用了一个默认的ace，该ace允许自己将msds写入到其他身份的一半中。添加一个拒绝自己写入msds的新ace属性，该属性被分配到其他身份的一半中，将中断这些攻击链，然后将不得不返回到与无约束委派的原始属性。如果您的企业组织不使用基于资源的受限委派，您可以考虑添加一个ACE，阻止每人写入属性msds allowedtototobenthetheridentity的操作。
0x015 防御检测
以下事件可用于日志文本中描述的攻击的检测思路：
- S4U2Self：可以在Kerberos服务票据请求事件（事件ID 4769）中检测到S4U2Self，其中“帐户信息”和“服务信息”部分指向同一帐户。
- S4U2Proxy：可以在Kerberos服务票据请求事件（事件ID 4769）中检测到S4U2Proxy，其中“附加信息”中的“传输服务”属性不为空。
- 无约束域持的久性：可以在Kerberos服务票据请求事件（事件ID 4769）中检测到上述域持久性技术，其中附加信息中的传输服务属性不为空（表示S4U2Proxy),并且服务信息指向“krbtgt”帐户。
- msds allowedtoctonbehalf-ofotheridentity：如果定义了适当的sacl，则可以在目录服务对象修改事件（事件ID 5136）中检测到基于资源的约束委派配置更改,其中LDAP显示名称为“msds allowedtoactonbehalf-ofotheridentity”。主题标识和对象标识相同的事件可以是上面提到的一些攻击的指示符
0x16 来自微软的建议
微软在MS-SFU第5.1节中强调了S4U2Proxy的风险：
S4U2Proxy是一个危险的扩展，应尽可能限制。但是，引入基于资源的约束委派允许任意帐户调用S4U2Proxy。方法是将“传入”委派配置为其自身，那么，我们应该像KDC一样强有力地保护所有账户。