企业官网建设流程全解析

拿到授权测试的目标后，我通常进门第一件事不是急着开扫描器，而是先坐下来想清楚一个问题：目标如果有个登录框，我准备拿什么字典去撞密码。密码字典生成这个环节看着简单，实际很讲究。Kali Linux 里 Crunch 和 Cewl 这套组合，一个是按规则批量生成密码序列的“暴力生成器”，一个是从目标网站文本里提取真实单词的“词料收割机”，单用都不稀奇，但把它们合在一起用，往往能做出比网上那些几十 GB 默认字典高效得多的定向字典。

这篇文章就把我平时用 Crunch 和 Cewl 做组合生成字典的思路、命令、参数细节和踩坑经验完整写出来。无论你是刚开始接触渗透测试的新手，还是经常做内网口令评估的老手，只要目标场景里有登录框、有弱口令测试环节，这套方法都能让你少跑很多冤枉路，也少等几个通宵。

1. 先搞懂 Crunch 和 Cewl 为什么能高效组合

1.1 密码字典的真相：量不如准

很多人一想到密码字典，第一反应就是去网上下个“社工库字典合并包”“几百 GB 全字符集大字典”。这类东西不是没用，而是效率太低了。一次爆破的请求量上限就摆在那，你拿一个 500 GB 的字典去撞，可能三天三夜都跑不完，而且里面大量组合根本不会出现在目标环境里。

真正能做出口碑的测试流程，讲究的是“精准”两个字。目标系统有密码策略，比如“位数 8 到 16，必须包含大小写和数字”，那你就得先按这个策略去生成结构化的候选集；目标站点里到处是员工姓名、产品代号、邮箱前缀、公司英文缩写，那这些就是比任何通用字典都值钱的词料。

所以说，密码字典的核心不是数量，而是命中率。这也是为什么我始终坚持自己生成字典，而不是直接拉一个现成的大文件。

1.2 Crunch 和 Cewl 的分工逻辑

Crunch 和 Cewl 正好形成两个互补的维度：

组合的逻辑很简单：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。这个文件里预置了很多常用集合，比如：

使用方式是在后面跟字符集名称：

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 带前缀字典.txt

Crunch 会保留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

常用参数含义：

举个例子，我测试某个内部 Wiki 系统时，只跑了：

cewl http://192.0.2.10/wiki -d 2 -m 4 -w wiki_words.txt --with-numbers --email --lowercase

几分钟后拿到一个几百行的词料文件，里面有“project”、“admin”、“helpdesk”、“2024”这些词，还有几个形如zhangsan@example.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.txt

best64.rule是最常用的规则集，里面包含大小写替换、末尾加数字、末尾加年份、键盘序列等常见变换。比如原始词是admin，规则变形后可能产生Admin、admin123、admin@2024、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. 常见问题与避坑指引

关于锁定的问题，再单独说一句。测试口令安全的时候，不能一门心思只关心字典生成，还得关注目标的账号锁定策略。之前遇到过某系统设置了“连续 5 次失败锁定账号”，这种情况下再好的字典也没用。合理的做法是先对每个目标账号只试 3-4 个高命中的定向密码，留足安全余量，等确认没有触发风控再决定是否扩大测试范围。这里才是真正考验渗透测试人员工程能力的地方。

Crunch 和 Cewl 本身也有版本差异。新装的 Kali 一般已经预装这两个工具，如果没装，一条命令就能搞定：

apt install crunch cewl

另外，Cewl 对页面文本的提取质量受目标站点内容质量影响很大。页面里大量使用图片代替文字、或者内容本身是扫描件转换的 PDF，Cewl 就会失效。遇到这种情况，我一般会直接放弃自动提取，改用人工整理词料，效果反而更好。

我个人在实际操作中的体会是：字典生成永远是一个迭代过程，不要指望第一次跑出来的字典就能直接命中。先用 Cewl 抓词料、用 Crunch 补模式、再用规则引擎变形，跑完一轮之后根据目标的反馈继续精修，通常两三轮下来，字典的质量就非常能打了。最后再分享一个小技巧：把 Cewl 的邮箱前缀单独提出来作为用户名列表，再把 Cewl 的词根通过 Crunch 生成“前缀+数字”的候选密码，往往能同时解决“账号枚举”和“弱口令”两个方向，很多看似复杂的系统在这一步就出效果了。