信息打点实战：CDN绕过、漏洞回链与资产测绘的完整流程

一次授权测试，拿到目标域名，习惯性先ping了一下，结果所有探测流量都被CDN节点接住了，端口扫描扫到的全是CDN边缘节点，Web指纹识别的结果也是缓存页面。这时候如果继续硬碰硬去跑目录字典，大概率是浪费时间。真正有用的做法是先做一轮完整的信息打点——CDN绕过、业务部署梳理、漏洞回链、接口探针、全网扫描、反向邮件这套动作走下来，把目标资产的真实面貌还原出来，后面进入漏洞测试阶段才会顺。

这篇文章就把我在实际项目里常用的一套信息打点流程完整拆开讲一遍，每个动作解决什么问题、底层逻辑是什么、实操时有哪些坑，都会提到。先强调一下前提：下面所有方法只适用于你拥有合法授权的测试目标。没有授权的扫描、探测、验证都属于违法行为，这个底线没有任何商量余地。

1. CDN绕过的本质：不是找IP，而是找没被CDN保护的入口

很多人一上来就问“怎么绕过CDN”，但第一步应该是先确认目标真的在CDN后面。判断方法不复杂：用多地ping工具看解析结果，如果不同地区返回的IP不一样，或者返回的IP明显属于某个云厂商的CDN节点段，那基本可以判断套了CDN。再配合响应头观察，Cloudflare会有server: cloudflare和cf-ray字段，Akamai会有server: AkamaiGHost，国内厂商的CDN也各有特征。还有一种判断方式是看TLS证书，CDN节点的证书经常不是目标域名专属的，证书的CN、SAN和签发者信息会露出马脚。

常见的CDN特征我整理了一个表，方便对照：

确认目标确实套了CDN之后，接下来的思路不是和CDN硬刚，而是寻找目标业务链路上没有套CDN的环节。

1.1 从历史DNS记录和子域名里挖真实IP

历史DNS记录是我最常用的入口。很多站点在接入CDN之前，源站IP是直接暴露在DNS A记录里的。通过微步在线、SecurityTrails、DNSDB这些平台的公开历史解析记录，可以查到目标域名半年前甚至更早的解析结果，经常能翻出入CDN之前的源站IP。查的时候注意不要只看最近几天，往前翻的时间跨度越大，命中率越高。

子域名是另一个稳定入口。CDN的配置往往只覆盖主域名或者核心业务域名，边缘子域像test、dev、old、api、m、static这些经常被遗漏，直接解析到源站或者源站所在网段。找子域名的渠道很多：证书透明度日志（crt.sh直接搜域名）、被动DNS数据、搜索引擎收录、Github代码泄露，也可以用字典爆破。爆破时如果遇到泛解析会有一堆假阳性，判断方法是随机拼一个不存在的子域，看它解析到什么地址，如果解析结果和大量爆破结果一致，那这个字典结果的准确性就要打问号了。

1.2 用证书和邮件服务定位源站

不少企业的证书是和源站绑定的，用证书信息做反查也是一个好路子。具体做法是先从crt.sh或者浏览器导出目标域名的证书，拿到证书序列号，然后去空间测绘平台用证书序列号反查所有部署过这张证书的IP。如果某个IP上配的目标域名证书且不是CDN节点，那大概率就是源站。证书反查这个方法在“多家业务共用一个证书”的场景下特别好用。

邮件服务是我特别推荐优先检查的。很多企业会把mail、smtp、pop3这类子域名解析到独立的邮件服务器，而邮件服务器基本不会买CDN加速。通过MX记录、SPF记录拿到的邮件服务器IP，有时候和Web源站同机房、同C段，甚至就是同一台机器。这个方向不仅对CDN绕过有效，本身也是第6章反向邮件分析的基础。

1.3 验证候选IP是不是真正的源站

找到几个候选IP之后，需要验证。最直接的方法是修改Host头：本地绑定hosts或者用curl -H "Host: target.com" https://IP直连IP，看返回的内容是否和目标站点一致。再对比一下TLS证书，如果候选IP上部署的证书确实是目标域名的，基本可以锁定源站。还可以对比favicon的hash值和页面body特征，这个在多个候选IP之间做筛选时效率很高。

