SRC漏洞挖掘实战：从资产测绘到漏洞利用的漏斗式方法论

1. 项目概述：SRC漏洞挖掘的“狩猎”逻辑

在安全圈里混久了，SRC（安全应急响应中心）对很多人来说，既是证明自己技术实力的“演武场”，也是获取合法回报的“狩猎场”。但很多新手，甚至一些有一定经验的朋友，常常陷入一个误区：拿到一个目标，打开扫描器一顿狂扫，然后对着报告里密密麻麻的“中危”、“低危”漏洞发呆，感觉无处下手。这就像猎人进了森林，不看地形、不辨足迹，只管乱放枪，结果自然是一无所获。

真正的SRC漏洞挖掘，远不止是工具扫描那么简单。它是一套从“战略侦察”到“战术打击”的完整流程，核心在于 信息收集 与 逻辑推理 。信息收集是地基，决定了你能看到多大的攻击面；逻辑推理是建筑蓝图，指导你如何从海量信息中筛选出有价值的脆弱点。今天，我就结合自己这些年“狩猎”的经验，把从资产梳理到最终漏洞命中的全流程，掰开揉碎了讲清楚。无论你是想入门SRC的新手，还是希望提升挖掘效率的老手，这套方法论都能帮你建立起清晰的思路，告别盲目扫描，实现精准打击。

2. 核心思路：从“面”到“点”的漏斗式挖掘模型

很多人在SRC挖掘中感到迷茫，根本原因在于思路是发散的、点状的。看到一个子域名就去测一下，发现一个端口就去扫一下，整个过程缺乏主线。高效的挖掘必须遵循一个清晰的逻辑模型： 漏斗式挖掘 。这个模型的核心是逐层过滤、逐步聚焦，将庞大的攻击面收敛到具体的高价值漏洞点。

2.1 漏斗模型的四层结构

我们可以把整个挖掘过程想象成一个四层漏斗：

1. 第一层：资产边界测绘（Attack Surface Mapping） 。这是最上层，目标是把目标企业所有对外的数字资产尽可能完整地找出来。这不仅仅是域名和IP，还包括云存储桶、移动应用、API接口、第三方服务、甚至暴露在公网的代码仓库、文档等。这一层的输出是一个庞大的资产列表，关键词是“全”。

2. 第二层：资产属性分析与分类（Asset Profiling & Categorization） 。面对成百上千的资产，我们需要给它们打标签、分门别类。比如：哪些是核心业务（如支付、用户中心）？哪些是边缘系统（如官网、宣传页）？哪些是开发测试环境？哪些用了Java，哪些用了PHP？哪些部署在云上，哪些是自建机房？分类的目的是为了评估资产的 价值 和 风险 ，优先处理高价值目标。

3. 第三层：脆弱点探测与验证（Vulnerability Probing & Validation） 。在分类后的资产上，进行有针对性的漏洞探测。这里要摒弃“全端口全漏洞”的暴力扫描。对Web应用，重点检查身份认证、业务逻辑、特定组件（如OA、CMS）；对服务端口，检查是否存在未授权访问、弱口令、已知EXP。这一层的关键是“准”，需要大量手动测试和逻辑判断，工具只是辅助。

4. 第四层：漏洞深度利用与报告撰写（Exploitation & Reporting） 。确认漏洞存在后，需要评估其真实影响。一个SQL注入，是能直接拖库，还是只能盲注？一个文件上传，能否获取服务器权限？同时，报告撰写要清晰、专业，包含复现步骤、影响证明（截图、视频）、修复建议。这一层体现的是“深”和“专”。

这个漏斗模型的意义在于，它强制你进行 战略性思考 。你的时间和精力是有限的，必须把它们投入到最可能产出成果的路径上。接下来，我们就深入每一层，看看具体怎么做。

3. 第一层实操：立体化资产信息收集

资产收集是基石，广度决定深度。我们的目标是绘制一张尽可能详细的“目标数字地图”。

3.1 子域名发现：打开入口的大门

子域名是Web应用的直接入口。收集要兼顾被动和主动。

• 被动收集（悄无声息） ：利用第三方聚合数据。常用工具和网站包括：

  • subfinder , amass ：命令行工具，聚合数十个数据源。
  • chaos （需申请）：Project Discovery的官方数据集，质量很高。
  • crt.sh , certspotter ：通过证书透明度日志发现子域。
  • SecurityTrails , VirusTotal ：这些平台的历史DNS记录有时能挖到已下线但仍有用的资产。
  • 实操心得 ：不要只依赖一种工具。将 subfinder 、 amass 和 assetfinder 的结果合并去重，往往能得到最全的列表。记得检查泛解析（ *.target.com ），避免收集到大量无效域名。

