1. 项目概述：从端口扫描到认证攻击的思维跃迁

在渗透测试和网络安全评估的日常工作中，很多朋友，尤其是刚入行的新手，拿到一个Windows靶机后的第一反应往往是：上Nmap，扫端口。看到开放的445、135、3389，就想着去爆破、去尝试已知的漏洞利用。这当然没错，端口是服务的入口，是攻击的起点。但今天我想分享一个更深入的思路：端口扫描只是信息收集的“前菜”，真正的“主菜”往往隐藏在那些看似正常的网络协议交互背后，特别是身份认证这个环节。

这个项目的核心，就是打破“扫描-利用”的线性思维，教你如何将经典的网络发现工具Nmap与强大的中间人攻击工具Responder组合起来，形成一套“组合拳”。这套方法的目标不再是简单地发现开放服务，而是主动地、诱导性地去探测和利用Windows系统在网络认证过程中可能存在的脆弱性。你可能会发现，一个看似固若金汤、补丁齐全的Windows Server 2016或Windows 10系统，其最薄弱的环节并非某个具体的远程代码执行漏洞，而是它向网络宣告自己身份、请求服务时所用的协议。

简单来说，我们不再被动地等待扫描结果，而是主动“设局”，让目标机器在特定的网络环境下（通常是我们可控的局域网），向我们发起认证请求。通过分析这些请求，我们能够截获甚至破解其认证凭据的哈希值，从而为后续的横向移动或权限提升打开突破口。这尤其适用于内网渗透测试，当你拿下一台跳板机后，面对内网中大量Windows主机，这种手法往往能起到奇效。

2. 核心原理：LLMNR/NBT-NS投毒与Nmap的脚本化侦察

要理解这套组合拳，必须先弄懂两个核心概念：Windows的备用名称解析机制，以及Nmap的脚本引擎如何为我们提供精准的“攻击指引”。

2.1 Windows名称解析的“备胎”与Responder的毒药

在Windows网络中，一台机器要访问另一台机器，比如通过\\fileserver\share这样的路径，它首先需要将“fileserver”这个名字解析成IP地址。最正统的方式是查询DNS服务器。但如果DNS服务器查询失败（比如目标不在DNS记录里，或者DNS服务器本身不可达），Windows就会启用它的“备胎”机制：LLMNR（链路本地多播名称解析）和NBT-NS（NetBIOS名称服务）。

• LLMNR：基于多播，主机会在本地链路范围内喊话：“嘿，谁是fileserver？”，理论上同一网段的所有主机都能听到。
• NBT-NS：一个更老但依然广泛支持的协议，用于在缺少WINS服务器的网络中解析NetBIOS名称。

Responder工具的核心攻击原理，就是监听这些“备胎”协议发出的查询请求。当它监听到一个LLMNR或NBT-NS查询（例如，某台主机错误地输入了\\wrongserver\share，或者尝试访问一个不存在的网络资源）时，它会立刻跳出来响应：“我就是fileserver！”，从而将自己伪装成目标机器。接下来，当查询者（即我们的靶机）试图向这个假冒的“fileserver”进行身份认证以访问共享时，所有的认证流量（包括NTLMv1/v2哈希）都会被发送到Responder这里，从而被我们截获。

注意：这种攻击成功的前提是，目标网络内没有启用并强制使用DNS，或者用户/系统进程会尝试访问一些不存在的网络资源。在内网中，由于配置复杂或管理疏忽，这种情况非常普遍。

2.2 Nmap的深度：超越端口扫描的脚本引擎

Nmap远不止一个端口扫描器。它的NSE（Nmap Scripting Engine）脚本引擎是一个宝库。对于我们的组合拳，Nmap扮演了两个关键角色：

1. 精准的目标发现与服务识别：首先，我们用Nmap快速扫描网段，找出所有在线且开放了SMB（445/tcp）、RDP（3389/tcp）、WinRM（5985/tcp, 5986/tcp）等典型Windows服务端口的机器。这比盲目地让Responder监听整个网络更高效。
2. 漏洞与配置侦察：更重要的是，我们可以使用特定的NSE脚本对目标进行深度侦察。例如：
   • smb-os-discovery: 获取目标的操作系统版本、计算机名、工作组/域名。
   • smb-security-mode: 探查SMB服务签名的启用情况。如果签名未被强制要求，这为后续的中间人攻击提供了便利。
   • smb-vuln-*系列脚本：检查已知的SMB漏洞（如MS17-010永恒之蓝），虽然我们主要关注认证漏洞，但全面了解目标风险没有坏处。
   • http-ntlm-info: 如果目标开启了Web服务（如IIS），可以尝试获取NTLM认证信息。