实际项目里经常出现的情况是：CDN只覆盖了www主域名，根域或者某个老域名直接解析到源站。所以做CDN绕过时，先看根域解析、再看www解析、再看老域名解析，往往比花时间翻历史记录更快。

2. 业务部署画像：把目标企业的资产边界先从公开信息里画出来

2.1 从“公司主体”视角看资产

信息打点最容易犯的错误是只盯着一个域名打。真实企业的资产往往分散在集团、子公司、关联公司名下，安全团队的管理范围也未必能覆盖到所有角落。所以第一步不是扫描，而是画主体边界。

先查ICP备案。用目标主域名反查主办单位名称，再拿主办单位名称反查该主体名下还有哪些域名，这一步能把你从“一个域名”带入“一批域名”的视角。然后查工商股权结构，目标公司的对外投资、分支机构、历史名称变更，集团下子公司的域名经常不在安全团队的重点关注列表里。再看历史域名和相似域名，目标公司用过的老域名、拼写相似的仿冒域名，偶尔上面还挂着测试系统、文件服务器这样的遗留资产。

这些信息全部来自公开渠道，但把它们串起来之后，资产的边界一下子就清晰了。后面做业务部署画像和全网扩展，都依赖这一步画出来的主体关系。

2.2 常见独立部署系统的识别清单

业务部署的另一个重要维度是识别目标企业自己部署的常见系统。这类系统往往有固定指纹、固定路径、已知漏洞组件，是整个信息打点过程中价值最高的入口类型。我在实际项目中常用的识别清单如下：

快速识别的方法分三个层级：浏览器访问目标站点时直接看登录页的title、JS文件名、版权信息；小规模目标用Wappalyzer、WhatWeb这类浏览器插件和命令行工具；大批量资产则用EHole、TideFinger、fscan这类指纹识别工具一次性跑完，再对识别出的系统做分类。

2.3 部署细节里的隐藏资产

业务部署里还有几个容易漏掉的方向。

同IP不同站点是经常被忽略的。一个IP上可能通过虚拟主机部署了多个站点，直接访问IP看到的只是一个默认页或者无关应用，但绑定不同Host之后会出现完全不同的站点。做完CDN绕过拿到源站IP后，用IP反查在同一主机上的其他域名，经常能发现目标公司别的业务系统，甚至一些内部系统。

云上对象存储也是高发遗漏点。很多企业把静态资源、备份文件、用户上传文件放到对象存储桶里，如果权限配置不当，可能可以通过列举接口直接下载文件。但这块要特别注意合规边界，确认授权范围后才做验证。

代码托管平台暴露则是另一个高价值方向。员工把代码推到公开仓库，代码里带的配置文件、密钥、内网地址，比扫描器跑出来的端口信息值钱得多。这个方向靠的是关键词搜索和耐心，和纯技术扫描是两条路。

做业务部署画像时，我脑子里始终有一张图谱：域名、IP、系统、端口、入口、凭据，后面做一切测试都往这张表里填。信息打点不是多跑几个工具的问题，而是你能不能还原出目标企业的真实IT架构。

3. 漏洞回链：让目标服务器自己暴露内网与出口信息

3.1 漏洞回链的原理

漏洞回链（callback）指在测试过程中向目标应用提交一个带有我们可控域名或地址的payload，当目标应用在特定条件下主动向这个地址发起请求时，我们在监听端就能看到这条请求记录。打个比方，你去敲一户人家的门，门开了，门缝里漏出的光告诉你屋里有人在开灯——回链就是那道光。

回链常见的触发场景有几种：SSRF漏洞中目标服务器根据我们提供的URL发起请求；XSS盲打中目标后台管理端执行了我们提交的脚本，浏览器请求了回链地址；邮件场景中目标系统向我们的回链邮箱发信，邮件头暴露目标邮件网关的IP；文件包含、模板注入这类漏洞则可以通过OOB数据外带方式，把目标内容拼到DNS请求里带出来。

3.2 回链平台的选型与搭建

回链服务本质上是“一个能记录请求的接收端”，按使用方式可以分为三类。

公网DNSLog服务是最快捷的，注册dnslog.cn、ceye.io这类平台后，会生成一个专属子域，把payload拼成随机子域提交到目标，有请求就会记录DNS解析记录。interactsh是近几年用得多的交互式平台，支持DNS、HTTP、SMTP回调，记录内容丰富。Burp Collaborator则是Burp Suite自带的能力，生成的子域能记录DNS、HTTP、SMTP等流量，功能很强，适合配合Burp工作流使用。

