域安全浅析-基础概念及历史漏洞分析

基础概念

Active Directory

DNS & LDAP & Kerberos

Kerberos Overview

TGT & TGS

Kerberos & PAC

Kerberos & SPN

Kerberos Delegation

历史漏洞

GPP (MS14-025)

GoldenPAC (MS14-068)

PrivExchange (SSRF & NTLM Relay)

NTLM Tampering (Drop The MIC) & RBCD

Mitm6 & NTLM Relay & Kerberos Delegation

TL;DR

本文首先介绍了Windows域的基础概念，比如什么是Kerberos、票据(Ticket)、PAC(Privilege Attribute Certificate)、委派(Delegation)。了解了这些概念后，进一步对历史上出现过的典型漏洞原理进行分析，比如PAC伪造、NTLM转发及降级攻击、利用基于资源的约束委派获取主机权限，希望能帮助读者解开一些疑惑，对域安全有更清晰的认识。

文中大部分内容来源于互联网上的优秀文章，笔者根据自己的理解进行整理编写，水平有限，难免会出错，还请各位看官不吝指教。

一、基础概念

1.1 Active Directory

Windows域也叫活动目录(Active Directory)，是微软开发的应用于Windows域环境的目录服务(AD DS - Active Directory Domain Services)，中央集权式管理域内所有资源，包括域内的用户、用户组、计算机、共享目录、打印机、策略等。

域(Domain)是相对工作组(Workgroup)的概念，通过 Kerberos 或者 NTLM 认证实现了企业级的单点登录，方便用户访问企业内部资源，包括打印机、文件共享服务、Web应用等。

域内的一切资源皆对象，总体上可分为两种类型，一种是容器型对象，比如用户组，可以包含其它对象，另外一种是叶子型对象，其无法包含其它对象，比如某个用户、某台计算机。通过ACLs(Access Control Lists)可对域内对象进行访问控制。

1.2 DNS & LDAP & Kerberos

活动目录域服务(此后简称AD)三大基础协议

https://troopers.de/downloads/troopers19/TROOPERS19_AD_Fun_With_LDAP.pdf

1.2.1 Active Direcotry & DNS

AD要正常工作，就需要通过DNS(Domain Name System)来解析主机名与IP地址的对应关系，或者定位某些服务，比如客户端可以通过DNS的SRV记录获取主域控服务器的地址(dig -t SRV _ldap._tcp.pdc._msdcs.domain.com)，更多关于DNS在域内的作用可以参考: https://blogs.msdn.microsoft.com/servergeeks/2014/07/12/dns-records-that-are-required-for-proper-functionality-of-active-directory/。

要通过Kerberos认证访问域内某个服务，需要知道运行该服务的主机域名，也就是FQDN(fully qualified domain name)，如果仅指定目标服务的IP地址进行访问，则会转为NTLM认证。

dir \pdc.domain.comc$ -- Kerberos认证

dir \10.10.10.10c$ -- NTLM认证

1.2.2 Active Directory & LDAP

AD是微软实现的目录服务(Directory Service)，通过LDAP(Lightweight Directory Access Protocol)协议对域内对象进行读写操作。这种关系就像是WEB服务需要通过HTTP协议访问一样。

AD是一个命名空间，通过对象名称可以找到与这个对象有关的所有信息。

关于AD与LDAP更多内容可以参考: https://troopers.de/downloads/troopers19/TROOPERS19_AD_Fun_With_LDAP.pdf

1.2.3 Kerberos Overview

Hades & cerberus

Kerberos是MIT制定的一种网络认证协议，其名字来源于希腊神话中一只三个头的地狱看门犬(Cerberus)，也被叫作“hound of Hades”，守护着地狱的大门，防止死者逃离。而Kerberos协议也是由三个角色组成，即客户端、目标资源服务、第三方可信机构KDC(Key Distribution Center)。

Kerberos协议设计的初衷的是在不安全的网络环境下，基于加密实现安全高效的认证，避免中间人攻击(比如密码泄露或重放攻击)。Kerberos协议通过可信的第三方(域控)实现了用户对目标服务(资源)访问权限的认证。域控服务器存储了域内所有用户(user and computer account)的密码信息，目标服务本身不需要存储或访问用户的密码信息，通过可信第三方即可对用户的身份进行认证，相对传统的NTLM认证更安全，并且高效。

微软对Kerberos做了一些功能扩展，比如PAC、S4U子协议(后文会有详细介绍)。