• 主动枚举（主动试探） ：

  • 字典爆破 ：使用 gobuster 、 ksubdomain 等工具，配合强大的字典（如 commonspeak2 、 fuzzdb 以及自己积累的行业特定词汇）。
  • DNS区域传送检测 ：虽然古老，但偶尔在管理不当的DNS服务器上还能发现。 dig axfr @ns.target.com target.com 。
  • 搜索引擎语法 ： site:target.com -www 在Google、Bing中搜索，有时能发现被遗忘的站点。

3.2 IP与端口扫描：勾勒网络轮廓

拿到域名后，需要解析到IP，并了解开放了哪些服务。

1. 域名解析 ：使用 dnsx 、 massdns 进行批量解析，注意收集A记录、AAAA记录（IPv6）、CNAME记录（指向其他域名，可能是云服务）。
2. CDN识别 ：如果IP地址属于Cloudflare、Akamai、阿里云CDN等，说明背后有真实服务器（源站IP）。绕过CDN是重要一步，方法包括：
   • 查询历史DNS记录（ SecurityTrails , viewdns.info ）。
   • 查找子域中未接入CDN的（如 test.target.com , dev.target.com ）。
   • 通过邮件服务器、第三方服务（如 github 、 s3 桶）信息反查。
   • 注意事项 ：切勿使用非法的网络攻击手段尝试获取源站IP，如DDoS。SRC挖掘必须在授权和法律框架内进行。
3. 端口扫描 ：使用 nmap 、 masscan 、 naabu 。
   • 策略 ：先快速扫描全端口（ masscan -p1-65535 ），识别开放端口。再对开放端口进行精细化扫描和服务识别（ nmap -sV -sC -p ）。
   • 重点关注端口 ：
     • 80, 443, 8080, 8443 ：Web服务。
     • 21, 22, 23, 161 ：FTP, SSH, Telnet, SNMP（弱口令、未授权高发区）。
     • 6379, 27017, 9200 ：Redis, MongoDB, Elasticsearch（未授权访问重灾区）。
     • 389, 636, 3268 ：LDAP服务（可能泄露内网信息）。
     • 1433, 3306, 5432 ：MSSQL, MySQL, PostgreSQL数据库。

3.3 关联资产与“蛛网”扩展

现代企业资产盘根错节，不能只看主域名。

• 关联企业挖掘 ：目标公司可能收购了其他公司（子公司），或者属于某个大型集团。通过企查查、天眼查等商业查询平台，找到关联公司名称，再对这些新目标进行子域名收集，往往有意外收获。
• 第三方服务暴露 ：
  • 云存储桶 ：AWS S3 ( *.s3.amazonaws.com )、阿里云OSS ( *.oss-cn-*.aliyuncs.com )、Google Cloud Storage。使用 cloud_enum 等工具进行枚举，直接访问桶地址，查看是否配置为“公开可读”甚至“公开可写”。
  • 代码仓库 ：Github、Gitlab、Gitee。搜索公司名、项目名、邮箱后缀，常能找到泄露的API密钥、数据库密码、内部代码和配置文件。
  • 文档与协作平台 ：Confluence、Jira、Jenkins。这些系统若暴露在外且未正确配置权限，可能泄露项目信息、内部账号甚至执行命令。
• 移动应用与API ：
  • 从各大应用商店下载目标公司的APP，使用 jadx-gui 、 frida 等工具进行逆向，分析其通信的API接口（ *.api.target.com ）、硬编码的密钥等。
  • 使用 katana 、 gau 、 waybackurls 等工具，从历史爬虫数据、归档网站中收集目标域名的所有URL路径，特别是API路径（通常包含 /api/ , /v1/ , /graphql 等）。

这一阶段结束后，你应该获得一份包含域名、IP、开放服务、关联资产、关键URL的庞大清单。接下来，就是如何管理并从中筛选出“猎物”。

4. 第二层实操：资产价值评估与攻击面优先级排序

手里拿着一份可能有成千上万个条目的资产列表，如果平均用力，效率极低。我们必须学会 评估与排序 。

4.1 资产分类与打标

我习惯用电子表格或Notion这样的工具来管理资产，并至少添加以下几列标签：

