Windows 下 Hydra 配 txt 字典做口令基线核查实战

简介：hydra Windows 版及配套 txt 字典集合，面向需要在 Windows 环境开展口令安全测试、渗透测试学习与实验复现的安全从业者和进阶学习者，可解决 hydra 在 Windows 下运行依赖与字典准备两类问题。压缩包共 99 个文件，约 120.9MB，主体由 37 个 txt 字典、32 个 dll 运行库及 2 个 exe 可执行程序构成，另含少量 sample、head、master 等辅助文件；txt 覆盖常见弱口令、多语种词表与按流行度排序的口令集，dll 与 exe 则支撑 hydra 及 pw-inspector 等工具在 Windows 上启动运行，目录组织便于按工具与词表分类取用。已有 2143 人学习下载。读者可获得可直接解压使用的 Windows 版 hydra 运行环境、较完整的口令字典素材，以及配套说明与恢复文件，适合搭建本地实验、验证认证防护强度并积累字典筛选与测试思路。

1. hydra Windows 版配 txt 字典：把口令基线核查搬回本机

一台 Windows 笔记本，一份整理好的 txt 字典，加上 hydra 的 Windows 编译版，就能在自己维护的那几台机器上把口令基线过一遍——不用另开虚拟机，不用装双系统，解压完就能敲命令。hydra 本身做的事情很朴素：把你 txt 字典里的口令逐条送到目标服务的认证接口，按你给的并发和超时，如实记录哪一条被放行。它不会替你猜，字典里没有的口令它一个字也变不出来，所以真正决定效率的是那份 txt 字典怎么整理，而不是参数敲得多花哨。这套组合适合负责内网资产盘点、上线前做口令基线核查、或者带学生做授权实验的从业者；不适合没拿到书面授权就想去试别人机器的人——那不是技术问题，是另一回事。

2. 版本选型与首次跑通：Windows 上让 hydra 活下来

先把一件事说清楚：hydra 的原生开发环境是类 Unix，Windows 上没有官方安装包。市面上能拿到的所谓 Windows 版，本质是社区用 POSIX 兼容层编译出来的可执行文件，再配上一堆运行时 dll 打包成压缩包。理解这一点，后面九成的启动失败都能自己定位。

2.1 三条获取路径的取舍

实际能走通的路只有三条，各有各的代价：

我一般先用预编译包把流程跑通，确认字典、协议、目标都通，再决定要不要为某个缺失模块去折腾编译。反过来先啃编译，十有八九卡在依赖库版本上，两天过去连一次登录都没发出去，血泪经验。

提示：无论走哪条路，只在你自己的资产或持有书面授权的范围内使用。超出范围的操作不是技术问题。

2.2 依赖补齐与第一次跑通

预编译包解压后通常长这样：一个主程序、一个兼容层核心 dll、若干加密与网络相关的 dll。千万不要把 exe 单独拷到别处——它启动时按当前目录和系统目录找 dll，单飞必报错。正确做法是整个目录一起搬，且路径里不带空格和中文。

第一次运行先别急着连目标，用帮助输出验证程序本身能不能起来：

# 在解压目录里打开 cmd 或 PowerShell，先看主程序能否加载 hydra.exe -h # 能正常输出帮助后，再看某个协议模块的具体用法 hydra.exe -U http-post-form

第一行验证的是依赖链是否完整。如果报「找不到 xxx.dll」，说明解压不完整或被杀毒软件隔离了某个文件，去隔离区找回来加白名单；如果直接闪退、窗口一闪而过，在 cmd 里手动执行就能看到报错文本，这比双击强得多。第二行-U是查看模块参数，不同构建的模块集合差别很大，先确认你要用的协议在不在列表里，别写完一长串命令才发现模块压根没编进去。

确认程序能跑之后，做一次本地闭环测试：在自己机器上开一个测试用的 ssh 或 ftp 服务，用一个已知正确的账号密码跑单条验证。

# 单账号单密码，只验证链路通不通，不加载字典 hydra.exe -l testuser -p testpass -t 1 -V ssh://127.0.0.1