以下三张图描述了Kerberos认证的基本流程，大体上分六个步骤(三个来回)：

• 域用户登录时，向KDC(域控)的AS(Authentication Service)服务发送一段用自身密码(变种)加密的时间戳，证明其知道该用户的密码，这一步称为"预认证"(preauthentication)。

• 域控的AS服务验证用户的密码是否正确(域控存储了域内所有用户的密码信息)，验证通过后返回给用户一个TGT票据(Ticket Granting Ticket)，也叫“登录票据”(Login Ticket)，该票据经过域控的krbtgt帐号密码加密，也就是说除了域控，理论上没有人能解密该票据里面的数据，更无法伪造。该票据作为用户的凭证，内部包含了该用户的用户名、用户ID、所属组ID等信息(这些信息统称为PAC-Privilege Attribute Certificate，后面会有PAC的详细介绍)，之后用户申请其它服务的资源访问票据(Resource Access Ticket)时，需要再次提供该TGT给域控，向域控表明身份，而无需再次重复上一步的预认证过程。域控收到用户提交的TGT，如果能通过krbtgt帐户的密码正常解密，则认为TGT票据内的所有数据都是有效可信的。

• 用户此时希望访问某共享目录服务，需要向域控的票据授予服务(TGS-Ticket Granting Service)申请目标服务的资源访问票据(Resource Access Ticket)。将第二步中域控返回的TGT提交给票据授予服务，并指明希望申请某主机(fileserver.domain.com)的文件共享服务(CIFS-Common Internet File System)票据。前面提到过，TGT是用户的身份凭证，由KDC颁发，只有域控自身可解密，无人可伪造。

• TGS服务返回给用户对应目标服务的服务票据(Service Ticket)，也叫资源访问票据(Resource Access Ticket)，该票据是由运行目标服务的服务帐号(通常为计算机帐户)密码加密的，只有域控及目标服务自身知道该密码，所以用户同样无法解密或伪造该票据。

• 用户将上一步收到的资源访问票据发送给目标服务(这里是CIFS/fileserver.domain.com)。

• 目标服务收到该票据，用运行该服务的帐户密码解密该票据，验证该用户的身份及权限，决定认证成功或失败。

更详细的介绍可以参考以下两篇：

https://en.wikipedia.org/wiki/Kerberos_(protocol)

https://www.roguelynn.com/words/explain-like-im-5-kerberos/

1.3 TGT & TGS

可以看出，前四步是Kerberos认证的关键步骤，用户申请了TGT票据(Ticket Granting Ticket)，其由域控的认证服务(Authentication Service)生成并发送给客户端，可以理解为现实世界中的身份证，以及访问目标服务所需要的服务票据(Service Ticket)，其由域控TGS(Ticket Granting Server)服务颁发，可以理解为身份证复印件，其指明该复印件仅对特定服务有效，比如该复印件仅作为某网站实名认证用，不可用于其它业务。

TGT票据也叫登录票据(Logon Ticket)，服务票据也叫资源访问票据(Resource Access Ticket)或者ST(Service Ticket)，有时也直接称其为TGS。

票据都是跟指定服务绑定的，TGT票据由域控的AS服务颁发，仅对域控的TGS服务有效。服务票据(Service Ticket)由域控的TGS服务颁发，一般仅对其要访问的目标资源服务有效。TGT与TGS的本质区别，也许只在于票据目标服务名不一样。*maybe*

另外TGT可以理解为一种特殊的服务票据，其由域控的认证服务(Authentication Service)生成并发送给客户端，由krbtgt帐户加密(票据都是由目标服务帐户密码加密的)，仅能提供给域控的票据授予服务(Ticket Granting Server)作表明身份用，并不能直接用来访问其它服务(比如CIFS、MSSQLSvc等)。

票据都分为两部分，即明文及密文部分，明文部分指明该票据是针对哪个服务的(比如krbtgt帐户运行的TGS服务、某计算机帐户运行的HTTP服务)。密文部分包含票据有效期、PAC(Privilege Attribute Certiificate)等。其中明文部分sname(Service Name)不受加密保护，在特定场景下，攻击者可以任意替换服务票据(ST)中明文部分的服务名(Service Name)，只要修改过的服务名与ST中原始的服务是由同一帐户运行的，修改过的ST依然是有效的。也就是说同一个帐户运行了多个服务实例，访问这些服务理论上只需要一个有效的ST即可。

