CeWL实战：从企业官网生成高管专属密码字典

最近接了一个企业授权安全评估项目，甲方是一家互联网科技公司，官网信息量很足，团队介绍、CEO访谈、新闻稿、招聘页面全都齐活。按常规套路，做完资产梳理我本来打算直接上扫描器，但评估员工账号弱口令风险时，我先把 CeWL 拉出来，用企业官网生成了一份"高管专属字典"。这份字典在后面的账号安全测试中发挥了很大作用，直接暴露了好几个使用姓名拼音+出生年份做密码的高风险账号。这篇文章就把完整的思路和实操过程整理出来，聊一聊 CeWL 这个爬虫工具怎么从官网信息里提取关键词，如何加工成针对性极强的密码字典，以及实战中那些文档里不会写的细节和坑。适合做企业安全评估、红蓝演练和账号安全审计的同行参考，也适合刚接触字典生成思路的入门读者。

1. 为什么企业官网能变成密码字典？CeWL 的核心逻辑一次讲透

1.1 官网本身就是"情报富矿"

很多安全测试人员习惯把目标官网当成一个"入口"，顺手扫一遍目录、找找后台页面就完事。但从字典生成的角度，官网其实是整个目标里最容易合法获取情报的地方，没有之一。企业官网会把员工姓名、职位、邮箱、办公城市、公司成立年份、部门名称、产品名称、大事记、CEO 致辞甚至个人爱好全部放在公开页面上，而这些信息恰好是大多数员工设置密码时的"灵感来源"。

你随便打开一家公司的"关于我们"页面，大概率能看到创始团队的照片和简介，例如"某某，联合创始人兼 CEO，毕业于某高校，喜欢马拉松"。这些信息本身就是密码元素的天然组合池：姓名拼音、英文名、入职年份、创业年份、公司域名前缀、座机区号、产品线名字，全都在里面。更别提招聘页面常见的"hr@xxx.com"，这种邮箱前缀往往就是某个HR的姓名拼音，而 HR、财务、行政这些岗位的账号权限往往又比普通员工高得多，属于典型的高价值目标。

所以 CeWL 的价值不在于它多"黑科技"，而在于它把"从官网提取关键词"这件事自动化了。人工去页面里复制粘贴当然也能做，但效率太低，漏词率高。CeWL 会用爬虫自动抓取指定 URL 下的页面内容，从 HTML 文本中提取单词，按长度过滤，去重排序，最终输出一份可以直接用于字典制作的词表。

1.2 CeWL 的抓取和词频提取原理

CeWL 全称是 Custom Word List Generator，是一款用 Ruby 编写的命令行工具，Kali 里自带，平时做授权测试时不用额外装环境。它的工作流程可以拆成四步：

1. 从指定的起始 URL 出发，按照爬行深度参数沿页面里的超链接向下抓取。
2. 把每个抓回来的 HTML 页面里的正文内容拆成单词。
3. 过滤掉自带停用词表里的常见无意义单词（例如 the、and、of 这类英文虚词），再按照最小单词长度参数过滤掉太短的词。
4. 对所有单词去重、排序，输出成字典文件；如果开启了提取邮箱参数，还会额外把页面里的 mailto 链接或明文邮箱地址单独收集出来。

这里有个关键点容易被忽略：CeWL 提取的是"页面里的文本单词"，而不是"中文语义片段"。它对中文内容基本无能为力，只能提取页面里夹杂的英文品牌词、拼音注释、英文缩写和数字串。所以如果目标官网是全中文页面，CeWL 的原始输出往往会比较稀碎，但这不代表工具没用——它抓出来的英文单词、数字、域名片段，加上从"关于我们"里人工整理的中文拼音词条，组合起来恰恰是字典的主力。

CeWL 另一个容易被忽略的能力是-e参数可以提取邮箱。邮箱前缀是字典里的高价值词条，因为它通常直接对应着员工账号名或姓名拼音。例如某高管的邮箱是yang.ming@example.com，那么yangming、yangming2024、ym2024这类组合就应该优先进入字典候选。邮箱本身不一定是密码，但它能帮你确认目标账号的命名规则，减少后面组合时的盲目性。

理解了这个原理，再看后面的实操就会清晰很多：CeWL 负责把"公开信息里的关键词"尽可能全面地薅下来，人工负责把这些关键词和常见密码组合规则加工成真正有针对性的字典。

注意：所有字典生成和后续账号安全测试，必须在获得目标企业书面授权的范围内进行。未授权对任何系统做测试都是违法行为，本文所有内容仅用于合法的企业安全评估场景。

2. 手把手实操：用 CeWL 抓取官网并生成 CEO 专属字典

2.1 环境准备与基础抓取命令

