拿到授权测试的目标后我通常进门第一件事不是急着开扫描器而是先坐下来想清楚一个问题目标如果有个登录框我准备拿什么字典去撞密码。密码字典生成这个环节看着简单实际很讲究。Kali Linux 里 Crunch 和 Cewl 这套组合一个是按规则批量生成密码序列的“暴力生成器”一个是从目标网站文本里提取真实单词的“词料收割机”单用都不稀奇但把它们合在一起用往往能做出比网上那些几十 GB 默认字典高效得多的定向字典。这篇文章就把我平时用 Crunch 和 Cewl 做组合生成字典的思路、命令、参数细节和踩坑经验完整写出来。无论你是刚开始接触渗透测试的新手还是经常做内网口令评估的老手只要目标场景里有登录框、有弱口令测试环节这套方法都能让你少跑很多冤枉路也少等几个通宵。1. 先搞懂 Crunch 和 Cewl 为什么能高效组合1.1 密码字典的真相量不如准很多人一想到密码字典第一反应就是去网上下个“社工库字典合并包”“几百 GB 全字符集大字典”。这类东西不是没用而是效率太低了。一次爆破的请求量上限就摆在那你拿一个 500 GB 的字典去撞可能三天三夜都跑不完而且里面大量组合根本不会出现在目标环境里。真正能做出口碑的测试流程讲究的是“精准”两个字。目标系统有密码策略比如“位数 8 到 16必须包含大小写和数字”那你就得先按这个策略去生成结构化的候选集目标站点里到处是员工姓名、产品代号、邮箱前缀、公司英文缩写那这些就是比任何通用字典都值钱的词料。所以说密码字典的核心不是数量而是命中率。这也是为什么我始终坚持自己生成字典而不是直接拉一个现成的大文件。1.2 Crunch 和 Cewl 的分工逻辑Crunch 和 Cewl 正好形成两个互补的维度工具角色强项弱项Crunch规则生成器按最小长度、最大长度、字符集、固定格式生成海量组合适合补足“策略要求的通用部分”纯枚举没有语义概念生成的词和人脑习惯脱节Cewl词料收割机从目标网站的页面文本、文档、链接路径里提取单词和邮箱生成的词和真实场景强相关不执行 JS拿不到动态渲染内容对中文分词基本无效组合的逻辑很简单Cewl 负责告诉你“这个站点的人喜欢用什么词”Crunch 负责把这些词扩展成“符合登录密码规则的可试组合”。一个是点一个是面两者结合在一起覆盖面才完整。1.3 用之前先想清楚边界这句话我必须放在前面字典生成本身是一种中性的技术手段但你把生成的字典拿去哪里撞直接决定了这件事的性质。我只在两类场景里用这套流程一类是自己拥有或者拥有明确书面授权的系统测试另一类是 CTF、靶场、本地实验环境。没有授权就去对线上系统做口令爆破那已经不是技术问题了是合规和法律问题。实际操作时我的习惯是先和甲方确认测试范围把目标登录地址、账号列表来源搞清楚再动手生成字典。宁可前期多沟通十分钟也别在最后测试报告里出现任何模糊地带。2. Crunch 核心参数与实用姿势2.1 基础语法min、max、字符集Crunch 的语法非常简洁核心就三个位置参数crunch 最小长度 最大长度 [字符集或字符集名称] [选项]最简单的例子生成 8 位纯数字字典crunch 8 8 0123456789 -o 8位纯数字.txt我一般不会手写一整串字符更多时候直接引用 Kali 自带的字符集文件/usr/share/crunch/charset.lst。这个文件里预置了很多常用集合比如字符集名称内容适用场景numeric数字 0-9手机号、工号、纯数字口令hex-lower0-9 加 a-f固件密钥、注册码等非口令场景lowercase小写字母 a-z英文单词型弱口令lowerupper大小写字母 a-zA-Z大小写混合口令printable全部可打印 ASCII 字符覆盖所有符号体积爆炸谨慎使用使用方式是在后面跟字符集名称crunch 8 8 lowercase -o 8位小写.txt这里需要先算一笔账8 位纯数字就是 10^8 1 亿条文件大概 900 MB。8 位纯小写字母是 26^8 ≈ 2088 亿条你算算这个文件得多大所以用 Crunch 前一定要先估算数量级别盲目堆字符集。2.2 pattern 模板把已知规则变成目标顺序Crunch 最值钱的功能是-t参数它能让你按照已知的密码格式生成而不是傻傻地全排列。占位符规则如下代表小写字母,代表大写字母%代表数字^代表特殊符号假设目标系统密码策略是8 位首字符必须是大写字母中间 3 位小写然后 2 位数字最后 1 位特殊符号。直接用一条命令生成crunch 8 8 -t ,%%^ -o 策略密码.txt这种模式生成的候选数量是 26大写× 26^3小写× 10^2数字× 33符号≈ 1.5 亿条左右虽然也不少但相比于“所有 8 位全组合”已经是缩小了很多量级。还有更实用的玩法如果你知道某个系统内部账号前缀固定比如管理员账号开头是 “sa”后面才会跟数字那就可以写成crunch 6 8 -t sa%%% -o 带前缀字典.txtCrunch 会保留sa这两个固定字符只替换后面的占位符。这个能力在指纹明确的内网系统里非常有用因为很多单位初始化密码的规律真的很稳定比如“公司缩写 工号 年份”这种格式。2.3 控制输出大小与中断别让磁盘爆炸生成字典前先手动算一下“条数”和“文件大小”这个习惯能救你很多次。核心公式组合条数 字符集大小 ^ 密码位数 文件大小 ≈ 条数 × (密码位数 1)这里的 1 是换行符。比如生成 6 位纯数字就是 10^6 100 万条文件约 7 MB随便跑生成 8 位纯数字则是 1 亿条约 900 MB勉强能接受生成 8 位小写字母就是 2088 亿条约 20 TB你根本生不完。如果你确实需要生成很大的字典又担心中断后白干可以用-c按行数拆分和-b按大小拆分把输出切成小文件crunch 8 8 0123456789 -b 50mb -o 分块字典 -c 1000000-b 50mb会按 50 MB 大小分块-o 分块字典支持在文件名里加%d通配符来自动编号比如-o chunk-%d.txt。另外-z gzip可以在生成的同时压缩输出能明显省磁盘空间。3. Cewl 词料提取的关键细节3.1 常用参数与爬取实例Cewl 的作用是去爬网站页面并把文本里的单词提取出来。它的常见姿势是这样的cewl http://192.0.2.10/ -d 2 -m 5 -w /tmp/target_words.txt --with-numbers --email --lowercase常用参数含义参数作用我的建议-d爬取深度测试范围小就设 1 或 2太深会非常慢-m最小单词长度默认 3我一般设置 5 或 6太短的词没有价值-w输出文件指定词料输出路径--with-numbers保留包含数字的单词很有用能保留 “admin2024” 这类--email提取邮箱地址邮箱前缀往往就是账号或密码习惯--lowercase统一转小写减少后续去重的麻烦-u自定义 User-Agent有些页面会拦截默认爬虫 UA建议伪装成浏览器举个例子我测试某个内部 Wiki 系统时只跑了cewl http://192.0.2.10/wiki -d 2 -m 4 -w wiki_words.txt --with-numbers --email --lowercase几分钟后拿到一个几百行的词料文件里面有“project”、“admin”、“helpdesk”、“2024”这些词还有几个形如zhangsanexample.com的邮箱地址。这些信息比任何通用字典都更接近真实密码。3.2 词料清洗与分类提取出来不等于能用Cewl 跑出来的原始词料通常夹杂着很多页面导航词、版权声明、重复内容直接拿去用很容易稀释字典质量。我的固定动作是先清洗sort -u wiki_words.txt -o wiki_words_clean.txt把重复行去掉。接着按长度过滤因为密码策略通常有最小位数限制awk length($0) 4 length($0) 8 {print} wiki_words_clean.txt wiki_words_filter.txt然后根据场景做简单分类。如果测试目标是 Windows 域环境邮箱前缀就是重点可以用cut -d -f1提取前缀作为账号候选如果目标是员工自定义密码那就把“项目名”“系统名”“年份”分离出来。中文站点是 Cewl 的一大盲区因为它默认按英文分词规则处理。遇到中文企业站我通常的做法是先去官网英文版或品牌页拿到公司英文名和产品英文代号再从 URL 参数、JS 文件名、接口路径里手动收集有意义的词根。这样收集到的词虽然量少但和目标的相关性极高。3.3 爬取被限制时的处理思路Cewl 本质是一个轻量爬虫面对常见的反爬策略时会直接扑空。我遇到过的典型情况有三种。第一种是请求被 UA 拦截页面返回 403。解决办法是加-u参数伪装成 Chrome或者干脆先用真实浏览器访问目标页面并保存 HTML再用 Cewl 的本地模式去解析文件cewl /tmp/saved_page.html -m 5 -w local_words.txt第二种是页面内容靠 JS 动态加载Cewl 看到的是空壳。这种情况我一般不会硬磕 Cewl而是先调用无头浏览器把渲染后的页面 dump 下来再交给 Cewl 处理。第三种是测试环境需要登录 Cookie 才能看到正文。Cewl 本身不能带 Cookie我的替代方案是用curl登录后保存页面源码再从源码里手工提取关键词。多花几分钟但总比生成一堆无效字典再去撞要省时间。4. 三套组合方案从合并到定向生成4.1 方案一直接合并去重建基础字典最直接、也最常用的组合方式用 Crunch 生成符合密码策略的“通用部分”用 Cewl 抓取目标相关的“语义部分”然后合并去重。# 1. Cewl 抓取词料 cewl http://192.0.2.10/ -d 2 -m 5 -w /tmp/site_words.txt --with-numbers --lowercase # 2. Crunch 生成 8 位纯数字和小写字母组合 crunch 6 8 0123456789 -o /tmp/digits.txt crunch 6 8 lowercase -o /tmp/lower.txt # 3. 合并并去重 cat /tmp/site_words.txt /tmp/digits.txt /tmp/lower.txt | sort -u /tmp/base_dict.txt wc -l /tmp/base_dict.txt这个方案的好处是简单、直接能快速得到一个覆盖面还不错的基础表。它适合那种你还没完全摸清目标密码策略的场景先用一个通用表跑一轮看看哪些账号命中率高再针对性做二次字典。4.2 方案二让 Crunch 把 Cewl 词料变成定向字典基础字典只是第一步。真正能体现“高效组合”的玩法是用 Crunch 的-q参数读取 Cewl 的词料文件再通过 pattern 模板给这些词根“追加数字或符号尾巴”。举个例子Cewl 从目标站点提取到“admin”“demo”“test”这种词根我猜目标管理员喜欢用“单词 两位数字”的格式做密码那么可以这样# 先过滤出长度合适的词根 awk length($0) 4 length($0) 5 {print} /tmp/site_words.txt /tmp/root_words.txt # 让 Crunch 把每个词根接上两位数字生成 6-7 位组合 crunch 6 7 -t %% -q /tmp/root_words.txt -o /tmp/directed_dict.txt这里的原理是-q让 Crunch 把词料文件中的每一行当成一个可替换的单位放到占位符的位置%%继续表示两位数字。这样生成的字典里你会看到admin12、demo88、test33这类组合而不是纯暴力枚举产生的无意义字符。这个方案的命中率我实测下来明显高于纯模板暴力型因为它利用了目标站点的真实词汇习惯。同时产出的组合条数很小哪怕做成“词根四位数字特殊符号”也才几万条跑起来非常快。4.3 方案三组合之后再跑规则变形进阶必看如果你手头的时间充足又想试探更复杂的变形可以在合并字典后再叠加一层规则引擎。Kali 里的 hashcat 自带--stdout模式不需要真的跑破解只需要把字典里的每一行按规则变形输出。# 先用前两个方案产生合并字典 cat /tmp/site_words.txt /tmp/directed_dict.txt | sort -u /tmp/merged_dict.txt # 再用 hashcat 规则做变形增强 hashcat --stdout -r /usr/share/hashcat/rules/best64.rule /tmp/merged_dict.txt /tmp/final_dict.txtbest64.rule是最常用的规则集里面包含大小写替换、末尾加数字、末尾加年份、键盘序列等常见变换。比如原始词是admin规则变形后可能产生Admin、admin123、admin2024、Adm1n等一批变体。这种组合看起来有点“超纲”但它实际上是把 Crunch 和 Cewl 的产物做了一次化学放大。需要注意一个副作用规则变形会让体积扩大很多倍如果前面生成的字典已经很大这一步可能导致文件翻到几十 GB所以一般我只在中小规模、定向明确的场景下使用。5. 一次完整实操记录与心得5.1 从信息搜集到最终字典的完整流程拿一个典型的授权测试场景举例目标是一个内网业务系统登录页要求密码 6-12 位允许大小写和数字。我手上有一个账号清单需要构造一个用于弱口令评估的字典。第一步先爬目标站点cewl http://192.0.2.10/ -d 2 -m 5 -w /tmp/web_words.txt --with-numbers --lowercase第二步清洗和过滤词料sort -u /tmp/web_words.txt -o /tmp/web_words_clean.txt awk length($0) 4 length($0) 6 {print} /tmp/web_words_clean.txt /tmp/roots.txt第三步用 Crunch 做两套模式一套是“小写单词 2 位数字”一套是“大写开头 小写 数字”的通用策略crunch 6 8 -t %% -q /tmp/roots.txt -o /tmp/direct_dict.txt crunch 6 8 ,%% -o /tmp/rule_dict.txt第四步合并、去重、统计cat /tmp/direct_dict.txt /tmp/rule_dict.txt /tmp/web_words_clean.txt | sort -u /tmp/final_dict.txt wc -l /tmp/final_dict.txt拿到最终字典后我一般会先head -n 20 /tmp/final_dict.txt看一眼生成的内容是否符合预期。确认无误再把这个字典交给爆破工具去跑。5.2 不同目标场景下的取舍这套流程不是死板的实际使用中要根据目标调整侧重点。如果目标是公网企业站点Cewl 词料的价值最高因为企业官网往往带有品牌词、产品名、客服邮箱员工的弱口令经常从这些词里衍生如果目标是内网核心系统Crunch 模板的优先级更高因为内网系统的密码策略通常强制“字母数字符号”而员工的真实习惯往往是“固定单词固定数字固定符号”。我遇到过一个内网目标密码策略里要求必须有数字和特殊符号结果内部大量账号的密码格式都是“英文缩写 年份 感叹号”。这种场景下靠 Cewl 收集企业英文缩写再靠 Crunch 生成缩写2024!这类格式命中率非常可观。5.3 实测下来的个人经验用这套流程做了很多次口令评估后我最大的感受是不要把生成字典和测试爆破割裂开。第一次测试一般只用最小集合探路看看目标有没有账号锁定策略、有没有验证码、有没有频率限制。如果目标系统有连续错误锁定机制那生成再大的字典也没意义反而应该重点做小规模高命中的定向字典。还有一点Crunch 生成超大字典前我一定会先跑个小样验证 pattern 对不对。以前我就吃过亏写了一个自认为正确的占位符模式结果生成出来的全是稀奇古怪的组合白白跑了半小时才反应过来。小样命令很简单crunch 6 6 -t ,%% -o test.txt head -n 10 test.txt看到 sample 里的第一条符合预期再放开跑大字典这个习惯能帮你提前拦截一大批低级的格式错误。6. 常见问题与避坑指引现象原因解决办法Cewl 跑完什么都没输出目标页面是 JS 渲染或 UA 被拦截用真实浏览器保存页面源码后本地解析自定义 UACrunch 生成数量爆炸磁盘瞬间被填满字符集太大或位数太长先用公式计算条数改用 pattern 模板缩小范围合并后的字典重复率过高多个字典来源交叉重叠用sort -u去重后再用中文站点几乎提不出有效词料Cewl 默认按英文分词改为手动收集品牌拼音、URL 参数、接口英文名hashcat 规则变形后文件量暴涨几十倍规则集会对每行生成多种变体先在小规模字典上试跑确认体积后再决定是否全量打开字典文件出现乱码源页面编码格式不统一用iconv -f gbk -t utf-8做编码转换后再入字典爆破时频繁被目标锁定账号测试节奏没控制好降低每秒请求数或换高精度小字典低频打点关于锁定的问题再单独说一句。测试口令安全的时候不能一门心思只关心字典生成还得关注目标的账号锁定策略。之前遇到过某系统设置了“连续 5 次失败锁定账号”这种情况下再好的字典也没用。合理的做法是先对每个目标账号只试 3-4 个高命中的定向密码留足安全余量等确认没有触发风控再决定是否扩大测试范围。这里才是真正考验渗透测试人员工程能力的地方。Crunch 和 Cewl 本身也有版本差异。新装的 Kali 一般已经预装这两个工具如果没装一条命令就能搞定apt install crunch cewl另外Cewl 对页面文本的提取质量受目标站点内容质量影响很大。页面里大量使用图片代替文字、或者内容本身是扫描件转换的 PDFCewl 就会失效。遇到这种情况我一般会直接放弃自动提取改用人工整理词料效果反而更好。我个人在实际操作中的体会是字典生成永远是一个迭代过程不要指望第一次跑出来的字典就能直接命中。先用 Cewl 抓词料、用 Crunch 补模式、再用规则引擎变形跑完一轮之后根据目标的反馈继续精修通常两三轮下来字典的质量就非常能打了。最后再分享一个小技巧把 Cewl 的邮箱前缀单独提出来作为用户名列表再把 Cewl 的词根通过 Crunch 生成“前缀数字”的候选密码往往能同时解决“账号枚举”和“弱口令”两个方向很多看似复杂的系统在这一步就出效果了。