Windows | 凭证窃取与缓解措施（二）

       Windows 中存在各种权限认证相关的凭证以及缓解凭证窃取的措施，本文旨在厘清 Windows 中常见的凭证基本概念以及对应的缓解措施。        

       注：在某些情况下，用户、账户、帐户概念混用，但实际上账户符合规定，帐户符合习惯；凭据与凭证概念同义；票据与票证概念同义；凭证相关的缩写概念混用。由于 Windows 系统沿用帐户，故本文遵照习惯统一描述为帐户、凭证、票据，并标注各类概念的英文全称以及缩写。

       接上篇，介绍 LSA Secrets、Tickets、NTDS.DIT 凭证窃取与缓解措施。

5. 凭证: LSA Secrets

LSA Secrets

存储在注册表中的凭据，允许以用户权限运行服务或任务。除了服务帐户外，还可能包含应用程序密码，例如 VPN 或自动登录凭据。当存在高特权、非内置帐户的服务或计划任务时，这些特权帐户必须存储在 LSA Secrets 注册表项中，具有系统管理员权限的攻击者都可以使用它们。

如何获得和使用的？

管理员权限允许访问加密的注册表数据，解密所需的密钥。

Windows 服务无需用户交互即可运行，因此当使用域帐户（与本地系统、网络服务和本地服务等本地内置帐户相反）执行它们时，该帐户的密码必须存储在Windows 注册表中的 LSA Secrets 键中。

多年来，各种应用程序（包括 Windows）发现在注册表中存储各种不同的凭据很有用，包括 RAS 和 VPN 密码、默认登录凭据、用于验证计划任务的凭据，甚至 IIS 应用程序密码。

常用工具

Cain、Metasploit、Mimikatz、gsecdump、AceHash、creddump、Nishang PowerShell

暴力破解

从攻击者的角度来看，服务帐户最具吸引力，因为它们在 Windows 企业中非常常见，通常具有很高的特权，并且很少更改。

LSA Secrets 以加密形式存储在安全配置单元注册表项 SECURITY/Policy/Secrets 中。每个LSA Secrets 都有自己的密钥和父密钥可以解码“Secrets”。除了安全配置单元之外，转储工具还需要访问系统配置单元才能，获得最终解密密钥。

Nishang PowerShell 渗透测试框架的Get-LsaSecret.ps1 可以用于转储（和解密）LSA Secrets。管理员权限允许访问转储 LSA  Secrets 注册表区域。解密后，所有密码都是明文形式。

缓解措施

• 防止管理员帐户泄露

• 不要在低信任系统上使用需要特权帐户的服务或计划任务

• 减少需要域帐户执行的服务数量

• 对任何必须使用的帐户进行审计

• 托管服务帐户（Managed Service Accounts）

• 组托管服务帐户（Group Managed Service Accounts）

减轻 LSA Secrets 攻击的最佳选择是确保低信任度系统不存在需要高特权、非内置帐户的服务或计划任务。

由于完全消除对 LSA Secrets 的依赖可能非常困难，因此可能出现在该密钥中的任何帐户都应遵循最小特权规则并进行严格审计。

Server 2008R2 发布托管服务帐户（Managed Service Accounts）。此功能对使用域帐户权限运行的服务帐户，要求密码更改时间（默认为 30 天）和密码复杂性。

Windows 8 系统的组托管服务帐户（Group Managed Service Accounts），更加灵活和易于管理。

reference

• https://github.com/samratashok/nishang

• https://blog.stangroome.com/2013/07/28/avoid-password-management-with-group-managed-service-accounts/

6. 凭证: Tickets

Tickets

Kerberos 向经过身份验证的用户颁发票据，无需额外的身份验证即可重复使用这些票据。票据缓存在内存中，有效期为 10 小时。

如何获得和使用的？

票据可以从内存中窃取并用于在其他地方进行身份验证进行传递票据攻击（ Pass the Ticket, PtT）。此外，域控制器（DC） 的访问允许为任何没有过期的用户创建票据（黄金票据，Golden Ticket）。可以请求和伪造服务帐户票据，包括服务帐户哈希的离线破解（Kerberoasting）。

使用 Windows 系统的企业严重依赖 Kerberos 身份验证协议。

常用工具

Mimikatz、WCE、kerberoast、impactket、Rubeus

Kerberos