先说明一下测试场景：这是一个虚构的模拟项目，目标为某公司官网，下文中的公司名、人名、域名均为虚构代称，实操命令里的 URL 需要替换成你自己获得授权的目标地址。

准备阶段只需要满足两个条件：本机能运行 CeWL（Kali 自带，或者用安装了 CeWL 工具的容器环境），目标 URL 已确认在授权范围内。建议先建一个工作目录，把所有输出文件放进去，避免后面文件越来越乱：

mkdir -p dict_project cd dict_project

基础抓取命令是这个形态：

cewl https://www.example.com -d 2 -m 6 --with-numbers --lowercase -w crawler_base.txt

这条命令的参数含义分别是：

• -d 2：爬行深度设为 2，意思是抓取首页，并继续抓取首页能跳转到的二级页面。对于一般企业官网，深度 2 基本能覆盖"首页 + 关于我们 + 产品页 + 新闻列表"这几个核心板块。
• -m 6：单词最小长度为 6，意思是只保留 6 个字符以上的单词，过滤掉 to、the、you 这类短噪声词。
• --with-numbers：保留包含数字的单词。这个参数很关键，因为实际密码里带数字的比例非常高，例如example2024、vip888。没开这个参数，CeWL 会把这类词直接丢掉。
• --lowercase：把所有词统一转成小写，方便后续合并去重。
• -w crawler_base.txt：输出到指定文件。

第一次跑完，先看一眼单词量级和数据质量：

wc -l crawler_base.txt head -50 crawler_base.txt

如果crawler_base.txt里大部分是英文常见词、和公司品牌没什么关系，别着急，这是正常的，因为官网的英文段落本来就会带来大量通用词汇。字典的真正价值不在第一轮全站抓取，而在第二轮针对重点目录的精细抓取。

实操心得：全站抓取这一轮，-m不建议设太低。低于 6 会混入大量无意义的短英文词，比如 pay、buy、news、page，这些词放到密码组合里几乎不会命中，只会污染字典、拖慢后面去重的速度。如果官网本身英文内容少，可以适当降到 5，但尽量不要低于 5。

2.2 从"关于我们"和"联系我们"里挖个性化词条

全站抓取只是开胃菜，真正建立 CEO 专属字典核心词库的是第二轮：针对 about、contact、news 这三个目录做精细抓取。这三个页面是员工姓名、邮箱、新闻稿、管理层介绍的高发区，也是"人名+公司名+年份"类密码组合最容易撞上的词源。

cewl https://www.example.com/about -d 1 -m 4 --with-numbers --lowercase -e -w crawler_about.txt cewl https://www.example.com/contact -d 1 -m 4 --with-numbers --lowercase -e -w crawler_contact.txt

这里把-d降到 1，是因为只需要抓取当前页面，不需要顺着页面链接继续往下爬，避免把无关的公司新闻稿全部拉进来。-m降到 4，是因为人名拼音和邮箱前缀经常只有 4~6 个字母，例如yang、ming、hr02，如果最小长度还是 6，这些短词会被直接过滤掉。-e参数打开邮箱提取，把页面里能看到的邮箱地址收集到输出文件里。

跑完之后，把两份结果合并，并加上人工整理的词条。人工整理这一步不能省，因为 CEO 专属字典的灵魂就在这些机器抓不出来的信息里。以模拟项目为例，假设 CEO 化名 A 先生，公开信息包括：姓名拼音 yangming、英文名 Andrew、2006 年入职公司、联系方式里出现过区号 010，那么可以手工整理出这些基础词条：

cat > manual_info.txt <<'EOF' example exampletech shilikeji yangming mingyang andrew ay ceo founder boss 010 2006 2024 example2024 EOF

注意看这些词条的分类逻辑：第一类是公司品牌词（example、shilikeji），第二类是 CEO 姓名拼音和英文名（yangming、andrew），第三类是职位词（ceo、founder），第四类是年份和区号（2006、2024、010）。这些词单独出现的命中率不高，但它们是后面组合规则的核心"原材料"。

实际操作时，除了文字简介，图片的 alt 属性、PDF 年报里的元数据、员工署名、新闻稿里的引述段落都值得翻一下。很多项目介绍里会写负责人姓名和联系方式，这些信息在 CEO 字典里比十个英文单词都有用。

2.3 组合规则与最终字典生成

原材料到位之后，接下来是把它们组合成真正可用的字典。组合这一步的目标不是暴力穷举，而是按照"真实人类设置密码的习惯"来生成候选词条。先把三轮抓取的结果合并、去重：

cat crawler_base.txt crawler_about.txt crawler_contact.txt manual_info.txt | sed '/^$/d' | sort -u > dict_all.txt wc -l dict_all.txt

