1. 项目背景与核心价值
做内网安全评估的朋友，对“拿到一台Windows主机之后怎么扩大战果”这件事应该都不陌生。很多时候，你手里已经有一个普通域账号，甚至只是拿到了一个本地管理员权限的跳板机，但接下来的横向移动总是被卡住——不是目标机器补丁打得太勤，就是杀软盯得太紧。这时候，Inveigh就能派上大用场。
Inveigh是一款运行在Windows平台上的网络攻击模拟与验证工具，核心功能是监听内网中的**LLMNR（链路本地多播名称解析）、mDNS（多播DNS）和NBNS（NetBIOS名称服务）**流量，并对此类请求进行响应，从而捕获内网用户在处理共享路径、访问错误域名时泄露的凭据哈希。它本质上是在模拟一种内网环境下相当常见的错误配置场景：Windows系统在标准DNS解析失败后，会退而求其次使用多播协议发起名称解析请求，Inveigh就是抓住这个“兼容性机制”来做文章。
为什么说它适合作为一个“全攻略”的讲解对象？因为Inveigh的功能覆盖面很广，既有被动监听，也有主动欺骗；既支持抓取NTLMv1/v2哈希，也支持抓取明文凭据（在特定协议下）；既有传统的PowerShell版本，也有更现代的C#版本（Inveigh Zero）。这意味着它不是一个“点了就完事”的脚本，而是需要你理解协议原理、掌握参数配置、懂得分析抓取结果，才能用好的工具。
这篇文章面向的读者，大概是三类人：
- 做内网渗透测试的工程师：需要用Inveigh验证内网名称解析层面的安全隐患，证明风险的可利用性。
- 做红队演练的成员：需要在限定时间内快速搭建凭据捕获链路，为后续横向移动或权限提升提供弹药。
- 做蓝队防御与检测规则开发的工程师：需要熟悉攻击工具的流量特征，才能在日志里发现它，写出有效的检测规则。
我接下来要讲的，不光是“Inveigh怎么用”，还会把背后的协议原理、参数选择的逻辑、运行时的坑、以及事后怎么分析数据都交代清楚。尤其是最后一部分——如何在企业环境里发现Inveigh的踪迹，这对防御方向的朋友会非常有用。
2. 核心功能拆解：它到底在抓什么、怎么抓
2.1 三种名称解析协议，为什么会被攻击者盯上
要理解Inveigh的运作，得先搞清楚Windows内网的一个历史包袱。
当一台Windows机器需要访问某个主机名（比如用户输入了\\fileserver或\\192.168.1.50之外的错误主机名），但DNS服务器没给结果时，系统不会直接报错，而是会按顺序尝试其他解析方式：
- DNS：标准解析，优先使用。
- LLMNR：通过UDP 5355端口发送多播查询，询问局域网内谁是这个主机名。
- NBNS：通过UDP 137端口发送NetBIOS名称查询广播。
- mDNS：类似LLMNR，多用于发现本地网络设备。
这里的问题在于：LLMNR和NBNS在设计上是“信任局域网内所有主机”的。任何一台机器收到查询请求后，都可以回应“我就是你要找的那台主机”。操作系统并不会去验证回应的真实性。攻击者只需要在内网里跑一个监听工具，等着某些粗心的用户（或某些配置不好的服务）发出这种解析请求，然后冒名顶替，就能引导受害者把凭据发过来。
Inveigh做的就是这件事。它监听UDP 5355、UDP 137、UDP 5353端口，一旦发现有名称解析请求，就立刻用自己配置的“假身份”回应。受害者收到回应后，会尝试与Inveigh建立会话，这个会话通常走的是SMB协议。在建立SMB会话的过程中，客户端需要向服务器证明自己的身份，于是Inveigh就拿到了NTLMv2哈希。
2.2 哈希捕获之外：Inveigh还能做什么
很多人把Inveigh简单理解为“抓哈希工具”，但实际上它的功能远不止这一点。根据实测，以下几个能力在实战中价值极高：
- HTTP/HTTPS监听：Inveigh可以启动一个伪造的HTTP服务，当受害者被引导访问这个服务时，浏览器会自动尝试使用当前Windows登录会话进行集成认证（IWA），从而泄露NTLM哈希。这在某些需要Web访问的场景下比SMB更隐蔽。
- LDAP认证捕获：支持监听LDAP协议上的认证请求，在某些域环境下能拿到哈希。
- WPAD（Web代理自动发现协议）欺骗：Inveigh可以模拟WPAD服务器，响应浏览器的代理自动配置请求，返回一个恶意的PAC文件。这个功能很“脏”，因为它不仅能抓哈希，还能引导受害者的浏览器流量经过攻击者控制的中转，实现中间人攻击。
- 明文凭据捕获：在HTTP基本认证、FTP、IMAP、SMTP等明文协议下，直接捕获用户账号密码。
- SMB中继辅助：虽然Inveigh本身不直接做中继，但它捕获到的哈希，可以直接配合其他工具进行NTLM中继攻击，在特定条件下甚至不需要破解就能拿下目标会话。
与其把Inveigh当“抓包工具”，不如把它看作一个“内网名称解析欺骗与凭据收集平台”。你通过它确认的不只是“网络里有没有人发哈希”，更是“网络里哪些主机、哪些用户存在可被利用的信任盲区”。
2.3 两个版本，怎么选
Inveigh目前有两个主要分支：
- PowerShell版（Inveigh.ps1）：早期版本，使用PowerShell脚本实现，功能稳定，但运行时资源占用相对较高，且容易被杀软查杀。适合在目标机器上有PowerShell执行环境且你不太担心被杀软发现的情况下使用。
- C#版（Inveigh Zero）：用C#编写的独立可执行程序，不依赖PowerShell，体积小、运行效率高、混淆空间大，是当前实战环境下的首选。Inveigh Zero还有一个优点：可以编译成多种形态（exe、dll、shellcode），方便在不同场景下加载。
我的建议是：新人先学PowerShell版，因为它参数直观、文档相对丰富，方便理解原理；实际评估或演练环境中，优先使用Inveigh Zero。原因很简单——现在内网环境里Windows Defender的查杀能力不弱，PowerShell版脚本落地后很容易触发扫描告警，而Inveigh Zero经过简单混淆后，过静态查杀的概率高得多。
3. 实战配置全流程：从环境准备到结果分析
3.1 环境与前置条件
在正式开始配置之前，先把话说明白：Inveigh是内网工具，测试环境请使用自己搭建的虚拟机网络，或在与客户签署授权协议的合规评估环境中使用，不要在不具备授权的网络中运行。
从技术层面上，Inveigh的运行环境要求很低：
- Windows 7及以上版本的Windows系统（推荐使用Windows Server 2016/2019或Windows 10/11虚拟机）。
- 网络适配器需要能够收到内网广播/多播流量，也就是说，运行Inveigh的机器与你想要捕获流量来源的机器，需要在同一个二层网络（同一网段或同一广播域）。跨网段时，LLMNR和NBNS的请求过不来，工具基本失效。
- 有管理员权限运行（Inveigh需要绑定低端口和监听原始套接字，普通用户权限受限）。
- 防火墙需要放行监听端口。Windows防火墙默认会拦截入站的UDP 5355/137等端口，运行前需要在防火墙上放行相应规则，或者直接把测试机的防火墙临时关闭（测试环境推荐后者，省事且避免踩坑）。
3.2 获取工具与基本验证
Inveigh Zero的获取方式，一般是通过代码托管平台直接下载已经编译好的Release版本，或者自己拉取源码用Visual Studio或dotnet CLI编译。这里我给一个最稳妥的路径：
- 在一台隔离的开发机（可以连外网）上下载Inveigh Zero的源码。
- 使用dotnet CLI编译（例如
dotnet build），生成exe。如果目标机器是纯x64环境，编译Release-x64版本即可。 - 将编译好的二进制文件拷贝到测试虚拟机，运行前先用
InveighZero.exe --help验证依赖库是否齐全（比如VC++运行库），缺什么补什么，避免到现场才发现跑不起来。
我个人习惯在编译时顺手对二进制做一个简单的“瘦身”——用UPX之类工具压缩体积。这样做的目的不只是减小文件体积，更重要的是降低特征检测的命中率。如果你用的是PowerShell版，那就不用编译，直接下载Inveigh.ps1到目标机器后Import-Module或者IEX远程加载即可。
3.3 模式选择：被动监听还是主动欺骗
Inveigh的运行模式可以大体分成两种，理解它们的使用场景，是配置的第一步：
被动监听模式：Inveigh只监听流量，不主动回应任何LLMNR/mDNS/NBNS请求。这种模式极其隐蔽，适合在“目标环境有大量用户正在产生名称解析错误流量”的场合使用。比如你测试的Subnet里有几百号办公人员，经常有人输错共享路径、手滑在浏览器里敲了\\xxx，被动监听就能默默收集哈希。这种模式的缺点是产出不稳定，运气成分较大。
主动欺骗模式（默认开启）：Inveigh回应所有可观察到的名称解析请求，并尝试引导请求者与自己的SMB/HTTP服务会话。这种模式效率极高，几乎每个请求都会转化为一次认证尝试，哈希产出量大大提升。但它的流量特征也更明显，容易被安全设备感知。
从实战角度，我建议在授权评估环境的初始侦察阶段用被动监听跑个15分钟，看看流量规模。如果哈希产出很少，再切到主动欺骗模式。这一套组合动作能帮你判断：当前网络的用户习惯是“容易踩坑”还是“很老实”，从而决定投入产出比。
3.4 关键参数逐一拆解
Inveigh Zero的命令行参数很多，刚开始看到会有点头大。我挑几个在实际配置中出镜率最高、对结果影响最大的参数，结合使用场景来说：
-Listener：指定使用的协议，常见值是SMB、HTTP、HTTPS、LDAP、mDNS、LLMNR、NBNS。默认全开。如果你只想验证SMB场景，可以大幅减小监听面以降低被发现的概率。-NBNS/-LLMNR/-mDNS：分别控制是否启用NetBIOS、LLMNR、mDNS的响应功能。建议默认全开，除非你有特定的验证目标。-StatusOutput：控制是否在控制台显示实时状态。测试时建议打开，方便观察；在实际评估现场，为了减少屏幕上的字符变化特征，可以关掉或降低输出频率。-HTTPPort：HTTP监听端口，默认是80。如果80端口已经被占用，可以改到8080或自定义端口。-SMBPort：SMB监听端口，默认是445。除非你明确知道自己在干什么，否则不要改这个端口。SMB客户端向服务器发起会话时，协议默认强制使用445，改了之后客户端会直接连接失败。-FileOutput：将运行日志输出到本地文件。这个参数很重要，特别是当你需要事后做详细分析或者向客户写报告时，日志是凭证来源的最好证据。-MachineAccount：是否接受机器账号（计算机账号）的认证请求。默认情况下，Inveigh会过滤掉机器账号的哈希，只保留用户账号，因为机器账号哈希密码周期短、破解价值低。但如果你的目标是验证某个服务器的配置问题，可以考虑放开这个选项。
还有一个参数值得特别关注：-Challenge。这个参数允许你指定一个固定的NTLM挑战值。在NTLM认证过程中，服务器会发送一个挑战值（Challenge）给客户端，客户端使用自己的密码哈希对该挑战值进行加密计算，生成响应（Response）。如果你不指定Challenge，Inveigh每次认证都会生成随机的Challenge，看起来更自然。但如果你要攻击的是一个已知账户，又想事后用彩虹表或预计算攻击加速破解，固定Challenge就很有用。它牺牲了一些自然性，换来了后续攻击链条的便利性。这个参数在不同场景下的选择，建议提前在实验室里测试确认。
3.5 一个完整的实战启动命令示例
假设场景：你在一台Windows Server 2019上运行Inveigh Zero，目标网段里有约200台办公终端，你需要做一次名称解析攻击模拟。我的推荐配置如下：
InveighZero.exe -FileOutput Y -StatusOutput Y -StatusOutputInterval 15 -LLMNR Y -NBNS Y -mDNS Y -HTTP Y -HTTPS N -SMB Y -FileOutputDirectory C:\temp\logs -MachineAccount N -Challenge Random解释一下选择逻辑：
-FileOutput Y：开启日志文件输出，方便事后写报告。-StatusOutputInterval 15：每15秒刷新一次控制台状态，不至于刷屏，又能实时掌握节奏。-HTTP Y、-HTTPS N：启用HTTP监听，禁用HTTPS。HTTPS需要配置证书，在实际场景中如果只是想抓哈希，HTTP已经足够；启用HTTPS需要额外准备证书，且证书合法性会引起客户端弹窗，反而暴露行为。-Challenge Random：使用随机挑战值，保证每次认证过程的自然性，避免因为相同Challenge被检测规则关联。
运行后，控制台会显示监听的端口状态，并实时输出捕获到的IP、主机名、用户名摘要。默认情况下，哈希会显示为NTLMv2-SSP Hash格式，这是目前破解工具（如Hashcat）最认的格式之一。
3.6 结果分析与下一步利用
当你捕获到一批NTLMv2哈希后，接下来有两条路：
路线一：离线破解。使用Hashcat等工具，将Inveigh输出的哈希直接喂给Hashcat进行字典攻击或暴力破解。NTLMv2哈希的破解速度受限于密码复杂度和算力，但好消息是内网用户的密码往往存在大量弱口令，字典攻击的命中率远超预期。我见过在“全员强制密码复杂度”的企业内网中，仍然能通过字典跑出一批P@ssw0rd、Welcome123之类的密码。
路线二：中继攻击。如果目标网络没有启用SMB签名（SMB Signing），你可以将捕获到的认证请求直接转发到另一台目标服务器上，冒充受害用户访问该服务器上的服务。这就是所谓的NTLM中继攻击。实际上我曾经在一个测试环境里，通过Inveigh捕获哈希后立刻进行中继，成功在另一台未打补丁的服务器上用捕获的凭据创建了计划任务，整个过程没用一次密码破解。
具体执行时，哈希日志文件里通常包含以下字段：Timestamp（捕获时间）、SourceIP（来源IP）、SourceHost（来源主机名）、Username（用户名）、Domain（域名）、Hash（哈希值）。保存好这些信息，既用于后续攻击，也用于报告编制。如果你的评估项目后续需要向客户证明“哪个用户名的密码最弱”，这就是最直接的证据链。
4. 常见问题与实战排查技巧
4.1 为什么跑了半天一个哈希都没抓到
这是新人最常遇到的问题。出现这个情况，排查顺序一般是：
- 网卡选错。Inveigh Zero默认监听第一个网卡，如果测试机有多块网卡（VMware环境下尤常见），可能监听的是不接业务流量的那块网卡。解决方法：运行前用
ipconfig查看所有网卡，通过参数指定正确网卡。 - 防火墙拦截。Windows防火墙默认拦截入站UDP端口，导致Inveigh根本收不到请求。测试环境直接关闭防火墙（
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False），生产环境评估时则放行具体端口并记录规则变更。 - 网段隔离。前面说过，LLMNR和NBNS是二层广播/多播，必须同网段。跨网段场景下Inveigh大概率颗粒无收。
- 客户端没有产生错误解析请求。如果内网DNS解析很干净，用户不乱输主机名，被动监听自然没产出。这时候就需要整体切换为主动欺骗模式，即便如此，也要等待用户发请求，不能把响应伪装替换原本的DNS解析流程。
4.2 捕获到哈希，但破解不出密码
不少朋友卡在这一步。NTLMv2哈希的破解难度相对较高，尤其是密码超过12位且包含大小写、数字、特殊字符时，纯暴力破解基本不现实。我建议的做法是：
- 先跑一份高质量字典（可以直接找公开的知名字典文件，或者通过规则变形生成）。
- 如果字典没跑出来，再用“掩码攻击”针对常见密码结构（比如
Capital+lower+数字+特殊字符的8位组合）做第二轮尝试。 - 如果还是没结果，果断放弃离线破解，转走中继路线。密码破解可以后续慢慢跑，时间成本别耗在评估的关键路径上。
4.3 Inveigh与杀软的对抗
Inveigh Zero本身是明文的C#程序，绝大多数杀软引擎都能检测到特征码。要规避其实有两条路线：
- 编译期混淆：使用混淆器对二进制做混淆处理，或者直接修改源码中的特征字符串后重新编译。这个操作虽然简单，但对绕过静态检测效果明显。
- 内存加载：用Cobalt Strike或其他后渗透框架将Inveigh加载到目标进程内存中执行，不落地文件，以规避文件扫描。不过这种方式对操作者的框架使用能力有要求，对纯Inveigh使用者来说可能有些重了。
坦白说，作为一个“模拟攻击工具”，Inveigh的本身定位就决定了它一定会在蓝队那边留下大量检测特征。如果你做的是红队实战演练，建议提前确认目标环境中是否有EDR产品，以及EDR对进程行为监控的严格程度。必要时候，放弃Inveigh改用轻量级自研脚本可能更有胜算。
4.4 流量特征自查表（给蓝队朋友）
如果你站在防御侧，想判断内网是否有人运行了Inveigh，可以从以下几个维度排查：
| 检测维度 | 特征表现 | 排查方法 |
|---|---|---|
| UDP端口监听 | 主机异常监听UDP 5355、137、5353端口 | 使用netstat -ano结合进程名检查 |
| SMB会话源 | 非文件服务器的IP向客户端回应SMB会话建立请求 | 分析SMB握手源IP是否为可疑地址 |
| 认证失败规律 | 短时间内对多个主机发起大量NTLM认证且挑战值相同 | 查看Windows安全日志4648、4771事件 |
| DNS与LLMNR流量比值 | LLMNR流量异常增高，且请求均被同一IP回应 | 抓包分析或使用NetFlow分析 |
| HTTP代理异常 | 非标准代理服务器返回PAC文件 | 分析HTTP代理自动配置请求的来源 |
蓝队朋友如果排查到上表的前两行特征，就可以开始考虑在内网启动应急响应流程了。
4.5 兼容性与运行环境避坑
在实际环境中，我遇到过几次比较棘手的兼容性问题：
- Windows Server Core环境：无图形界面的Server Core也能运行Inveigh Zero，但日志输出需要重定向到文件才能正常查看。这个不算问题，只是容易让人以为没运行成功。
- VMware虚拟机的网卡类型：如果测试虚拟机使用NAT模式而非桥接模式，它可能收不到真实内网的多播流量，导致工具静默失效。建议一律使用桥接模式，并确认网络交换机没有开启端口隔离。
- IPv6环境：现代Windows默认启用IPv6，LLMNR的查询也可能走IPv6路径（监听地址为
ff02::1:3组播）。Inveigh Zero对这些IPv6场景的支持没有IPv4那么完善，所以如果你的测试环境是纯IPv6，效果会打折扣。实操时，可以考虑在测试机网卡上临时禁用IPv6，逼迫客户端走IPv4路径。
4.6 日志文件分析小技巧
Inveigh的日志文件是纯文本格式，行数可能会非常庞大。我一般会直接用PowerShell做初步过滤，把最有价值的信息提取出来：
Get-Content in.txt | Select-String "NTLMv2"这样能把所有哈希行过滤出来。接着再用Select-Object -Unique按用户名去重，得到一个去重的“用户哈希清单”，这比在原始日志里大海捞针高效得多。另一个技巧是按来源IP聚合，看看哪些主机是“哈希大户”——这往往对应着网络里的高危用户（喜欢乱点链接、乱输地址的用户）。在写整改建议时，这就是重要的数据支撑。
5. 检测与防御视角：攻击工具的另一面价值
5.1 从攻防两端理解工具的意义
很多刚接触Inveigh的人会把它单纯理解为一个“攻击工具”。但作为长期做安全评估的从业者，我觉得更有价值的视角是：Inveigh是一面镜子，它照出的不是工具多厉害，而是内网基础配置有多脆弱。
换个角度想，如果你们公司内网的DNS解析完善、所有终端都禁用了LLMNR和NetBIOS、防火墙做了严格的入站规则，那么即使在内网里跑100遍Inveigh，它也只能空手而归。工具的成功率，直接取决于网络基础配置的“卫生程度”。
所以，在向管理层汇报评估结果时，我不建议把重点放在“Inveigh捕获了多少哈希”上，而应该转化为三条业务语言：
- 当前内网有多少比例的主机启用了LLMNR/NBNS自动解析（通过脚本扫描可评估覆盖范围）。
- 这些主机中有多少用户在评估期间访问了错误的共享路径（哈希捕获数量）。
- 哈希捕获后，攻击者利用这些哈希能访问哪些关键系统（通过中继或破解后的资产价值评估）。
这样的表述能把“工具演示”升华为“安全风险评估”，对推动整改资源的投入帮助最大。
5.2 针对性加固建议
基于Inveigh的攻击路径，防御方可以考虑以下加固手段：
- 组策略禁用LLMNR：通过
Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off multicast name resolution，设为Enabled。这是一条黄金配置，能堵住LLMNR攻击入口。 - 禁用NetBIOS over TCP/IP：在网卡高级TCP/IP设置中取消NetBIOS启用，或通过DHCP选项进行全局配置。这能进一步减少NBNS欺骗面。
- 启用SMB签名：在域策略中设置“Microsoft网络客户端/服务器：对通信进行数字签名（始终）”，这会显著增加NTLM中继攻击的难度。
- 限缩NTLM认证：通过
Network security: Restrict NTLM系列策略，限制NTLM在外网/入站请求中的使用范围。考虑到一些老旧系统兼容性，可以先从审计模式开始逐步收紧。 - 监控UDP 5355/137的异常监听：建立针对敏感端口监听情况的周期性检查任务，快速发现异常主机。
5.3 关于合法使用的必要提醒
Inveigh能力的边界，完全取决于使用者的授权范围。根据网络安全法和行业通用规范，任何形式的渗透测试、攻击模拟都必须满足以下条件：
- 在目标网络中有明确授权，且授权范围清晰到具体IP段、系统和时间窗口。
- 测试行为不会对业务系统造成不可恢复的影响（Inveigh本身不丢包、不改配置，但中继攻击可能产生会话干扰，需要在测试前充分评估风险）。
- 测试数据妥善保管，禁止泄露或用于非授权用途。
在实际项目中，如果客户因为“抓到了管理员哈希”而产生不必要的关注，通常需要解释清楚：工具捕获的是哈希而不是明文密码，且评估报告的焦点在于暴露面而非个人行为。保持透明、流程规范，才能让技术工作落地时不产生偏差。
5.4 对安全建设的延伸思考
Inveigh这类工具的存在，本质上在提醒我们：内网并不像很多人想象的那样“安全”。很多企业花了大量成本建设边界防御（防火墙、IPS、WAF），却忽视了内网协议本身的缺陷和终端配置的短板。等到攻击者已经通过钓鱼、漏洞利用、供应链等手段进入内网时，内网协议层面的弱点就成了横向移动的“高速公路”。
防御方应该利用Inveigh这一类工具主动进行“内网钓鱼演练”——在不影响业务的前提下，模拟攻击者放置监听点，收集哈希数据，再据此反向定位问题终端。这种方式的产出不是一份冷冰冰的报告，而是一串真实存在的用户名、IP和主机清单，整改责任人对这些数据无法推诿。
6. 个人经验与最后建议
做内网测试这些年，Inveigh是我工具箱中常备的一员，但它从来不是“银弹”。真正让测试有成效的，是对协议细节的理解、对目标网络环境的尊重，以及在动手前就把可能的影响面想清楚。我不止一次看到测试人员把Inveigh的主动欺骗模式开到最大，结果把整个网段的用户都引导到了自己的假SMB服务上，虽然哈希抓了一大堆，但业务部门投诉“系统时不时卡一下”，最后评估报告也不得不打折扣。
如果说有什么最想分享的个人教训，那就是：Inveigh的开箱即用性太强了，强到很容易让人忽视它背后的协议机制。花点时间把LLMNR、NBNS、WPAD、NTLM这些协议怎么看、怎么工作、在什么条件下可被欺骗搞明白，比多跑几个命令有用得多。你越懂协议，就越知道什么环境下开什么参数，什么时候该收手，什么时候该换工具。
另外，有个小习惯值得养成：每次跑完Inveigh，都把捕获到哈希的主机名和来源IP汇总成一张表格，当作“健康体检报告”存档。下一轮再做测试时，就可以对比一下——上次暴露出来的那些问题主机，这次还在不在名单上。如果一个季度过去了，同一个IP、同一个用户名还在列表里，那说明整改流程肯定哪里出了问题，这正是安全的真实状态。