Kerberos认证协议是基于票据（Tickets）的一种认证方式。

名称解释：

• 用户（Client）

• 服务器（Server）

• 密钥分发中心（Key Distribution Center, KDC）：包括认证服务器（Authentication Server, AS）和票据授权服务器（Ticket Granting Server, TGS）

• 票据授权凭证（Ticket Granting Ticket, TGT）：包含特权属证书（PAC）

• 服务票据（Server Ticket, ST）

• 特权属证书（Privilege Attribute Certificate, PAC）：包含用户（Client）的相关权限信息，用于验证用户权限，只有密钥分发中心（KDC）能创建并查看

• krbtgt：密钥分发中心（KDC）服务使用的帐户，属于域管理员组，每个用户帐户的票据授权凭证（TGT）都由 krbtgt 产生

• CIFS服务 （Common Internet File System）：通用Internet文件系统，可以访问远程Internet计算机上的文件并要求此计算机提供服务

• 委派（Delegation）：真实环境中，往往多个服务不可能在用一台机器上。如果用户在使用服务 A 时，需要服务 B 上属于自己的数据，最简单的方式就是让服务 A 代用户去请求服务 B 返回相应的数据，这个过程称为委派

Kerberos认证过程简述：

• 用户（Client）向认证服务器（AS）发起请求，请求内容包含用户（Client）的哈希值参与加密的时间戳、SID 等信息。

• 认证服务器（AS）使用用户（Client）密码哈希值进行解密，如果解密正确，就返回用 krbtgt 帐户的 NTLM 哈希值参与加密的票据授权凭证（TGT），票据授权凭证（TGT）包含特权属证书（PAC），特权属证书（PAC）包含用户（Client）相关的权限信息，如，SID所在组。

• 用户（Client）向票据授权服务器（TGS）发起请求，请求内容包含票据授权凭证（TGT）。

• 票据授权服务器（TGS）使用 krbtgt 帐户的 NTLM 哈希值对票据授权凭证（TGT）进行解密，如果解密正确，就返回用特定服务（Server）帐户的 NTLM 哈希值参与加密的服务票据（ST），并附带特权属证书（PAC）。注：认证过程中，无论用户（Client）是否具有访问特定服务的权限，只要票据授权凭证（TGT）正确，就会返回服务票据（ST）。

• 用户（Client）向特定服务（Server）发送请求，请求内容包含服务票据（ST）。

• 特定服务（Server）使用自己服务帐户的 NTLM 哈希值对服务票据（ST）进行解密，如果解密正确，就将附带的特权属证书（PAC）发送给密钥分发中心（KDC）进行解密，密钥分发中心（KDC）判断该用户（Client）是否具有访问该服务的权限。注：如果没有设置附带的特权属证书（PAC），该服务不会向密钥分发中心（KDC）发送请求判断权限，这也是白银票据（Silver Ticket, ST）攻击成功的原因。

Kerberos协议使用票据授予凭证 （TGT） 和服务票据（ST）来对用户帐户对特定服务访问进行身份验证。由于 Windows 中的几乎所有操作都与帐户相关，因此身份验证负担可能很大。为了减少向域控制器 （DC）身份验证的请求数量，默认情况下，签发的票据有效期为 10 小时。这意味着的攻击者可以用该票据来冒充特权用户，规避身份验证过程。

传递票据（Pass the Ticket, PtT）

       票据在有效期间缓存在内存中，Mimikatz 允许具有管理员权限的攻击者将系统上存在的所有票据转储到文件中。然后可以将获得的票据传递给其他系统以验证为该帐户票据授予凭证 （TGT）或服务票据（ST）。这些票据也可以直接导入其他系统，而无需知道用户哈希或密码。

超越哈希（Overpass the Hash, OPtH）

       如果攻击者可以从系统中转储域帐户的 NTLM 哈希，则此哈希可用于请求服务票据（ST），提供对其他系统资源（如文件共享）的访问。虽然类似于传递哈希，但该攻击使用 Kerberos 协议进行身份验证，而不是 NTLM，这意味着即使存在传递哈希缓解措施也可以利用（例如，限制网络上的 NTLM 身份验证）。

Kerberoasting/Kerberoast