合并之后，用下面的命令做一轮词频排序，看看哪些词在官网出现频率最高，这些高频词往往和品牌、核心产品、公司口号强相关，密码组合中的"公司名+年份""品牌名+特殊字符"就依赖这些词：

cat dict_all.txt | tr 'A-Z' 'a-z' | sort | uniq -c | sort -rn | head -40

然后，按真实密码设置习惯扩展组合。这里有一个很实用的公式：基础词条 + 常见后缀。所谓常见后缀，不是随便拍脑袋，而是基于大量弱密码统计得到的高频模式，主要是四类：

1. 年份类：2010、2016、2020、2023、2024，以及公司成立年份、CEO入职年份。
2. 特殊符号类：!、@、#、.、_，尤其是 @ 和 ! 出现频率最高。
3. 数字类：123、666、888、521、110。
4. 重复加强类：直接在基础词后面重复一次，比如 yangmingyangming。

组合的时候不需要把所有排列全部列出来，那会让字典膨胀几千倍，反而降低效率。比较实用的做法是维护一个"密码模式模板"列表，然后对基础词条做规则替换。手动构造一份规则化字典可以这样写：

cat > combo_rules.txt <<'EOF' yangming@2024 yangming!2024 Yangming@2024 Yangming!2024 example@2024 example2024! shilikeji2024 ceo@2024 andrew2006 010yangming yangming010 yangming2024 mingyang2024 ay2024 EOF cat combo_rules.txt | sort -u > ceo_dict.txt

到这里，一份以 CEO 姓名、公司品牌、年份、职位为核心组合出来的字典就成型了。建议再手工翻一遍，把明显不符合常见密码习惯的组合删掉，比如把纯 010、纯 example 这种太简单的单独词从最终字典中剔除，它们单独存在时冗余度高，几乎不会作为密码实际出现。最终字典的规模一般控制在 2000～5000 条之间，太小会漏规则，太大只会拖慢测试速度并提高被风控锁定的概率。

如果你觉得手工写组合规则太慢，可以考虑用 cupp 这类社工字典生成器做一部分扩展。cupp 是交互式工具，运行后按提示输入姓名、昵称、出生日期、伴侣名字、宠物名字等信息，会自动生成一份组合字典。虽然是交互式，但实际用起来很快，和 CeWL 的产出合并后能有效提升覆盖度。不过 cupp 更偏"通用个人字典"，对官网信息的针对性不如前面人工构造的方案强，所以我的习惯是两者结合：CeWL 全站抓取负责广度，人工构造的规则组合负责针对性，cupp 负责补足那些和官网无关但常见的个人习惯密码。

3. 字典实战验证与命中率分析

3.1 科学评估字典效果的两个维度

字典做出来不是终点，能验证有效性才叫完成。在授权测试中，评估字典效果有两个维度需要分开看：一个是覆盖率，一个是命中率。

覆盖率指的是字典里的词条是否覆盖了目标账号可能使用的密码模式。评估方法很简单：把字典里的词条按规则分类，统计每类的占比。比如一份 3000 条的字典里，"姓名+年份"占多少、"公司名+特殊符号"占多少、"纯数字串"占多少。如果某类完全缺失，说明字典在这一维度上存在明显盲区，需要补对应规则的词条。实际操作中，我遇到过团队几个人都用"姓名首字母+入职年份"做密码的情况，如果字典里没构造"姓名首字母+年份"这个规则，就会漏掉一整个平行账号，这是覆盖率评估最大的价值。

命中率则是实际测试时字典发挥作用的比例，通常通过小范围账号样本试跑来观察。真实的渗透测试项目里，账号锁定策略非常常见，连续尝试 5～10 次就锁定是很多企业的默认配置。所以在评估弱口令风险时，单纯拿字典快速怼登录接口是很鲁莽的做法，不仅容易把账号锁死，还会触发风控告警。更稳妥的方式是挑选一批已经取得授权的低风险测试账号，在测试环境中模拟登录验证，或者拿脱敏后的数据散列进行离线比对，把命中率数据统计出来即可。

关于账号锁定，这里有个重要的实战经验：字典生成完后，不要上来就全量跑。先把字典里概率最高的前 200 条挑出来，按账号逐一尝试，每个账号最多尝试 2～3 次就停下来。锁定风险永远比暴破效率优先，账号锁死导致业务中断，这个锅最后一定记在安全测试头上。

3.2 命中率解读与迭代改进闭环

拿到第一批命中结果之后，字典的工作才进行到一半。看一组实际测试数据：假设用 3000 条字典对 12 个授权测试账号做离线比对，命中 4 个账号，看起来命中率不高，但如果仔细复盘命中的密码，会发现它们高度集中在两类规则上：一类是姓名拼音+出生年份，另一类是公司英文名+2024。这说明该企业的密码设置习惯在这两条规则上有明显倾向性。