这些信息对于我们评估攻击面、选择最可能响应LLMNR/NBT-NS投毒的目标（例如，那些处于工作组环境而非严格域环境、计算机名看起来像开发或测试机的目标）至关重要。

3. 环境准备与工具配置

在开始实操前，我们需要一个受控的环境。强烈建议在虚拟化环境（如VMware Workstation或VirtualBox）中搭建一个隔离的测试网络。

3.1 测试环境拓扑

一个典型的最小化测试环境包括三台虚拟机：

1. 攻击机（Kali Linux）：运行Nmap和Responder。需要配置为桥接或NAT模式，确保能与靶机在同一二层网络。
2. Windows靶机（如 Windows 10/11 或 Windows Server 2016/2019）：这是我们试图获取其凭据的目标。将其网络模式设置为与攻击机相同（例如，都连接到VMnet8的NAT网络）。
3. 可选：域控制器（Windows Server + AD DS）：如果你想模拟更真实的域环境，可以加入一台。在域环境中，LLMNR/NBT-NS投毒依然可能生效，尤其是当DNS记录不全或客户端配置错误时。

关键点：确保攻击机和靶机在同一个广播域内。你可以通过在攻击机上执行ip addr show或在靶机上执行ipconfig来确认它们是否在同一网段。

3.2 工具安装与基础配置

攻击机（Kali Linux）: Kali Linux通常预装了Nmap和Responder。如果没有，安装非常简单：

sudo apt update sudo apt install nmap responder -y

Responder基础配置： Responder的配置文件位于/etc/responder/Responder.conf。在发起攻击前，有几个关键选项需要审视：

• SMB = On/Off： 是否响应SMB协议请求。通常保持On。
• HTTP = On/Off： 是否响应HTTP协议请求。开启后可以捕获通过浏览器发起的NTLM认证。
• HTTPS = On/Off： 同上，针对HTTPS。
• SQL = On/Off： 响应MSSQL认证请求。
• LDAP = On/Off： 响应LDAP请求。
• FTP = On/Off： 响应FTP请求。
• Challenge = 1122334455667788： 这是NTLM质询（Challenge）。在实战中，有时为了兼容性或者特定破解工具的需要，可能会修改为一个固定值。但保持默认随机生成通常是最佳选择。

对于初次测试，我们可以先保持默认配置。但务必理解，开启的服务越多，Responder在网络上就越“活跃”，也越容易被网络监控设备发现。

4. 组合拳实战：从扫描到哈希捕获

现在，让我们进入核心的实操环节。整个过程是一个清晰的循环：侦察 -> 投毒 -> 诱导 -> 捕获。

4.1 第一阶段：Nmap侦察与目标筛选

假设我们的攻击机IP是192.168.1.100，我们需要扫描192.168.1.0/24网段。

步骤1：快速存活主机发现我们不需要一开始就进行全端口扫描，先用Ping扫描快速找出存活主机。

sudo nmap -sn 192.168.1.0/24

这个命令会列出所有在线的主机IP。从中找到我们的Windows靶机，假设其IP为192.168.1.150。

步骤2：针对性端口与服务扫描对靶机进行更细致的扫描，重点探测Windows相关服务。

sudo nmap -sS -sV -O -p 135,139,445,3389,5985,5986,80,443 192.168.1.150

• -sS: TCP SYN扫描，速度快且相对隐蔽。
• -sV: 探测服务版本。
• -O: 尝试识别操作系统。
• -p: 指定我们关心的端口。

步骤3：深度信息收集与漏洞初筛使用NSE脚本获取更详细的信息，这能帮助我们判断靶机的“攻击价值”和可能存在的弱点。

sudo nmap --script smb-os-discovery,smb-security-mode,smb-vuln-*,http-ntlm-info -p 445,80,443 192.168.1.150

输出分析与目标画像：