关于修改服务票据服务名可参考:

https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html#solving-a-sensitive-problem

https://www.secureauth.com/blog/kerberos-delegation-spns-and-more

1.4 Kerberos & PAC

由于原生Kerberos协议仅对用户身份有效性进行验证(即证明该用户确是其声称的用户)，目标服务无从判断用户对自身服务具有哪些访问权限，所以微软对Kerberos做了扩展，在票据中增加了PAC(Privilege Attribute Certiificate)数据块，如下图所示，包含了该用户的用户名、用户ID、所属用户组ID等信息，为了确保这些敏感信息不被非法篡改，分别用域控krbtgt帐户密码及目标服务帐户密码对其进行签名(TGT票据比较特殊，目标服务帐户即为krbtgt帐户)，分别给TGS服务及目标服务用来验证PAC信息的完整性，默认该签名算法是需要密钥的，比如下图中的hmac-md5、hmac-sha1。

也许正因为PAC是微软对Kerberos做的扩展，所以用户在认证的第一步，即发起预认证请求(AS-REQ)时，设置PA-PAC-REQUEST=False，认证服务会生成一个不包含PAC的有效TGT，后面介绍的MS14-068(GoldenPAC)漏洞会利用这一特性。

TGT票据中的加密部分包含了PAC

1.5 Kerberos & SPN

域用户和计算机帐户包含各种属性，比如名字、描述等，其中一个属性叫服务主体名(Service Principal Name)，是提供服务所必须的一条属性。服务主体名(后称为SPN)在一个林(forest，林内可包含多个域)内必须是唯一的，不然Kerberos认证会失败。

SPN是由服务实例注册的林内唯一标识符，客户端想要访问某个服务，必须指定该服务实例的SPN。

SPN有两种类型:

一种是基于主机的，计算机帐户创建时，内置服务会自动创建该种类型的SPN，<service class>部分代表服务类型，常见的有HOST、LDAP、CIFS等，<host>部分代表运行该服务所在的主机名，[port]及[service name]部分为可选部分，用于区分运行在同一主机同一服务的多个实例。

• <service class>/<host>:[port]/[service name] -- host-based SPN，比如 MSSQLSvc/server1.domain.com:1433

另外一种则是任意的，通常情况下，以域用户身份运行的服务采用此类SPN，其中服务类型和服务名可任意指定。

• <service class>/<service name> -- Arbitrary SPN，比如 AcmeService/GlobalBank

1.6 Kerberos Delegation

Delegation(委派)是Kerberos相对传统的NTLM认证所独有的特性，当用户向某服务发起认证后，该服务可以代理/假冒(impersonate)该用户，以其身份访问其它服务，比如下图中用户访问Web服务，Web服务以用户的身份向域控申请数据库服务的访问权限(第6步)。也就是说该Web服务具有被用户委派的权限，或者说该Web服务可以代理(“假冒”)用户在域内进行认证。

Kerberos Delegation 分为以下几种类型：

• Unconstrained Delegation/非约束委派

• TrustedForDelegation=True(Kerberos Only)，没有任何限制的TGT票据转发，Since Windows Server 2000
• ServierA具有非约束委派的权限时，当用户向域控申请ServiceA的ST时，域控将该用户的TGT附加到生成的ST中，之后用户向ServiceA提供该ST，ServiceA可以从ST中把用户的TGT提取出来，放入自身的LSASS进程中，"假冒"该用户向域控申请ServiceB的ST。

• Constrained Delegation/约束委派(基于S4U协议扩展)

• S4U2Proxy/msDS-AllowedToDelegateTo=NotNULL(生成的ST总是具有Forwardable属性)，有限制的TGS票据转发，Since Windows Server 2003
• ServiceA具有约束委派权限时(msDS-AllowedToDelegateTo=ServiceB)，用户向域控申请ServiceA的ST时，域控将生成的ST(for User to ServiceA)标记为可转发(Forwardable)，ServiceA利用该ST执行S4U2Proxy，"代理"用户向域控申请ServiceB的ST，之后ServiceA使用域控返回的ST(for User to ServiceB)访问ServiceB。

• S4U2Self/协议过渡(Protocol Transition)，帮助不支持Kerberos认证(比如仅支持NTLM)的客户端生成对自身服务可用的TGS票据