任何一个域用户都可以向域控制器（DC）请求域服务的票据。返回的票据具有运行该服务的帐户的非加盐密码哈希。攻击者可以寻找在域用户（或域管理员）帐户上下文中运行的服务票据（ST），并可以导出服务帐户 NTLM 哈希离线破解，由于服务帐户密码通常具有很高的权限并且很少更改，因此这些密码非常有价值。

黄金票据（Golden Ticket, GT）

攻击者可以为任何帐户创建永不过期的黄金票据（GT）（Mimikatz 将默认有效期设置为 10 年，还可以增加）。通常用于创建域管理员的票据授权凭证（TGT），即使域管理员的密码被重置后也能正常利用。

创建域管理员的黄金票据（GT），攻击者必须先在域控制器上获得管理员访问权限。然后提取 krbtgt 帐户的 NTLM 哈希，用于创建黄金票据（GT）。krbtgt 帐户的 NTLM 哈希可以从域控制器（DC）内存中提取，或者通过 NTDS.DIT 活动目录数据库来提取。

如果攻击者丢失域管理员访问权限，只需要拥有在域内任何系统上的用户访问权限，可以重新引入之前生成的黄金票据（GT），使用传递票据（Pass the Ticket, PtT）攻击再次提升为域管理员。

所需条件：

域名域SIDkrbtgt帐户 的 NTLM 哈希需要伪造的域管理员账户名

白银票据（Silver Ticket, ST）

通过从内存中转储计算机帐户哈希，攻击者可以为该系统创建白银票据（Silver Ticket, ST）。

白银票据（Silver Ticket, ST）为单一服务或计算机的全访问通行证。这种攻击使用转储的计算机服务帐户 NTLM 哈希伪造服务票证（ST），通常可以冒充该系统的任何用户，包括域管理员。

由于身份验证过程不需要与密钥分发中心（KDC）通信，所以隐蔽性较强。创建白银票据（ST）需要使用服务账号的 NTLM 哈希，而这个哈希值大概率需要拿到域控制器（DC）的权限才能获得，所以白银票据（DC）大部分情况下作为后门存在。

计算机帐户密码应该每 30 天更改一次，但并不会总是更改。攻击者会关闭系统上的密码更新确保白银票据（ST）无限期地工作。

      所需条件：

域名域SID服务账号的 NTLM 哈希要伪造的用户帐户名域控IP可利用的服务

万能密钥（Skeleton Key）

攻击者具有访问域控制器的权限，可以利用 Mimikatz 工具注入 LSASS 进程，在进程内存中为任何域帐户的设置一个相同的后门密码（Skeleton Key）。用户的实际密码仍可用于身份验证，即使用户更改密码后，也可以使用万能密钥（Skeleton Key）进行身份验证。

非约束委派（Unconstrained Delegation）

通过域管理员权限配置了非约束委派（Unconstrained Delegation）的服务帐户机器上，LSASS 进程中缓存了用户的票据授权凭证（TGT）可模拟用户去访问域中任意服务。比如，服务 B 的服务帐户开启非约束委派，当用户 A 访问服务 B 时，会将用户 A 的票据授权凭证（TGT） 发送给服务 B 并保存进内存，服务  B利用用户 A 的身份去访问用户 A 能访问的任意服务。

约束委派（Constrained Delegation）

由于非约束委派的不安全性，Windows Server 2003 中引入了约束委派（Constrained Delegation），对 Kerberos 协议进行拓展，引入了 S4U（S4U2Self / S4U2proxy），运行服务代替用户向密钥分发中心（KDC）请求票据（TGT/ST）。

S4U2self（Service for User to S4U2Self）

可以代表自身请求针对其自身的 Kerberos 服务票据（ST）；如果一个服务账户的 userAccountControl 标志为 TRUSTED_TO_AUTH_FOR_DELEGATION，则其可以代表任何其他用户获取自身服务的票据授权服务器（TGS） 和服务票据（ST）。

• 用户 A 向 service1 发送请求。用户已通过身份验证，但 service1 没有用户的授权数据。通常是由于身份是通过 Kerberos 以外的其他方式验证的。

• 通过 S4U2self 扩展以用户 A 的名义向密钥分发中心（KDC）请求用于访问 service1 的服务票据1（ST1）。

• 密钥分发中心（KDC）返回给 service1 一个用于用户验证 service1 的服务票据1（ST1），其中可能包含用户的授权数据。

• service1 可以使用服务票据1（ST1）中的授权数据来满足用户的请求，然后响应用户。

