红队实战信息收集：从域名枚举到攻击链路建模

1. 这不是教科书里的“信息收集”而是红队进现场前真正要干的活你拿到一个目标域名比如 example.com老板说“先摸清家底别急着打。”这时候90%的人会立刻打开终端敲nmap -sV example.com扫完端口就去翻 GitHub 上找现成的漏洞 PoC。结果呢三天后发现——目标压根没开 80 端口Web 服务跑在 8443管理后台藏在admin-internal.example.com:8080而这个子域连 DNS 解析记录都没上公开 DNS更糟的是他们用的是自研 API 网关所有接口路径都带/v3/internal/前缀但目录爆破工具默认只扫/api/和/v1/……你扫了 20 小时漏掉了最关键的三个入口。这就是真实渗透测试里最常被低估的一环信息收集不是扫描动作的堆砌而是对目标数字资产结构的逆向建模过程。它不产出“一堆 IP 和端口”而是要回答五个硬问题目标对外暴露的完整域名图谱长什么样主站、CDN、邮件、API、测试环境、历史遗留子域每个域名背后实际运行的服务指纹与技术栈是什么不是“Apache 2.4”而是“Apache 2.4.52 mod_wsgi Django 4.1.7 PostgreSQL 14.5”哪些服务是可交互的、有业务逻辑的、带身份验证边界的比如/auth/login是表单但/api/v2/auth/token才是 JWT 签发点哪些路径是开发者无意暴露的、调试接口、备份文件、源码泄露点.git/,backup.zip,/phpinfo.php,/debug/整个资产拓扑中哪条链路最短、权限提升代价最低、且最难被 WAF 或日志监控捕获比如从邮箱系统泄露的员工邮箱 → 钓鱼获取 VPN 凭据 → 登录内网 Jenkins → 提权构建服务器我干过 73 次红队评估其中 61 次的关键突破口都来自信息收集阶段发现的“非标准路径”或“隐性子域”。这不是玄学——它依赖一套分层递进、交叉验证、带上下文理解的工具链组合而不是单个工具的参数调优。本文不讲“nmap 有哪 17 种扫描模式”而是带你走一遍我每次进现场必做的 5 个阶段从 DNS 域名枚举开始到端口服务测绘再到 Web 路径深度探测最后完成资产关联与风险排序。所有工具选型、参数组合、绕过技巧、误报过滤逻辑全部基于近 3 年真实靶场和甲方生产环境实测。你可以直接抄作业也可以根据目标类型政府网站 / SaaS 平台 / IoT 后台调整权重。核心关键词就这五个渗透测试、信息收集、端口扫描、域名枚举、目录爆破——它们不是孤立动作而是一张动态演化的攻击面地图的绘制步骤。2. 域名层为什么“subfinder assetfinder”只是起点真正的战场在 DNS 记录链与历史数据绝大多数人把域名枚举等同于“找子域”于是装个 Subfinder跑一条命令subfinder -d example.com -o subs.txt然后就去扫这些子域的端口。这就像拿着城市地图找门牌号却不知道这栋楼十年前是银行、五年前改成了网吧、现在一楼是奶茶店二楼是共享办公——你根本不知道哪些“门牌”还有效、哪些已废弃、哪些只是跳转代理。真正的域名层信息收集必须拆解为三层当前解析层、历史痕迹层、基础设施层。每一层提供不同维度的可信度与利用价值。2.1 当前解析层不只是 A 记录更要抓全 CNAME、TXT、MX、NS 的语义线索dig和nslookup是基础但关键在于如何读取返回结果中的隐藏信号。比如CNAME 记录指向 CDN 厂商如xxx.cloudfront.net、xxx.azureedge.net说明该域名由云服务商托管真实源站 IP 极可能被隐藏此时应立即转向httpx -status-code -title -tech-detect探测其回源行为而非盲目扫端口。TXT 记录含google-site-verification或atlassian-domain-verification表明该域名曾接入 Google Workspace 或 Atlassian 产品大概率存在admin.google.com或admin.atlassian.com的 SSO 管理后台且可能启用邮箱验证登录。MX 记录指向mail.example.com这个mail子域极可能运行着邮件服务器如 Zimbra、Microsoft Exchange而这类服务自带 Web 管理界面/zimbra/、/owa/且常因版本老旧存在未授权访问漏洞。我习惯用这条命令一次性提取全部关键记录for record in A CNAME TXT MX NS; do echo $record ; dig $record example.com short; done | tee dns-raw.txt提示short参数必须加否则输出包含大量冗余头信息tee保存原始数据后续做人工研判时比工具自动解析更可靠——因为很多安全团队会故意在 TXT 记录里埋干扰项如vspf1 include:_spf.google.com ~all中的_spf.google.com实际是子域但 Subfinder 默认不递归。2.2 历史痕迹层Wayback Machine 不是怀旧网站而是资产变更的时间切片机很多人用waybackurls只是为了扒历史 URL 做目录爆破这太浅了。Wayback Machine 的真正价值在于通过快照时间戳反推目标技术栈迭代路径。例如2022 年 3 月快照显示首页用 jQuery 1.12.4已知 XSS 漏洞2023 年 8 月快照突然切换为 Vue 3.2.45且/static/js/app.xxxxxx.js文件存在2024 年 1 月快照中该 JS 文件消失首页改用 Cloudflare Workers 动态渲染。这意味着2022–2023 年间前端存在可利用的 jQuery 漏洞2023 年 8 月部署的 Vue 应用很可能留有sourceMap.js.map文件可还原原始源码2024 年切换 Cloudflare Workers 后所有静态资源由 CDN 缓存但 Workers 代码本身可能写在 GitHub 公共仓库搜example.com site:github.com。实操中我用gaugetallurls配合时间范围筛选gau --subs --threads 10 --blacklist jpg,png,gif,css,woff2,ttf example.com | \ grep -E (js|map|json|xml|php|asp|jsp) | \ sort -u urls-from-wayback.txt注意--subs参数强制包含子域--blacklist过滤掉无业务逻辑的静态资源grep精准定位可能含敏感逻辑的扩展名。这比直接导出全部 URL 快 5 倍且误报率下降 70%。2.3 基础设施层从 IP 归属反推组织架构比任何子域扫描都高效这是最被忽视、但实战效果最强的一招通过主站 IP 的 ASN 信息批量获取同一运营主体下的其他资产。原理很简单大型机构银行、运营商、高校通常将所有对外服务 IP 划在同一 BGP AS 号下。一旦你拿到example.com的 A 记录 IP比如203.0.113.42查它的 ASNcurl -s https://api.bgpview.io/ip/203.0.113.42 | jq .data.prefixes[].prefix返回可能是203.0.113.0/24—— 这意味着整个 C 段都属于该单位。接着用massdns批量反查该网段内所有有 DNS 解析的域名seq 1 254 | sed s/^/203\.0\.113\./ | sed s/$/.in-addr.arpa/ | \ massdns -r resolvers.txt -t PTR -o J | \ jq -r .data.answers[].answer | \ grep -oE [a-zA-Z0-9.-]\.[a-zA-Z]{2,} | \ sort -u as-owned-subs.txt我在某省政务云项目中用此法在 12 分钟内发现 47 个未在任何子域列表中出现的内部管理系统域名如hr-portal.gov.cn、finance-audit.gov.cn其中 3 个直接暴露了弱口令后台。原因这些系统从未做过子域备案但 IP 归属完全一致。注意此方法对云厂商多租户环境如阿里云、AWS效果有限因其 IP 池混用但对自建 IDC、教育网、金融专网成功率极高。务必结合shodan search asn:AS12345交叉验证。3. 端口与服务层为什么“全端口扫描”是最大误区精准服务识别才是关键很多人一上来就nmap -p- -sS -T4 target以为扫全 65535 个端口就能“不留死角”。结果呢扫描耗时 8 小时CPU 占满防火墙日志炸锅返回一堆open|filtered根本分不清是真开放还是被中间设备拦截最关键的22SSH、3389RDP、5900VNC端口反而因速率限制被漏掉更致命的是nmap默认的-sV版本探测对 Docker 容器化服务如nginx:alpine、redis:7.0识别率不足 40%因为它依赖 banner 匹配而容器镜像常精简 banner 信息。真正的端口层工作必须遵循“三阶收敛”原则先缩范围再定协议最后识服务。3.1 第一阶用“高频端口业务特征”快速锁定有效端口放弃全端口幻想我从不扫全端口。我的初始端口列表只有 37 个覆盖 92% 的真实业务场景21,22,23,25,53,69,80,81,88,110,111,135,137,138,139,143,161,179,389,443,445,465,500,512,513,514,587,636,993,995,1080,1433,1521,1723,2049,3306,3389,5432,5900,6379,8080,8443,8888,9200,9300,10000这个列表不是拍脑袋定的。它来自近三年 CVE 统计22/3389/5900占远程管理类漏洞披露量的 68%3306/5432/6379占数据库未授权访问漏洞的 81%8080/8443/8888是 Java/Spring Boot/Node.js 应用默认端口占 Web 框架漏洞的 73%9200/9300是 Elasticsearch 默认端口2023 年曝出 12 起大规模数据泄露均源于此。执行命令nmap -p $(cat top-ports.txt | tr \n ,) -sS -T4 --min-rate 1000 --max-retries 1 example.com -oN port-scan.nmap--min-rate 1000强制每秒发包 ≥1000--max-retries 1避免重传拖慢速度-sS半开扫描降低被拦截概率。实测下来37 个端口平均 42 秒扫完准确率比全端口高 3 倍。3.2 第二阶对开放端口做协议指纹而非简单端口映射nmap -sV的问题是它假设80端口一定是 HTTP443一定是 HTTPS。但现实中某 IoT 设备把 MQTT 服务mosquitto跑在443端口伪装成 HTTPS 流量绕过防火墙某区块链节点把 P2P 通信geth跑在80端口返回HTTP/1.1 400 Bad Request但实际是 JSON-RPC 协议某内网代理把 SOCKS5 服务跑在1080但 banner 被刻意抹去。这时要用ncat做协议探活# 对每个开放端口发送协议特征字符串 echo -ne GET / HTTP/1.1\r\nHost: example.com\r\n\r\n | timeout 5 ncat -nv example.com 80 21 | head -5 echo -ne \x16\x03\x01\x00\xdd\x01\x00\x00\xd9\x03\x03 | timeout 5 ncat -nv example.com 443 21 | hexdump -C | head -3 echo -ne \x00\x00\x00\x00\x00\x00\x00\x00 | timeout 5 ncat -nv example.com 1080 21 | hexdump -C | head -3HTTP 流量会返回 HTML 或重定向TLS 流量会触发 Server HelloSOCKS5 会返回0x05 0x00支持无认证MQTT 会返回0x10开头的 CONNECT ACK。提示timeout 5防止卡死hexdump -C直接看十六进制响应比文本解析更可靠。我写了个小脚本proto-finger.sh输入端口列表自动分类输出http/https/mqtt/socks5/rpc类型比nmap -sV快 8 倍且零误报。3.3 第三阶服务识别必须绑定上下文脱离业务场景的“版本号”毫无意义nmap返回Apache httpd 2.4.52然后呢如果这是 CDN 回源 IP版本号完全无关紧要如果这是内网 Jenkins 服务器2.4.52搭配Jenkins 2.387才构成 RCE 链如果这是客户自建的 WordPress 站点2.4.52本身无漏洞但mod_security规则版本决定能否绕过 WAF。所以我的服务识别流程是用httpx获取状态码、标题、技术栈-status-code -title -tech-detect用nuclei -t http/cves/扫描已知 CVE 模板如apache-cve-2021-41773.yaml对关键服务Jenkins、GitLab、Confluence单独跑nuclei -t technologies/检测插件版本最后人工核验curl -I https://example.com看Server、X-Powered-By头是否与扫描结果一致。我在某金融客户渗透中nmap识别为nginx 1.18.0但httpx发现其X-Backend-Server头是kong/3.4.1nuclei扫出 Kong Admin API 未授权访问CVE-2023-37722。最终通过/kong/admin-api/创建恶意插件实现 RCE——而这一切始于对Server头的二次校验。4. Web 层目录爆破不是暴力穷举而是基于路由规范与开发习惯的智能猜解“目录爆破 dirsearch big.txt” 是最大的认知陷阱。big.txt有 2 万个单词但真实 Web 应用的路径命名90% 遵循三类规律框架默认路径Spring Boot 的/actuator/health、Laravel 的/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.phpCMS 插件路径WordPress 的/wp-content/plugins/wp-file-manager/lib/filesystem.php、Drupal 的/sites/default/files/private/开发者手误路径.git/、.env、backup.zip、config.php.bak、/dev/、/test/。用通用字典扫就像用全国地名列表找某栋楼的快递柜密码——方向错了。4.1 第一阶段用“技术栈驱动字典”替代通用字典效率提升 10 倍我的目录爆破永远分两步第一步用httpx和nuclei确定技术栈httpx -u https://example.com -status-code -title -tech-detect -method GET -timeout 10 -threads 50 | tee tech-info.json nuclei -u https://example.com -t technologies/ -o tech-nuclei.txt输出示例[tech-detect] wordpress 6.2.2, nginx 1.18.0, php 8.1.2, mysql 5.7.39第二步按技术栈加载专属字典WordPress用wpscan --api-token xxx --url https://example.com --enumerate ap,vt,cb,dbe,u,m获取插件/主题列表再生成专属字典# 抓取所有插件路径 curl -s https://example.com/wp-content/plugins/ 2/dev/null | \ grep -oE href[^]* | \ grep -oE /wp-content/plugins/[^]* | \ sed s/$// | \ sort -u wp-plugins.txt # 合并基础路径 插件路径 cat wp-common.txt wp-plugins.txt | sort -u wp-final-dict.txtSpring Boot用nuclei -t http/miscellaneous/spring-boot-actuator.yaml直接检测/actuator/下所有端点再用ffuf爆破/actuator/env泄露的配置项。提示wpscan的--enumerate参数必须加它比手动爬目录快 20 倍且能发现wp-content/plugins/下未链接的插件如被注释掉的a href/wp-content/plugins/old-plugin/。4.2 第二阶段用“响应特征指纹”过滤无效路径告别“403/401 泛滥”dirsearch默认把403 Forbidden当作“路径存在”但现实中403可能是 WAF 拦截如Cloudflare 403403可能是目录浏览禁用Index of /被关403也可能是真实路径如/admin/需登录返回403而非401。我的解决方案是用ffuf的-frfilter regex和-fwfilter words双维度过滤。例如ffuf -u https://example.com/FUZZ -w wp-final-dict.txt \ -t 100 -timeout 10 -ac \ -fr (403|401|Cloudflare|WAF|Security) \ -fw 12,15,18 \ -o ffuf-results.json-fr过滤掉含 WAF 关键词的403响应-fw 12,15,18表示过滤掉响应行数为 12/15/18 的页面这些是 Nginx/Apache 默认错误页的固定行数-ac自动校准避免网络抖动导致误判。实测对比对同一目标dirsearch返回 127 个403路径ffuf仅返回 9 个有效路径其中 7 个确认为后台入口/wp-admin/、/wp-login.php、/xmlrpc.php等。4.3 第三阶段用“路径关系推理”发现隐藏入口超越字典边界最高阶的目录发现是从已知路径反推未知路径。比如发现/api/v1/users立刻猜/api/v2/users、/api/v1/admin、/api/internal/users发现/static/css/main.css立刻猜/static/js/app.js、/static/img/logo.png、/static/fonts/发现/uploads/2023/10/report.pdf立刻猜/uploads/2023/09/、/uploads/2024/01/、/uploads/backup/。我用arjunHTTP 参数发现工具配合ffuf实现自动化# 先用 arjun 找参数 arjun -u https://example.com/api/v1/users -o json -t 50 params.json # 再用 ffuf 爆破参数值 cat params.json | jq -r .parameters[] | while read p; do ffuf -u https://example.com/api/v1/users?$pFUZZ -w payloads.txt -t 50 -fr 404 done在某 SaaS 平台渗透中arjun发现?token参数ffuf爆破出?tokenadmin直接绕过 JWT 验证——而这个参数从未出现在任何文档或前端代码中。注意路径推理必须结合robots.txt、sitemap.xml、/crossdomain.xml交叉验证。我写了个小工具path-guesser.py输入已知路径自动输出 50 个高概率衍生路径命中率达 63%。5. 资产整合与风险排序如何把 2000 行扫描结果变成一份老板能看懂的突破口报告信息收集结束时你手里有subs.txt127 个子域port-scan.nmap37 个端口其中 12 个开放tech-info.json8 个技术栈组合ffuf-results.json43 个有效路径params.json5 个敏感参数如果直接把这些丢给老板或客户等于交了一份“原始日志”。真正的价值在于把离散数据构建成攻击链路图并标注每条链路的实施成本与成功概率。5.1 第一步用“资产矩阵表”统一维度消除工具间的数据割裂我用 Excel或csvkit命令行建立四维矩阵子域IP开放端口技术栈关键路径风险等级验证状态admin.example.com203.0.113.42443,8080Spring Boot 3.1.0, Tomcat 10.1.12/actuator/env,/actuator/h2-console高已验证mail.example.com203.0.113.4325,143,443Zimbra 9.0.0_GA_4135/zimbra/,/zimbra/public/中待验证关键操作IP 列必须填真实 IP不能写CNAME因为admin.example.com可能 CNAME 到cloudflare.net但真实源站 IP 在203.0.113.42技术栈列合并多个工具结果httpx的tech-detectnuclei的technologies/whatweb的--verbose输出关键路径列只填“可交互、有业务逻辑”的路径过滤掉/favicon.ico、/robots.txt等无利用价值项风险等级按三要素评分利用难度1–5 分1无需认证5需物理接触影响范围1–5 分1单用户数据5全库泄露检测难度1–5 分1WAF 明显告警5流量完全正常。总分 ≥12 为高危8–11 为中危≤7 为低危。5.2 第二步用“攻击链路图”替代线性列表让决策者一眼看清最优路径我从不写“建议先打 A再打 B”。我画链路图[admin.example.com:443] ↓ (Spring Boot Actuator Env 泄露) [http://localhost:8080] ← (本地文件读取) ↓ (读取 /etc/passwd) [credentials in /home/tomcat/.aws/credentials] ↓ (AWS Access Key) [EC2 Instance in us-east-1] ↓ (SSM Session Manager) [Internal Database Server]这张图用纯文本实现方便粘贴到邮件每一步标注触发条件/actuator/env返回spring.profiles.activeprod且systemProperties含user.home验证命令curl -s https://admin.example.com/actuator/env | jq .propertySources[].properties.systemProperties.value.user.home下一步动作curl -s https://admin.example.com/actuator/env | jq -r .propertySources[].properties.systemProperties.value.user.home | xargs -I {} curl -s https://admin.example.com/actuator/env?path{}/.aws/credentials。提示链路图必须基于已验证数据未验证的路径用[ ]括起已验证的用→连接。我在某次汇报中用此图让客户安全负责人当场拍板“优先处理admin.example.com其他暂停”。5.3 第三步输出“可执行摘要”把技术语言翻译成业务影响老板不关心CVE-2023-37722他关心“这事会不会导致客户银行卡号泄露”所以最终报告的结尾我只写三句话最高危突破口admin.example.com的 Spring Boot Actuator/env端点未授权访问可读取服务器环境变量已验证获取 AWS 密钥进而控制 EC2 实例影响范围全部生产数据库。次高危突破口mail.example.com的 Zimbra Web 管理后台/zimbra/使用默认管理员密码zimbra可直接登录并导出全部员工邮箱影响范围全员钓鱼攻击面扩大。规避建议立即禁用/actuator/env端点为 Zimbra 管理后台启用双因素认证所有 AWS 密钥轮换为 IAM Role。没有“综上所述”没有“未来展望”只有“现在必须做什么”。因为渗透测试的价值从来不是展示你多懂技术而是帮客户把风险降到最低。我在实际操作中发现只要把信息收集阶段的资产矩阵表和攻击链路图做扎实后续漏洞利用环节的耗时平均缩短 65%。因为你知道哪条路最短、哪扇门没锁、哪把钥匙就在门口——这才是专业红队和脚本小子的本质区别。