• TrustedToAuthForDelegation=(True:生成的ST具有Forwardable属性，False:生成的ST没有Forwardable属性)
• S4U2Self works on any account that has an SPN, regardless of the state of the TrustedToAuthForDelegation attribute. If TrustedToAuthForDelegation is set, then the TGS that S4U2Self produces is forwardable, unless the principal is sensitive for delegation or a member of the Protected Users group.
• 也就是说S4U2Self子协议对于任意具有SPN的帐户都是可用的，无论该帐户TrustedToAuthForDelegation属性被设置为真或假。为假时，S4U2Self生成的ST不可被转发，只能访问其自身。只有为真时，S4U2Self生成的ST才具有转发属性(Forwardable)，可被S4U2Proxy用来转发(即转发至域控的TGS服务)生成访问另外一个服务的ST。对于传统的约束委派来说是这样，但是对于下面介绍的基于资源的委派而言，无论S4U2Self生成的ST是否具有转发属性，均可被S4U2Proxy用来转发生成访问另外一个服务的ST(Service Ticket)。

• Resource-Based Constrained Delegation/基于资源的约束委派

• AllowedToActOnBehalfOfOtherIdentity，Since Windows Server 2012
• 不需要域管理员权限(不同于传统的非约束委派或约束委派)，也就是不需要 SeEnableDelegationPrivilege 权限，任何计算机对象都可以自行设置其 msDS-AllowedToActOnBehalfOfOtherIdentity 属性。
• 跟传统的约束委派方向相反，基于资源的约束委派是由ServiceB设定允许ServiceA代理用户访问ServiceB(from ServiceA to ServiceB setting on ServiceB)，此时并不需要ServiceA帐户具有任何特殊权限，即不需要ServiceA帐户具有任何以下属性TrustedForDelegation、msDS-AllowedToDelegateTo、TrustedToAuthForDelegation。*maybe*
• 基于资源的约束委派是约束委派的一种，也需要用到S4U协议扩展，只是相对于传统的约束委派权限更高，自由度更大。

https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html

二、历史漏洞

2.1 GPP (MS14-025)

管理员为了统一管理计算机本地管理员的密码，有时会通过组策略(Group Policy Preferences)来统一设置，该方法会将配置信息写入 \<DC>SYSVOL<Domain FQDN>Policies 域控共享目录的XML文件中，类似的文件有drives.xml, groups.xml, printers.xml等。SYSVOL共享目录保存了登录脚本、组策略数据等其它域内共享数据，所以域内任意用户均对该目录具有读权限，并且这些数据在所有域控服务器之间自动同步。

XML文件中的密码字段(cpassword)采用AES256加密存储，但是微软在2012年公开了加密密钥，导致密文可轻易还原。MS14-025补丁禁用了组策略保存密码的功能，但即使打了该补丁，之前保存的配置文件依然存在，需要手动删除相应xml文件。

https://adsecurity.org/?p=2288

2.2 GoldenPAC (MS14-068)

前面提到过,PAC是微软对Kerberos协议做的扩展，其中包含了用户名、ID、所属组等信息，并且用krbtgt及目标服务的帐户密码(long-term secret key)进行签名确保其完整性，以防止用户伪造身份信息。

但是微软在实现的过程中，除了支持默认的HMAC-MD5、HMAC-SHA1等需要密钥(keyed)的加密算法外，还支持弱加密算法，比如MD4、MD5、CRC32等，这类算法不需要密钥(unkeyed)，所以攻击者可以任意伪造PAC中的信息(比如该用户所属组)，只需要用MD5算法对伪造的PAC数据进行签名，域控TGS服务即认为该PAC数据是有效可信的。

常规TGT的模样，PAC中包含敏感信息并且由域控krbtgt帐户密码签名。

虽然PAC是可以伪造的，但是PAC包含在票据的加密部分内，以TGT为例，PAC所在的部分外层被krbtgt帐户密码加密，客户端无法解密，也就无法替换其中的PAC数据。

上文提到过，用户在预认证阶段(AS-REQ)如果指定PA-PAC-REQUEST为False，域控AS服务会为其生成一个不包含PAC数据的TGT票据，同样以krbtgt帐户密码加密且有效。

客户端伪造高权限(比如"Domain Admins"管理员组)的PAC并采用不需要密钥的弱加密算法进行签名，附加到上一步域控返回的不包含PAC的TGT中，向域控TGS服务发起TGS-REQ发起请求(上图中第3步)，申请krbtgt服务的服务票据，也就是TGT。存在该漏洞的域控TGS服务验证用户提交的TGT及PAC都是有效的，所以生成有效的TGT票据(管理员组权限)返回给客户端。

