渗透测试专用字典体系：按场景结构化、可嵌入工作流的爆破资源

1. 这不是“字典合集”，而是一套可直接嵌入工作流的密码爆破资源体系

你有没有过这样的经历：凌晨两点，刚搭好靶机环境，准备对一个Web登录页做弱口令测试，结果卡在了字典选择上——用rockyou.txt？太老，漏掉大量新平台默认口令；自己写规则生成？耗时两小时，跑出来全是无效组合；临时去GitHub搜“password wordlist”，翻到第17页，下载5个压缩包，解压发现3个是空文件夹、1个是base64编码的txt、还有1个居然是某培训机构的课程大纲……最后干脆改用Burp Intruder随便填了100个常见密码，草草收场。这不是懒，是工具链断裂带来的实操窒息感。

“渗透测试字典不用四处扒”这句话背后，真正要解决的从来不是“有没有”，而是“能不能立刻进流程、能不能精准匹配场景、能不能避免误报拖慢节奏”。我从2013年第一次用hydra爆破路由器telnet开始，到后来带团队做金融行业红队评估，踩过所有字典相关的坑：字典体积过大导致内存溢出、编码不一致引发HTTP请求乱码、大小写策略错配导致漏掉admin/Admin/ADMIN三类变体、甚至因为字典里混入了Windows路径分隔符（\）导致SQLmap报错中断。所谓“史上最全合集”，不是堆砌GB级文件，而是按攻击阶段—目标类型—协议特征—语言环境四维坐标系完成结构化组织，并预置校验机制。它包含的不只是password.txt，而是覆盖Web表单、SSH密钥提示、WiFi WPA握手包、Active Directory域账户、IoT设备Telnet默认凭据、API Token枚举、JWT密钥爆破等11类高频场景的专用词表，每一份都经过md5sum校验、UTF-8 BOM清理、重复行去重、控制字符过滤，并附带usage.md说明其设计边界（比如某个字典专为中文CMS后台设计，已排除拼音首字母缩写类弱口令，因实测发现该类组合在目标环境中命中率为0）。解压即用，本质是把过去需要3小时手动筛选+清洗+验证的前置工作，压缩成一条tar -xzf命令。

这个合集面向三类人：刚考完CEH想动手练的新人，能跳过“找字典”这个最劝退环节，直接聚焦在Burp联动、速率控制、响应识别等核心能力训练上；驻场做周期性渗透的工程师，可将其中的domain_usernames.txt与客户AD导出的sAMAccountName字段做差集，快速生成高价值爆破列表；还有红队队员，当需要在物理接触后30分钟内拿下某台未打补丁的Windows Server时，直接调用win_default_creds.txt + crackmapexec，比临时写PowerShell脚本快4倍。它不教你怎么用hydra，但确保你输入的每一行，都是经过真实攻防对抗验证过的“有效弹药”。

2. 字典失效的本质：不是数量不够，而是语义失焦与上下文错配

很多人以为字典爆破失败是因为“字典太小”，于是疯狂收集更大文件：20GB的rockyou扩展版、150GB的LeakedSource数据集、甚至有人把整个Common Crawl的HTML文本用正则抽密码……结果呢？跑了一整夜，CPU满载，日志里全是401 Unauthorized，最后发现目标系统根本没启用Basic Auth，而是在前端JavaScript里做了密码强度校验，真正的后端接口只接受SHA256哈希值。问题出在哪？不是字典不够大，是字典和目标系统的语义层完全脱节。

我们来拆解一次典型失效链路。假设目标是一个教育SaaS平台的教师端登录接口，URL为https://teacher.edu-saas.com/api/v1/auth/login，参数为{"username":"xxx","password":"xxx"}。如果你直接扔rockyou.txt进去，大概率会失败。为什么？因为rockyou.txt的语料来源主要是2009年RockYou公司泄露的明文密码库，其构成逻辑是：用户在注册时自由设置的、符合当时通用强度规则（8位+大小写字母+数字）的密码。而2024年的教育SaaS平台，其教师账号由学校IT管理员批量导入，用户名格式为“teacher_2024_001”，初始密码强制为“Edu@2024+工号”，且首次登录必须修改。此时，真正有效的字典应该是：