• 如果smb-security-mode显示message_signing: disabled，说明SMB签名未启用，这对于任何基于SMB的中间人攻击都是利好消息。
• 如果smb-os-discovery显示计算机名是DEV-WIN10，工作组是WORKGROUP，那么它很可能是一台工作组机器，更容易受到本攻击。
• 如果扫描结果显示开放了Web服务（80/443），且http-ntlm-info脚本能获取到信息，说明该Web服务可能支持Windows集成认证，这又增加了一个潜在的认证入口。

4.2 第二阶段：启动Responder布下陷阱

在另一个终端窗口，我们启动Responder，开始监听网络上的LLMNR/NBT-NS/mDNS请求。

sudo responder -I eth0 -wrf

• -I eth0: 指定监听网卡，请替换为你的实际网卡名（可用ip a查看）。
• -w: 启动WPAD代理服务器。很多Windows系统会自动寻找Web代理，此选项可以响应WPAD请求，进一步诱导流量。
• -r: 响应SMB协议请求。
• -f: 指纹主机。这能提供更多关于请求主机的信息。

启动后，Responder会安静地运行，等待“鱼儿”上钩。它的界面会实时显示监听到的协议活动和捕获到的哈希。

4.3 第三阶段：主动诱导与被动等待

这是最需要技巧和耐心的一步。我们需要让靶机产生那些会触发备用名称解析的请求。方法分为主动和被动：

被动等待：这是最基本的方式。什么都不做，等待网络中的正常活动。例如，用户可能在资源管理器里错误地输入了\\fileserve\share（少了个r），或者某个服务、计划任务在尝试访问一个已经不存在的网络路径。在内网中，这类“噪音”比你想象的多。

主动诱导：我们可以更积极地“推”靶机一把。方法有很多，其核心是让靶机尝试访问一个不存在的、但名字听起来合理的网络资源。

1. 利用Nmap的smb-brute脚本（谨慎使用）： 针对SMB服务进行弱口令爆破尝试。即使密码错误，靶机在认证过程中也可能泄露计算机名等信息，Responder可能捕获到相关流量。但这种方式会产生大量日志，不推荐在需要隐蔽的测试中使用。

   # 示例，仅用于理解原理，实际慎用 sudo nmap --script smb-brute --script-args userdb=/usr/share/wordlists/usernames.txt,passdb=/usr/share/wordlists/passwords.txt -p 445 192.168.1.150

2. 伪造资源定位器： 这是更优雅的方式。如果靶机上有可访问的共享（比如我们之前扫描发现的），我们可以尝试在其内部制造一个指向不存在主机的链接。但这通常需要一定的初始权限。
3. 针对Web服务的诱导： 如果靶机有Web服务，我们可以诱使用户（或模拟用户）访问一个需要NTLM认证的页面，或者访问一个嵌入类似file://fakehost/share链接的页面。

一个更通用且低交互的方法是，在攻击机上向靶机发起一个指向不存在主机的SMB连接请求。虽然这是从攻击机发起的，但有时会触发靶机的反向查询或相关网络行为。可以使用smbclient或rpcclient工具进行尝试，目标指向一个虚构的主机名。

# 示例：尝试用空会话连接一个不存在的主机 smbclient -L \\\\nonexistentserver -N -I 192.168.1.150

这个命令本身会失败，但它产生的网络流量有可能被Responder利用。

4.4 第四阶段：哈希捕获与初步分析

当诱导成功时，Responder的界面会突然变得活跃。你可能会看到类似下面的输出：

[LLMNR] Poisoned answer sent to 192.168.1.150 for name FAKESERVER [SMB] NTLMv2-SSP Client : 192.168.1.150 [SMB] NTLMv2-SSP Username : DEV-WIN10\Administrator [SMB] NTLMv2-SSP Hash : Administrator::DEV-WIN10:1122334455667788:2F4F4E8B...（很长一串）

恭喜！你捕获到了一个NTLMv2哈希！

Responder默认会将捕获到的哈希保存到/usr/share/responder/logs/目录下，文件名为SMBv2-*.txt或HTTP-*.txt等。

哈希类型解读：

• NTLMv1： 较老的格式，相对容易破解。在现代高版本Windows上较少见，除非系统或策略特意降级。
• NTLMv2： 目前最常见的格式，安全性比v1高很多，破解需要强大的算力（GPU）和庞大的密码字典。