-l和-p是小写，表示单个固定值；-t 1强制单线程，排除并发干扰；-V把每一次尝试都打印出来，方便看清握手到认证的每一步。这一步通了，说明程序、网络、协议模块三样都没问题，再上字典才不会有「到底是字典不对还是程序不对」的黑匣子困境。

2.3 txt 字典的硬性格式要求

hydra 对字典文件的要求只有一条：一行一个口令，除此之外什么都不认。听起来简单，实际翻车基本都在这条上：

• 文件必须是纯文本，不能是 docx、xlsx 改后缀。
• 编码统一用 UTF-8 无 BOM。带 BOM 的文件，第一条口令前面会多出三个不可见字节，这条永远对不上。
• 换行符用 LF。Windows 记事本默认存 CRLF，某些构建会把\r当成口令的一部分读进去，于是字典里明明有admin123，实际发出去的是admin123\r。
• 不留空行、不留行尾空格。空行会被当成空口令尝试，白白消耗一次认证机会，还可能触发账户锁定计数。
• 注释不要用#，hydra 不认注释语法，#开头的行会被当成真实口令发出去。

这五条里，CRLF 和 BOM 是最阴的两个，因为文件在编辑器里看着完全正常。判断方法很简单：用十六进制编辑器看文件头三个字节是不是EF BB BF，再看行尾是不是0D 0A。第 3 章会给一段脚本一次性把这两个问题清掉。

3. txt 字典工程化：从散装词表到能打的清单

随便网上抓一份几百万行的弱口令表直接怼进去，是最常见的低效做法。字典不是越大越好，命中率和耗时的比值才是关键。一份经过分层、清洗、排序的十万行字典，往往比一份没整理过的千万行字典先出结果。

3.1 三层结构：基础表、场景词、变形规则

我习惯把字典拆成三层，分开维护：

第一层是基础弱口令表。就是那批常年排在前面的组合：纯数字连号、键盘序、常见英文单词加年份、默认出厂口令。这一层的特点是量大面广，命中率最高，行数控制在十万以内，跑完通常只要几分钟。

第二层是场景词。根据目标性质往里加：如果是某个业务系统，加系统名、模块名的拼音和缩写；如果是办公网，加部门名、项目代号、季节加年份。这一层的价值在于，真实环境里大量口令是「单位缩写 + 年份 + 符号」这种结构，通用表里根本不会有。

第三层是变形规则。不是直接列出口令，而是对前两层做规则展开：首字母大写、全大写、末尾加!、加@123、加2024、把a换成@、把o换成0。这一层最容易失控，一条规则就能让字典膨胀十倍，所以要克制——先只开「首字母大写 + 年份后缀」两条，跑完看命中情况再决定要不要加。

注意：变形规则会显著拉长单轮耗时，而且部分系统有登录失败锁定策略。目标如果有「五次失败锁十分钟」这类策略，字典再花哨也没用，得先换思路。

3.2 清洗脚本：一次解决去重、编码、换行

下面这段脚本干四件事：剥掉 CRLF 和 BOM、去掉空行和注释行、按长度过滤、去重后以 LF 换行重写。跑完之后字典可以直接喂给 hydra，不用再操心格式。

# dict_clean.py —— 字典清洗：去 BOM/CRLF、去空行、长度过滤、去重、统一 LF import io SRC = r"D:\dict\raw.txt" # 原始字典，编码乱一点也没关系 DST = r"D:\dict\clean.txt" # 输出字典，保证 UTF-8 无 BOM + LF MIN_LEN, MAX_LEN = 6, 32 # 长度窗口，按目标的口令策略调整 seen = set() out = [] with io.open(SRC, "r", encoding="utf-8", errors="ignore") as f: for line in f: pwd = line.rstrip("\r\n") # 关键：先剥换行，CR 和 LF 一起处理 pwd = pwd.lstrip("\ufeff").rstrip() # 去 BOM 头和行尾空白 if not pwd or pwd.startswith("#"): # 空行、注释行直接丢 continue if not (MIN_LEN <= len(pwd) <= MAX_LEN): continue if pwd in seen: # 去重，集合判断 O(1) continue seen.add(pwd) out.append(pwd) # newline="\n" 强制 LF，别用默认值，Windows 下默认会写成 CRLF with io.open(DST, "w", encoding="utf-8", newline="\n") as f: f.write("\n".join(out) + "\n") print("kept=%d" % len(out))