• 用户名列表：teacher_2024_{001..999}（根据学校规模估算）
• 初始密码模板：Edu@2024+{001..999}
• 常见修改模式：Edu@2024+{001..999}!、Edu2024+{001..999}、Edu@2024{001..999}

这组数据量仅约3000行，但命中率可能超过60%。而rockyou.txt中那1400万行，99.9%与该场景无关。这就是“语义失焦”——字典的构建逻辑（用户自主设置）与目标系统的账户生成逻辑（管理员批量分配）完全错位。

更隐蔽的是“上下文错配”。比如测试某款国产NAS设备的Web管理后台，厂商文档写着“默认管理员密码为admin”，但实际部署中，设备首次启动时会通过DHCP获取IP并连接厂商云平台，云平台下发一个随机8位密码（如X7m#qL9p），同时将该密码AES加密后存入/etc/shadow。此时，用任何公开字典都无效，唯一可行路径是：1）抓取设备向云平台发送的注册请求，提取加密密钥；2）用该密钥解密shadow中的密码字段。字典在这里彻底退出舞台，变成密码学逆向问题。所以，所谓“全量字典合集”的真正价值，不在于穷尽所有可能，而在于帮你快速识别：当前目标属于哪一类语义场景？该调用哪个子集？是否需要立即切换策略？

我在某次医疗设备渗透中就吃过这个亏。目标PACS系统Web界面显示“用户名：admin，密码：123456”，但反复尝试均失败。抓包发现登录请求被重定向到一个OAuth2授权端点，实际凭证用于调用后端的DICOM服务。最终发现，真正的弱口令藏在设备串口调试接口的U-Boot环境中，而那个环境使用的默认密码，就在我合集里的iot_uboot_defaults.txt里——它只包含12行，全部来自不同芯片厂商的SDK默认配置。这12行，比100GB的通用字典更有杀伤力。

3. 合集结构解析：按攻击生命周期组织的11类专用词表

这个合集不是简单打包，而是按渗透测试的实际工作流重新编排。我把整个爆破过程拆解为“侦察→建模→生成→验证→迭代”五个阶段，每个阶段对应特定字典类型。下面详细说明核心11类词表的设计逻辑、适用边界及实操注意事项。

3.1 web_login_basic：Web表单基础爆破词表（含大小写智能变体）

这是使用频率最高的子集，但绝非rockyou.txt的简单搬运。它包含三个层级：

• Level 1：纯基础组合（200行）—— admin/admin、root/toor、test/test、guest/guest等，用于快速探测是否存在裸奔账户；
• Level 2：Top 100 CMS默认凭据（327行）—— WordPress、Joomla、Drupal、DedeCMS、帝国CMS等的安装默认账号密码，已剔除已被厂商废弃的旧版本组合；
• Level 3：大小写智能变体引擎（Python脚本+预生成列表）—— 输入"admin"，自动输出admin/Admin/ADMIN/admin123/ADMIN123等12种变体，但严格排除无意义组合（如AdMiN，因实测发现目标系统多为不区分大小写的数据库查询）。

提示：该词表默认禁用数字后缀（如admin1、admin2），因2023年CNVD披露的Web框架漏洞报告显示，83%的自动编号账户已被安全团队列为高危监控对象，实际命中率低于0.7%。如需启用，请运行./gen_suffix.py --enable-digits --range 1-50手动生成。

3.2 ssh_telnet_defaults：网络设备默认凭据库（含厂商指纹映射）

区别于传统“路由器默认密码表”，此库绑定设备指纹识别。例如，当Nmap扫描返回ssh-hostkey: 2048 xx:xx:xx:xx:xx:xx:xx:xx (RSA)，其MD5前8位为a1b2c3d4，则自动匹配ssh_fingerprint/a1b2c3d4.txt——该文件只包含该型号设备固件中硬编码的3个密码（如zte/ZTE123、huawei/Huawei@2023）。库中已收录华为、H3C、锐捷、TP-Link、MikroTik等27家厂商的142个设备型号指纹，覆盖2018-2024年主流固件版本。所有密码均经真实设备验证，剔除了厂商文档中存在但实际固件已移除的“幽灵凭据”。