捕获到的哈希格式通常是用户名::域名:质询:响应:响应...。对于工作组机器，“域名”就是计算机名本身。

5. 哈希的后续处理与利用思路

拿到哈希并不意味着游戏结束，它是一把“钥匙”，但还需要找到对应的“锁”或者把它“熔铸”成能用的形态。

5.1 离线破解哈希

这是最直接的方法。使用工具如John the Ripper或Hashcat，配合强大的密码字典和规则，尝试还原出明文密码。

使用Hashcat示例： 假设我们捕获的哈希保存在hash.txt文件中。

# 识别哈希模式（Hashcat模式号 5600 对应 NetNTLMv2） hashcat --example-hashes | grep -i ntlmv2 # 使用字典模式破解 hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt -O # 使用组合规则破解 hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

破解成功率完全取决于密码的复杂度和你的字典/规则强度。对于弱密码，可能在几分钟内就能破解；对于强密码，则可能遥遥无期。

5.2 哈希传递攻击

如果我们无法破解哈希，或者时间紧迫，可以尝试Pass-The-Hash (PTH)攻击。这种攻击允许我们直接使用捕获到的NTLM哈希（无需明文密码）向其他支持NTLM认证的服务进行身份验证。

常用工具：

• Impacket 套件： 这是一组Python脚本，功能极其强大。
  • psexec.py: 使用哈希（或密码）获取目标的半交互式Shell。

    python3 psexec.py -hashes :<NTLM哈希> <域名/用户名>@<目标IP> # 示例：python3 psexec.py -hashes :2F4F4E8B... DEV-WIN10/Administrator@192.168.1.150

  • smbexec.py: 类似psexec，但执行命令的方式不同，可能更隐蔽。
  • wmiexec.py: 通过WMI执行命令，是另一种常见的横向移动方式。
• CrackMapExec： 一款专为内网渗透测试设计的瑞士军刀，PTH是其核心功能之一。

  crackmapexec smb 192.168.1.150 -u Administrator -H <NTLM哈希> -x whoami

重要注意事项：哈希传递攻击的成功与否，取决于目标服务的配置。例如，SMB服务如果启用了“限制NTLM认证”或“要求SMB签名”，可能会阻止PTH攻击。这也是为什么之前我们用Nmap的smb-security-mode脚本进行侦察的原因。

5.3 中继攻击

这是比单纯捕获哈希更高级、危害可能更大的攻击。我们捕获到的认证请求，不单单是保存下来破解，而是实时地将其“转发”（中继）到另一台机器上，并以受害者的身份在第二台机器上执行操作。

为什么中继攻击更危险？

1. 无需破解哈希： 即时利用，成功率取决于中继目标的服务配置。
2. 权限提升： 可以将一个普通域用户的权限，中继到域控制器上，如果该用户在域控制器上有管理权限（例如，被加入了某些管理组），后果不堪设想。
3. 绕过NTLM破解难度： 直接绕过了对强密码哈希的破解。

实施中继攻击的挑战：

• SMB签名： 这是中继攻击最大的克星。如果中继目标（如另一台文件服务器或域控制器）强制要求SMB签名，那么中继过去的请求会被拒绝。Windows Server默认对域控制器之间的通信强制要求SMB签名，但对来自域成员的请求则不强制。这是一个关键的攻击面。
• 工具选择： Responder本身内置了简单的HTTP/S和中继功能，但更强大和灵活的中继工具是Impacket 的ntlmrelayx.py。

  # 基本的中继示例，将捕获的认证中继到指定目标 python3 ntlmrelayx.py -t smb://<目标服务器IP> -smb2support -socks # -socks 参数会开启一个SOCKS代理，我们可以通过这个代理以受害者的身份访问目标服务器资源。

在实际的内网渗透中，中继攻击往往与LLMNR/NBT-NS投毒结合，形成自动化攻击链：Responder负责毒化并捕获认证，ntlmrelayx负责将认证中继到预先定义好的高价值目标列表（如所有的域控制器、文件服务器）进行尝试。

6. 防御措施与检测建议

了解了攻击原理，作为防御方，我们应该如何应对？

6.1 根本性防御：禁用不安全的协议

最彻底的解决方案是在所有Windows主机上通过组策略禁用LLMNR和NBT-NS。