接下来要做的是迭代：把这两条命中规则作为核心，扩展出更多变体。比如姓名拼音+出生年份已经命中，那姓名首字母+出生年份、英文名+出生年份、姓名全拼+入职年份大概率也有戏。于是把字典中这两类规则的词条比重调高，去掉那些零命中的噪声规则，用精简后的新字典再做第二轮验证。这样经过两三轮迭代，字典会从"通用网页词表"变成"贴合目标企业密码习惯的定制词表"，这才是整个流程图价值最大的一步。

字典迭代过程中有一个很容易踩的误区：命中了一个密码，就把所有和该密码相似的模式全量铺开。比如命中了yangming2024，就把yangming2010、yangming2011一直推到yangming2030，这种做法生成的词条命中率极低，因为真实用户的记忆习惯通常会锁定一个固定的年份（入职年、生日年、结婚年），而不是逐年顺延。正确的做法是优先补齐目标个人的特殊年份，包括公司成立年、CEO 入职年、公开采访里提到的个人重要时间节点，这些才是有意义的扩展方向。

经过两轮迭代后，最终字典应该达到这个状态：规模比最初小 30%～50%，但核心规则词条密度明显提高，每类规则都能对应到官网或公开信息中的某个具体情报点，而不是泛泛排列。

4. 常见报错与避坑指南

4.1 高频问题速查表

CeWL 用起来门槛不高，但实战中确有不少细碎问题。下面这五个问题是我在项目里最常遇到的，直接整理成速查表：

4.2 几条真正值钱的实操心得

第一，别只管 CEO 一个人。标题写的是 CEO 专属字典，但实战中真正应该覆盖的是整个高管团队加关键职能岗。财务、人事、运维、商务这些岗位的账号权限往往比普通员工高得多，而且使用弱口令的概率并不低。官网的"团队介绍"页面把这些人的姓名、职位、头像全部公开了，按同样的思路扩展即可。我的做法是给每个目标人物各建一份单独的字典，再合成一份总的候选词库，这样既保留了针对性，又覆盖了横向移动的需求。

第二，CeWL 抓到的内容里，--with-numbers抓出来的数字词条优先级非常高。官网中出现的团队人数、成立年数、融资额、产品版本号、联系电话里的数字段，这些页面上的数字虽然不一定直接对应密码，但极容易出现在密码中。比单纯依赖letmein、password这类通用弱口令靠谱得多。建议把 CeWL 输出里所有包含数字的行单独抽出来：

grep '[0-9]' crawler_base.txt | sort -u > numbers_only.txt

这份数字词表单独保留，后面做组合规则时直接套用。

第三，线上测试一定要控制节奏。生产系统的登录接口不是给你随便试密码的，一个不小心就会把账号锁死、触发短信轰炸、惊动运维团队。做字典验证时，使用测试环境优先，使用离线数据优先，实在需要线上验证，务必控制好频率，并且提前和客户方确认好账号锁定策略和应急恢复方案。字典生成只是安全评估的辅助手段，不是攻击工具，专业的第一体现在不给自己和客户找麻烦。

第四，字典生成后做一次"自洽性检查"：把最终字典按规则类型抽样打印 50 条，人工读一遍，看有没有明显不合理的词条，比如纯公司名、纯人名这种不会作为密码直接出现的孤词。真正出现在密码里的，几乎都是"姓名+年份""品牌+特殊符号+数字"这样的组合结构。抽样检查虽然原始，但能避免字典里混着大段垃圾词条还浑然不觉的问题。

第五，Cewl 全站抓完一遍之后，第二轮精细抓取时注意页面的robots.txt。虽然测试已有授权，但尊重目标站点的抓取约束不仅合规，也能减少被风控系统盯上的概率。如果robots.txt里明确 disallow 了某些目录，全站抓取时应当避开这些目录，只对授权范围内的页面做提取。

5. 结尾的一些个人体会

我做字典生成这个环节的时间不算短，最大的感受是：工具永远是次要的，对人性的理解才是核心。CeWL 本质就是把公开信息自动整理成词表，真正让字典产生威力的，是基于"普通人的密码习惯"构造组合规则。姓名、年份、特殊符号、公司品牌，这四类元素的排列组合，基本能覆盖大部分员工真实设置密码的模式。而我自己的习惯是，不管目标官网大小，CeWL 永远只跑两轮，第一轮全站抓取看整体词量，第二轮重点针对 about、contact、news 三个目录精细抓取。第二轮的结果经常比第一轮有价值得多，因为那是员工姓名、邮箱和业务细节最密集的地方。多轮迭代，小步验证，控制噪音，这就是我目前觉得最实用的工作流。