客户端可以用域管理员权限的TGT(身份证)继续向域控的TGS服务申请域内任意服务的ST，比如域控服务器的CIFS服务，从而获取域控服务器权限。

攻击者在请求ST的过程中，伪造了PAC中的用户所属组信息(声称自己具有多个管理员组权限)，并且采用弱加密算法(这里是md5)对PAC数据进行签名。

PAC弱签名算法及历史上出现过的类似漏洞

https://adsecurity.org/?p=525

2.3 PrivExchange (SSRF & NTLM Relay)

2.3.1 Exchange SSRF

Exchange Web Services (EWS) API中的 PushSubscriptionRequest 函数存在SSRF(Server Side Request Forgery)漏洞，任意拥有邮箱的域用户可以利用该功能诱使Exchange服务向其指定的URL发起HTTP请求(定时推送订阅通知)。如果攻击者伪造HTTP服务，要求Exchange服务进行NTLM认证(基于HTTP)，则可将认证请求转发至域内其它服务(比如域控的LDAP服务)进行认证，从而获取运行Exchange服务的计算机帐户的权限。

详情可参考:

https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/

https://www.thezdi.com/blog/2018/12/19/an-insincere-form-of-flattery-impersonating-users-on-microsoft-exchange

2.3.2 (too) high privileges by default

当服务在域成员计算机上的LocalSystem帐户下运行时，该服务具有授予该计算机帐户的任何网络访问权限。运行Exchange服务的计算机帐户在AD内具有较高的权限，其属于"Exchange Trusted Subsystem"组，而该组又属于"Exchange Windows Permissions"组。

BlueHat-2017-Metcalf-ActiveDirectorySecurityTheJourney-Final.pdf

"Exchange Windows Permissions"组对域对象具有WriteDacl权限，关于Dacl可以参考: https://docs.microsoft.com/en-us/windows/win32/secauthz/dacls-and-aces，或者下图

https://specterops.io/assets/resources/an_ace_up_the_sleeve.pdf

也就是说Exchange服务可以对域内任意对象新增或删除ACE(Access Control Entries)，比如为某个用户增加DCSync权限(相当于拥有域管理员权限)，DCSync实际上需要以下三个权限:

• Replicating Directory Changes
• Replicating Directory Changes All
• Replicating Directory Changes In Filtered Set

https://www.slideshare.net/harmj0y/i-have-the-powerview

2.3.3 NTLM Relay

2.3.3.1 NTLM Relay 101

NTLM实际上也叫NTHash，其加密算法为MD4(UTF-16-LE(password))，NTLMv1/v2(也叫Net-NTLMv1/v2)是由NTHash衍生而来(引入随机数进行加密)，做网络认证用。

NTHash存储在系统SAM(Security Account Manager)及域控的NTDS.dit数据库中，可以用来执行Pass-The-Hash攻击，而Net-NTLMv1/v2不能用来执行Pass-The-Hash，仅能用来转发(relay)。

NTLM是基于挑战-应答机制的认证协议，使用共享密钥(即用户的密码)来对客户端进行认证，如下图所示：

• 第一步客户端向服务端发起认证请求，协商使用的协议版本(Net-NTLMv1/v2)、是否启用签名等信息。
• 第二步服务端选择一个版本并返回一段随机字符作为challenge(也叫nonce)。
• 第三步客户端使用NTHash对challenge加密并发送给服务端(response)，如果加密结果与服务端计算的结果匹配，则客户端认证成功。

正常NTLM认证过程

NTLM认证协议天然存在转发攻击的风险，攻击者诱使客户端向其自身发起NTLM认证，并将其转发至目标服务器，通过中间人攻击实现在不需要用户密码的情况下，以客户端身份向服务器发起认证。SMB签名可以阻止此类转发攻击，但是默认情况下，只有域控的SMB服务默认强制启用签名校验。

中间人执行NTLM转发攻击

2.3.3.2 Reflective NTLM Relay is Dead?

在MS08-068补丁之前，基于SMB的NTLM认证可以转发至客户端自身的SMB服务，所以也叫反射型转发，这个补丁之后，客户端发起的基于HTTP的NTLM认证依然可以转发至自身的SMB服务，该漏洞通常用来实现本地提权，MS16-075修复了这种跨协议(Cross-protocol)的反射型转发。

