CodeKitHub工具介绍
NTLM（NT LAN Manager）是微软的一种遗留挑战-响应认证协议，至今仍用于本地 Windows 账户登录，在许多 Active Directory 环境中也作为后备认证方式存在。它的密码验证值——通常被称为"NTLM 哈希"——在微软自己的 MS-NLMP 协议规范中被定义为 `MD4(UTF-16-LE(password))`：先把密码编码为 UTF-16 小端序（不同于 UTF-8，每个字符都变成 2 字节），然后对这段字节序列执行一次 RFC 1320 定义的 MD4 算法。
UTF-16LE 这一步，是大多数人重新实现 NTLM 时最容易搞错的细节：如果哈希的是字符串的 UTF-8 字节而不是 UTF-16LE 字节，会得到一个完全不同、错误的摘要，尽管肉眼看到的文本是一样的。这个工具的编码方式是正确的，因此其输出与 Windows 自身存储的值、以及 hashcat（模式 1000）和 Mimikatz 所期望的值完全一致。
由于 NTLM 出现的年代早于现代密码哈希设计，它完全不具备后来为对抗破解而专门加入的那些保护措施：没有针对每个用户的盐值，没有可调节的工作量因子，也没有刻意的多轮迭代。它只是一次 MD4 运算，因此计算速度极快——这对遗留系统的兼容性很方便，但对抵御暴力破解和字典攻击来说却是灾难性的。
为什么使用它？
- 刚在一次授权渗透测试中从客户的NTDS.dit里提取了一批哈希，想在把完整转储丢进hashcat之前，先确认自己写的解析脚本输出的哈希格式是否正确。
- 在开发自己的凭据审计工具，刚按照MS-NLMP规范手写了一版MD4(UTF-16LE)实现——把"password"这个已知测试向量粘进来，确认输出确实是8846F7EAEE8FB117AD06BDD830B7586C，再放心用在真实数据上。
- 在做一个关于Windows认证的CTF题目或家庭实验环境练习，需要快速算出某个密码对应的NTLM哈希应该是什么样，又不想为了查一个值专门开一台Windows虚拟机。
- 在讲一门关于遗留认证漏洞的安全课程，想现场给学生演示：因为NTLM没有加盐，同一个密码不管属于哪个账户、哪个域，得到的哈希永远完全一样。
- 100% 本地计算：你的输入不会离开浏览器，即使在授权评估中处理敏感凭据材料也很安全。
使用方法
- 在输入框中输入需要哈希的密码或字符串。
- 点击"生成 NTLM 哈希"。
- 查看 32 个字符的十六进制 NTLM 哈希（默认输出大写，与 Windows 及大多数破解工具的显示方式一致——取消勾选可改为小写）。
- 点击"复制"将哈希复制到剪贴板。
示例
输入
password输出
8846F7EAEE8FB117AD06BDD830B7586C这是一个广为人知、可独立验证的测试向量：字符串 "password" 的 NTLM 哈希永远是 8846F7EAEE8FB117AD06BDD830B7586C。你可以用任何其他正确的 NTLM 实现来核对这个工具的输出。
NTLM 与现代密码哈希方案对比
下表说明了为什么 NTLM 被认为已不适合用来保护新系统，尽管它仍然嵌入在遗留的 Windows 与 Active Directory 基础设施中。
| 属性 | NTLM | bcrypt / scrypt / Argon2 |
|---|---|---|
| 底层原语 | 单次 MD4 运算 | 专为慢速设计、成本可调的哈希算法 |
| 加盐 | 无——相同密码永远得到相同哈希 | 每个密码使用唯一的随机盐值 |
| 迭代 / 拉伸 | 无 | 可配置的工作量因子，可随时间调高 |
| 抗暴力破解能力 | 很弱——现代 GPU 每秒可尝试数十亿次 | 刻意让每次猜测的代价都很高 |
| 目前仍在使用的场景 | 遗留 Windows 认证、Active Directory 后备方案 | 新应用、当前最佳实践 |
相关工具
如果你需要的是通用的加密哈希，而不是 NTLM 专属的 MD4(UTF-16LE) 构造，以下工具可能更适合。
常见的NTLM核对场景
这个工具最大的价值，是作为一次更大的授权工作流里的快速核查步骤——在把某个值真正投入更大的流程之前先确认它是对的，而不是取代那个流程本身。
| 场景 | 核对的是什么 | 为什么重要 |
|---|---|---|
| 自研脚本验证 | 自己实现的MS-NLMP算法对照已知测试向量 | 在UTF-8与UTF-16LE的bug悄悄污染整批数据之前就发现问题 |
| 提取哈希抽查 | 某条从SAM/NTDS.dit提取的记录对照预期明文 | 确认提取工具正确解析了数据格式 |
| hashcat/Mimikatz格式核对 | 输出结构是否符合模式1000的预期 | 避免用格式错误的哈希列表跑了一整轮徒劳的破解任务 |
| 培训与CTF练习 | 手动算出的哈希对照工具的输出结果 | 一步步建立对MS-NLMP实际运作方式的直觉理解 |
常见问题
NTLM 哈希到底是什么？
它是 Windows 为 NT LAN Manager 认证计算并存储的密码验证值，定义于微软的 MS-NLMP 规范，公式为 MD4(UTF-16LE(password))——即对密码的 UTF-16 小端字节编码执行一次 MD4 运算。结果始终是 128 位，显示为 32 个十六进制字符。
为什么偏偏是 UTF-16LE，而不是 UTF-8 或 ASCII？
自 NT 设计之初，Windows 内部就一直以 UTF-16LE 存储文本，因此密码在哈希前也按这种方式编码。每个字符都会变成 2 字节（小端字节序），包括普通的 ASCII 字符，比如 'a' 会变成 0x61 0x00 而不只是 0x61。对同一字符串的 UTF-8 字节做哈希会得到完全不同的错误结果——这是从零实现 NTLM 时最常见的一个 bug。
NTLM 在今天还安全吗？
不安全，微软自己也建议尽可能改用 Kerberos 来替代它。NTLM 没有盐值，所以相同的密码在任何用户、任何系统上永远得到相同的哈希，这使得预先计算好的彩虹表查询成为可能。它也没有迭代或工作量因子——只是一次不加盐的 MD4 运算——现代 GPU 每秒可以对捕获到的哈希尝试数十亿次猜测。它之所以还存在，主要是为了兼容旧版 Windows 系统和应用程序。
NTLM 和 bcrypt、scrypt、Argon2 这类现代密码哈希算法有什么不同？
现代密码哈希算法刻意设计得很慢，并且带盐：bcrypt、scrypt 和 Argon2 都会为每个密码添加唯一的随机盐值，以及一个可调的成本因子，可以随硬件性能提升而不断调高，专门用来让大规模暴力破解的代价变得昂贵。NTLM 两者都没有——它设计于离线暴力破解还不算现实威胁的年代，这一点在它的设计上暴露无遗。这正是为什么 NTLM 绝不应该用于保护任何新系统；这个工具真正的用途是兼容现有 Windows 基础设施和进行授权安全测试，而不是构建新系统。
NTLM 哈希生成器有哪些合法用途？
在授权的渗透测试或凭据审计中验证从 SAM 数据库或 NTDS.dit 提取的哈希；检查自己的工具或脚本是否正确实现了 MS-NLMP；在自己掌控的实验环境中为 hashcat（模式 1000）或 Mimikatz 格式兼容性检查生成测试哈希；以及完成明确涉及 NTLM 的 CTF 或培训练习。用这个工具攻击你不拥有、也没有书面授权测试的账户或系统，不属于合法用途。
我的密码或输入内容会发送到服务器吗？
不会。MD4 的计算完全在浏览器中用 JavaScript 完成——浏览器没有原生的 MD4 API，所以它是直接在这个页面的客户端代码中实现的，你输入的任何内容都不会被传输到任何地方。
这个工具能处理LM哈希吗，还是只支持NTLM？
只支持NTLM。更古老的LM哈希用的是完全不同、也更弱的方案（把密码拆成两段各7个字符，分别用DES哈希），而且自Windows Vista起，微软默认已经禁用了LM哈希的存储。如果你需要专门处理遗留的LM哈希，需要用为那个算法专门设计的另一个工具。
为什么同样的输入每次都得到完全相同的哈希，没有随机性？
这是预期行为，也正是真实NTLM的表现——NTLM没有盐值，所以MD4(UTF-16LE(输入))是一个纯确定性函数。相同输入永远得到相同输出，这正是让NTLM容易被预计算彩虹表攻击的弱点所在。
可以用它给密码以外的内容做哈希吗，比如用户名或挑战值？
技术上可以——工具只是对你输入的任意文本计算MD4(UTF-16LE(输入))，所以任何字符串都适用。但如果你要完成更完整的NTLMv2挑战-响应握手（涉及NTLM哈希加上服务器挑战、客户端随机数和HMAC-MD5），单纯这个哈希计算器还不够，需要额外的步骤。
怎么验证这个工具的输出确实是对的？
用内置的示例：字符串"password"的NTLM哈希是一个广为人知、独立发布过的测试向量——8846F7EAEE8FB117AD06BDD830B7586C。输入它确认能得到完全一致的结果，如果想进一步放心，也可以对照hashcat自带的测试向量或其他可信实现再核对一次。
大小写或末尾空格会影响输出结果吗？
会，和真实NTLM表现完全一致——算法哈希的是你提供的精确字节，所以"Password"和"password"会得到完全不同的哈希，不小心多打的一个空格也会改变结果。在核对从别处提取的哈希时，这一点值得特别留意。