• S4U2self 向 service1 提供有关用户的信息，但 S4U2self 不允许 service1 代表用户 A 向其他服务发送请求，这时需要 S4U2proxy 发挥作用了。

S4U2proxy（Service for User to Proxy）

可以以用户 A 的名义请求其它服务的服务票据（ST），限制了 S4U2proxy 扩展的范围。服务帐户可以代表任何用户获取在 msDS-AllowedToDelegateTo 中设置的服务的票据授权服务器（TGS） 和服务票据（ST），首先需要从该用户到其本身的票据授权服务器（TGS） 和服务票据（ST），但它可以在请求另一个服务的票据授权服务器（TGS）之前利用 S4U2self 获得其本身的票据授权服务器（TGS） 和服务票据（ST） 。

• 用户 A 向 service1 发送请求，service1 需要以用户 A 身份访问 service2 上的资源。

• service1 以用户 A 的名义向密钥分发中心（KDC）请求用户 A 访问 service 2 的服务票据（ST2）。

• 如果请求中包含特权属证书（PAC），则密钥分发中心（KDC）通过特权属证书（PAC）的签名数据来验证特权属证书（PAC） ，如果特权属证书（PAC）有效或不存在，则密钥分发中心（KDC）返回 service 2 的服务票据（ST2）给 service1，但存储在服务票据（ST2）的 cname 和 crealm 字段中的客户端身份是用户 A 的身份新信息，而不是 service1 的身份信息。

• service1 使用服务票据（ST2）以用户 A 的名义向 service2 发送请求，并判定用户 A 已由密钥分发中心（KDC）进行身份验证。

• service2 响应上一步 service1 的请求。

• 最终 service1 响应第一步用户 A 的请求。

不同于允许委派所有服务的非约束委派，约束委派的目的是在模拟用户的同时，限制委派机器/帐户对特定服务的访问。

注：约束委派攻击的前置条件是服务自身需要通过密钥分发中心（KDC）认证的票据授权凭证（TGT） ，如果攻击者获取配置约束委派的服务账户的密码或NTLM 哈希，就可以模拟域内任意用户，如，域管理员用户；并代表其用户获得对已配置服务的访问权限，即服务票据 （ST）。

基于资源的约束委派（Resource Based Constrained Delegation）

Windows Server 2012 中引入了约束委派基于资源的约束委派（Resource Based Constrained Delegation），与传统约束委派相比，不需要域管理员权限去设置相关属性，而将设置委派的权限交给了服务机器。

利用基于资源的约束性委派进行攻击的条件：

• 一个机器账户

域用户有一个 ms-ds-MachineAccountQuota 属性，即允许用户在域中创建计算机帐户的个数，默认是10。新的计算机帐户会自动注册域的 SPN

注：为什么是机器账户，而不能是普通用户账户，因为攻击过程涉及 S4U2Self 协议，而它只适用于具有 SPN 的账户，普通账户是没有 SPN。

• 一个有权限修改 msDS-AllowedToActOnBehalfOfOtherIdentity 的账户

查询域内计算机的 mS-DS-CreatorSID，这个值代表的是将计算机加入到域内的用户，它是具有修改 msDS-AllowedToActOnBehalfOfOtherIdentity 的权限。

如果我们拥有配置某台机器 msDS-AllowedToActOnBehalfOfOtherIdentity 的权限与创建机器账户的权限，那我们就相当于拿到了此机器的所有权限。

首先添加机器账户，修改 msDS-AllowedToActOnBehalfOfOtherIdentity 值为机器账户的 SID，然后以机器账户的身份伪造成本地管理员（administrator） 申请一张访问此机器账户机器的服务票据（ST），因为机器账户没有配置约束性委派，所以票据是不可转发的，但是在基于资源的约束性委派中S4U2self阶段的票据是不可转发的，最后利用服务票据（ST）去访问修改了 msDS-AllowedToActOnBehalfOfOtherIdentity 属性的机器。

通过基于资源的约束委派攻击，我们能够使普通域用户以域管理员身份访问计算机 CIFS 等服务，实现本地权限提升。

DCSync

域控制器（DC）经常相互通信，使用目录复制服务远程协议（MS-DRSR）协议同步和更新数据。

