基于开发关键词的子域名Fuzz方法

一、问题背景与目标

在企业级渗透测试中，发现隐藏的测试/预发布/管理环境（例如 app-test.example.com、api-uat.example.com、dev.example.com 等）能显著提升攻击面。很多组织在子域命名上会嵌入环境关键词（test、uat、dev、stg 等），因此使用关键词驱动的 fuzz（字典+变异）进行子域发现，是一种高效的方法。

目标：通过系统化的关键词字典和变异策略，最大化发现与目标域名相关的潜在子域，同时控制噪音与误报，确保结果可验证、可追溯。

---

二、方法概述（高层流程）

1. 情报收集（Passive）

   • CT 日志（Certificate Transparency）、公共 DNS 解析历史、公共错误页、搜索引擎索引、GitHub/GitLab、社交媒体、WHOIS、技术指纹（HTTP headers、TLS certs）等。

2. 初始字典准备（Seed Words）

   • 汇总环境关键词、项目名、服务名、地域、版本号、迭代编号等。

3. 变异/组合生成（Fuzz Core）

   • 前缀/后缀、点/连字符/下划线变体、缩写/同义词、数字后缀、字母缩写、语言变体（cn/zh/en）等。

4. 主动探测（Active）

   • 大规模 DNS 解析（并发、批量解析）、HTTP 请求校验、证书 SAN 验证、CNAME 指向、PTR/A/AAAA/MX 记录检查。

5. 结果去重与验证（Post-processing）

   • 去掉泛解析（wildcard）噪声、过滤无响应或 404 的 HTTP、对有效主机做指纹采集（HTTP title、Server header、fingerprints）。

6. 分类与优先级评估（Risk Triage）

   • 把发现按环境、公开程度、服务暴露程度分级，供后续漏洞验证或蓝队处置。

---

三、字典设计细节（核心要点）

1. 基础关键词集合（Seed）

• 环境：dev, test, t, qa, uat, sit, stg, stage, preprod, prod, live, perf, canary, demo, beta
• 角色/服务：app, api, web, admin, portal, api-gateway, auth, idp, mgt
• 内部标识：internal, intranet, mgmt, ops, infra, backup, legacy
• 区域/实例：eu, us, cn, asia, apac
• 版本/编号：v1, v2, v3, 01, 02

2. 组合模板（建议生成方式）

• 前缀型：<env>-<service> → uat-api
• 后缀型：<service>-<env> → api-uat
• 点分隔：<service>.<env> → api.uat.example.com
• 多层：<service>.<project>.<env> → api.payments.uat

3. 变异规则（mutation）

• 分隔符：-、.、无（直接拼接）
• 缩写：uat ↔ u、test ↔ t、development ↔ dev
• 同义替换：stage ↔ stg、preprod ↔ pre-prod
• 数字化：追加 01/02/001 或 -01
• 大小写不敏感，但生产中可统一小写处理

4. 字典来源建议

• 公司内网文档、部署脚本、CI/CD 配置、DNS 区域文件、代码仓库（YAML/JSON）、证书 SAN、第三方公开源（Shodan、Censys、CT）、历史漏洞报告。

---

五、主动探测策略与工具链

1. DNS 解析

• 推荐工具：massdns、dnsx、masscan（用于端口）、amass（整合被动与主动）。
• 并发控制：使用适当并发（例如 50-200 并发）以避免触发 WAF 或 DNS 限制，同时尊重授权条款。
• 缓存与重试：对 NXDOMAIN 与 SERVFAIL 做短期缓存与指数退避。

示例（伪命令）：

# 使用 dnsx 批量解析字典
cat wordlist.txt | dnsx -d example.com -a -resp -silent > resolved.txt

2. 证书透明与被动源

• 利用 CT 日志可以发现带有关键词的证书（例如 *.uat.example.com）。工具：crt.sh、amass 的 crtsh 模块。
• 被动源还有：VirusTotal、SecurityTrails、PassiveTotal、Censys、Shodan。

3. HTTP 校验

• 对解析成功的子域进一步发起 HTTP(s) 请求以获取响应码、Title、Server header、重定向目标、指纹信息。工具：httpx、ffuf（对路径进行 fuzz）、gau（抓取历史 URL）。
• 重要：证书错误或自签名也可能指示内部环境。

4. WAF/防护识别与规避（仅用于授权测试）

• 通过检测速率限制、响应差异、CAPTCHA 页面判断是否被保护。调整并发、随机化请求间隔、使用不同来源 IP（代理池）进行测试（须严格授权并记录）。

---

六、泛解析（Wildcard）与误报控制

泛解析会导致大量假阳性（比如 anything.example.com 都解析到同一 IP）。应对方式：

1. 预检 wildcard ：先解析若干随机子域（如 zzzz-random-123.example.com）看是否解析成功，若成功则说明存在泛解析。
2. 内容/指纹对比：对解析到同一 IP 的多个子域，比较 HTTP 标题、响应指纹、TLS 指纹，若完全相同且与通用错误页一致，判为泛解析噪声。
3. CNAME 路径检查：有时泛解析背后是 CDN 或反向代理，检查 CNAME 链以识别代理层。

---

七、去重、分组与优先级评估

1. 去重：基于 FQDN 去重，保存首次发现时间、解析 IP、证书索引。

2. 分组：按 environment 关键词分组（dev/test/uat/prod）并再按服务类型分组（api/web/admin）。

3. 优先级评分（示例打分规则）：

   • 证书存在且包含主域名：+3
   • 解析到公网 IP 且端口 80/443 可用：+2
   • 响应包含 "admin"/"login"/"dashboard" 关键字：+2
   • 被动来源（CT/VT/Censys）已有记录：+1
   • 泛解析疑似：-5（直接降低优先）

根据分数决定后续的渗透或漏洞验证顺序。

---

九、常见陷阱与对策

• 速率限制导致盲区：降低并发、使用退避策略、分批探测。
• 误报率高（泛解析）：先做 wildcard 测试并结合指纹判定。
• TLS 与 HTTP 重定向：许多内部环境仅在 HTTPS 上可见，必须同时检测 443 与 80。
• CDN/反向代理隐藏真实主机：检查 CNAME、Server header 与证书 SAN，结合端口指纹识别后端服务。
• 黑名单/法务风险：所有测试动作必须有书面授权与时间窗口，产生的外联流量需记录以供审计。

---

十、不同环境字典

dev
development
d
local
int
integration
ci
build
test
t
qa
qc
functional
ft
regression
sit
uat
pre
preprod
pre-prod
preproduction
stag
stg
stage
canary
can
preprod
gray
grey
rolling
prod
production
p
live
main
perf
performance
load
stress
soak
sandbox
sbx
demo
beta
preview
admin
mgmt
internal
intranet
backup
legacy
archive
infra
ops