MS16-075补丁之后，研究人员发现Java实现的NTLM依然存在反射型转发漏洞，可以实现跨协议的反射型转发，关于为什么Java实现的NTLM认证存在该漏洞，笔者还没有完全搞明白，感兴趣的同学可以参考: https://www.youtube.com/watch?v=gyR3RQEpfxU。

2.3.3.3 Cross protocol relaying

NTLM认证通常封装在其它协议内部，比如SMB、HTTP(s)、LDAP、IMAP、SMTP、POP3、MSSQL，其内部的NTLM认证部分是一样的，所以可以将一种协议内部的NTLM认证转发至其它协议。比如基于HTTP的NTLM认证通过HTTP Header中的“Authorization”发送，攻击者可以将其抽离出来发送至SMB服务进行认证。

2.3.4 Relay NTLM（in HTTP）to LDAP

综合以上介绍的Exchange SSRF漏洞、Exchange默认权限过高、NTLM转发攻击，攻击者可以诱使Exchange服务向其自身发起HTTP NTLM认证，并将其转发至域控的LDAP服务，以Exchange服务的身份认证成功后，利用其修改任意域对象DACL的权限，赋予攻击者控制的域帐户DCSync权限，从而dump出域内任意帐户的NTHash，获取域管理员的权限。

https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/

2.4 NTLM Tampering (Drop The MIC) & RBCD

上一个漏洞中介绍了利用Exchange服务发起基于HTTP的NTLM认证并转发至域控LDAP服务认证，进而修改域ACL权限(Exchange服务帐户具有WriteDacl权限)，提升任意用户为域管理员权限。而这个漏洞则可以实现将辅助域控服务器的基于SMB的NTLM认证转发至主域控的LDAPS服务，利用基于资源的约束委派特性(RBCD:Resource-Based Constrained Delegation)，以任意用户身份(域管理员)生成辅助域控服务器CIFS服务的ST(Service Ticket)，从而获取辅助域控服务器权限。

• 该攻击过程首先利用打印机服务(SpoolService)MS-RPRN(Print System Remote Protocol)RPC接口的一个BUG，利用该BUG可诱使目标服务器向任意主机发起SMB认证，详情可参考：https://www.slideshare.net/harmj0y/derbycon-the-unintended-risks-of-trusting-active-directory/41。
• 研究人员发现，在基于SMB的NTLM认证过程中，即使客户端在第一步协商(NTLM_NEGOTIATE)请求中指定需要对NTLM认证进行签名(SMB Signing)，只要服务端未强制要求签名(域控LDAP(s)服务默认不强制要求签名)，攻击者即可以通过中间人攻击，在转发基于SMB的NTLM认证的过程中，将NTLM安全级别降低为未签名的状态，从而实现将基于SMB的NTLM转发至域控的LDAPS服务进行认证。该漏洞(CVE-2019-1040)详情可参考：https://blog.preempt.com/drop-the-mic。
• 域成员计算机运行的服务通常与其计算机帐户对应，而任意域用户都具有创建计算机帐户的权限(默认可创建10个，详情可参考：MachineAccountQuota)，创建计算机帐户的同时为其注册SPN，使其成为一个合法的服务帐户(ServiceA)。
• 以辅助域控服务器的计算机帐户向主域控LDAPS服务认证成功后，由于域内任意计算机对象都具有基于资源的约束委派权限(Since Windows Server 2012)，其可以自行决定允许另外一个服务(ServiceA)“假冒”任意用户访问其自身的CIFS服务(ServiceB，这里为辅助域控的文件共享服务)，CIFS服务实际上是SMB协议的一种实现。
• 新创建的计算机帐户(for ServiceA)被辅助域控服务器(ServiceB)授予基于资源的约束委派权限后(AllowedToActOnBehalfOfOtherIdentity=ServiceA)，其可以通过S4U协议(S4U2Self+S4U2Proxy)以域管理员身份登录辅助域控服务器的CIFS服务，从而获取域控服务器权限。