安全研究人员 Benjamin Delpy 和 Vincent Le Toux 发现了多种滥用此协议的方法，包括模拟域控制器并向真正的域控制器（DC）发送同步请求以获取任意帐户的密码哈希（和历史哈希）。甚至可以请求创建黄金票据（GT）的 krbtgt 帐户。

注：本地管理员（Administrator）、域管理员组（Domain Admins Group）或域控制器组（Domain Controllers Group）的用户和域控制器的机器帐户才有 DCSync 操作权限。

在域内任一机器上模拟域控制器，利用 DRS（Directory Replication Service）服务的 IDL_DRSGetNCChanges 接口向真正的域控制器（DC）发送数据同步请求，复制用户帐户凭证，而无需登录到域控制器（DC）。

注：DCSync 攻击不适用于只读域控制器（RODC）

DCShadow

DCSync攻击的反转利用，DCShadow攻击需要域管理员权限，创建恶意的域控制器，利用域控之间的数据同步复制，将预先设定的对象或对象属性注入正在运行的合法域控制器，创建域后门。

缓解措施

• 凭证保护（Credential Guard Win10+)

• 域保护用户组（Domain Protected Users Group Win8+)

• 远程凭证保护 （Remote Credential Guard Win10+)

• 受限管理员（Restricted Admin Win8+)

• 要求服务帐户的密码复杂性

• 定期更改服务帐户密码

• 组托管服务帐户（Group Managed Service Accounts）是一种很好的缓解措施

• 审计服务帐户异常活动

• 限制和保护域管理员

• 定期（每年）更改 krbtgt 密码

票据攻击的常见缓解措施：

• 传递票据（Pass the Ticket, PtT）：凭证保护（Credential Guard）；远程凭证保护（Remote Credential Guard）

• 超越哈希（Overpass the Hash, OPtH）：C凭证保护（Credential Guard）；域保护用户安全组（Domain Protected Users Security Group）；禁用 RC4 身份验证

• Kerberoasting/Kerberoast：长而复杂的服务帐户密码；组托管服务帐户（Group Managed Service Accounts）

• 黄金票据（Golden Ticket, GT）：域保护用户安全组（Domain Protected Users Security Group）；定期更改 krbtgt 密码

• 白银票据（Silver Ticket, ST）：定期更新机器帐户密码

• 万能钥匙（Skeleton Key）：域保护用户安全组（Domain Protected Users Security Group）；特权帐户使用智能卡

• 非约束委派（Unconstrained Delegation）：配置需要使用约束委派进行委派的服务器

• 约束委派（Constrained Delegation）：受保护用户组（Protected Users Security Group）；将所有高权限的管理员帐户配置为“帐户敏感且无法委派“

• 基于资源的约束委派（Resource Based Constrained Delegation）：受保护用户组（Protected Users Security Group）；将所有高权限的管理员帐户配置为“帐户敏感且无法委派“

• DCSync：域保护用户安全组（Domain Protected Users Security Group）；审计/限制具有复制权限的账户

• DCShadow：域保护用户安全组（Domain Protected Users Security Group）；审计/限制具有复制权限的账户

基于票据的攻击是最难检测和缓解的凭证问题之一，因为大多数票据攻击都使用 Kerberos 的正常功能。票据可以在一段时间内保持有效，即使在更改密码后也是如此。直到 Windows 10 和 Server 2016 才出现真正的缓解措施。

Windows 8.1 中引入的域保护用户安全组（Domain Protected Users Security Group）可以缓解超越哈希（OPtH）攻击，因为它不再使用 RC4 加密方案。默认情况下，票据的生命周期也较短为4 小时，但不能完全防止传递票据攻击，因为用户的票据仍存在于内存中。

Windows 10+ 中的凭证保护（Credential Guard）使用虚拟机隔离来防止访问用户的哈希和票据。可以防止管理员转储票据以用于攻击，例如，传递票据（PtT）或转储哈希值以用于超越哈希 （OPtH）攻击。

远程凭证保护 （Remote Credential Guard）和受限管理员（Restricted Admin） 措施，不会将用户票据传递到远程系统，即使在 RDP 等交互式会话期间也是如此。因此，当启用这些选项时，无法从远程系统窃取高价值帐户的票据。这有助于缓解票据传递（PtT）攻击。

凭证保护（Credential Guard）和远程凭证保护 （Remote Credential Guard），无法彻底防止 Kerberos 相关攻击。虽然用户帐户票据受到很好保护，但是服务票据仍然可能被滥用。

