用CeWL打造定向密码字典：从参数到实战的完整指南

在授权渗透测试里密码喷洒和弱口令爆破是最常碰到的环节。我发现自己反复面对一个尴尬情况手头通用字典动辄几个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.txtCewl在爬取时会遵守robots.txt吗实际测试中cewl对robots.txt的遵守情况并不稳定。在授权测试中你应当先评估目标的robots.txt和网站服务条款。如果目标明确要求不允许爬取某些目录或者站点有严格的反爬策略不建议强行爬取可以换一种思路例如只爬取你已获授权测试的页面范围。安全合规永远是第一位的。另外测试过程中要控制爬取节奏设置合理的代理和限速策略。目标网站如果是生产环境被爬挂了对谁都没好处。cewl默认爬速不慢如果不加限制地深度爬取很容易对目标产生压力要在命令行层面做主动控制比如单独跑小站点时把深度设低一些或配合-u代理工具做限速。最后再说几句实战心得用cewl生成定向字典我从最早“跑一把出个字典”到现在“结合目标特征反复调参、多轮清洗、配合规则扩展”中间踩了不少坑。现在我的标准流程基本稳定为先人工浏览目标站点判断内容构成再选择深度和词长参数跑第一轮拿到基础词表后按频率排序人工检视核心词然后区分场景决定是直接喂hashcat还是继续加工最后结合多来源信息生成用户名列表与密码候选集按顺序做喷洒测试。cewl不是万能的它替代不了对目标的深入理解和人工分析。但如果用得好它能把“公开信息到定向字典”这个过程压缩到几分钟内完成这是其他工具很难替代的。希望这篇实战拆解能帮你在授权测试里少走点弯路。