在撰写本文时，这些基线仍然处于“草案”状态。草案版本的基线可以在这里找到。

在Microsoft的建议中，仍然存在一些问题，并且可能需要继续进行修订。在本文中，我们按照现有版本进行分析，但对于凭据保护方面我做出了必要的修改。我将在后文中解释为什么必须对其进行修改。

问题1

当有用户进行错误类型的SMB共享时，我能够捕获多播的哈希值。

修复方案：

禁用组策略中的“多播名称解析”（Multicast Name Resolution），如下图所示。

问题2

仍然存在NBT-NS（Netbios）投毒（Poisioning）的问题。我无法使用与问题1中相同的方法捕获到任何哈希值。如果不在网络上使用，则应该将Netbios关闭。

修复方案：

通过组策略首选项，或者通过手动插入注册表的方式，创建以下注册表项。（Dword Value NodeType）

问题3

即使网络客户端和域成员都启用了SMB签名，我们也能够直接查看Responder的SMB共享，或者在网页上嵌入共享并使其隐藏，同时仍然转储哈希值。

尝试与Responder建立SMB连接的截图。

密码哈希值立即被转储，无需输入。

在Responder中执行以下命令。在这里，并非WPAD存在问题，而是SMBv2在转储HTLM哈希值过程中出现了问题。

修复方案：

限制传出的NTLM流量。在将规则设置为“Deny All”（全部拒绝）之前，我们应该首先对流量进行审计。审计将允许我们通过NTLM操作日志收集NTLM相关事件。至少应该针对特权访问工作站的事件进行审计。如果存在可以访问的远程系统，但该系统无法处理NTLM之外的任何其他内容（例如Kerberos），那么这样的设置将会带来问题。幸运的是，还有另一种设置，允许在服务器出现异常的情况下请求NTLM身份验证。

日志表明，访问Responder CIFS共享的行为被阻止。

下面是阻止时的提示，并且无法使用Responder捕获哈希值。

如果大家想要了解关于此设置的更多信息，建议阅读Microsoft官方文档

如果大家希望将NTLM限制在整个域内，建议参考这里方法。

问题4

关于WPAD，同样存在一些注意事项。从2.3.2版本开始，就启用了Responder的代理身份验证。我尝试对其进行强制身份验证，以实现无需交互，透明地获取凭据。然而，这一点不适用于Windows 10 RS5，但后者能够通过转到Responder IP来获得NTLM响应。

如问题3中所述，针对出站NTLM进行身份验证限制，是一个针对恶意WPAD代理服务器的有效对策，因为Responder将尝试使用NTLM身份验证来捕获凭据。

Windows 10 RS5（1809）在这方面存在一些问题，默认情况下，系统会启动自动代理发现。

此外，WinHTTP Web代理自动发现服务（WinHTTP Web Proxy Auto-Discovery Service）默认是运行的，其运行过程中需要依赖。

我建议关闭代理页面上的“自动检测设置”选项。如果必须要启用这个选项，那么我建议部署一个持续启用的VPN连接，并带有免费Wi-Fi热点，以防止无意中泄露密码哈希值。

如果后续再发现有其他需要注意的地方，或者各位读者提出了任何其他建议，我都会再对这篇文章进行更新。