NTLM身份验证由3种消息类型组成：NTLM_NEGOTIATE，NTLM_CHALLENGE，NTLM_AUTHENTICATE。为了确保恶意行为者不在传输过程中处理消息，在NTLM_AUTHENTICATE消息中添加了一个额外的MIC（消息完整性代码）字段。MIC是使用会话密钥应用于所有3个NTLM消息的串联的HMAC_MD5，该会话密钥仅对启动认证的帐户和目标服务器是已知的。因此，试图篡改其中一条消息的攻击者（例如，修改签名协商）将无法生成相应的MIC，这将导致攻击失败。

MIC的存在在NTLM_AUTHENTICATE消息的'msvAvFlag'字段中公布（标志0x2表示该消息包括MIC），它应该完全保护服务器免受试图移除MIC并执行NTLM中继的攻击者的攻击。但是，我们发现 Microsoft服务器不利用此保护机制并允许无符号（无MIC）NTLM_AUTHENTICATE消息。

强制执行SMB签名，开启域中所有服务器的强制SMB执行功能 （在 Windows 域环境下，默认只有域控服务器开启了强制 SMB 签名）

尽量不使用NTLMv1，因为NTLMv1的安全性较低，可以通过设置GPO来完全禁止

启用所有域控服务器的强制 LDAPS Channel Binding 功能 （此功能默认不启用。启用后有可能造成兼容性问题。）

启用所有域控服务器的强制 LDAP Signing 功能，防止LDAP中的NTLM中继 （此功能默认不启用。启用后有可能造成兼容性问题。）

开启EPA，防止Web服务器上的NTLM中继，强制所有Web服务器（OWA，ADFS）只接受EPA的请求

开启所有重要服务器（比如所有 Exchange 服务器）上相关应用的Channel Binding 功能（如 IIS 的 Channel Binding 功能）

减少使用NTLM，即使是安全配置和完全修补的NTLM也比Kerberos更不安全

[1]. https://blog.preempt.com/drop-the-mic
[2]. https://blog.preempt.com/security-advisory-critical-vulnerabilities-in-ntlm
[3]. https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/

主要是将SMB重放到LDAP，可以通过使Windows服务器（如Exchange）对我们进行身份验证，并将该身份验证通过LDAP中继到域控制器，则可以在ActiveDirective中以重放的受害者权限执行操作。在Exchange情境中，这具备足够高的权限来产生我们自己的DCSync权限，而这种权限是PrivExchange漏洞的基础。   
另外一种场景是滥用Resource Based Constrained Kerberos的委派机制，该种机制可以导致在受害者主机授予攻击者权限，导致可以以管理员权限访问该服务器。 但是NTLM协议的工作方式，无法将SMB流量重放到LDAP，因为标志位的变动将会出发LDAP签名。

关键步骤是CVE-2019-1040使得攻击者可以在不改变原有身份验证的情况下修改NTLM身份验证数据包，删除用于阻止从SMB重放到LDAP的标志。

1. 使用任意AD账户，通过SMB连接到受害者Exchange服务器，触发SpoolService的bug。攻击者服务器将通过SMB连接到受害者,SMB可以通过修改后的ntlmrelayx版本重放到LDAP。使用重放的LDAP身份验证,向攻击者帐户授予DCSync权限。攻击者现在可以使用DCSync转储AD中的所有密码哈希。
2. 使用任何AD帐户,通过SMB连接到受害服务器,并触发SpoolService 错误。攻击者服务器将通过SMB连接到您,SMB可以通过修改后的ntlmrelayx版本中继到LDAP。使用中继的LDAP身份验证,将受害者服务器的基于资源的约束委派权限授予攻击者控制下的计算机帐户。攻击者现在可以作为受害者服务器上的任何用户进行身份验证。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！