自建回链服务也不复杂：准备一个独立域名，把回链子域的A记录或NS记录指向自己的VPS，在VPS上用tcpdump udp port 53监听DNS请求，或者用python3 -m http.server监听HTTP请求，有请求过来就能看到。自建的好处是数据隐私可控、不依赖第三方平台稳定性，缺点是线路质量和维护成本要自己负责。

使用时有几个细节要注意：回链子域名一定要随机化，不要每次都用一个固定前缀，否则容易被目标安全设备批量拦截；每条回链记录要带时间戳和随机token，方便后续区分是哪条POC产生的请求；多人协作测试时，每人分配独立子域前缀，避免记录互相污染。

3.3 回链结果的情报提取

回链不只是确认“有没有请求”，每条请求记录都能读出不少有价值的信息。

DNS请求记录本身说明目标服务器具备对外发起DNS解析的能力，验证了出网方向。HTTP请求里的路径和User-Agent字段，可能携带目标服务器的内网IP、主机名、操作系统、Web容器版本。请求头中的X-Forwarded-For字段有时能暴露目标内网的代理链结构。如果是SMTP回链，邮件头里的Received链会直接暴露发信服务器的IP和主机名。

我在实际项目中用得最多的是三个场景。第一个是验证SSRF漏洞是否存在，把参数改成回链地址看有没有请求进来，确认之后再把回链地址指向内网地址，比如http://127.0.0.1:8080，看能不能继续探测内网接口。第二个是XSS盲打，目标系统有留言、反馈、后台审核这类功能，提交带回链的payload，如果管理员后台触发执行，就能间接证明存储型XSS的严重性。第三个是绕过WAF的判断，把回链地址拼接在各种容易触发WAF拦截的参数里，观察是回链先触发还是先被拦截，能反向推断WAF的拦截规则。

这里必须提醒一个实际问题：回链地址如果以明文形式出现在请求参数里，很容易被目标的安全设备和日志审计关联分析。所以在授权测试窗口内要控制payload规模，不要一上来就大批量盲打，否则目标安全团队很快就会发现测试行为。

4. 接口探针：从JS、API文档和框架路径里挖出隐藏入口

4.1 为什么传统的目录扫描不够用

现代Web应用几乎都是前后端分离架构，前端浏览器会把所有静态资源加载一遍，其中JS文件里往往写满了后端接口地址、访问路径、甚至认证信息。这些接口路径在目录字典里根本扫不到，因为它们不是常见单词组合，而是后端程序员自定义的路径拼接。接口探针解决的就是“找到目录扫描发现不了的入口”这个问题。

目录扫描靠字典瞎猜，接口探针靠证据推理——两者的效率差异在真实项目里非常明显。

4.2 从JS文件中提取接口的完整流程

第一步是抓包。访问目标站点首页和相关功能页面，把HTML、JS、CSS全部保存下来。对于前后端分离比较彻底的应用，主页面可能只是一个壳，真正的业务逻辑都在JS文件里。

第二步是提取。常用工具我列一下：URLFinder可以提取JS和页面中的URL；JSFinder会递归爬取JS里的子域名和URL；LinkFinder基于正则从JS提取端点；jsluice是一个Go写的库，解析JS里的字符串和路径很精准。如果目标站点规模不大，直接打开浏览器DevTools的Network面板，手动筛选XHR请求记录，效率反而更高，因为你能结合上下文判断每个接口的真实用途。

第三步是处理。提取到的接口要做去重和分类：过滤掉静态资源路径（.js、.css、.png这类），只保留API路径；有些接口是相对路径，要结合页面URL拼成完整地址；很多接口对请求方法有要求，测试时按JS里出现的方式请求，再看响应差异。

4.3 常见框架的典型暴露路径

不同开发框架有各自的典型暴露路径，接口探针时这些路径是必测的：

Spring Boot的Actuator如果开放，能读到环境变量和配置信息，heapdump更是可以下载内存快照，里面经常能找到明文口令和Token。Swagger文档开放的话，整份接口清单、参数定义、鉴权方式全部暴露，后面测试的效率完全不一样。

4.4 接口参数、密钥泄露和鉴权差异