• 资产类型 ：主站、子业务系统、后台管理系统、测试/开发环境、第三方服务、API网关、移动端接口等。
• 技术栈 ：通过 Wappalyzer 浏览器插件或 whatweb 命令行工具批量识别。标注如： Java/SpringBoot , PHP/ThinkPHP , Python/Django , Nginx , Apache Tomcat 。知道技术栈能极大缩小漏洞测试范围（例如，ThinkPHP有专属的历史漏洞）。
• 业务重要性 ：根据常识判断。核心交易、用户中心、管理后台 > 官网、宣传页 > 测试站、归档站。
• 访问状态 ：正常访问、需要登录、返回4xx/5xx错误、被CDN/WAF拦截。
• 特殊特征 ：是否存在登录框、文件上传点、查询接口、验证码、短信接口等。这些是高风险功能点。

4.2 攻击面分析与优先级矩阵

建立一个简单的优先级矩阵来指导后续测试：

实操心得 ：不要忽视“测试环境”（ dev , test , staging ）。这些环境的安全防护通常远弱于生产环境，但代码和功能与生产环境相似，在这里发现的漏洞（如SQL注入、RCE）往往能通杀生产环境，且危害证明更直接。它们是SRC挖掘中的“低垂果实”。

4.3 自动化信息聚合与看板

对于大型目标，手动分类效率太低。可以借助一些自动化工作流：

1. 使用 httpx 或 nuclei 的 tech-detect 模板，批量探测资产的技术栈。
2. 编写简单脚本，根据URL关键词（如 /admin/ , /api/ , /upload/ ）自动打标。
3. 将最终结果导入到 Elasticsearch + Kibana 或 Grafana 中，制作一个可视化的资产安全看板，实时查看资产分布、风险状态，让决策更直观。

通过第二层的筛选，你的目标从“一片森林”聚焦到了“几棵最有价值的果树”。接下来，就是拿起工具，检查这些果树上是否有熟透的果子（漏洞）。

5. 第三层实操：针对性漏洞探测与手工验证

这是最体现技术功底和耐心的环节。工具自动化扫描（如 nuclei , xray ）可以作为初筛，但高价值、逻辑复杂的漏洞，必须依靠手工测试。

5.1 Web应用漏洞挖掘

这是SRC提交漏洞的主要来源。

• 常规漏洞扫描与手动复现 ：
  • 使用 nuclei 配合庞大的社区模板库进行快速扫描。 但切记 ：不要直接把 nuclei 报告当最终结果。对于它报出的漏洞，尤其是中高危，必须手动复现一遍。很多是误报（如基于响应长度的SQL注入检测），或者需要特定条件才能触发。
  • 对 xray 、 awvs 等扫描器报告也应持同样态度。它们是指南，不是结论。
• 身份认证与权限漏洞 ：
  • 越权测试 ：这是业务逻辑漏洞的宝库。核心方法是：用两个不同权限的账号（如普通用户A和管理员B），抓取B执行高权限操作的请求包，替换成A的Token或Session，重放请求，看是否能以A的身份执行B的操作。分为水平越权（访问同级别用户数据）和垂直越权（获取更高权限）。
  • 密码重置/找回逻辑漏洞 ：重点测试验证码是否可爆破、是否返回在响应中、是否可重放、修改绑定手机/邮箱的流程是否有缺陷。
  • 会话管理漏洞 ：检查Cookie中的Session ID是否可预测、是否在注销后仍有效（未失效）、是否存在并发登录导致会话覆盖等问题。
• 业务逻辑漏洞 ：
  • 支付漏洞 ：金额篡改（前端修改、负数、溢出）、商品数量篡改、重复支付、支付状态绕过（未付款生成已付款订单）。
  • 优惠券/积分漏洞 ：无限领取、金额修改、条件绕过。
  • 抽奖/抢购漏洞 ：并发请求、时间篡改、次数限制绕过。
  • 资料修改漏洞 ：能否修改他人信息、能否注入恶意代码（如个人简介处XSS）。
  • 实操心得 ：业务逻辑漏洞没有通用扫描器。必须深入理解业务流程，把自己当成一个“恶意用户”，不断问“如果…会怎样？”。多使用Burp Suite的 Repeater 和 Intruder 模块进行参数篡改和重放测试。
• 特定组件与框架漏洞 ：
  • 在资产梳理阶段标注的技术栈此刻派上用场。如果目标是 Spring Boot ，检查 actuator 端点是否暴露（ /actuator/heapdump 可泄露内存信息）、是否存在 Spring Cloud 相关漏洞。
  • 如果是 ThinkPHP ，检查历史RCE漏洞（如 5.x 的 method 调用）。
  • 如果是 Shiro ，检查是否存在反序列化漏洞（使用 shiro_attack 工具）。
  • 对于 OA 、 CRM 等通用系统，搜索其历史漏洞和EXP。

