别再只盯着密码了！从Wireshark抓包实战，一步步拆解Windows NTLM认证的完整流程
从流量视角透视Windows NTLM认证：一次完整的SMB共享访问抓包实验
在网络安全领域，理解认证协议的实际运作方式远比记住理论概念重要得多。当我们谈论Windows NTLM认证时，大多数文档都会展示那个经典的"协商-质询-认证"三步流程图，但真正能说清楚每个阶段网络数据包具体交换了什么内容的人却不多。本文将带你用Wireshark亲手捕获一次真实的SMB共享访问过程，像拆解精密钟表一样，逐层剖析NTLM认证的每个数据包。
1. 实验环境搭建与基础准备
1.1 实验拓扑设计
我们需要准备两台Windows机器（建议使用Windows 10或Server 2016以上版本），保持它们在同一个局域网内。实验拓扑非常简单：
- 客户端：192.168.1.100（随意配置，建议关闭防火墙）
- 服务器：192.168.1.200（需要开启SMB共享服务）
提示：在服务器上创建一个测试共享文件夹，并设置允许特定用户访问的权限。建议专门为实验创建一个测试账户，避免使用生产环境凭据。
1.2 必要工具安装
确保客户端已安装以下工具：
- Wireshark（最新稳定版）
- Nmap（用于基础网络探测）
验证SMB服务是否开启的快速方法：
nmap -p 445 192.168.1.200如果看到445端口状态为"open"，说明SMB服务正在运行。
1.3 Wireshark抓包配置
启动Wireshark后，选择正确的网络接口（通常是以太网或Wi-Fi适配器），然后在过滤栏输入：
smb || nbns || nbss || ntlmssp这个过滤表达式会捕获所有与SMB协议、NetBIOS名称服务以及NTLM安全支持提供程序相关的流量。
2. NTLM认证全流程抓包分析
2.1 初始连接阶段
当我们执行net use \\192.168.1.200\share命令时，首先会观察到几个预备数据包：
- NetBIOS名称解析（NBNS）：客户端通过广播查询目标服务器的NetBIOS名称
- SMB会话建立：TCP三次握手后的SMB协议协商
- SMB Tree Connect：客户端尝试连接共享目录
这些预备步骤与NTLM认证无关，但构成了后续认证的基础通信通道。此时如果查看SMB头部的SessionID字段，会发现其值为0x00000000，表示尚未建立认证会话。
2.2 NTLM Type 1 - 协商消息
第一个关键的NTLM数据包是客户端发送的Type 1 Negotiate消息。在Wireshark中，这个包通常被标记为"NTLMSSP_NEGOTIATE"。我们需要重点关注几个字段：
| 字段名 | 值示例 | 含义 |
|---|---|---|
| NTLMSSP Identifier | NTLMSSP | 协议标识 |
| Message Type | 1 (0x00000001) | 消息类型 |
| Flags | 0xE2898235 | 能力协商位图 |
Flags字段的每个比特位都代表客户端支持的功能。例如：
- Negotiate 128(位5)：请求128位加密
- Negotiate NTLM(位9)：必须设置为1
- Request Target(位10)：请求服务器返回认证目标信息
2.3 NTLM Type 2 - 质询消息
服务器响应Type 1的消息是Type 2 Challenge。这个数据包中有两个关键信息：
- Challenge字段：8字节或16字节的随机值（取决于NTLM版本）
- Target Name字段：服务器的域名或主机名
在Wireshark中展开NTLMSSP部分，可以看到类似如下的结构：
NTLM Secure Service Provider NTLMSSP Identifier: NTLMSSP NTLMSSP Message Type: CHALLENGE (0x00000002) Target Name: WIN-SERVER Flags: 0xE2898235 Challenge: 5f3d6c8a1b9e4d72这个Challenge值是整个认证过程的核心，它会被用于后续的响应计算。值得注意的是，现代Windows系统默认使用NTLMv2，此时Challenge是16字节的随机数。
2.4 NTLM Type 3 - 认证消息
客户端收到Challenge后，会使用用户密码的NTLM Hash对其进行加密计算，生成Type 3 Authenticate消息。这个数据包包含以下关键组件：
- LM Response：较弱的响应值（现代系统通常填充固定值）
- NTLM Response：真正的认证凭证
- User Name：请求认证的用户名
- Workstation Name：客户端主机名
在Wireshark中，NTLMv2 Response的结构通常如下：
NTLMv2 Response HMAC-MD5: 0e97ca7fc432ed1c57443906451e0768 Blob: 0101000000000000D61B2FEB9153DA010F07D4CFA041319E...这个响应值的计算过程涉及多个加密步骤，我们将在下一章详细拆解。
3. NTLMv2响应值的深度解析
3.1 NTLMv2 Hash的计算
NTLMv2响应不是直接用密码Hash加密Challenge得到的，而是经过多层转换。首先需要计算NTLMv2 Hash：
import hashlib import hmac password = "Passw0rd!" user = "Administrator" domain = "WIN-SERVER" # 计算NTLM Hash ntlm_hash = hashlib.new('md4', password.encode('utf-16le')).digest() # 计算NTLMv2 Hash ntlmv2_hash = hmac.new( ntlm_hash, (user.upper() + domain).encode('utf-16le'), digestmod='md5' ).digest()这个NTLMv2 Hash将作为下一步HMAC计算的密钥。
3.2 Response的完整生成过程
完整的NTLMv2 Response由两部分组成：NTProofStr和Blob。计算过程如下：
构造Blob：
- 当前时间戳（8字节）
- 客户端随机数（8字节）
- 目标信息（从Type 2消息获取）
- 随机填充数据
计算NTProofStr：
challenge = b"\x5f\x3d\x6c\x8a\x1b\x9e\x4d\x72" blob = b"\x01\x01\x00\x00\x00\x00\x00\x00\xD6\x1B\x2F\xEB\x91\x53\xDA\x01..." ntproof_str = hmac.new( ntlmv2_hash, challenge + blob, digestmod='md5' ).digest()- 组合最终Response：
Response = NTProofStr + Blob3.3 关键字段的Wireshark定位
在分析抓包数据时，以下几个字段值得特别关注：
- NTLMSSP_AUTH中的NTLMv2 Response字段
- Session ID的变化（认证成功后不再为0）
- SMB Tree ID在成功认证后的后续请求中保持一致
可以通过Wireshark的"Follow TCP Stream"功能查看完整的认证对话序列。
4. 安全分析与防御建议
4.1 NTLM协议的已知弱点
从抓包分析可以看出NTLM协议的几个固有安全问题：
- 基于单向Hash：无法有效防御重放攻击
- 无服务器认证：客户端无法验证服务器身份
- Session安全性依赖随机数质量
4.2 常见攻击手法与检测
| 攻击类型 | 依赖条件 | 检测方法 |
|---|---|---|
| Pass-the-Hash | 获取NTLM Hash | 监控异常登录行为 |
| NTLM Relay | 中间人位置 | 分析SMB登录源IP |
| 暴力破解 | 弱密码策略 | 审计失败登录日志 |
4.3 加固配置建议
对于必须使用NTLM的环境，建议实施以下防护措施：
- 启用SMB签名：
Set-SmbServerConfiguration -RequireSecuritySignature $true - 限制NTLM版本：
# 仅允许NTLMv2 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel" -Value 5 - 网络层防护：
- 限制445端口的访问范围
- 部署IDS规则检测NTLM Relay尝试
在实验过程中，我注意到一个有趣的现象：即使启用了Kerberos的环境，当DNS解析失败时，Windows仍会回退到NTLM认证。这提醒我们，仅仅配置Kerberos并不足够，必须彻底禁用NTLM才能真正消除相关风险。