几个参数值得说清楚。errors="ignore"是为了对付编码混杂的原始字典——有些老字典是 GBK，直接按 UTF-8 读会抛异常，忽略掉无法解码的字节比整个文件读失败强。MIN_LEN=6对应大多数系统的口令最小长度策略，比这短的口令根本不可能被接受，放进字典纯属浪费次数；如果目标策略允许 4 位，改成 4。MAX_LEN=32是为了砍掉误抓进来的整段文本——原始字典里混进说明文字是常事，那些超长行发出去只会拖慢速度。最后newline="\n"这一行是整段脚本里最容易被忽略、也最要命的一行。

清洗完顺手验一下结果，用 PowerShell 几行就够：

# 校验输出字典：BOM、行数、空行、行尾空格 $p = "D:\dict\clean.txt" $b = [System.IO.File]::ReadAllBytes($p) "前3字节: " + ($b[0..2] -join ',') # 应该不是 239,187,191 $lines = Get-Content $p "总行数: " + $lines.Count "空行数: " + ($lines | Where-Object { $_ -eq '' }).Count "行尾空格: " + ($lines | Where-Object { $_ -match '\s$' }).Count

如果前三个字节是239,187,191，说明输出还带 BOM，回头检查写入时的encoding参数；空行数和行尾空格数都应该是 0，不是 0 就把脚本里的过滤条件再收一遍。

3.3 裁剪与排序：先跑最可能命中的那一段

清洗只是把脏东西去掉，排序才是真正提升效率的动作。同一个字典，把高命中率的行放前面，配合-f参数（找到第一个就停），整体耗时会差出好几倍。

我的排序惯例是：默认出厂口令和空口令排最前，然后是纯数字六位以下，再是「单词 + 年份」，最后才是变形展开的部分。这套顺序在大多数内网环境里能在一两分钟内出结果。反过来把变形结果堆在前面，前十万条全是各种符号组合，跑半天一个不中。

另外按目标数量做裁剪。目标是单台机器，字典五万行以内足够；目标是一个网段里几十台机器，反而应该缩小字典、加大对单台的覆盖深度，因为并发预算被摊薄了。这个权衡在第 4 章的并发参数里还会再提一次。

4. 参数拆解：账号、并发、超时、输出怎么配

hydra 的参数不多，但每个都有明确含义，乱设的结果不是慢就是被封。这一章按「输入怎么给 → 资源怎么控 → 结果怎么留 → 协议怎么写」的顺序过一遍。

4.1 账号与密码的四种输入方式

账号和密码的组合方式一共四种，对应四个参数：

# 1. 单账号 + 单密码，用于链路验证 hydra.exe -l admin -p Pass@123 ssh://192.168.10.21 # 2. 单账号 + 字典，最常见：已知用户名，试口令强度 hydra.exe -l admin -P D:\dict\clean.txt ssh://192.168.10.21 # 3. 账号字典 + 单密码，用于撞库思路的横向排查 hydra.exe -L D:\dict\users.txt -p Pass@123 ssh://192.168.10.21 # 4. 双向字典 + 内置变换，-e nsr 分别代表空口令/账号当口令/账号反写 hydra.exe -L D:\dict\users.txt -P D:\dict\clean.txt -e nsr ssh://192.168.10.21

小写-l/-p是单个值，大写-L/-P是文件，这一点搞反了会直接报错。-e nsr里的三个字母是三个内置变换，n试空口令，s把用户名本身当口令，r把用户名反写当口令——这三个几乎零成本，实际环境里命中率却不低，值得常开。另外还有一个-C参数可以直接读「账号:密码」格式的组合文件，做定向核对时比双向字典清晰。