• 关于基于资源的约束委派攻击可以参考上文中的“1.6 Kerberos Delegation”部分，这里简要介绍下攻击过程。
• 由于Kerberos协议支持协议过渡(Protocol Transition)，允许不支持Kerberos认证(比如通过NTLM或Form表单认证)的客户端接入Kerberos认证体系，故任意服务(拥有SPN的帐户)可为客户端生成可访问其自身的ST(Service Ticket)，又由于Kerberos无从验证客户端声称的用户身份，任意服务(ServiceA)可为任意域用户(比如域管理员)生成用于访问其自身的ST(默认该服务票据不具有转发属性)，即使该域用户并未实际向ServiceA发起过认证。该过程通过S4U2Self子协议实现。也就是说任意服务帐户均可以向域控TGS服务申请生成以域管理员身份访问自身的ST(PAC部分表明其为域管理员)。
• 乍看起来，上一步生成的域管理员用的ST仅能访问服务自身，且不具有转发属性，但此时如果该服务帐户进一步利用该服务票据执行S4U2Proxy操作，申请已设置了基于资源的约束委派(AllowedToActOnBehalfOfOtherIdentity=ServiceA)的目标服务票据(ServiceB)，则域控TGS服务生成可用于ServiceB的管理员身份的服务票据。传统的约束委派执行S4U2Proxy时需要提供的ST具有转发属性(Forwardable)，但是基于资源的约束委派是由目标服务(ServiceB)设定的，无需原始服务(ServiceA)具有任何特殊权限，也就不需要其提供的ST具有转发属性，所以上一步生成的ST是可以用来执行S4U2Proxy操作，所以说基于资源的约束委派权限更大，自由度更高，也就更不安全。也就是说如果ServiceB设置了基于资源的约束委派权限允许ServiceA代理用户访问ServiceB，则ServiceA可以域管理员身份访问ServiceB(比如CIFS服务)，从而获取ServiceB所在主机系统权限。换言之，只要获取了域内某主机计算机帐户权限，利用基于资源的约束委派特性，攻击者即可控制该主机。
• 关于基于资源的约束委派攻击，强烈建议阅读这篇文章: https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html

2.4.1 Drop The MIC

NTLM认证包含三部分消息:NTLM_NEGOTIATE、NTLM_CHALLENGE、NTLM_AUTHENTICATE，分别对应下图中的三步，为了确保消息在网络传输中不被恶意篡改，NTLM_AUTHENTICATE部分加入了MIC(Message Integrity Code)字段，采用HMAC_MD5对这三种消息统一做了签名校验，任何一步中的消息被篡改均会导致签名失效。

但是由于不是所有客户端都支持MIC，比如Windows XP/2003，所以也许为了保持向后兼容，该字段也并非必须的。在去掉NTLM_AUTHENTICATE消息中MIC字段的同时，还需要修改/去除一系列其它字段，以让服务端完全相信客户端不支持MIC(*maybe*)，从而不对NTLM认证进行签名校验。也就是实现了将基于SMB的NTLM认证(默认客户端协商进行签名)降级为未签名的状态。未签名的NTLM可顺利转发至域控的LDAPS服务进行认证。

正常的协商签名的NTLM认证过程

NTLM转发攻击过程中去掉签名请求及相关字段，实现NTLM安全降级

https://blog.preempt.com/drop-the-mic

2.4.2 Relay NTLM（in SMB）to LDAPS

• 触发辅助域控服务器(这里是rlt-app-server)的打印机服务BUG，令其向攻击者控制的主机(10.0.2.6)发起SMB认证。
• 利用ntlmrelayx.py将基于SMB的NTLM认证请求转发至主域控(rlt-dc)的LDAPS服务(这里不能转发至LDAP服务是因为只有LDAPS服务才具有创建计算机帐户的权限)，--remove-mic 去除签名相关信息，实现NTLM安全降级，--delegation-access 创建新的计算机帐户(XYZQAJUC$)并授予其对转发的计算机帐户(即辅助域控服务器rlt-app-server)的基于资源的约束委派权限。

• 利用新创建的计算机帐户“假冒”域管理员(baasbob)身份向域控TGS服务申请辅助域控服务器HOST服务的服务票据，可进一步dump出辅助域控服务器上所有用户的NTHash。也就是说，控制了辅助域控服务器的计算机帐户，即可以通过基于资源的约束委派特性获取该服务器的系统权限。

https://dirkjanm.io/exploiting-CVE-2019-1040-relay-vulnerabilities-for-rce-and-domain-admin/

2.5 Mitm6 & NTLM Relay & Kerberos Delegation

通过IPv6中间人攻击、NTLM转发、基于资源的约束委派特性的组合利用，攻击者可获取局域网同一广播域内任意域内主机系统权限。

