当使用 Windos 域时，所有凭据都存储在 DC 中，当用户尝试使用域凭据对服务进行身份验证时，该服务需要请求 DC 验证他们是否正确

  • Kerberos : 最新版本使用，也是默认协议
  • NetNTLM : 为兼容目的保留的身份验证协议

(NTLM 身份验证数据包中存在标头 **<font style="color:#DF2A3F;">NTLMSSP</font>**)

NetNTLM

:::info NetNTLM 通常称为 WIndows 身份验证或者 NTLM 身份验证，允许应用程序在客户端和 AD 之前扮演中间人的角色，所有的身份验证都以质询的形式转发给 DC， 如果成功完成，应用程序将对用户进行身份验证。

在验证过程中，注意是应用程序接收到用户的凭证，去 DC 验证

:::

NetNTLM 协议的认证过程分为三步：

  • 协商 ： 确认双方协议版本
  • 质询 ： 就是 挑战(Chalenge)/响应 (Reponse) 认证机制起作用的范围
  • 验证 ： 在质询完成后，验证结果

质询的完整过程：

  • 客户端向服务器发送用户信息 (用户名) 请求
  • 服务器接收到请求，生成一个 16 位的随机数，称为 “Challenge” ， 使用登陆用户名对应的 NTLM Hash 加密 “Challenge” 生成 “Challenge1”， 同时生成后将 “Challenge” 发送给客户端
  • 客户端接收到 “Challenge” 后使用将要登陆用户对应的 NTLM Hash 加密 “Challenge” 生成 Response, 然后将 Response 发送至服务器端

其中，经过NTLM Hash加密Challenge的结果在网络协议中称之为Net NTLM Hash

验证： 服务器端接收到客户端的 Response 。比较 “Challenge1” 和 Response 是否相等，若相等认证通过

Challenge 是 Server 产生的一个 16 字节的随机数，每次认证不同

整个过程如下：

NetNTLM 验证 - 图1

  1. 客户端向他们要访问的服务器发送身份验证请求。
  2. 服务器生成一个随机数并将其作为挑战发送给客户端。
  3. 客户端将他们的 NTLM 密码哈希与质询（和其他已知数据）结合起来生成对质询的响应并将其发送回服务器以进行验证。
  4. 服务器将质询和响应转发给域控制器进行验证。
  5. 域控制器使用质询重新计算响应并将其与客户端发送的原始响应进行比较。如果它们都匹配，则客户端通过身份验证；否则，访问被拒绝。认证结果被发送回服务器。
  6. 服务器将认证结果转发给客户端。

请注意，出于安全考虑，用户的密码（或哈希）永远不会通过网络传输。

注意：所描述的过程适用于使用域帐户的情况。如果使用本地帐户，服务器可以验证对质询的响应，而不需要与域控制器交互，因为它在其 SAM 上本地存储了密码哈希。

IP 与 主机名

两者之间有区别吗 dir \za.tryhackme.com\SYSVOL和dir \\SYSVOL

有相当大的差异，它归结为所使用的身份验证方法。当我们提供主机名时，网络身份验证将首先尝试执行 Kerberos 身份验证。由于 Kerberos 身份验证使用票证中嵌入的主机名，因此如果我们改为提供 IP，则可以强制身份验证类型为 NTLM。虽然从表面上看，这对我们来说并不重要，但最好了解这些细微的差异，因为它们可以让您在红队评估期间保持更加隐蔽。在某些情况下，组织将监控OverPass-and Pass-the-Hash攻击。强制 NTLM 身份验证是书中避免在这些情况下检测的好技巧。