简介这是一份面向渗透测试与安全评估人员的字典合集覆盖框架信息泄露、备份文件泄露、配置文件泄露等常见信息收集场景。按用途划分目录dir目录字典可直接加载Burp Suite进行目录爆破dns子域名字典辅助域名收集filename备份文件名字典支持文件名与后缀组合访问另有弱口令密码字典和用户名字典适合在授权测试中快速验证常见凭据。资源共204个文件压缩包32.48MB。除大量txt字典171个外还包含13个Python脚本、6个Markdown说明文档、3个CSV默认密码表、3个Excel表格以及alldorksv3、routes、dic、jar、license、json、lst等特殊格式文件兼顾规则模板、辅助脚本与参考数据便于不同工具链调用。目前已有51人学习下载对于需要快速搭建目录爆破、子域枚举和弱口令测试工作流的人员这一字典包能减少收集与整理成本直接投入授权测试适合Web安全初学者和中级渗透测试者按需取用。1. 渗透字典决定信息泄露测试上限的那批文本一份渗透字典的质量往往比扫描器版本更决定结果。测试 Spring Boot、若依这类框架时尤其明显框架路径、备份文件、配置文件泄露靠的不是扫描器多聪明而是字典里有没有对应的路径和文件名。这个压缩包表面看是常见渗透字典集合拆开后会发现它把目录、子域名、备份文件名、弱口令、用户名五类 payload 分开摆放还带 alldorksv3、PASS.JAR、credentials.json 这类附加料明显是按真实授权测试流程整理的。适合准备做内网或外网授权测试、需要快速搭一套 Burp 探测物料的人也适合照着它的分类思路自建一份信息泄露语料。下面的内容不吹“字典越大越好”而是从框架信息泄露、备份文件组合模式、配置文件泄露三个具体场景把用法、参数和踩坑一次讲掉。2. 拆开这包字典先搞清楚每个文件是干什么的拿到压缩包不要急着整包丢进 Burp先把文件过一遍。很多人只盯着 password 字典用结果在框架信息泄露测试时浪费了大量时间因为真正能用上的其实是 dir、filename 这两类词表。2.1 dir、dns、filename、password、username五类字典的设计意图从摘要可以明确这套字典的五大分类dir 为目录字典dns 为子域名字典filename 为备份文件名字典password 为弱口令字典username 为用户名字典。用表格整理一下使用场景字典分类用途建议放入的工具关注响应dirWeb 目录 / 路径爆破Burp Intruder、dirsearch、ffuf200、301、403、500dns子域名爆破subfinder、amass、dnsx解析成功的记录filename备份文件名探测组合模式 curl / Burp Cluster bomb非 404 响应password弱口令爆破Burp Intruder、hydra、超级弱口令检测工具登录失败 / 成功跳转username用户名枚举Burp Intruder、wpscan 等响应长度差、报错文案差dir 字典是整套的基座。很多框架信息泄露路径比如/.git/HEAD、/actuator/、/WEB-INF/classes/都是一行一行扫出来的没有这些基础路径后面组合模式无米下锅。dns 字典则适合先做子域名收集锁定目标暴露面后再进入目录爆破阶段。filename 字典是这套资源里比较有价值的部分。它放的不是完整路径而是纯文件名比如www、backup、admin、1、index这类常见命名。摘要里特别提到“使用组合模式将文件名与后缀进行组合访问”也就是说扫描时要用文件名加后缀的方式请求例如www.zip、www.sql、backup.tar.gz。这个设计比硬编码完整路径的字典灵活得多尤其在遇到不同站点备份命名习惯不一致的时候。password 和 username 字典不用多说区别在于它已经按用途拆好。weak password 和 username 分开意味着可以在 Burp Cluster bomb 模式下做交叉组合避免把所有口令都堆在同一个文件里导致 payload 爆炸。2.2 容易被忽略的 CSV、JAR 和 JSON附加文件的价值压缩包里除了那五类核心字典还躺着一批看着像其它东西的文件。先看 alldorksv3这是典型的 dork 列表可以导入 Burp 测试一些搜索型接口或跟踪链接类功能也可以在收集信息阶段用来查公开索引。它不是用来直接跑目录的这点要分清。passwords.csv、Scada_Password.csv、ics-default-passwords.csv三个文件是口令表。后两者面向工业控制系统比如常见的施耐德、西门子、罗克韦尔设备默认账号。如果你测试的是能源、制造行业的授权目标这两份表会命中很多通用默认口令但如果测的是互联网业务系统命中率会很低绕开就行。table.dic是通用字典通常用来兜底。前面 dir 字典没扫出来的路径可以用它再扫一遍代价是时间翻倍。PASS.JAR这个文件名很有迷惑性它不是 Java 可执行包本质是一份按场景整理的口令字典。遇到这种命名别直接当压缩包处理先用file或编辑器查看头部再决定怎么加载。credentials.json是结构化凭证文件适合给脚本读取比如自动化登录接口测试时直接解析成用户名密码对。6captchas.lst是验证码相关列表。可能是验证码接口路径也可能是常见验证码参数名。在登录爆破遇到图形验证码时把这个列表配合手工验证可以先尝试绕过或寻找重复使用验证码的接口。还是那句话授权范围内再测验证码逻辑别拿它去打没有授权的目标。2.3 框架指纹与配置泄露这些路径到底从哪里来光有字典还不够得知道扫什么路径。以目前最常遇到的 Spring Boot 框架为例/actuator、/actuator/env、/actuator/heapdump、/trace、/mappings、/beans这些端点是 Spring Boot Actuator 的一部分一旦暴露经常直接泄露环境变量、数据库连接串和堆内存快照。对应的就是 dir 字典里的 actuator 相关条目。若依框架是另一类高频目标。它基于 Spring Boot 二次开发常见路径包括/prod-api/、/dev-api/、/api/、/druid/、/swagger-ui.html、/tool/gen等。框架默认路径的泄露往往意味着配置文件也会被顺带找出来比如application.yml、bootstrap.yml、logback.xml。配置文件泄露是信息泄露里最要命的一块。Maven 项目会把settings.xml放在本地仓库或者 CI 机器上如果 Web 目录存在备份文件把它打包进去攻击者拿到后能直接看到私服地址、账号密码。logback.xml是日志配置文件泄露后通常会暴露日志路径、日志级别、常见业务包名甚至某些硬编码在property里的密钥。这套字典里的 filename 列表恰好覆盖了这类常见文件名扫描时把logback.xml、application.yml、settings.xml当作普通文件名去试命中率比想象中高。3. 把字典加载到 BurpIntruder 配置与资源池调优字典最后都要落到扫描工具上。Burp 是渗透测试里最常用的载体这里从 Intruder 四种模式开始讲清楚怎么把这套字典挂上并让扫描不翻车。3.1 Intruder 四种攻击模式怎么选Burp Intruder 有四种模式很多人第一次用就选 Cluster bomb结果请求数量呈指数级增长跑了一半就卡死。结合这套字典我的建议是这样Sniper狙击手一个 payload 位置遍历同一字典。适合测试单个参数或单个路径。比如把GET /{这里替换} HTTP/1.1中的路径位置设为唯一插入点加载 dir 字典。Battering ram撞锤多个位置共用同一个 payload。适合把用户名和密码位置同时填同一个值。Pitchfork草叉多个 payload 列表按行平行使用。username 字典和 password 字典如果行数一致可以一一对应尝试减少组合数量。Cluster bomb集束炸弹多个字典做笛卡尔积。适合 filename 组合模式一个位置放文件名另一个位置放后缀但它们组合后会生成大量请求建议先把文件名列表控制在 100 行以内。一般拿到这套字典后第一步扫描目录用 Sniper 就够了。Sniper 对字典没有尺寸要求即使 filename 字典有几千行也能跑完。如果确实想让结果更可控可以把普通路径和备份文件名合并成一个整合文件再用 Sniper 跑一遍。3.2 Payload 处理与 Grep-Match 设置在 Burp 里加载字典的流程很固定进入 Proxy 或 Repeater发送请求到 Intruder然后在 Payloads 选项卡里选择“Simple list”点击 Load... 选择字典文件。这里有三个细节很容易被忽略。第一个是 Payload encoding 勾选。默认情况下 Burp 会把 payload 里的特殊字符做 URL 编码比如#会变成%23、/会变成%2f。目录扫描和备份文件测试时路径里的/是必须原样保留的否则请求会全部打在一个错误路径上。我一般在 Payload Options 里取消 URL-encode让 payload 原样插入。第二个是 Grep-Match。在 Intruder 的 Settings 选项卡里加一条 Grep - Match 规则比如抓root、password、jdbc:、BEGIN RSA PRIVATE KEY、property这些关键词。响应包里一旦命中其中任何一个Intruder 结果区会自动用勾标出来。这样就不用一条条看响应内容里有没有真正的泄露痕迹只凭关键词命中数量就能快速定位高价值目标。第三个是重定向处理。遇到登录接口返回 302 时默认设置不会跟随重定向导致响应长度差异不明显。建议在 Settings 里的 Redirections 选项选择 All或者手动把请求发到 Burp 的 Cookie 容器里处理。不过要注意跟踪重定向会增加耗时对纯目录扫描不划算建议只在口令爆破场景开启。3.3 Resource Pool 与线程控制低配机器也能跑完 backup 字典跑字典死在资源池上的情况太常见了。Burp 默认的资源池不限制最大并发一旦 filename 字典组合出来的请求数超过几万个线程会疯狂抢占网络连接目标服务器也可能直接封 IP 或断连。我通常的做法是给每个扫描任务建独立 Resource Pool。在 Burp 右上角 Resource Pool 面板里新建一个组Maximum concurrent requests 设置为 5 或 10Delay between requests 设置在 50 到 200 毫秒之间。为什么要加延时因为多数 WAF 和反爬策略只盯着高频请求5 线程加 100 毫秒延迟可以把请求频率降到每秒 10 次以内反而比暴力超时更稳定。具体线程参数可以参考这个表扫描场景最大并发延迟超时(ms)目录扫描 dir 字典1050ms5000备份文件组合 Cluster bomb5100ms8000口令爆破 Pitchfork3200ms10000子域名解析200ms3000还有一个经验先用一个 10 文件行的小样本试跑一遍确认 Burp 的请求格式和 GREP 规则没写错再全量加载。这比跑完 5 万个请求后才发现路径格式错误要省力得多。4. 框架信息泄露与备份/配置文件检测拿来就能用的探测流程字典落到具体场景里才有价值。这一章按三条线讲透Spring Boot Actuator 和若依框架的路径探测、备份文件组合模式、配置文件泄露排查。4.1 Spring Boot Actuator 与若依框架的路径探测先说 Actuator。Spring Boot 项目启用 Actuator 后会暴露一组/actuator开头的端点。测试时先扫 ACTUATOR 基础路径再用已知端点列表深入。利用 dir 字典中的常见路径一个典型的 bash 探测循环如下while read path; do code$(curl -k -s -o /dev/null -w %{http_code} https://target.com/${path}) if [ $code ! 404 ]; then echo $code ${path} fi done dict/dir.txt这段脚本的逻辑是逐行读取 dir 字典把每个路径拼到目标域名后面用curl -s静默请求-w %{http_code}只输出状态码。-k是为了在目标证书不正规时不触发报错。若依框架的路径也是同理把/prod-api/、/dev-api/、/druid/这些词条提前放到字典头部能更快遇到高价值响应。如果扫描到/actuator返回 200紧接着就要确认端点是否真正开放。用 curl 直接请求/actuator/health和/actuator/env/actuator/env返回环境变量时通常伴随jdbc:或password字段。这一步必须手工验证防止扫描器把 200 当成漏洞而忽略实际内容。4.2 备份文件组合模式文件名与后缀排列扫描摘要里反复提“filename 字典使用组合模式”这是整套资源里最值得重点讲的技巧。所谓组合模式就是把字典里的文件名和后缀列表做笛卡尔积生成www.zip、www.bak、admin.sql、config.tar.gz这类完整路径。写一个 Python 脚本快速生成测试列表import itertools names [line.strip() for line in open(dict/filename.txt, encodingutf-8) if line.strip()] exts [.zip, .tar.gz, .sql, .bak, .rar, .txt, .7z, .gz] with open(backup_wordlist.txt, w, encodingutf-8) as fp: for name, ext in itertools.product(names, exts): fp.write(f{name}{ext}\n)这段代码做了三件事第一用itertools.product生成文件名和后缀的全组合第二把组合结果写入新文件backup_wordlist.txt第三生成的是一个可直接刷进 Burp 的普通文本。你可以根据目标系统的备份习惯增删后缀比如 Windows 服务器常见.rar和.7zLinux 服务器常见.tar.gz和.sql。拿到backup_wordlist.txt后直接加载到 Burp Intruder 的 Sniper 模式插入位置放在域名后面。实际测试时经常出现“当开发人员在线上环境中对源代码进行了备份操作并且将备份文件放在了 web 目录下”的场景这种备份文件一旦被访问到往往就是源码泄露的开始。用组合模式测试的价值在于它并不假设备份文件名一定是www.zip而是覆盖了所有常见命名和后缀的可能。4.3 配置文件泄露logback.xml、Maven settings.xml 的排查配置文件泄露与目录扫描是两回事。很多人扫完目录只看几个状态码却不关注响应内容里的关键词。正确的做法是把返回 200 的路径全部抓下来再用关键词过滤。推荐使用 Burp Intruder 的 Grep-Match 功能关键词至少包含这些password、username、jdbc:、token、secret、api_key、access_key、property、logging.file.path。一旦响应里出现这些词这个 200 的路径就值得手工打开看内容。具体到配置文件本身有几个固定套路值得记配置文件泄露特征常见路径application.yml/.properties包含数据库密码、Redis 密码、密钥对/application.yml、/config/application.ymllogback.xmlXML 头、日志路径、业务包名/logback.xml、/WEB-INF/classes/logback.xmlmaven settings.xmlserver标签、私服地址、镜像仓库/settings.xml、/.m2/settings.xml.git/config[remote origin]、仓库地址/.git/config.svn/entries版本号、文件列表/.svn/entries其中 Maven 配置文件的排查经常被忽略。很多 Spring Boot 项目通过 Maven 构建settings.xml一旦泄露私服里的所有依赖都可能被拖走而且这个文件往往就在 web 目录的备份包里。若依框架则通常把数据库配置文件放在resource目录下打包到 jar 后路径会变成/BOOT-INF/classes/application-druid.yml扫描时不要漏掉这条。5. 避坑指南渗透字典压测中容易翻车的五个问题字典本身不会坑人使用方式会。这一章把我实际踩过的坑按“现象 → 原因 → 解决”写清楚每一条都能省你半天时间。5.1 现象目录扫描返回一大片 200但人工访问全是统一登录页造成这种情况最常见的原因是目标框架把不存在的路由也返回 200比如 Vue 前端路由或 Spring Boot 的default page。若依框架尤其典型它会在网关层统一处理不存在的路径也返回一个统一的 HTML 页面。原因响应码不是有效判断条件框架的全局异常处理把 404 吞掉返回 200。解决对比响应长度和响应内容。若所有 200 的页面Content-Length一致说明这些响应是同一种兜底页面真正的目录在扫描结果里的特征应是响应长度波动。用 Burp 的Inspect面板按大小排序或者给 Grep-Match 加一个 target 页面独有的关键词然后反选过滤。5.2 现象备份文件组合模式跑到一半 Intruder 卡死进度条再也不动这是资源池设置不当的直接后果。组合模式生成的请求数量轻松上万如果同时在 Intruder 里跑多个 TabBurp 的线程会被拖垮。原因Resource Pool 没有限制最大并发系统文件句柄或网络连接耗尽。解决单独建一个 Resource Pool最大并发调成 3延迟 200ms。另外一个更稳妥的做法是先用上面第 4 节的脚本生成完整backup_wordlist.txt然后用 Sniper 模式一次性跑而不是在 Intruder 里实时做笛卡尔积。5.3 现象从 CSV 字典加载 payload 时Burp 把一个条目拆分成了多个passwords.csv、ics-default-passwords.csv这类文件用逗号分隔字段但 Burp 的 Simple list 默认按行读取不会主动识别 CSV 结构。如果直接加载一行里的多个字段会被当成一整个 payload导致口令爆破失败。原因Burp 不会处理 CSV 中的分隔符整行被当作单一字符串。解决把 CSV 转换成每行一个 payload 的纯文本格式比如用awk -F, {print $1}提取第一列或手动用 Excel 另存为 CSV 后导入前先做一列去重。对 Scada_Password.csv 这类工控口令表建议只取用户名和密码两列分别输出到单独文件再加载。5.4 现象中文用户名或带#的 payload 请求后乱码目标系统返回参数错误这套字典里的 username 文件大概率包含中文姓名但终端或 Burp 的环境编码不对导致发送出去的请求是 GBK 字节流目标系统按 UTF-8 解码就出现乱码。原因字典文件本身编码可能是 GBK 或 UTF-16Burp 默认按 UTF-8 读取。解决先用file命令检查字典编码再用iconv -f GBK -t UTF-8 dict/username.txt -o username_utf8.txt做转码。如果服务器本身是 GBK 编码常见于老牌 OA 系统则反过来转成 GBK 后加载。编码问题不解决再强的字典也发挥不出作用。5.5 现象lic-dtct等等别用奇怪的工具直接说弱口令字典扫出的结果大量误报默认口令字典里有不少口令是admin/admin、test/test这类测试账号。扫描器一旦发现登录接口返回了跳转或welcome字样就容易判定为弱口令。但实际很多系统前端会用 JavaScript 校验口令错误也返回 200只是页面内容里带着错误提示。原因只对比响应码没有对比响应主题。解决把登录请求的响应内容拉出来用 Grep-Match 同时匹配“success”“welcome”“index.jsp”“修改密码”等关键词多个关键词任一命中才判定成功。如果是 JSON 接口直接匹配code:0之类的业务字段。这一步能把误报率压缩到 5% 以下。6. 让字典保持新鲜合并增量、去重排序并沉淀成自己的语料库字典用得再熟半年不更新也会失效。框架一改版路径就变新中间件也会带来新端点所以最后一章分享一个我每天都会跑一遍的维护流。先做一个最基础的清理把所有类别字典合并去重并按长度排序cat dict/dir.txt dict/filename.txt dict/dns.txt | \ sed s/\r$// | \ grep -v ^$ | \ sort -u combined_wordlist.txtsed s/\r$//用来干掉 Windows 换行符grep -v ^$移除空行sort -u去重排序。这一步执行完就能得到一份干净可复用的大字典。注意不要把所有分类强行混在一起组合模式下还是保持filename、dir各自独立。接着是从实战回流增量。我在跑完一次 Burp 扫描后会把返回非 404 但没在字典里出现的路径单独存成一个new_paths.txt定期合并进 dir 字典。文件备份名也一样如果目标系统用了20240101_backup.zip这种带日期的命名就把20240101这个样式提取出来追加到 filename 字典下一次遇到同类命名习惯的系统就能直接命中。如果你在维护过程中发现某一类固定框架路径频繁变化比如 Spring Boot Actuator 端点在不同版本里增删建议单独建一个framework_paths.txt。我自己习惯把/actuator/health、/actuator/beans、/actuator/configprops、若依的/prod-api/、/dev-api/、/tool/gen全放进来每次扫描前先用这个文件打头阵再跑通用 dir 字典。这套逻辑比祈祷字典刚好覆盖目标框架要可靠得多。字典整合不是越大越好。盲目合并会产生大量重复路径让 Intruder 空转。所以我每周做一次全量清理先sort -u去重再用wc -l对比合并前后行数确认增量是真实的新路径而不是重复数据。如果发现某个文件突然膨胀了 30% 以上十有八九是重复爬取合并出了问题需要回查来源文件。从那以后我每次拿到新目标都会强制走一遍这个流程先加载framework_paths.txt快速确认框架指纹再挂 filename 组合模式扫备份最后才跑整体 dir 字典。这个过程花不了五分钟但能避免在错误路径上砸下去几千个请求。字典是死的使用顺序和维护习惯才是让它在信息泄露测试里持续生效的关键希望这份使用笔记帮你在下一次授权测试里少走几步弯路。本文还有配套的精品资源点击获取