账号字典也要过一遍第 3 章的清洗，尤其要去重和去空行，重复账号会被反复尝试，白白累加失败计数。

4.2 并发、超时、间隔：三个参数决定你会不会被封

这是最容易翻车的地方。三个参数的含义分别是：

• -t：并行连接数，默认 16。指向同一目标的并发任务数。
• -W：等待响应的超时秒数，默认 30。目标响应慢就调大，网络抖动厉害就调大。
• -c：每次连接之间的等待秒数，默认 0。这个参数是给「怕触发频率限制」的场景准备的。

新手最常见的错误是把-t拉到 64 甚至更高，觉得快。实际结果是：目标服务的连接队列被打满，一半请求超时；防火墙的异常连接检测被触发，源 IP 直接被拉黑；如果有账户锁定策略，几秒钟就把账号锁死，后面字典再准也白搭。

我的取值习惯是：单台内网机器-t 4到-t 8，跨网段或经过防火墙的-t 2到-t 4，对响应慢的老系统-t 1配-W 20。这个速度看着慢，但胜在能跑完，比跑两分钟被封十分钟快得多。如果确认目标有频率限制，加-c 1或-c 2，让每次尝试之间歇一下。

# 保守配置：单目标、低并发、显式超时、找到即停、逐条打印、结果落盘 hydra.exe -l admin -P D:\dict\clean.txt -t 4 -W 15 -f -V -o D:\dict\hit.txt ssh://192.168.10.21

-f是找到第一组就退出，单账号场景下必须加，否则它会拿着已经命中的账号继续把整本字典跑完。-V打印每一次尝试，调试阶段很有用，正式跑大批量时建议关掉，否则控制台输出本身会拖慢速度。-o把结果直接写文件，比事后从滚动屏里翻要靠谱。

4.3 输出格式与中断续跑

hydra 的输出默认是人读的文本，一行一条命中记录，格式大致是「协议://地址:端口 账号 口令」。较新的构建支持-b指定输出格式，能直接出 json，方便后续用脚本汇总成表格。如果你的构建不支持，就按文本行去正则匹配，也不难。

中断是常态——跑一半发现字典排序不对、发现目标换了、发现并发还是太高。这时候有几个习惯能省事：

• 每次跑都把-o带上，文件名带日期和目标标识，别用默认名。
• 跑之前把命令写进一个 txt，改参数时改 txt 再复制执行，避免手敲出错。
• 大字典拆成小段跑，每段单独输出，出问题只丢一段。

hydra 本身没有断点续跑功能，想接着上次的位置继续，只能自己把字典切成几段，记录跑到第几段。所以一开始就按「一万行一段」切好，比事后补救容易。

4.4 ssh、ftp、mysql 三个直连模块的写法

这三个是最常用的直连模块，写法高度一致，差别只在协议前缀和端口：

# ssh：默认 22，非标端口用 -s 指定 hydra.exe -L users.txt -P clean.txt -t 4 -f ssh://192.168.10.21 hydra.exe -L users.txt -P clean.txt -t 4 -s 2222 ssh://192.168.10.21 # ftp：默认 21，老系统上仍然大量存在 hydra.exe -l ftpuser -P clean.txt -t 4 -f ftp://192.168.10.22 # mysql：默认 3306，注意这里账号通常有主机限制 hydra.exe -l root -P clean.txt -t 2 -f mysql://192.168.10.23

-s指定非标准端口，比在地址后面写:2222更稳妥，某些构建对冒号语法的解析不一致。mysql 模块的并发建议压到-t 2，数据库服务对短时间大量失败连接的容忍度很低，很容易在日志里刷出一片告警。

ssh 模块还有一个现实边界：目标如果只允许密钥认证、关闭了口令认证，hydra 会在协议协商阶段就失败，表现为「所有口令都不对」。这时候别怀疑字典，先手动用 ssh 客户端连一次，看服务端是不是直接拒绝了口令方式。这是很常见的误判来源。