接口探针阶段，除了找接口路径本身，还要关注两类问题。

一类是参数和密钥泄露。JS文件里经常硬编码appKey、accessKey、secret、加密盐这些敏感数据，用正则去匹配这些关键字命中后，直接就是高价值入口。这些密钥虽然可能只用于前端调用，但暴露了目标对敏感信息的防护意识，顺着这个思路往往能找到更多类似问题。

另一类是鉴权差异。同一个接口，用GET还是POST、带不带X-Forwarded-For、带不带Referer，响应结果完全不同。很多系统是“前端鉴权”，服务端根本没验证调用者身份，只是前端不展示管理按钮。直接访问接口URL，如果返回200并有数据，说明接口层存在明显的鉴权缺陷。

用ffuf做接口fuzz是效率很高的方式。把提取到的接口路径作为字典，拼接在域名后面跑一遍，对比响应长度和状态码。字典的构造要贴合业务场景，/api/user、/api/admin、/api/config、/api/export、/api/upload这些高频路径是必测的。

5. 全网扫描：从被动收集切换到主动测绘的资产扩展

5.1 全网扫描的含义与授权边界

业务部署画像是从公开信息出发推理资产，全网扫描则是把已知的目标IP段、关联域名、证书特征放到更大的范围做主动测绘。它不是无脑拿一个IP做全端口扫描，而是有策略地扩展资产面。

可扩展的方向包括：已知源站IP的邻近C段、目标公司自持IP段（通过ASN信息查询）、证书特征关联的IP集合、同主体下其他域名解析到的IP、云上新创建资源映射出来的端口。

这里必须把边界说清楚：所有扫描范围都必须在授权委托书允许的范围内。如果授权范围写的是一个域名，那C段扫描就超出了授权范围，必须重新确认。这一点没有商量的余地，不要说“扫一下C段问题不大”，出了问题就是大问题。

5.2 扫描工具与执行流程

我的常规流程分四步。

第一步用masscan做全端口扫描，速度优先。命令大概这样：

bash复制masscan -p1-65535 --rate=3000 -e eth0 -oG target.gnmap 目标IP

实际项目中rate参数要根据本机带宽和目标机房承受能力调整，国内机房一般在1000到5000之间。扫描前先确认目标主机可达，避免把大量流量浪费在不存在的主机上。

第二步对开放端口做服务识别和脚本扫描：

bash复制nmap -sV -sC -p 80,443,8080,3306,6379 目标IP

nmap的服务识别要比全端口扫描慢得多，所以只对masscan确认开放的端口执行。

第三步把识别的服务按指纹归类：Web类、数据库类、中间件类、运维管理类。第四步对Web端口做指纹识别和后续的目录/接口探测，对数据库、中间件类则记录版本号，留给下一阶段的漏洞匹配。

5.3 网络空间测绘平台的补充价值

主动扫描之外，网络空间测绘平台（FOFA、Quake、Hunter、Shodan、ZoomEye）能提供历史数据，覆盖主动扫描扫不到的资产。常用的检索思路有几种：用证书指纹或序列号关联同证书的IP；用favicon hash关联使用同一图标的站点；用ICP备案号或公司名直接检索资产；用body特征（某个特定的JS路径、版权字符串）找相似应用。

这个环节我做得最多的其实是反向验证。从测绘平台看到某个IP开放了某个端口，但主动扫描时没扫到，这通常说明目标网络配置了来源IP白名单，只放行了特定来源的访问。遇到这种情况，说明目标网络里有访问控制机制，打点到这里就要考虑是不是需要调整探测来源、或者换一种交互方式。

5.4 高危暴露面的处理思路

全网扫描结果里，下面这些端口和协议需要重点记录：

遇到这些暴露面，第一步不是马上尝试利用，而是记录“这是一个高风险入口”，回到第2章的资产表里标注。信息打点阶段的目标是把资产地图做全做准，不是在扫描阶段就把目标服务打崩。扫描节奏控制不好，触发了目标的安全告警，后面的测试窗口只会更窄。

6. 反向邮件：从一封邮件头扒出邮件网关与真实IP

6.1 为什么邮件系统是信息打点的富矿

邮件系统几乎是所有企业的基础设施，但它经常被安全团队放在低优先级：CDN保护的是Web业务，邮件网关IP基本属于“裸奔”状态。更关键的是，邮件链路里天然包含服务器的IP、主机名、软件指纹，只要会读邮件头，就等于把目标企业的邮件基础设施信息主动摆到面前。