一种针对远程凭证保护 （Remote Credential Guard）的攻击是使用当前用户的令牌从域控制器请求任意服务帐户票据，然后可用于通过网络进行身份验证，攻击利用原理——即任何一个域用户都可以请求来自域控制器的任何一个域服务的票据。该票据具有运行该服务的服务帐户的 NTLM 哈希，攻击者寻找在域用户（或域管理员）帐户的上下文中运行的票据。然后可以离线破解哈希（Kerberoasting）。

缓解 Kerberoasting 攻击的最佳措施是定期更改服务帐户密码并使用更加复杂的密码。前者缩短了攻击者收集的票据的生命周期，后者有效地防止了 Kerberoasting。

Server 2008R2 首次引入组托管服务帐户（Group Managed Service Accounts），此功能每 30 天自动更改服务帐户密码并使用非常复杂的密码。但是，这些操作都不能完全防止服务票据滥用。需要长期主动监控具有异常活动高权限的服务帐户。

黄金票据（Golden Ticket）攻击难以识别和缓解。检测一种方法是查找内部所有的无效帐户（尽管也可以为有效帐户创建黄金票据）。终止当前使用的任何黄金票据（Golden Ticket），只能定期更改域控制器（DC）用于创建票据的 krbtgt 帐户密码。

reference

• https://dfirblog.wordpress.com/2015/12/13/protecting-windows-networks-kerberos-attacks

• https://cdn.atraining.ru/docs/CERT-EU-SWP_14_07_PassTheGolden_Ticket_v1_1.pdf

• https://github.com/nidem/kerberoast

• https://www.sans.org/blog/kerberos-in-the-crosshairs-golden-tickets-silver-tickets-mitm-and-more/

• https://mp.weixin.qq.com/s/WyFeKkmzIjqcbP5uciDW6Q

• https://www.dcshadow.com

• https://www.cyberark.com/resources/blog/no-more-pass-the-hash-exploring-the-limitations-of-remote-credential-guard

7. 凭证: NTDS.DIT

NTDS.DIT

Active Directory 域服务 （AD DS）数据库保存域内所有用户和机器帐户已加密的 NTLM 哈希，但使用的加密算法易于破解。

如何获得和使用的？

NTDS.DIT位于域控制器（DC）上的 WindowsNTDS 文件夹中。该文件已锁定，需要管理员访问权限才能加载驱动程序以访问磁盘文件或使用卷影复制。

常用工具

ntdsutil、VSSAdmin、NTDSXtract、MetaSploit、 PowerShell、ntdsdump

暴力破解

域控制器（DC）通常是攻击者在获得域管理员凭据后最先访问的地方之一。主要目标是 NTDS.DIT 文件。这个数据库拥有域内所有用户和机器帐户已加密 的 NTLM 哈希，可以提供对域中几乎所有资源的访问，包括那些即使是域管理员也无法访问的保护资源，帐户哈希是 NT 格式（对于旧系统可能是 LM）并且每个帐户的历史密码 NTLM 哈希记录也存在（非常适合在其他地方利用密码重用）。

NTDS.DIT 数据库采用可扩展存储引擎 （ESE）格式，位于 %SystemRoot%NTDS 文件夹中。该文件已锁定，因此无法通过普通方式复制。提取文件的最常见方法是加载驱动程序或工具，以提供对磁盘的原始访问（规避 Windows API 保护）或使用内置的卷影复制服务。无论采用何种技术，域控制器都需要管理员权限。

通过卷影复制提取，是目前最流行的选择。如果系统上没有卷影副本，攻击者可以创建一个卷影副本，还须从域控制器（DC）收集 SAM 和 SYSTEM 注册表配置单元，以便于解密数据库中的数据。

收集文件后，可以使用开源工具 NTDSXtract 完成离线提取。获得域中的每个用户的 NTLM 哈希。

缓解措施

这种攻击是迄今为止在域内可以完成的最危险和最具破坏性的攻击。在大多数情况下，如果攻击者获得了这种级别的访问权限，他们就可以控制整个企业。 因此，最相关的缓解措施是在攻击者获得域控制器（DC）的访问权限之前检测并阻止。

reference

• https://github.com/csababarta/ntdsxtract

原文始发于微信公众号（TahirSec）：Windows | 凭证窃取与缓解措施（二）