在授权渗透测试里，密码喷洒和弱口令爆破是最常碰到的环节。我发现自己反复面对一个尴尬情况：手头通用字典动辄几个G，但遇到对目标定制化程度要求高的场景，比如只针对某家公司官网的密码喷洒，通用字典反而命中率低得可怜。后来我认真用了Kali里自带的一个工具，cewl，事情才有了根本性改观。这篇文章就把我实际使用cewl的经验完整写出来，包括参数怎么取舍、爬取策略怎么定、生成后的字典如何清洗和扩展，以及在真实项目中踩过的坑。
cewl的全称是Custom Word List generator，用来从目标网站内容中自动提取单词，生成高度定制的密码字典。很多人误以为它就是普通爬虫，其实它的核心价值在于“定向”——它能根据网站的真实用词、品牌名、产品名、联系方式等，生成与该目标强相关的字典。这种字典在针对特定组织、特定业务的密码爆破中，效果远超rockyou等通用字典。下面我从原理讲到实战，一步步拆开。
1. CeWL能给你的字典库补上哪块短板
1.1 通用字典的局限是“不够贴合”
第一次接触密码字典的人多半会去下载rockyou.txt或类似的大字典，几百万条甚至上亿条词。这类字典适合拿来跑通用弱密码，像“admin123”“password”之类，但一旦目标企业把员工密码设置成“公司名+年份+特殊符号”这种组合，通用字典基本帮不上忙。
原因很简单：通用字典不够“贴合”。它没有访问过目标站点，不知道这家公司的产品叫什么、官网footer里写了什么电话号码、招聘页面出现了哪些地名。而现实中很多人设密码，就是从这些公开信息里取材的。cewl做的事，就是把目标网站上这些“活的信息”变成可用的单词列表，本质上是从目标的公开内容中反向推导出密码的可能性空间。
我在一次授权测试中碰到过一个客户，员工账号密码居然是“公司英文名缩写+2023!”。这种信息在官网“关于我们”页面中完全公开，但通用字典不会收录这种组合。用cewl抓取该公司官网后，公司英文名出现了几百次，直接进入字典前列，密码喷洒一下就出来了。
1.2 CeWL的工作原理决定了它的价值
cewl是Ruby写的，工作流程不复杂：请求目标URL抓到HTML，提取出页面中的文字内容，按空格、HTML标签等分隔符切分词，再经过过滤（去重、过滤过短的词、剔除常见停用词），最后按需要的格式输出。就这个“简单”的机制，反而成了它的优势——不依赖API，不需要目标主动配合，只需要目标网站能被爬取。
从实际使用来说，cewl还有个常被忽略的点：它能深入爬取多级页面。默认会顺着页面里的链接继续抓，深度可以配置。如果目标网站有博客、新闻、产品文档，抓取深度拉到3到4层，基本能把这家公司的“词汇指纹”完整摸一遍。
CeWL输出的单词列表不仅仅是给密码爆破用的。它还能在用户名枚举、安全培训演示、红队报告编写时提供素材。比如字典里提取到的邮箱地址，可以直接用来构建用户的账号名列表。我在很多项目中同时使用这两类输出，一个词表跑密码，一个邮箱表生成账号，效率提升非常明显。
2. 装好环境先跑通一个最小示例
2.1 在Kali和普通Linux上的安装方式
Kali Linux默认装好了cewl，直接终端输入cewl就能看到帮助信息。如果你用的是其他Linux发行版，安装也简单：
# Debian/Ubuntu系 sudo apt install cewl # 或者直接用gem安装 gem install cewl装完验证一下：
cewl --help如果出现参数列表，说明环境没问题。我建议先找个测试站点跑通最小示例，再研究高级参数。
2.2 最小示例：抓取一个页面并输出单词表
最小可用命令如下：
cewl https://example.com -w example_dict.txt这条命令会抓取example.com首页，提取单词，写入example_dict.txt。默认最小单词长度是3，所以像“a”“an”这类词会被过滤掉。
跑完之后看看文件的头部和统计信息：
head -20 example_dict.txt wc -l example_dict.txt拿到基础字典后，我通常会再做一次频率分析和词长分布分析，判断这批词是否贴合目标。这一步很多人跳过，但我建议别省，原因后面讲。
2.3 核心参数一览：先有个整体框架
cewl参数不算特别多，但每个参数都会直接影响输出质量。我先列一个高频参数组合：
| 参数 | 作用 | 默认值 | 我的建议 |
|---|---|---|---|
-d | 爬取深度 | 2 | 根据站点规模设3到4，别设过大 |
-m | 最小单词长度 | 3 | 密码场景建议6到8 |
-w | 输出文件 | 无 | 每次必带 |
-e | 是否提取邮箱 | 不提取 | 结合需求开启 |
-c | 输出附带出现次数 | 不附带 | 建议开启，省去手动统计 |
--with-numbers | 包含带数字的单词 | 不包含 | 喷密码场景强烈建议开 |
-u | 指定代理 | 无 | 需要走代理访问目标时可配 |
-a | 自定义User-Agent | 默认 | 被WAF拦截时尝试换UA |
参数怎么组合，取决于你的测试目标和授权范围。下面我逐个说清楚。
3. 核心参数逐个拆解：决定字典质量的工程化取舍
3.1 爬取深度-d：抓得多不等于抓得好
-d是depth的缩写，控制cewl从起始URL开始，顺着链接递归抓几层页面。默认值是2，表示抓取首页以及首页链接的一层页面，共2层。
实际项目中，我通常从官网首页开始，把深度设在3。为什么不是5或10？因为很多站点的导航结构里，“关于我们”“产品中心”“新闻动态”这些页面都在首页的二三层链接中，抓到3层已经能把全站核心词覆盖。继续加深，会爬进新闻文章的翻页列表、博客归档等大量低价值页面，不仅耗时长，还可能触发目标WAF的访问频率限制。
如果目标站点只有几个页面，比如公司展示型官网，那么-d 2就够用了。设置前最好先用其他爬虫工具（如httrack或Burp的spider）把站点结构摸一遍，再决定深度。爬得太深，页面上无关词干扰越大，字典纯度反而下降。
3.2 最小单词长度-m：密码场景一定要调高
默认最小长度是3，这适合做通用词库，但不适合直接当密码字典用。现在几乎没有哪个系统允许3位纯字母密码，喷密码时词长过短只会拖慢速度、拉低命中率。我在真实项目中几乎总是将-m设为6到8。
举个例子，抓取一家企业官网后，不加-m会得到一大串“the”“and”“for”“our”这类高频词，加上“CEO”“CTO”这类缩写词。但这些词并不是用户设置密码的高频选择。调高到6之后，剩下的词大多是真正有业务含义的词，比如产品名、客户名、地名、公司核心业务词。这样的字典更“贴”，跑起来也更精准。
另外，-m并不是设得越高越好。如果目标密码策略要求最少8位，那就设8；如果要求6位，设6正好。先搞清楚目标的密码策略再定参数，这一点很重要。
3.3 提取邮箱-e：额外收获的账号线索
CeWL的-e参数会从页面中提取mailto链接里出现的邮箱地址，默认不开启。邮箱的价值有两个方面：一是生成用户名列表，二是邮箱前缀本身可能就是常见密码的一部分。
实际使用中，我会将输出重定向到单独文件，跟单词表分开，防止污染字典：
cewl https://example.com -e --email_file emails.txt -w words.txt在授权范围内提取到的邮箱，可以按前缀（@符号之前的字符）整理成账号名列表，用于后续的用户名枚举测试。这一步配合Burp或Hydra做得比较顺。需要注意的是，有些网站会用图片、混淆文本或JavaScript渲染邮箱，cewl抓不到，这时可以配合其他工具补充。
3.4 附带词频计数-c：访问频率就是权重
加-c参数后，cewl输出的每个词会附带出现次数，格式是“词\t次数”。不要小看这个次数，它反映了目标内容中词的重要性。出现次数越多的词，越可能是品牌词、核心产品名，也越可能被用户拿来构造密码。
我经常做一步：用-c输出后，把字典按出现次数倒序排列，取前200条做人工检视。通常能看到网站的高频品牌词和高管名字出现在最前面。把这些人名、品牌词结合年份和特殊符号规则交给hashcat去变形，命中率会明显高于直接拿原词表去跑。
3.5--with-numbers：容易被忽略但非常实用
默认情况下，cewl会把“admin123”这类带数字的单词过滤掉，因为默认分词逻辑按非字母字符分割。--with-numbers则允许输出包含数字的单词，这对于密码字典至关重要。现实中大量密码是“单词+数字”的组合，比如“company2023”，没有这个参数就抓不到。
建议在密码测试场景一律加上这个参数。如果担心输出过多低质量词，可以在后续清洗时配合正则过滤，比如只保留“字母+数字”形式且总长度8到16位的词。
3.6 代理与User-Agent：应对反爬的常用手段
-u参数指定HTTP代理，适用于需要经代理访问目标或配合Burp拦截调试的场景。-a可以伪造User-Agent，遇到对默认Python/Ruby UA敏感的目标时，把它设成主流浏览器的UA能降低被拦截的概率。顺带提醒一句，如果目标网站启用了比较严格的反爬，比如访问频率限制、JS质询等，光改UA是不够的，还需要控制爬取速率，或考虑用其他方式采集内容后喂给cewl处理。
4. 一次完整的实战：从目标站点到可用的定向字典
4.1 场景设定与前期侦查
假设授权范围内有一家做在线教育的公司，官网是edu-target.example，需要做一次密码喷洒测试。前期手动浏览站点，发现“关于我们”页面有创始人姓名、公司发展历程，招聘页面有办公城市，产品页有课程品牌名。这些信息就是密码构造的高价值素材。
手头没有针对性字典，直接拿通用字典跑了一次，命中率很低。问题在于密码组合形式大概率是“课程品牌名+年份+!”这类企业内部风格。这恰恰是cewl的用武之地。
4.2 第一次爬取：先拿基础词表
先跑一个相对保守的命令：
cewl https://edu-target.example -d 3 -m 6 --with-numbers -e -c -w edu_words.txt --email_file edu_emails.txt说明一下我的选择：深度3覆盖官网核心页面；最小词长6过滤短词；开启带数字词；开启邮箱提取；输出附带词频。爬取完成后，查看一下输出：
wc -l edu_words.txt sort -t $'\t' -k2 -rn edu_words.txt | head -50如果站点结构不复杂，一分钟内就能跑完。前几条高频词通常是品牌名、产品线名称。把这份词表直接丢给hashcat用best64规则跑，已经能覆盖不少“单词+数字”“单词+年份”的常见构造。
4.3 第二次爬取：补漏与扩展
第一次爬取往往只能覆盖公开页面的公开词，但很多有效词藏在更深层级的页面中。此时我可以调整参数，专门爬取博客或新闻板块：
cewl https://edu-target.example/blog -d 2 -m 6 --with-numbers -w edu_blog_words.txt为什么单独爬博客？因为博客文章里会出现具体的课程名、教师名、项目代号，这些词在首页很难出现。在授权测试中，这些词很可能就是员工设密码时的灵感来源。把两次词表合并去重：
cat edu_words.txt edu_blog_words.txt | sort -u > edu_combined.txt4.4 清洗和加工：让字典更“干净”
原始输出比较粗糙，我会做两步清洗。第一步是去除明显无效的高频停用词，比如“about”“contact”“menu”这类网站导航词。用grep和sed处理：
grep -vE '^(about|contact|menu|home|page|click|read|more|news|team)$' edu_combined.txt > edu_clean.txt第二步是筛选出适合做密码的单词和组合形式。比如只保留纯小写字母、首字母大写、全小写+数字、以及包含年份的模式：
grep -E '^[A-Za-z][A-Za-z]{5,}[0-9]{2,4}$|^[A-Z]{1}[a-z]{4,}[0-9!@#\$%]{1,}$' edu_clean.txt > edu_candidates.txt这步不是必须的，取决于你后边用什么工具跑字典。如果你打算交给hashcat加规则变形，那么原词表就够；如果打算直接跑明文密码，那筛选一下会更高效。
4.5 验证效果：和通用字典的对比
在同一次授权测试中，我用通用字典rockyou跑了一遍，再拿cewl生成并加工后的字典跑了一遍。两者的差异非常直观：rockyou能命中一些极弱的通用密码，但对包含企业和品牌的组合密码无能为力；cewl字典虽然条目少得多，但在目标场景中命中的都是“像这个公司员工会用的密码”。对于密码喷洒场景，字典的质量远比数量重要。cewl生成2000行高质量定向词，远胜于rockyou里2000万个通用词。
5. 字典生成之外的进阶玩法：组合、清洗与规则扩展
5.1 多来源词表合并
网站不是唯一的信息来源，也不用局限于cewl单次输出。把cewl抓取的词与领英公开职位信息、工商信息、招聘站点描述文本合并，一起处理后做密码字典，覆盖度会进一步上升。
方法不复杂：把各来源文本存成纯文本文件，用管道交给cewl读取。cewl支持从本地文件读取内容吗？有个思路是先把网页内容手动保存为文本，然后用sed和awk做关键词提取，最后合并到cewl的输出里。虽然cewl本身的强项是实时爬取，但在需要合并多来源素材时，自己写几行命令反而更灵活：
cat edu_clean.txt extra_company_info.txt | sed 's/[^A-Za-z0-9 ]/ /g' | tr ' ' '\n' | sort -u >> final_words.txt这种“cewl为主，手工整理为辅”的组合，让字典在定向场景中的实用性更强。在红队评估中，这种字典往往能覆盖到没有被通用字典覆盖的“企业自造词”。
5.2 用hashcat、john的规则扩展命中面
拿到cewl生成的原始词表后，不要直接拿去爆破。更有效的做法是交给hashcat做基于规则的变形。例如：
hashcat -m 0 -a 0 hashes.txt final_words.txt -r best64.rule --usernamebest64规则会对每一个基础词做多种常见变形：首字母大写、尾部加数字、末尾加特殊符号、年份替换等。cewl负责提供“靶向的核心词”，hashcat的规则负责把核心词变形为各种密码组合。两者结合，效果远好于任何一方单独作战。
John the Ripper也有类似规则功能，适合Linux口令哈希场景。使用手法上，我习惯把cewl字典喂给john，配合/etc/john/john.conf中的规则配置。处理效率上hashcat更快，但john适合离线小规模场景。
5.3 从人名和邮箱到账号列表
cewl提取的邮箱除了用于密码字典，还是账号枚举的素材。把邮箱前缀抽出来，结合目标公司的命名规则猜测用户名：
cut -d'@' -f1 edu_emails.txt | sort -u > usernames.txt如果邮箱前缀符合“名.姓”或“f.last”格式，就能顺藤摸瓜生成一批合法用户名。注意一点：在授权范围内，如果你已经拿到合法账号列表，再做密码猜测是在做“密码喷洒”，这是常见的测试方法，但一定要确认测试范围。
5.4 字典大小的工程化取舍
有人会觉得cewl生成的字典太小，担心覆盖不够。我的观点是：定向测试就要用定向字典。通用大字典适合跑“撞库”式的全面扫描，但在内网渗透、红队外网突破时，往往只有几次尝试机会（尤其是存在账号锁定策略时），这时候用几百行高质量的定向词表远比几百万行的通用词表有效。
如果目标系统没有锁定策略，允许大量尝试，那么可以把cewl词表加到通用字典前面，按“定向优先、通用兜底”的顺序去跑。这样既保留了定向的高效，又有通用兜底。
6. 我踩过的坑和排查过程，以及字典质量的自我检查
6.1 爬取深度太大导致全站“词噪音”
初次用cewl时，我把-d设成了6，目标是一个中型新闻网站，结果跑出了上万行词，其中充斥着大量与目标企业无关的新闻用语。花了不少时间洗完词，真正的品牌词反而淹没在噪音里。
问题本质在于：爬取深度越深，页面主题越泛，词与核心目标的关联度就越低。此后我的策略调整为：先用-d 2拿到核心词，再针对特定板块单独爬取。比如单独指定/about、/products、/blog路径，这样每个页面的词都比较聚焦。
6.2 默认长度过滤掉有效词
有一次跑某个客户的站，cewl默认-m 3，输出里带有“abc”这类词，但也漏掉了不少品牌词，因为品牌词是“A1Biz”“GoUP”这类长度小于6的组合。问题出在我没先看站点的品牌词构成，直接用了默认参数。
后来我养成了一个习惯：不管最终用什么参数，第一次先跑一遍不带-m限制的版本，然后人工翻翻文件，看看有哪些短词值得保留。如果短词多为噪声，就重新跑一遍并设置-m 6，这样既能防止遗漏又不会太脏。
6.3 完全依赖默认爬取，漏掉JS渲染内容
现在很多网站是单页应用或混合渲染，核心内容靠JavaScript加载，cewl直接抓取HTML时只能拿到空壳和脚本引用，提取出的词极其有限。遇到这类目标，我的思路是先用可执行JS的爬虫（比如Playwright或Selenium）把渲染后的HTML保存到本地，再想办法用cewl从本地文件或临时服务器上读取内容，或者提取文本后手工合并进词表。
具体做法可以这样：用Playwright拿到目标页面渲染后的纯文本内容，存成txt文件，然后用文本处理命令分批清洗，最后合并进cewl生成的词表里。虽然cewl本身不擅长处理JS渲染，但它作为核心提取引擎，配合自动化工具后依然好用。
6.4 没有处理大小写变体
CeWL爬到的单词保留着页面上的原始大小写，而真实密码中的“首字母大写”非常常见。如果直接用原词表跑，命中率会打折。我在实际项目中会把cewl输出的词表用awk做一次首字母大写变换，生成一份变体：
awk '{print toupper(substr($0,1,1)) substr($0,2)}' final_words.txt >> final_words_case.txt这种做法在密码喷洒中很好用，尤其是Windows域环境下，很多人习惯首字母大写。配合其他规则变形，基本能覆盖主流的大小写组合。
6.5 字典质量的自我检查方法
在交付任何测试结果前，我都会对cewl生成的字典做一次质量检查。几个简单指标：
- 词条总数：定向字典通常在500到5000行之间。太多说明抓取范围过泛，太少说明页面太薄或参数太严格。
- 与目标的相关性：人工检查前100行，确认大部分词与目标业务、人事、产品直接相关。
- 长度分布：统计词长分布，确保大部分词落在目标密码策略允许的范围内。
- 去重情况：确认没有大量重复项，避免浪费爆破时间。
检查方式用命令行就能完成：
awk '{print length($0)}' final_words.txt | sort -n | uniq -c | sort -rn | head -20如果长度集中在6到12位，说明字典合理性较好；如果大量词超过16位或低于6位，则需要调整-m参数或清洗规则。
6.6 一个容易忽略的问题：目标的robots.txt
Cewl在爬取时会遵守robots.txt吗？实际测试中，cewl对robots.txt的遵守情况并不稳定。在授权测试中，你应当先评估目标的robots.txt和网站服务条款。如果目标明确要求不允许爬取某些目录，或者站点有严格的反爬策略，不建议强行爬取，可以换一种思路，例如只爬取你已获授权测试的页面范围。安全合规永远是第一位的。
另外，测试过程中要控制爬取节奏，设置合理的代理和限速策略。目标网站如果是生产环境，被爬挂了对谁都没好处。cewl默认爬速不慢，如果不加限制地深度爬取，很容易对目标产生压力，要在命令行层面做主动控制，比如单独跑小站点时把深度设低一些，或配合-u代理工具做限速。
最后再说几句实战心得
用cewl生成定向字典，我从最早“跑一把出个字典”到现在“结合目标特征反复调参、多轮清洗、配合规则扩展”，中间踩了不少坑。现在我的标准流程基本稳定为：先人工浏览目标站点判断内容构成，再选择深度和词长参数跑第一轮；拿到基础词表后按频率排序，人工检视核心词；然后区分场景决定是直接喂hashcat还是继续加工；最后结合多来源信息生成用户名列表与密码候选集，按顺序做喷洒测试。
cewl不是万能的，它替代不了对目标的深入理解和人工分析。但如果用得好，它能把“公开信息到定向字典”这个过程压缩到几分钟内完成，这是其他工具很难替代的。希望这篇实战拆解能帮你在授权测试里少走点弯路。