4.5 http-post-form 的表单拼装

Web 表单是最需要手工调试的模块，因为每个站的登录接口都不一样。语法结构是三段，用冒号分隔：

# 结构：路径:请求体:失败或成功标识 hydra.exe -l admin -P clean.txt -t 4 -V \ 192.168.10.30 http-post-form \ "/login.php:username=^USER^&password=^PASS^:F=Invalid credentials"

三段分别是：登录接口的相对路径；POST 请求体，其中^USER^和^PASS^是占位符，会被替换成账号和口令；判定标识，F=后面跟登录失败时页面里出现的文字，S=后面跟登录成功时出现的内容。

拼这段命令的正确姿势不是猜，是先用浏览器开发者工具抓一次真实登录请求，把请求体原样抄下来，再把账号密码字段替换成占位符。要留意三点：请求体里的字段名可能是user、username、email，抄错一个就永远对不上；如果表单里有 CSRF token 之类的隐藏字段，hydra 处理不了动态 token，这个模块直接不适用；判定标识要选一段失败时一定出现、成功时一定不出现的文字，选错会导致大量误报。

注意：判定标识尽量用英文。中文标识在 Windows 控制台下受代码页影响，容易出现编码不匹配导致判定永远失败，排查起来非常费劲。

4.6 rdp 和 smb：知道它不行也是能力

rdp 和 smb 这两个模块要单独说，因为它们的成功率远低于 ssh 和 ftp，容易被误判成「字典不行」。

rdp 模块受网络级认证和凭据提供程序影响很大，很多现代 Windows 主机在认证前就要求完成一轮协商，旧构建的 rdp 模块走不到口令校验那一步，表现出来就是全部失败。判断方法是：手动用远程桌面客户端连一次，如果弹出的是标准登录框，说明口令认证路径存在，模块可能可用；如果直接提示不支持或连接中断，那就别在这个模块上耗时间。

smb 模块的边界更明确：只对较老的 SMB 方言有效，现代默认配置下基本不会被这个模块接受。看到 smb 全部失败，先别换字典，先确认目标的 SMB 版本和签名要求。

这两个模块的正确用法是「先小样本验证再投入」：拿一个已知正确的账号密码，-t 1跑单条，能通再上字典，不通就换路子。花十分钟做这个验证，比花两小时怀疑字典值。

5. 避坑与排查：Windows 下最容易翻车的五件事

这一章的五条都是实际踩过的，按「现象 → 原因 → 解决」写，遇到对应的直接对号入座。

5.1 双击闪退，或者提示缺 dll

现象：双击主程序窗口一闪而过；或在 cmd 里执行报「找不到 xxx.dll」，程序无法启动。

原因：预编译包的 dll 和 exe 是配套的，单独拷贝 exe、或者解压时被杀毒软件隔离了某个 dll，依赖链就断了。另外从压缩包直接双击运行（未解压到本地文件夹）也会出这个问题，因为临时目录里的依赖找不到。

解决：整个目录解压到一个纯英文、无空格的本地路径，比如D:\tools\hydra\，不要放在桌面或「下载」这种带中文的目录。检查目录里的 dll 是否齐全，去杀毒软件的隔离区把被拦的文件恢复并加白名单。执行时一律用 cmd 或 PowerShell 进到该目录再敲命令，别双击。

5.2 字典里明明有，就是跑不中

现象：手动确认某个口令是对的，但 hydra 跑完整本字典都没命中。

原因：九成是换行符或 BOM。记事本保存的 txt 是 CRLF，某些构建会把\r当成口令的最后一个字符；带 BOM 的文件第一条口令前面多三个字节。另有一成是行尾有不可见空格，或者文件实际是 GBK 编码，中文口令被读成了乱码。

解决：跑第 3 章那段清洗脚本，强制 UTF-8 无 BOM + LF 输出，脚本里的rstrip()顺带把行尾空格也清掉了。清完用 PowerShell 那段校验再确认一次，前三个字节不是239,187,191、空行数为 0，才算干净。