3.3 wifi_wpa_handshake：WPA/WPA2握手包离线破解专用词表

专为aircrack-ng/cowpatty优化。包含：

• 基础SSID衍生词（如wifi名称为“ChinaNet-ABCD”，则生成ChinaNet-ABCD、chinanet-abcd、CHINANET-ABCD、ChinaNetABCD）；
• 中国运营商默认SSID规则（如中国移动CMCC-XXXX、中国电信CTEL-XXXX，后4位为MAC地址后4位）；
• 物理位置关联词（基于Shodan API获取的目标地理坐标，生成“Beijing_2024”、“Shenzhen_WiFi”等本地化组合）。

注意：该词表默认禁用纯数字组合（如12345678），因WPA2-PSK协议要求密码长度≥8且至少含1个非数字字符，纯数字会被aircrack-ng直接跳过，徒增计算耗时。

3.4 ad_domain_users：Active Directory域环境专用用户名词表

不包含密码，只提供高价值用户名。来源包括：

• 公开招聘信息（猎聘、BOSS直聘爬取的IT岗位JD，提取“系统管理员”、“网络工程师”、“数据库DBA”等职位常用用户名前缀）；
• GitHub代码仓库中泄露的AD PowerShell脚本（搜索Get-ADUser -Filter "Name -like"语句，提取其过滤条件）；
• 某省政务云招标文件中的AD架构设计图（标注了ou=it,ou=finance等关键OU）。

生成的用户名格式为：it-admin-01、fin-db-2024、hr-system-2023，全部符合Windows NetBIOS命名规范（≤15字符，不含特殊符号），避免因格式错误被AD拒绝。

3.5 api_token_bruteforce：API密钥与Token枚举词表

针对RESTful API的Authorization: Bearer xxx或X-API-Key: xxx头。包含：

• 常见密钥前缀（sk_live_、pk_test_、ghp_、ak-、sk-）；
• JWT密钥常见弱值（secret、jwtSecret、123456、password）；
• 云服务默认密钥模式（AWS Access Key固定为AKIA开头，共20位；阿里云AccessKey ID为LTAI开头，共32位）。

特别设计token_pattern_matcher.py脚本：输入目标API返回的错误信息（如{"error":"Invalid API key format"}），自动匹配最可能的密钥长度与字符集，动态裁剪词表。

3.6 jwt_secret_wordlist：JWT签名密钥专用爆破词表

JWT爆破的关键不是穷举，而是聚焦HS256算法下最可能的密钥。该词表包含：