2.5.1 Mitm6 Overview

即使在IPv4网络中，Windows系统默认也会通过DHCPv6协议申请IPv6地址，并且会优先使用IPv6的DNS服务器去解析IPv4及IPv6域名A记录。攻击者在局域网内监听DHCPv6广播请求，伪造响应，分配给目标主机恶意DNS服务器(IPv6)，劫持目标主机首选DNS服务器。目标主机发起DNS请求时，攻击者可对其进行DNS欺骗。

劫持目标主机首选DNS服务器

https://blog.fox-it.com/2018/01/11/mitm6-compromising-ipv4-networks-via-ipv6/

2.5.2 WPAD Overview

2.5.2.1 A (short) history of WPAD abuse

WPAD全称为Windows Proxy Auto Detection，在企业网络中用来自动检测访问互联网的网络代理，提供 wpad.dat 文件的服务器IP地址首先会通过DNS服务器进行解析，如果解析失败，客户端会通过广播的方式寻求解析，比如LLMNR(Link-Local Multicast Name Resolution)，在同一广播域内的攻击者此时回应客户端，声称其自身为WPAD主机，客户端想要访问 wpad.dat 文件，就会向攻击者发起HTTP请求，攻击者此时要求客户端进行NTLM认证(HTTP 401)，客户端自动向其发起认证，该过程无需用户交互即可完成。攻击者可进一步将基于HTTP的NTLM认证转发至其它服务。

微软在2016年发布了安全更新(MS16-077)，做了以下两点修改缓解此类攻击：

• 客户端不再通过广播协议进行WPAD解析，仅能通过DNS服务解析。
• 即使WPAD主机要求认证(HTTP 401)，客户端也不再自动发起NTLM认证。

2.5.2.2 Exploiting WPAD post MS16-077

第一条缓解措施中，WPAD仅能通过DNS解析，利用 2.5.1 中的 mitm6 劫持客户端的首选DNS服务器，即可轻易绕过。

第二条缓解措施中，客户端不再向WPAD主机发起NTLM认证，研究人员发现，如果此时向客户端提供“有效的” wpad.dat 文件，并在其中指定攻击者为代理服务器，当客户端应用程序使用Windows API访问互联网时，会把攻击者当作是代理服务器，客户端向攻击者发起连接请求时，攻击者回应 HTTP 407(Proxy Authentication)，这不同于之前的HTTP 401认证，客户端会再次自动向其发起NTLM认证。

更详细的资料可参考: https://blog.fox-it.com/2018/01/11/mitm6-compromising-ipv4-networks-via-ipv6/

2.5.3 NTLM Relay & Kerberos Delegation

利用WPAD漏洞将NTLM认证(基于HTTP协议)转发至域控LDAPS服务，配合基于资源的约束委派获取目标主机服务器权限。

• 目标主机开机时，在用户登录前，系统通过会通过DHCPv6申请IP地址、DNS服务器等配置信息，系统访问某些网站时，需要对网站域名进行DNS解析，攻击者欺骗客户端称该域名指向其自身，当客户端发起HTTP请求时，会通过WPAD寻求代理，比如向DNS服务器询问 wapd.internal.corp 对应的IP地址，攻击者同样欺骗其指向自身，并提供给客户端“合法”的 wpad.dat 代理规则文件，该文件内部指定攻击者自身即为代理服务器，目标主机会继续向代理服务器发起HTTP请求，攻击者此时回应407响应(Proxy-Authenticate)，要求目标主机进行NTLM认证。

• 攻击者收到目标主机发起的基于HTTP的NTLM认证，随即将其转发至域控的LDAPS服务，由于基于HTTP的NTLM认证默认不协商签名，所以该过程可顺利完成，不需要利用上一个漏洞进行NTLM安全降低。

• 以目标主机计算机帐户身份向域控的LDAPS服务认证成功后，同样的利用基于资源的约束委派特性，攻击者可以任意身份(比如域管理员)登录目标主机。该过程可以参考上文中的"1.6 Kerberos Delegation"及"2.4 NTLM Tampering (Drop The MIC) & RBCD"中的约束委派部分。

劫持目标主机首选DNS服务器并将NTLM认证转发至域控LDAPS服务，配置基于资源的约束委派

申请目标主机CIFS服务票据获取其系统权限

https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/

原文始发于微信公众号（黑客白帽子）：域安全浅析-基础概念及历史漏洞分析