5.2 服务与端口漏洞挖掘

对于非Web服务，思路有所不同。

• 未授权访问/弱口令 ：
  • Redis ： redis-cli -h 直接连接，尝试 INFO 命令。若未授权，可写入Webshell或SSH公钥。
  • MongoDB ： mongo --host 直接连接。未授权访问可直接操作数据库。
  • Elasticsearch ：浏览器访问 http://:9200/_cat/indices 查看索引。
  • Memcached ： telnet 11211 ，使用 stats 命令。
  • 弱口令爆破 ：针对SSH、FTP、Telnet、MySQL、MSSQL、SMB等服务，使用 hydra 、 medusa 或 xhydra 进行爆破。 关键点 ：使用强字典（如 rockyou.txt 的变种、行业常用口令），并注意目标账户锁定策略，避免造成破坏。
• 特定协议漏洞 ：
  • SNMP ：使用 snmpwalk 查询，可能泄露系统信息、网络拓扑、进程列表。
  • LDAP ：匿名绑定可能泄露员工邮箱、部门结构等敏感信息。
  • NFS ：检查是否允许未授权挂载，可能导致文件泄露。

5.3 信息泄露的深度利用

信息泄露本身可能不是高危漏洞，但它是通往高危漏洞的“钥匙”。

• 源码泄露 ： .git , .svn , .DS_Store 目录泄露。使用 githack 、 dvcs-ripper 等工具可恢复完整源码。源码中可能包含数据库配置、API密钥、硬编码密码、内部接口地址。
• 备份文件泄露 ：扫描 www.zip , web.tar.gz , bak 等备份文件。有时甚至能找到数据库备份（ .sql 文件）。
• 配置文件泄露 ： /WEB-INF/web.xml , /config.json , /.env , /application.properties 。这些文件泄露数据库连接字符串、加密密钥、第三方服务凭证。
• 错误信息泄露 ：详细的SQL错误、堆栈跟踪（ StackTrace ）会暴露数据库结构、后端代码路径、使用的框架和库版本。
• 中间件/平台默认页 ： phpinfo() , Tomcat 管理页面、 Jenkins 控制台等。这些页面可能直接导致信息泄露或成为攻击入口。

在这一阶段，需要将自动化工具的广度和手工测试的深度结合起来。对每一个潜在的脆弱点，都要像侦探一样，思考“这里泄露的信息，能否用在别处？”、“这个参数异常，背后是怎样的处理逻辑？”

6. 第四层实操：漏洞利用、影响证明与报告撰写

发现漏洞只是成功了一半，如何证明其危害并清晰地传达给厂商，同样至关重要。

6.1 漏洞深度利用与链式攻击

单个漏洞的危害可能有限，但组合起来可能产生“化学反应”。

• 案例：信息泄露 -> 权限提升 。通过源码泄露获取到数据库密码，但数据库无法外连。进一步发现一个SQL注入点，通过该注入点可以读取数据库中的用户密码哈希。如果密码哈希强度弱（如MD5），破解后可能获得后台管理员密码，从而完成从外部注入到获取后台权限的跨越。
• 案例：越权 -> 存储型XSS -> 获取管理员Cookie 。在一个可越权修改他人资料的功能点，插入存储型XSS payload。当管理员查看用户列表或审核资料时，触发XSS，将管理员的Cookie发送到攻击者服务器，从而接管管理员会话。
• 实操心得 ：不要满足于提交一个孤立的“低危”信息泄露或“中危”XSS。多思考一步：“这个漏洞能帮我拿到什么信息？这个信息能否用来扩大战果？” 尝试构建攻击链，这往往能将漏洞等级从“中危”提升到“高危”甚至“严重”。

6.2 清晰专业的漏洞报告撰写

一份糟糕的报告可能让厂商忽略漏洞的风险，而一份专业的报告则能加速漏洞的确认与修复。 一份合格的SRC漏洞报告应包含以下部分：

