简介：这是一份面向安全测试与渗透学习者的爆破字典合集，提炼“渗透字典、爆破字典、安全必备”定位，主打多场景、高频复用。压缩包采用RAR封装，体积14.41MB，解压后约85M，内部整理了大量账号、密码、弱口令及常见服务凭据等字典内容，覆盖Web登录爆破、SSH/FTP/RDP远程服务口令检测、后台弱口令扫描、数据库与中间件口令探测等典型测试环节。字典按用途进行分组归类，包含登录入口、中间件、数据库、IoT设备等不同场景的字典组，可直接在Burp Suite、Hydra、fscan、Nuclei等工具中调用，也可通过自定义过滤快速提取目标服务所需字典，减少手工搜集时间。目前已有5467人学习下载，内容丰富且实用，适合安全工程师、渗透测试人员、等保评估人员以及网络安全初学者在日常评估和靶场练习中作为基础字典库使用。 做授权渗透测试时，最常遇到的尴尬场景就是：目标系统已经搭好，登录接口也找到了，但手里没有一份能打的字典。自己在网上零零散散攒了几份小字典，跑一轮下来要么命中率低得可怜，要么直接被WAF拦到怀疑人生。所以我看到“超全爆破字典合集85M.rar”这类资源，第一反应是兴奋，第二反应是谨慎——85M的数据，解压出来可能有几百万行，直接丢进Burp Suite里开跑，大概率不是效率翻倍，而是卡死、超时、误报一堆。这篇博文就围绕这份字典合集，讲清楚拿到手之后应该怎么拆、怎么洗、怎么用，以及实操中那些文档里不会写的经验和教训。适合做安全测试、CTF打靶、以及运维侧自测弱口令的工程师参考。
1. 拆包看结构：拿到字典合集第一步不是开跑，而是先看清里面有什么
很多人的习惯是拿到压缩包直接解压，然后挑最大那个txt拖进工具里开跑。这个做法我不推荐，至少对你自己的时间不负责任。85M的合集听起来很唬人，但里面可能装着十几种用途完全不同的字典，混在一起用，命中率会被大量低价值条目稀释。
1.1 解压前的准备：工具选型与文件校验
先说说解压这件事。rar格式在Windows下用WinRAR或7-Zip都能解，但有几个细节值得注意：一是解压路径尽量不要带中文和空格，个别后续处理脚本对路径解析不友好；二是有时候作者会给压缩包加注释或附带说明文档，解压后先读说明，能省掉很多自己摸索的时间。
如果手头只有Linux环境，可以直接用unar或rar命令行工具。我习惯用unar，它对非UTF-8编码的文件名兼容性比unrar好，不会解出来一堆乱码目录。解压完成后先用du -sh看看实际大小，再通过find统计文件数量和类型分布，心里先有个底。
1.2 字典分类盘点和内容抽样
这份85M合集解压后，大概率会看到这样几类文件：
- 用户名字典，包含常见姓名拼音、英文名、admin开头、test开头的各种变体。
- 弱密码字典，包含123456、password这类基础弱口令，以及它们的大小写、末尾加年份或特殊符号的变体。
- 键盘路径字典，例如qwerty、1qaz2wsx这类按照键盘相邻键位生成的内容。
- Web路径字典，用于目录扫描和文件发现，可能有几百M的常见路径、备份文件名、API接口名。
- 参数名字典，用于接口Fuzz，包含page、id、callback这类常见参数名。
- 子域名字典，用于子域名爆破，常见前缀加主域名组合。
有了分类意识之后，下一步就是抽样。直接用head抽前几十行、tail抽后几十行，再用grep看几个关键模式，比如是否包含年份、是否包含键盘序列、行尾是否带空格。这些特征直接影响后面清洗和使用的策略，跑偏了后面全白搭。
1.3 用命令行给字典做一次体检
基础体检命令基本这三条就够用：
wc -l 字典文件.txt sort 字典文件.txt | uniq -d | head -20 awk '{ if (length($0) < 6) print }' 字典文件.txt | head -20第一行看总行数；第二行看重复条目，确认这份字典有没有做过去重；第三行抽看是否存在过短的条目。很多合集压缩包为了凑体积，不做任何清洗，同样的密码可能有CRLF和LF两种换行版本，或者首尾带空格，这些脏数据如果不去掉，轻则浪费爆破轮次，重则在结果比对时造成大量误报。
2. 清洗与切分：85M的字典不能直接用，必须先做瘦身和分类
这里说的清洗不是把字典内容改得面目全非，而是通过去重、格式统一和场景切分，让这份全量合集变成几份可以直接套用的“战术工具包”。
2.1 为什么不能直接全量爆破
直接拿85M字典跑一轮，看起来是一条路走到黑，实际上有三个问题：
- 时间成本失控。本地测试还好，如果目标在远程，网络延迟加并发限制，跑完整轮可能需要几天几夜。
- 低频条目稀释命中率。字典越大，命中往往越集中在头部高频条目，后面的长尾大多是不同年份、不同特殊符号的排列组合，命中率极低，但耗时占比极高。
- 触发风控的概率大增。连续大量请求，验证码、账号锁定、IP封禁轮番上阵，最终可能一个有效结果都没拿到，反而暴露了测试行为。
所以，我的原则是：全量字典只用来做“兜底”，日常处理先用切分后的专用字典。
2.2 去重与格式统一的实操命令
在Linux下做去重和排序，这是标准操作：
# 去除首尾空白字符 sed -i 's/^[[:space:]]*//; s/[[:space:]]*$//' 字典文件.txt # 去重并保持原顺序 awk '!seen[$0]++' 字典文件.txt > 去重后.txt # 按长度排序，方便按密码长度分段使用 awk '{ print length($0), $0 }' 去重后.txt | sort -n | cut -d' ' -f2- > 按长度排序.txtWindows环境可以用Notepad++的插件或者PowerShell的Sort-Object -Unique，但处理超过百万行的文件时，Notepad++会明显卡顿，我一般还是建议在WSL或虚拟机里处理。处理完记得再看一眼文件大小，通常85M的原始内容，去重+清洗之后可能只剩40到60M，减少的不是信息量，是垃圾流量。
2.3 按场景切分，做成独立小字典
清洗完的统一文件，我会把它拆成几个场景专用的子集：
- 登录爆破字典：只保留6到20位的条目，去掉纯数字短串（这类由爆破工具规则生成就行，没必要占体积）。
- 路径发现字典：单独分离出含“/”和常见文件后缀（.php、.jsp、.bak、.git）的条目，供目录扫描工具使用。
- 参数Fuzz字典：提取纯参数名或赋值结构明显的内容，如“id=1”、“page=2”这类。
- 子域名字典：提取所有单词汇条目，与前缀词库拼接使用。
切分逻辑并不复杂，关键是形成习惯。实战中你会发现，一个按场景切好的小字典，通常几百KB到几M，跑起来又快又准，比抱着85M硬跑舒服太多。
3. Burp Suite中的接入与配置：让字典在Intruder里跑出该有的效率
提到爆破，Burp Suite的Intruder模块是绕不开的。但很多人在配置环节就会踩坑，导致爆破了很长时间才发现结果是无效的，白跑一趟。
3.1 Intruder四种攻击模式怎么选
Intruder的四种模式，很多人只认识Sniper，这不够用：
- Sniper（狙击手）：适合单参数爆破，比如只爆破密码，用户名固定。
- Battering ram（攻城锤）：多个参数使用同一个Payload，比如用户名和密码都用同一个值去试，适合测试同一口令是否在多个位置生效。
- Pitchfork（草叉）：多组Payload并行对应多个参数，适合已知用户名列表、对每个用户跑同组密码。
- Cluster bomb（集束炸弹）：笛卡尔积组合，适合用户名和密码都用字典且需要交叉组合的情况。
字典爆破登录接口时，最常用的组合是Sniper固定用户名跑密码，或者Pitchfork用户名字典和密码字典并行跑。如果用户名也不确定，Cluster bomb虽然全面，但请求量是指数级膨胀的，跑之前你最好先算算总量：假设用户名1000条、密码5000条，组合就是500万条请求，就算1秒10个请求也要跑快6天，这种量级基本不具备现实操作性。
3.2 Payload加载与编码处理
在Intruder的Payload Options里，直接把清洗好的字典文件加载进去即可。但要注意三个细节：
- 不要勾选“URL-encode these characters”作用于全部内容，有时候目标系统对某些符号不做编码也能正常解析，全量编码反而会导致尝试的密码与服务端实际接收的不一致。
- Process payload in functions之前，先明确是否需要大小写变体。如果字典已经包含大小写版本，就不要再用规则引擎重复生成，徒增四五倍请求量。
- 如果目标接口是JSON格式提交，要在Payload Processing里做一次字符串拼接，把字典值塞进
"password":"值"的结构里，否则请求格式错误，所有请求都会返回400，看起来在爆破，实际全打在请求解析阶段。
3.3 线程数与超时设置的经验值
Intruder跑大字典时，资源线程数不是越大越好。我自己的经验值：本地测试目标可以给到20到30线程；远程目标建议从5线程起步，观察响应时间和报错率后再逐步增加。超过10个线程时，Burp Suite自身的CPU和内存占用会明显上升，如果开着代理抓包的同时跑Intruder，大概率会把代理拖垮，这时候建议只保留Intruder，或者把代理请求记录临时关掉。
Timeout建议设为10到15秒。这个值太短容易把服务端响应慢的正常请求判定为超时，太长则会拖慢整体进度。同时记得在Grep - Extract里提取响应中的关键字段（如success、error、msg），方便后续通过响应差异做命中筛选，而不只是一味看状态码。
4. 从“跑完”到“跑准”：命中率提升与性能平衡的实战技巧
很多情况下，字典没问题，工具也没问题，但结果就是不尽如人意。问题出在跑法上——你没有把字典的价值真正发挥出来。
4.1 规则引擎：用一份基础字典生成一百倍变体
Burp Suite的Payload Processing里，规则引擎是一个很好用的功能，但很多人不会用。它可以对每一条基础Payload做如下变体：
- 首字母大写
- 全部大写或全部小写
- 末尾追加1-4位数字
- 替换常见替换符（a->@、s->$、e->3）
- 先追加再首字母大写
实际场景中，很多企业的弱口令检查会把“Password123”、“Welcome@2024”这类变体作为重点，而基础字典往往只收录了“password”、“welcome”这些原型。完全依赖字典，不如在字典之上加一把规则。我自己的方案是：基础字典保持精悍（几千条高频词汇），在Payload Processing里追加2到3个规则变体，把几千条基础词汇扩张成十万级候选集，命中率往往比直接跑十几M的原始字典更高。
注意，规则引擎生成的请求数量是乘法级的，启用之前自己先算清总量。比如基础词条5000条，追加年份和一位特殊符号，理论上就是5000乘几十种组合，十几万请求，这个量级在可控范围内。但如果基础词条本身就20万条，再乘规则变体，那就是几百上千万的量，性能上直接爆炸。
4.2 低频条目稀释与优先级排序
拿85M的全量字典直接跑，最终耗时大多耗在低频长尾上。很多2024、2025年的变体，确实有一定命中率，但整体回报率很低。我的做法是把字典分成三档：
- 第一档：常用弱口令，顶多几千条，第一轮就跑这个，目标系统如果存在基础弱口令，这一档就能命中大半。
- 第二档：规则变体，在第一档基础上用规则引擎扩展，覆盖到十万级候选集。
- 第三档：全量字典兜底，前两档全部跑完仍无结果时，再动用这个“核武器”。
这样分层的逻辑很简单：先用最小成本解决最常见的问题，把低概率高成本的扫描留到最后，而不是一上来就用低效方式把所有请求都打出去。
4.3 响应差异分析：判断命中的关键不只是状态码
很多人爆破完只看HTTP状态码，200就是成功，401就是失败。但实际项目里，很多系统无论密码对不对都返回200，然后通过响应体内容区分。所以，正确做法是从响应中提取几个关键标识：
- 响应长度。登录失败和成功时，页面通常会渲染不同的HTML结构，响应长度会发生明显变化。
- 响应体关键字。用Grep - Match配置
success、welcome、用户名或密码错误这些关键词，直接标出命中项。 - 重定向目标。有的系统密码正确后返回302跳转到dashboard，密码错误则留在登录页，此时通过
Redirections配置来判断。
我自己在实战中习惯把response length列为第一筛选条件，再用关键字做二次确认。因为响应长度可以在响应时间列直接看到，不用展开单条请求，效率高很多。如果你发现某一条请求的响应长度和其他请求差出好几个数量级，优先检查这条请求，命中可能已经在这里了。
5. 实战中躲不开的坑：验证码、锁定策略与合规边界
字典和工具都就绪了，真正进入实战阶段，还有几个绕不过去的坎。
5.1 验证码和账号锁定：字典再全也绕不开业务限制
现在的目标系统，稍微有点安全意识的都会上验证码、登录失败次数限制、连续失败锁定账号这类机制。这种情况下，Intruder的裸爆破基本不可行，需要先看业务流程能不能绕过：
- 验证码是否仅前端校验，后端不校验，抓包重放就能绕过。
- 验证码是否跟Session绑定，但Session在多次请求间不变，抓一次验证码就能重复使用。
- 失败锁定是否按用户名维度，锁定只针对单个账号，可以换账号继续跑同一个密码。
- 是否有接口差分，移动端接口、老版本接口可能没有完整的风控逻辑。
这些判断都需要在爆破前先手工抓包分析，而不是直接开跑一套流程。还有一种特殊情况：目标系统对密码错误次数直接封禁IP，那你只能降速，或者通过分布式代理池做轮换，此时爆破周期会被拉长到以天为单位，必须提前做好心理准备。
5.2 WAF拦截与限速策略
跑大字典时最崩溃的事情是：跑了几个小时，回头一看，从某个时间点开始，所有请求都返回403。这说明被目标或前置WAF识别了。识别依据一般有两个：单位时间请求频率、某账号失败次数。
对策首先是限速。Intruder自带Resource Pool可以设置延迟，比如每秒不超过5个请求，或者每个请求之间随机延迟1到3秒，这种低频率下大部分WAF默认不拦。其次，User-Agent一定要改，默认的Burp Suite UA特征太明显，建议改成常见浏览器的完整UA串，同时把Session Cookie的获取做成每次请求自动更新，避免固定值被识别为扫描器特征。
顺便说一句，如果要跑更大的量级，建议换用命令行工具配合代理轮换，这类场景 Burp Intruder 反而显得笨重。
5.3 授权边界与日志留存：爆破前务必确认测试范围
这一点放在最后说，但重要性排在所有技术前面。爆破字典本身是安全测试的常见工具，但使用它的前提是你在授权范围内进行测试。我自己的习惯是，开工前把授权范围中的域名、IP段、测试时间窗、测试账号边界全部写清楚，并保留授权凭证。测试期间的请求记录、爆破结果、命中截图全部留存，万一目标系统被风控误报为攻击行为，这些记录是证明测试行为合规的关键材料。
所有命中结果，不建议直接在聊天工具里明文传播。报告里写清楚用户名、密码、影响面、修复建议即可，不要把全部测试数据一股脑丢进报告附件，这是对自己也是对目标单位的保护。
还有一个小技巧，爆破前先在目标系统上创建一个测试账号，用这个账号验证正常登录的请求报文格式和响应特征，确保Intruder的请求包和真实登录请求完全一致。这一步能帮你提前发现很多格式问题，而不是等几小时爆破结束才发现报文一直是错的。
我在实际项目中用过不少类似的大体积字典包，坦白说，完整85M直接跑完的次数屈指可数，大部分场景都是拆开用、配合规则、分层推进。字典的价值不在大，而在怎么用。学会拆解和清洗，再配合对目标业务的正常判断，这份资源才能真正变成你手里的有效武器。后续如果遇到字典命中率不高的情况，建议先回溯到清洗和切分的环节，往往问题就出在那一步。
本文还有配套的精品资源，点击获取