5.3 跑到一半目标全部拒绝连接

现象：前几百条正常，之后所有尝试都超时或连接被拒，程序还在继续跑但全是失败。

原因：并发太高。目标服务的连接队列被打满，或者防火墙的异常连接检测被触发，源地址被临时封禁；如果目标有账户锁定策略，账号已经被锁，后续所有口令都无效。

解决：立刻停掉，等封禁窗口过去（通常十分钟到半小时）。重跑时把-t降到 2 到 4，加-c 1拉开间隔。如果是账户锁定，先确认锁定策略的阈值和窗口，把字典按「每 N 条停一次、等窗口过去」的方式分段跑，或者干脆换用不触发锁定的核对方式。这一条没有捷径，只能靠压低速率。

5.4 表单模块报错或者疯狂误报

现象：http-post-form 模块要么直接报模块参数解析失败，要么把一堆错误口令全标成命中。

原因：三种可能。请求体里的字段名抄错了；路径写成了完整 URL 而不是相对路径；判定标识选错了，F=后面的文字在成功页面里也出现，导致每条都被判成「未命中失败标识 = 命中」。

解决：先用-U http-post-form看当前构建的语法要求；用浏览器开发者工具抓真实请求，请求体逐字符核对；判定标识换成一段失败页独有的文字，最好用英文。调试时加-V看每次请求的实际响应，加-t 1单线程跑，把误报范围缩到最小再改。

5.5 路径带中文，程序找不到字典文件

现象：命令语法完全正确，但报「无法打开文件」或直接当成空字典跑完，零尝试零结果。

原因：编译环境对 Windows 盘符路径和中文路径的处理不一致，D:\字典\pass.txt这种路径在部分构建里解析失败，甚至D:\这种盘符写法也可能不被识别。

解决：字典和程序都放到纯英文无空格路径下，命令里用正斜杠或者相对路径。最稳的做法是cd到程序所在目录，字典也拷进去，命令里只写文件名-P clean.txt，把路径问题彻底绕开。

6. 进阶：结果复核、报告产出与字典迭代

跑出命中记录只是中间产物，真正交付的是能复核的结论。我现在的固定流程是三步。

第一步，逐条手动复核。hydra 的输出只代表「服务端返回了成功响应」，不代表这个账号真的可用。ssh 手动连一次、ftp 手动登一次、Web 表单手动提交一次，确认能进到登录后的页面。误报的来源包括：表单判定标识选错、服务端对错误口令返回 200、某些服务在达到失败上限后返回异常响应。这一步不做，后面全是白干。

第二步，把结果整理成可读的表。命中的记录按「资产地址、协议端口、账号、口令强度评级、是否复用」列出来，口令强度按长度、字符集、是否包含单位名/年份给个粗评。这份表比原始日志有用得多，因为决策者关心的是「哪些机器风险高」，不是「第 3721 条命中了什么」。

第三步，把命中结果反哺进字典。这条是长期收益最大的。每次跑完，把命中的口令结构总结出来——如果大量命中都是「单位缩写 + 年份」，下一轮就把这类结构批量生成放进第二层场景词；如果发现某个变形规则一次都没中，就从第三层删掉，给字典瘦身。跑过几轮之后，字典会收敛到一个又小又准的状态，同样的目标范围，耗时能压到最初的几分之一。

还有一个容易被忽略的验证动作：拿一份已知答案的字典做回归测试。在自己搭的测试环境里设几个已知账号，口令分别放在字典的不同位置（第一条、中间、最后一条），跑一遍看能不能全部命中。这个测试能在五分钟内验证「程序、字典格式、协议模块、判定逻辑」四件事是否同时正常，比在真实目标上瞎试高效得多。我把它写成了一个固定的检查脚本，每次换机器、换构建、换字典格式，都先跑一遍。

从那以后我每次换环境，都强制先跑一遍这个已知答案的回归测试，再动真实目标——省下的不是时间，是「到底是字典问题还是环境问题」这种说不清的自我怀疑。希望帮到你。

本文还有配套的精品资源，点击获取