1. 漏洞标题 ：简明扼要，如“XX系统后台管理模块存在垂直越权漏洞，可任意添加管理员”。
2. 所属厂商/域名 ：明确目标。
3. 漏洞等级 ：参考该SRC平台的自定等级（如高危、中危、低危），客观评估。
4. 漏洞详情 ：
   • 漏洞类型 ：如SQL注入、逻辑越权、RCE等。
   • 漏洞URL ：完整的请求地址。
   • 请求参数 ：发生漏洞的请求参数（如 POST 数据、 GET 参数、 Cookie 等）。
   • 复现步骤 ： 这是核心 。像写教程一样，一步一步描述如何复现漏洞。从登录（如需）开始，到触发漏洞的每一步操作、每一次请求。确保任何安全人员都能按照你的步骤100%复现。
     • 格式建议：1. 打开XX页面；2. 进行XX操作；3. 使用Burp Suite拦截请求，修改XX参数为XX；4. 发送请求，观察到XX结果。
5. 漏洞证明 ：
   • 截图/录屏 ：关键步骤的截图，特别是修改参数前后的浏览器界面、Burp Suite的请求响应包。录屏（GIF或MP4）是最直观的证明。
   • 数据证明 ：对于数据泄露漏洞，展示泄露的数据（如数据库名、表名、用户信息，注意打码敏感内容）。对于RCE，执行 whoami 、 id 等命令并展示结果。
6. 漏洞影响 ：阐述该漏洞可能造成的具体危害，如导致用户数据泄露、服务器被控制、资金损失、业务被篡改等。要具体，不要空泛。
7. 修复建议 ：提供切实可行的修复方案。例如：
   • SQL注入：建议使用参数化查询或预编译语句。
   • 越权：在服务端对每次操作进行严格的权限校验。
   • 信息泄露：关闭调试信息，对错误信息进行统一封装。
   • 弱口令：强制实施强密码策略，增加登录失败锁定机制。
8. 时间线 （可选但建议）：提交时间、厂商确认时间、修复时间等。体现专业性。

注意事项 ：在证明漏洞时， 严格遵守法律法规和道德底线 。只获取证明漏洞所必需的最小信息（如证明SQL注入时，查询 version() 或 user() 即可，不要拖取全部用户数据）。切勿进行破坏性测试（如删除数据、篡改首页）。你的目标是帮助厂商提升安全，而非造成损害。

7. 高效工作流与工具链搭建

单打独斗效率低下，一套自动化的工作流能让你事半功倍。下面分享我个人的工具链思路，你可以根据自己的习惯调整。

7.1 自动化侦察流水线

使用 Bash 脚本或 Python 脚本将各个工具串联起来，实现从子域名收集到基础漏洞扫描的半自动化。 一个简单的流水线示例：

#!/bin/bash
# 1. 子域名收集
subfinder -d target.com -o subfinder.txt
assetfinder --subs-only target.com | tee assetfinder.txt
amass enum -passive -d target.com -o amass.txt
# 合并去重
cat subfinder.txt assetfinder.txt amass.txt | sort -u > all_subs.txt

# 2. 解析域名并探测存活
cat all_subs.txt | dnsx -silent -a -resp-only | sort -u > ips.txt
cat all_subs.txt | httpx -silent -title -status-code -tech-detect -o httpx_result.txt

# 3. 从存活URL中提取路径和参数
cat httpx_result.txt | awk '{print $1}' | gau | sort -u > paths.txt
cat paths.txt | grep "=" | qsreplace "FUZZ" > fuzz_params.txt

# 4. 基础漏洞扫描 (需谨慎，控制速率和并发)
cat httpx_result.txt | awk '{print $1}' | nuclei -t ~/nuclei-templates/ -o nuclei_scan.txt -rate-limit 50

这个流水线每天定时跑一次，可以持续监控目标资产的变化和新出现的脆弱点。

7.2 信息管理与协同

• 本地知识库 ：使用 Obsidian 、 Notion 或 OneNote 记录每个目标的资产清单、测试笔记、漏洞思路、已提交报告。建立模板，让记录规范化。
• 协同与分享 ：如果是团队作战，可以搭建一个内部的 Wiki （如 MkDocs ）或使用在线协作文档，共享目标信息、工具字典、漏洞模式（Pattern），避免重复劳动。

7.3 核心工具选型与使用技巧

工欲善其事，必先利其器。以下是我认为在SRC挖掘各阶段最趁手的工具：

最重要的心得 ：工具是辅助，思维是主导。不要成为工具的奴隶。理解每个工具的原理和局限，在适当的场景使用它。真正的高价值漏洞，往往诞生于你对业务逻辑的深刻理解和坚持不懈的手工测试中。保持好奇心，多问“为什么”，你的漏洞挖掘之路才会越走越宽。