反向邮件的思路，就是通过发送和接收邮件来收集目标邮件基础设施信息。它和直接打Web是两条完全不同的路径，但往往能拿到Web路径拿不到的真实网络地址。

6.2 邮件头分析从哪里开始

一封完整的邮件，头部信息里包含大量线索：

• Received字段：每经过一跳，都会在最上面加一条Received。从下往上读，最下面是最早的发送方。
• Received-SPF：记录了发信IP是否通过SPF验证，以及具体IP地址。
• DKIM-Signature：签名域、选择器，从中能推断邮件安全网关的类型。
• Authentication-Results：记录邮件系统对发信身份的判断。
• Message-ID：格式有强烈指纹特征，比如Coremail的Message-ID形如<xxx@xxxx.coremail.cn>，Exchange的格式则完全不一样。

实操时怎么触发一封目标邮件？最常用的方式是利用目标站点上“找回密码”“注册”“联系我们”之类的功能，提交一个你控制的外部邮箱地址，然后等待邮件到达。收到后，在邮件客户端里打开“查看原始邮件”或“显示原文”，把Received、SPF、DKIM这些字段摘出来分析。从Received链里找到目标邮件网关或源站的出口IP，再回到第1章的CDN绕过流程里做交叉验证。

6.3 邮件网关指纹识别与用户枚举

识别邮件网关的类型，是反向邮件分析的一个核心步骤。如果邮件头里有coremail字样，说明使用的是Coremail邮件系统，国内很多企业和高校都用这个产品，某些版本存在已知的接口问题。如果收到的是Exchange邮件，登录界面通常是OWA，路径特征为/owa/、/ecp/、/autodiscover/autodiscover.xml，这类系统要特别注意历史漏洞组件。如果邮件发件域名对应的邮件系统是腾讯企业邮、阿里企业邮这类云平台，打点意义相对小一些，但能确认目标域名使用了哪些云服务。

用户枚举可以在这个阶段一起做。邮件系统登录接口对“用户不存在”和“密码错误”的响应往往有差异，观察错误提示、响应时间、响应内容里的字段，可以批量确认有效用户。注册或找回密码接口的响应差异也是一样。此外，向不存在的邮箱和存在的邮箱各发一封测试邮件，比较退信内容，也能区分用户是否存在。

枚举出来的有效用户名，结合前面从代码仓库、公开历史信息里发现的员工邮箱格式（比如姓名拼音@domain.com），很可能就是企业统一身份认证的账号。这类账号经常同时用于OA、邮件、办公系统的登录，价值很高。

6.4 邮件记录里可以延伸的动作

拿到邮件网关IP、SPF发信IP段之后，这些信息还有很多后续用途。

邮件网关IP可能和Web源站同IP段或同机房，拿网关IP做反向查询，看同一IP还绑定了哪些域名、哪些系统。SPF记录里列出的IP段基本可以映射出企业的邮件系统部署位置和办公网出口网段，这些信息在后续测试里能作为参考。如果识别出了具体的邮件系统产品和版本，回到漏洞库里去匹配已知漏洞，这就是漏洞回链思路在邮件场景的自然延伸。

邮件头分析同样要在授权范围内做。发测试邮件、枚举用户这些动作会产生真实外发流量，务必控制频次，同时要在授权书里先确认邮件系统是否包含在目标范围内。超出范围的动作一律不要做。

自己做信息打点，我一直保持一个习惯：每次收尾前一定把资产总表整理出来，字段就五列——域名、IP、端口、系统类型、入口或脆弱点。所有回链记录、接口探针结果、扫描日志按时间归档，方便后面写测试报告时复现。更重要的是把“还没有解决的问题”单独列出来，哪个子域名没查完、哪个接口没测、哪个IP段没确认，这些缺口就是下一轮打点的突破口。

信息打点不是追求一击必杀的技术，而是大量耐心推敲和交叉验证的积累。CDN绕过了真实IP找到了，业务画像有了轮廓，回链收到一条请求，接口清单列了几十行，IP段画出了一张网——这些东西拼在一起，目标的真实轮廓才浮现出来。打点做得越细，后续路径越宽，这点在我经手的项目里反复验证过。