• 硬编码密钥（从GitHub搜索jwt.sign(+secret:，提取真实项目中写死的密钥）；
• 环境变量推断密钥（如process.env.JWT_SECRET→ 尝试JWT_SECRET、jwt_secret、SECRET_KEY）；
• 密码管理器导出密钥（LastPass、1Password导出JSON中notesType: "web"字段的密码）。

所有密钥均经jwt_tool验证，剔除会导致InvalidSignatureError以外错误的无效条目。

3.7 iot_device_credentials：IoT设备全栈凭据库

覆盖嵌入式Linux、RTOS、Web管理界面三层：

• U-Boot层：各芯片厂商SDK默认密码（如Allwinner的sunxi、Rockchip的rk3399）；
• Linux Shell层：busybox默认账户（root:123456、admin:admin）；
• Web层：海康威视、大华、宇视等安防设备的Web默认密码（已按固件版本细分，v5.6.0以上禁用admin/123456）。

每条记录标注[VULN-CVE-2023-XXXX]，链接至NVD详情，方便快速定位漏洞利用条件。

3.8 database_default_creds：数据库默认账户词表

按数据库类型与部署场景细分：

• MySQL：root（本地socket）、mysql.sys（系统账户）、debian-sys-maint（Debian特有）；
• PostgreSQL：postgres（默认超级用户）、pg_database_owner（权限继承账户）；
• Redis：空密码（未授权访问）、default（新版默认账户）；
• MongoDB：admin（未鉴权模式）、__system（内部系统账户）。

特别标注[NO-AUTH]标签，提醒该账户在未开启认证时才有效，避免在已配置ACL的集群中浪费时间。

3.9 mobile_app_api_keys：移动App后端API密钥词表

从APK/IPA逆向工程中提取的真实密钥模式：

• Android：BuildConfig.API_KEY硬编码值（如a1b2c3d4e5f67890）；
• iOS：Info.plist中API_KEY字段（常为Base64编码，已预解码）；
• 通用：X-App-Version头对应的版本密钥（如v2.3.1→ 尝试app_v231_key、mobile_v231_secret）。

所有密钥均经Burp Collaborator验证，确保其确实在真实流量中被使用。

3.10 cloud_provider_secrets：云平台密钥枚举词表

针对AWS、Azure、GCP、阿里云、腾讯云的密钥格式：

• AWS：AKIA[0-9A-Z]{16}（Access Key ID）、[0-9a-zA-Z+/]{40}（Secret Access Key）；
• 阿里云：LTAI[0-9a-zA-Z]{32}（AccessKey ID）、[0-9a-zA-Z]{32}（AccessKey Secret）；
• 腾讯云：AKID[0-9a-zA-Z]{32}（SecretId）、[0-9a-zA-Z+/]{44}（SecretKey）。

词表本身不包含完整密钥，而是提供正则模式与长度校验脚本，配合gitleaks/secrets-scanner使用，避免误报。

3.11 custom_rule_based：规则驱动型动态生成器

这不是静态词表，而是一套YAML规则引擎。例如rules/web_cms.yaml定义：

name: "DedeCMS v5.7" patterns: - username: ["admin", "cfg_admin"] - password: ["123456", "dedecms", "www.dedecms.com"] - suffix: ["", "!2024", "@2024"] - case_transform: ["lower", "upper", "title"]

运行./gen_dict.py --rule rules/web_cms.yaml即可生成精准匹配该CMS的288行字典。规则支持嵌套、条件判断（如if version >= "v5.8": include "new_default_pwd"），让字典真正成为可编程的攻击资产。

4. 实战避坑指南：那些让你白跑10小时的隐藏雷区

即使有了结构清晰的字典合集，实操中仍有大量“看似正确、实则无效”的操作陷阱。这些坑往往不会报错，只会默默消耗你的时间和算力。以下是我用血泪经验总结的6个高频雷区，每个都附带验证方法与修复方案。

4.1 编码污染：UTF-8 BOM与Windows换行符引发的静默失败

最典型的案例：某次测试政府网站，用hydra爆破登录接口，字典是标准的UTF-8文本，但hydra日志显示所有请求都返回200 OK，却始终无法命中正确密码。抓包发现，请求体中的password字段值为admin——开头多了EF BB BF三个字节（UTF-8 BOM）。原来字典文件是从Windows记事本另存为UTF-8生成的，记事本默认添加BOM。而目标Web服务器的PHP脚本用$_POST['password']接收，BOM被当作密码一部分，导致永远比对失败。

验证方法：用hexdump -C your_dict.txt | head -n 5检查前几行，若出现ef bb bf即存在BOM；用file -i your_dict.txt查看编码，若显示charset=utf-8; with boms则确认。

修复方案：

# 批量清除BOM（Linux/macOS） find ./dicts -name "*.txt" -exec sed -i '1s/^\xEF\xBB\xBF//' {} \; # 或用iconv转换（更彻底） iconv -f UTF-8 -t UTF-8//IGNORE your_dict.txt > clean_dict.txt

另一个隐形杀手是Windows换行符\r\n。某些Web框架（如旧版Struts）在解析表单时，会将\r视为非法字符并截断，导致密码被截为admin\r。用cat -A your_dict.txt可显示$符号结尾的行即含\r，用dos2unix your_dict.txt一键修复。

4.2 大小写策略错配：目标系统不区分大小写，你的字典却在穷举所有变体

很多新手认为“大小写变体越多越好”，结果在测试一个MySQL数据库时，用包含Admin、ADMIN、aDmIn的字典爆破root账户，跑了一整晚毫无收获。原因很简单：MySQL的用户名比较默认是大小写不敏感的（collation为utf8mb4_0900_as_cs时除外），root和ROOT被视为同一账户。而你的字典中ROOT密码可能是错的，但root密码是对的，却因顺序靠后而未及时命中。

验证方法：先用单行字典测试root和ROOT，观察响应差异。若两者返回相同错误信息（如Access denied for user 'root'@'localhost'），说明用户名不区分大小写。

修复方案：立即停用所有大小写变体，改用web_login_basic/level1.txt（仅基础小写组合）。如需覆盖大小写敏感场景（如Linux系统账户），则单独启用linux_case_sensitive.txt，并确保其仅用于ssh或su命令，而非Web表单。

4.3 速率限制绕过失效：你以为的“慢速爆破”其实触发了蜜罐

某次测试电商后台，为避免触发风控，我设置了hydra-w 30（每30秒1次请求），结果3小时后发现IP被封禁。查日志发现，目标系统部署了商业WAF（某国内厂商），其蜜罐规则是：连续10次请求中，若有7次返回401且User-Agent相同，则判定为自动化工具。而我的hydra未设置随机UA，所有请求UA均为hydra，完美命中蜜罐阈值。

验证方法：用curl手动发送10次相同请求，观察第7次后是否返回403或跳转到验证码页面。

修复方案：

• 在hydra中启用随机UA：hydra -U -w 30 -t 1 -V -L users.txt -P pass.txt http-post-form "/login:username=^USER^&password=^PASS^:F=invalid" -H "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36"
• 更稳妥的是用Burp Intruder + 自定义payload，导入ua_list.txt（含200个真实浏览器UA）。

4.4 响应识别误判：401≠密码错误，可能是CSRF Token缺失

最让人崩溃的坑：字典明明包含正确密码，但hydra报告“all passwords tried and failed”。抓包发现，每次请求都返回401 Unauthorized，但仔细看响应头，缺少Set-Cookie: sessionid=xxx，而正常登录成功时会有该Cookie。进一步分析发现，目标登录接口要求请求中必须携带有效的CSRF Token，该Token在登录页HTML中以<input name="csrf_token" value="abc123">形式存在。没有Token，服务器直接返回401，与密码错误表现完全一致。

验证方法：用浏览器打开登录页，复制完整的HTML源码，搜索csrf、token、_token等关键词，确认Token字段名与值。

修复方案：放弃hydra，改用Burp Suite或编写Python脚本：
1）GET登录页，正则提取CSRF Token；
2）POST登录请求，将Token加入表单参数；
3）检查响应Cookie或重定向Location。

4.5 字典体积超限：2GB文件导致内存溢出，而你需要的只是前1000行

曾有个客户要求测试其内部Wiki系统，我习惯性加载了web_login_basic/level2.txt（1.2GB），hydra启动后直接OOM Killer干掉进程。后来发现，该Wiki基于Confluence搭建，管理员早已将默认账户admin重命名为wiki-admin，而wiki-admin就在字典的第872行。加载全部1.2GB纯属浪费。

验证方法：用head -n 1000 your_dict.txt | wc -l确认前1000行是否包含目标用户名；用grep -n "wiki-admin" your_dict.txt定位行号。

修复方案：

• 对大型字典，永远先用head -n 5000生成测试子集；
• 使用shuf -n 1000 your_dict.txt > test_subset.txt随机采样，提高命中概率；
• 在Burp Intruder中启用Payload Processing→Recycle results from previous payload position，实现用户名/密码的交叉组合，减少总行数。

4.6 协议层误解：把HTTP Basic Auth字典用在了Form-Based Auth上

这是新手最高频的错误。看到登录页面URL为https://target.com/admin/login，就认定是Basic Auth，用hydra -m /admin/login -s https target.com http-get /admin/login，结果全军覆没。实际上，该页面是标准的HTML表单，认证逻辑在后端PHP中完成，HTTP状态码永远是200，错误提示在HTML body中（如<div class="error">密码错误</div>）。

验证方法：用curl -I获取响应头，若包含WWW-Authenticate: Basic realm="Restricted Area"，才是Basic Auth；否则必为Form-Based。

修复方案：

• Basic Auth：用hydra -m /admin/login -s https target.com http-get /admin/login；
• Form-Based：用hydra -m /admin/login -s https target.com http-post-form "/admin/login:username=^USER^&password=^PASS^:F=密码错误"，其中F=后的内容必须是目标页面真实的错误提示文字（需用中文，因该站点为中文界面）。

5. 进阶技巧：如何让字典合集成为你的个人知识图谱

字典合集的价值，远不止于“解压即用”。当它成为你渗透工作流的有机组成部分，就能进化为动态生长的个人知识图谱。以下是我在三年实战中沉淀的3个高阶用法，它们让字典从“消耗品”变为“生产资料”。

5.1 基于目标反馈的字典在线学习：让每次失败都成为下一次成功的养料

传统字典是静态的，而真实攻防是动态的。我开发了一个轻量级脚本dict_learner.py，它能在爆破过程中实时分析失败响应，自动优化后续字典。例如：

• 当hydra报告[ERROR] could not connect to target port 443，脚本自动将目标域名加入blocked_hosts.txt，下次跳过该主机；
• 当Burp Intruder发现某次请求返回{"code":403,"msg":"Invalid token length"}，脚本提取token length关键词，调用./gen_length_dict.py --min 32 --max 40 --charset hex生成32-40位十六进制密钥子集；
• 当SQLmap报错Unknown column 'user_name' in 'field list'，脚本自动将user_name加入custom_field_names.txt，供后续--common-columns参数调用。

这个过程不需要人工干预，所有学习结果都写入./learned/目录，形成专属的“目标适应性字典”。某次测试某银行手机App，初始字典对/api/v1/user/login无效，但dict_learner.py捕获到错误信息"password must contain at least one uppercase letter and one special character"，30秒内生成bank_app_strong_pwd.txt（含Passw0rd!、Bank@2024#等127个组合），最终在第42次请求命中。

5.2 字典与漏洞POC的深度耦合：从“爆破”升级为“利用链组装”

字典不应孤立存在，而应作为漏洞利用链的一环。以CVE-2023-27350（Accellion FTA文件传输设备远程代码执行）为例，其利用前提是获取admin账户的密码。官方POC只提供硬编码密码admin，但实际环境中该密码已被修改。我的做法是：
1）将accellion_default_creds.txt（含12个历史默认密码）作为第一波爆破；
2）若失败，调用./exploit/cve-2023-27350.py --brute，该脚本会：
- 自动从web_login_basic/level2.txt中提取Top 50 CMS密码；
- 与accellion_default_creds.txt做笛卡尔积，生成admin:123456、admin:password等组合；
- 对每个组合，发送POC载荷并检测响应中的<title>Accellion字符串。

这样，字典不再是独立模块，而是POC的“燃料注入系统”。目前合集中已集成17个CVE的专用字典耦合脚本，覆盖Fortinet、Citrix、Zyxel等主流设备。

5.3 构建组织级字典知识库：将个人经验转化为团队资产

在红队项目中，我推动建立了“字典贡献公约”：每位成员在完成一次渗透后，必须提交：

• target_report.md：描述目标技术栈、发现的弱口令模式、绕过方式；
• new_words.txt：新增的有效密码（如某政务系统要求密码为“姓名拼音首字母+身份证后6位”，则提交zhangs123456）；
• false_positive.txt：被误判为有效但实际无效的组合（如admin:admin在测试中返回200但未登录成功，需标注原因）。

所有提交经./validate_new.py脚本自动校验（检查格式、去重、BOM清理、长度合规），通过后合并入主合集。三年来，团队积累的有效密码条目从12万增长到89万，但误报率从18%降至2.3%。最关键的是，新人入职第一周，就能基于./gen_team_dict.py --org gov --year 2024生成专属字典，无需再从rockyou.txt开始摸索。

最后分享一个小技巧：在合集根目录下，我放了一个quick_start.sh脚本。当你面对一个全新目标时，只需运行./quick_start.sh -t web -d "https://target.com" -u "admin"，它会：
1）自动识别目标CMS（用whatweb）；
2）匹配对应字典子集（如识别为WordPress，则加载web_login_basic/wordpress_defaults.txt）；
3）生成Burp Intruder配置文件（含CSRF Token提取规则）；
4）输出一条可直接复制执行的hydra命令。
整个过程30秒，这才是“解压就能用”的终极形态——它不是给你一堆文件，而是给你一套思考框架与执行引擎。