• 禁用LLMNR： 组策略路径：计算机配置 -> 管理模板 -> 网络 -> DNS客户端，启用“关闭多播名称解析”。
• 禁用NBT-NS： 在网络适配器的高级TCP/IP设置中，WINS选项卡下，选择“禁用TCP/IP上的NetBIOS”。

在企业域环境中，应通过组策略统一推送这些设置。同时，确保DNS服务健全且可靠，让主机没有理由去使用这些备用协议。

6.2 缓解措施：强化认证与访问控制

• 启用SMB签名： 对于所有服务器（尤其是域控制器），强制启用SMB签名。这能有效防御SMB中继攻击。组策略路径：计算机配置 -> 策略 -> Windows设置 -> 安全设置 -> 本地策略 -> 安全选项，将“Microsoft网络服务器：对通信进行数字签名（始终）”设置为“已启用”。
• 部署网络访问保护： 使用802.1X认证，确保只有授权设备才能接入网络，从物理层面减少攻击面。
• 实施网络分段： 将关键服务器（如域控制器）置于独立的VLAN中，并严格限制客户端与服务器之间、服务器与服务器之间的不必要的协议访问。
• 使用强密码策略： 增加NTLM哈希破解的难度。但这无法防御哈希传递和中继攻击。
• 尽可能使用Kerberos认证： 在域环境中，Kerberos比NTLM更安全。通过组策略限制NTLM的使用。

6.3 监控与检测

攻击总会留下痕迹，有效的监控可以及时发现威胁。

• 网络层监控： 部署IDS/IPS，设置规则检测LLMNR/NBT-NS协议的异常响应（例如，一个IP地址对大量不同的名称查询进行响应）。
• 主机层日志分析： 在Windows安全日志中，关注事件ID 4624（登录成功）和4625（登录失败），特别是登录类型为“网络”（Type 3）且登录进程为“NtLmSsp”的记录。如果发现来自同一源IP的大量NTLM登录尝试，尤其是失败尝试，可能意味着正在发生爆破或中继攻击。
• 使用微软的Attack Surface Analyzer等工具： 定期扫描系统，检查是否存在不安全的协议配置。

7. 实战中的思考与进阶技巧

在实际的渗透测试项目中，单纯运行工具往往不够。以下是一些从经验中得来的思考点：

1. 目标选择与时机：

• 工作时间 vs 非工作时间：在工作时间，用户活动频繁，触发备用名称解析的概率更高。但在非工作时间，自动化任务、计划任务可能会运行，它们也可能访问网络资源。
• 针对特定用户：如果通过前期信息收集，发现某个用户权限很高（如域管理员），可以尝试通过鱼叉式钓鱼邮件，诱导其点击一个指向\\your-fake-server\share的链接，从而精准捕获其哈希。

2. Responder的隐蔽性：

• 默认配置下的Responder非常“吵闹”。在需要隐蔽的测试中，可以考虑只开启最可能成功的服务（如SMB、HTTP），关闭FTP、SQL等不常用的。
• 修改默认的Challenge值有时可以绕过一些简单的哈希重复性检测，但这不是银弹。

3. 结合其他信息收集手段：

• 在启动Responder前，先用netdiscover,arp-scan等工具快速摸清网络结构。
• 使用enum4linux,ldapsearch等工具，如果已有一定权限，先收集域用户、计算机、组策略信息。这能帮你判断哪些是高价值目标，从而进行更有针对性的诱导。

4. 应对防御措施：

• 如果发现目标网络禁用了LLMNR/NBT-NS，不要气馁。可以尝试WPAD（Web代理自动发现协议）投毒或mDNS（多播DNS）投毒，Responder也支持这些。此外，针对IPv6的协议（如DHCPv6）也可能成为突破口。
• 对于启用了SMB签名的服务器，中继攻击失效。此时应回归到传统的漏洞利用、密码破解或寻找其他未受保护的服务（如WebDAV、未加密的WinRM等）。

这套“Nmap+Responder”的组合拳，其精髓在于思维的转变：从寻找漏洞到制造陷阱，从被动扫描到主动诱导。它迫使你更深入地理解网络协议是如何工作的，以及信任关系在何处可能被滥用。掌握它，你不仅多了一种强大的攻击手段，更能以攻击者的视角重新审视和加固你所要防御的网络环境。