大家刚开始打CTF的时候可能都经历过这个阶段好不容易拿下一道Web题或者渗透靶机的入口结果发现自己根本不知道下一步该干什么。网上搜了一堆工具nmap、dirsearch、Burp Suite全都装了对着目标一顿扫结果拿到的信息乱七八糟入口没找着反而把自己搞懵了。我当时也是这么过来的。后来经验多了才明白CTF里的大部分问题都不是工具不够强而是信息收集的思路没建立起来。尤其是Web题、渗透题、综合题信息收集的深度直接决定你能不能找到那个藏在角落的flag。把题目给你第一件事不是急着上扫描器而是先想明白“这台机器上可能有哪几类东西”再根据这个判断决定用什么姿势去收集。这篇分享我打算把CTF里最常见的信息收集套路完整捋一遍包含被动收集、主动扫描、源码泄露利用、敏感文件挖掘这些环节配上自己实战中觉得好用的工具和参数也会讲一些踩过的坑。无论是刚入门的新手还是已经打过几场比赛但效率不高的朋友我觉得多少都能有点收获。1. 信息收集不是“扫描”是建立攻击地图1.1 先想清楚要什么再决定怎么收CTF里的信息收集本质上和现实中去陌生小区找人是一回事。你不会拿着大喇叭满小区乱喊而是会先看看门牌号、观察一下哪几栋楼亮着灯、问下门卫这家住几楼心里有个地图再行动。放到题目里也是这样。你先要搞清楚目标是什么形态是只看一个IP还是要从一个域名开始往深处挖是明文HTTP服务还是HTTPS后面还有一层框架页面本身是一个登录框、一个文件上传点、还是一个目录展示页对方是常见的开源CMS还是纯手写的接口服务这些问题在动手之前就该有一个大致假设。有了假设才能决定用哪一类工具、跑哪一类字典、重点翻哪几个目录。盲目扫描最大的问题是你会得到一大堆结果但根本没有优先级最后把所有时间都浪费在无效信息上。我的习惯是把信息收集分成“先被动、再主动、后利用”三个阶段。被动阶段只看公开信息不直接碰目标主动阶段才开始发请求探测端口和路径利用阶段是把收集到的线索串起来找到真正的漏洞入口。很多新手上来就直接端口扫描加目录爆破等于跳过了被动阶段也跳过了对目标的理解这样效率其实很低。1.2 被动收集与主动收集两条腿走路被动信息收集指的是不与目标系统产生直接交互的情报获取方式。比如查备案信息、Whois、DNS记录、证书透明度日志、网页存档、代码搜索平台等等。这些数据在公网上本来就存在目标并不知道有人在看它隐蔽性很好拿到的东西也往往是主动扫描得不到的。主动信息收集则相反像端口扫描、目录枚举、指纹识别、服务版本探测都是直接向目标发请求然后根据响应来判断对方是什么、开了什么、藏了什么。速度快、信息量大缺点是动静太大容易触发日志告警甚至有防护系统会直接拦掉你的IP。两者怎么配合我通常的做法是先用被动手段把目标的家底摸一遍比如有哪些子域名、哪些端口曾经开放过、用了什么框架、有没有历史遗留的备份文件线索。有了这些铺垫再用主动扫描去验证和补充。顺序反过来的话你可能扫到一半IP被封了结果还没拿到什么有价值的情报那就很被动了。2. 被动信息收集不用碰目标也能拿到的线索2.1 网络测绘与搜索引擎先把目标底牌摸清楚被动收集的第一步我建议先上网络测绘平台。现在互联网上有很多公开的资产测绘平台比如FOFA、Quake这类它们会把全网IP的端口、服务指纹、标题、证书信息都记录下来。你只需要输入目标的IP或者域名就能看到这个目标在公网暴露了哪些服务这比你自己nmap去扫要快得多而且很多情况下不会被目标的防护拦截。用法其实很简单。假设你拿到的目标是example.com你可以直接在测绘平台里搜索域名相关的资产看它绑定了哪些IP、哪些端口。在CTF环境里目标通常是一个独立IP搜索该IP的结果大概率就是这台机器开了哪些服务。这时候你就能发现哦原来这个IP不只开了80端口还有5000端口那5000端口上跑的没准就是一个脆弱的服务这条线索直接决定了你后续主攻方向。我自己在测绘平台上比较喜欢看的字段有三个端口、服务指纹、页面标题。页面标题有时候会直接暴露后台管理系统、测试环境、或者某些客户端的名称这些信息单凭主动扫描不一定会浮出来。搜索引擎也不能忽略。这里说的不只是通用搜索引擎而是针对代码的搜索方式比如GitHub的代码搜索。CTF题目经常有开发者把源码传到公开代码仓库结果没设好权限这种信息一旦搜到等于题目已经白送一半了。搜的时候可以用目标的域名、特殊路径、或者一些代码特征作为关键词。2.2 证书痕迹、网页存档与DNS记录三个容易漏的信息源先说证书透明度日志。如果目标网站启用了HTTPS那么它申请证书的记录都是公开可查的查询这类日志的典型入口是crt.sh输入域名就能列出该域名相关的所有证书申请记录。证书的申请记录里常常包含子域名比如你只知道example.com查出来却发现还有dev.example.com、test.example.com这些子域名那这些子域名各自都可能是一个独立的题目入口。网页存档同样值得翻。存档服务会定期抓取目标网站的快照你可以看到这个网站在过去几个月甚至几年里长什么样。很多开发者在项目上线早期会把测试页面、备份文件、甚至带有密码的配置文件放在公开目录下后来虽然删了或者改了但存档里可能还留着快照。你顺着这些历史URL去访问有可能直接命中一个遗留的漏洞入口。我在比赛中靠这招翻到过不少后台地址原理就是旧版本页面里有指向后台的链接。DNS记录也不能只看A记录。SPF记录、DMARC记录、MX记录这些信息有时候会无意中暴露目标使用的第三方服务商或服务器IP。举个例子如果目标的MX记录指向某个邮件服务器IP而这个IP和主站IP不在同一网段那这台邮件服务器就可能是一个独立的信息系统多一个入口就多一分机会。CTF综合题里这种“域外资产”往往是出题人故意埋的点。2.3 指纹先行判断让后续扫描有的放矢被动收集的最后一环我建议做一次技术栈指纹确认。这一步可以在浏览器的隐身模式里手动访问目标看看响应头里暴露了什么信息比如Server: nginx/1.18.0、X-Powered-By: PHP/7.4、Set-Cookie里的会话名称等。这些头字段会告诉你对方是Nginx还是Apache、语言是PHP还是Java还是Python框架是哪一家的。还有一种更省事的方式就是用浏览器插件比如Wappalyzer访问页面时它会自动帮你识别CMS、框架、JS库、Web服务器等。识别出来的结果可以直接用来网搜这个框架有没有已知漏洞尤其是在目标站点用的是开源CMS的情况下找到版本号基本就等于找到了漏洞库里的目标。指纹信息收集得越准确后续主动扫描的方向就越清晰。如果确定是ThinkPHP就重点找对应版本的RCE利用如果确定是某个Java中间件就去搜它的反序列化漏洞。很多人扫描浪费时间的根本原因就是在没确认指纹的情况下眉毛胡子一把抓。这一阶段做扎实之后你已经相当于把目标的地图画出了一半剩下的就是用主动手段去验证和细化。3. 主动信息收集端口、目录、指纹的实战打法3.1 端口扫描全端口加版本探测别只扫80主动收集轮到端口扫描了。这里我先说一个最常踩的坑很多人习惯直接用nmap默认扫描只扫常用端口列表这就可能漏掉题目故意开的高位端口。CTF的题目环境里服务经常不是只开在80或者443上的。我见过不少题目在8080、8888、5000、60000这类端口上开了后台接口、管理面板、或者另一个业务系统。你要是只扫了默认端口就算目标页面好端端放在5000端口上你也看不见题目直接卡死。所以我的建议是CTF里端口扫描直接用全端口模式nmap -sS -sV -p- --min-rate 2000 目标IP解释一下这几个参数的含义-sSSYN半开扫描快且不容易被应用层日志记录大多数场景下够用。-sV探测端口对应的服务版本信息收集的关键一步拿到版本号才能去匹配漏洞。-p-扫描全部65535个端口别省这一步。--min-rate最低发送速率设为2000是为了快速过一遍端口列表比赛不等人。全端口扫完你会得到一个端口开放列表。这时候别急着高兴把所有跑着HTTP服务的端口都自己在浏览器里打开看一眼。有些端口虽然开着但不是Web服务比如可能是SSH、Redis、MySQL这类服务本身可能就是出题点尤其像Redis未授权这种经典考点端口一开就是送分题。另外扫描结果里显示的端口服务版本如果比较明确可以直接去搜对应版本漏洞比如某个老版本Nginx存在解析漏洞某些版本的OpenSSH有用户名枚举风险。这里要提醒一下扫描只是起点不要寄希望于一次扫描解决所有问题。3.2 目录枚举字典、线程与后缀组合的经验值端口确认了Web服务也开了接下来就是翻目录。目录枚举这一步工具我比较常用的是dirsearch和gobuster。dirsearch胜在开箱即用自带字典比较全你只要给定URL就能开始跑gobuster则更灵活支持各种模式的暴力破解适合自己控制字典和线程。ffuf我也用过尤其适合做参数和接口的模糊测试灵活性和性能都很不错但对字典的要求也更高。这里单独说一下线程参数。很多人觉得线程开得越大越快真实情况是大线程很容易触发服务器的并发限制或者直接被WAF拦下来。常见做法是控制在20到50之间如果目标明显反应变慢或者开始返回429状态码马上降速。后缀枚举也是关键。拿dirsearch举例你可以指定多个扩展名比如同时找.php、.html、.bak、.zip、.sql、.txt、.swpdirsearch -u http://目标IP -e php,html,bak,zip,sql,txt,swp -t 30CTF里目录扫描最值钱的命中也集中在备份文件、源码文件、敏感配置文件这几类上。z压缩包、sql数据库备份、swp编辑器交换文件任意命中一个都可能是一整个源码泄露的入口。所以我通常不满足于默认字典跑一轮跑完默认字典之后还会再用自己的CTF专项字典补一轮重点找admin、backup、test、upload、flag、login这些关键词路径。3.3 指纹识别确认拿到框架版本就成功一半目录扫描的同时我一般会顺手做一次更细的指纹确认。这一步不是简单看返回头而是去访问几个框架特有的路径。如果你的扫描结果里出现了/wp-login.php那基本能确定是WordPress接下来就去查这个WordPress版本的已知漏洞。如果页面里出现了/ThinkPHP特有的报错页面、或者在/index.php后面加特定参数能触发异常输出那很可能就是ThinkPHP站赶紧翻漏洞库找对应版本的RCE链。很多开源CMS、开源商城系统它们的登录后台路径、API接口路径、甚至安装残留文件都是固定不变的。这些路径本身就是最好的指纹来源。访问一下/administrator、/manager、/console、/api这类常见路径看返回状态码和页面内容就能帮你把目标的身份彻底坐实。指纹确认完之后关于这个目标“是什么、跑在哪、有没有漏”这三个问题你已经有很明确的答案了。接下来做的所有利用尝试都会在这张信息地图上按图索骥不会再对着空气开枪。4. 源码泄露与敏感文件最容易翻出分的地方4.1 .git、.svn与备份文件开发者的“后门”目录扫描命中了一堆高价值文件之后真正的重头戏开始了。CTF里最经常出现的几类源码泄露我挨个说。首先是.git泄露。原理其实很简单开发者用Git管理代码时项目根目录下会生成一个.git目录里面保存着每一次提交的完整记录和文件快照。运维如果直接把项目目录发布到Web服务器上而忘了限制.git目录的访问那任何能上网的人都可以通过访问http://目标/.git/把整个代码仓库历史扒下来。我见过不少新手直接访问/.git/config发现能读到内容然后就开始手工下载结果下载半天不知道下一步怎么办。正确做法是用现成的工具比如GitHack这类它会自动解析.git/目录的索引把能恢复的文件全部拉下来然后你在本地就能看到完整的项目源码。python githack.py http://目标/.git/跑完之后你本地就会多出一个项目目录。接下来就舒服了直接去看配置文件的数据库账号密码、看源码里有没有注释掉的密钥、看路由文件里有没有隐藏接口。很多时候flag根本不在漏洞利用里而是直接写死在源码的某个文件里这种题就是纯考信息收集。其次是.svn泄露原理类似。SVN在项目目录下会留下.svn目录里面保存了版本信息和部分文件文本旧版本SVN甚至可以直接通过.svn/entries文件读取目录下的文件列表。虽然现在用SVN的项目少了但挨打的老系统里偶尔还能碰上。还有一类更粗暴的就是备份文件泄露。开发者在更新代码前总喜欢打包一份比如www.zip、backup.zip、site.tar.gz、index.php.bak打包完放到服务器上忘删了。这种文件一旦被目录扫描器命中直接下载解压就是整个网站源码。所以我的字典里这类后缀和文件名是重点照顾对象。4.2 页面源码、JS文件与注释细节里藏考点除了这些文件层面的泄露还有很多信息根本不需要工具就在页面上摆着只看你翻不翻。我拿到一个Web入口第一件事就是看页面源码而且是逐行看。右键查看源码重点不是看那堆渲染出来的HTML而是看注释。很多开发者会在代码里留类似!-- TODO: 修改后台链接 --、!-- admin path: /hidden_admin --这种话。看起来是无心之举在题目里往往就是出题人故意埋的路标。JS文件也值得翻。现代站点基本都放了大量JS这些文件里经常会写着/api/user/info、/api/upload这类接口地址。用浏览器的开发者工具打开页面切到Sources标签页把所有JS文件拉出来过一遍。如果你会编程可以直接写脚本批量抓取页面里链接到的所有JS文件再用正则搜/api/、token、password这些关键词。CTF里有些后台接口就是这样被发现的直接访问甚至可能绕过前端校验。另外前端调试时经常会有一些隐藏的调试接口或者测试账号实体展示在页面的某个角落。比如按钮的href指向一个支付跳转地址、某个表单的action指向一个管理后台、某个静态资源路径里出现了疑似内网IP的地址。这些都要记录到笔记里后面整合利用时很可能用到。4.3 杂项文件检查robots.txt、DS_Store与错误页面最后说几个单独要检查的小文件这些东西不花多少时间但经常能有意外收获。robots.txt算是Web信息收集的必修课。虽然对方写了Disallow不意味着真的不许爬但它能直接告诉你站点里有哪些目录是管理员不想让搜索引擎看到的。CTF出题人经常会把后台路径、上传目录、隐藏接口写在robots.txt里等你发现。所以目录枚举第一波我基本会先看一眼/robots.txt。DS_Store则更冷门一点它是macOS在文件夹里自动生成的文件里面记录了该目录下的文件名列表。如果一个公开目录里有DS_Store且可以被访问你就能用工具把它解析出来把目录里的所有文件名读出来。以前有专门工具干这事逻辑也不复杂本质就是解析二进制格式然后输出文件名。CTF里出现过不少目标站根目录留DS_Store一解析直接看到一堆源码文件名的情况。错误页面也有信息量。故意访问一个不存在的路径看404页面上有没有暴露脚本路径、物理路径、框架版本号。再试着访问一些会触发异常的输入比如给动态参数传一个数组或者非法字符如果站点开启了调试模式报错页可能会直接打印完整堆栈里面写着代码路径、数据库查询语句、服务器操作系统这些细节都是下一阶段利用的信息燃料。5. 常见问题与排查技巧实录5.1 漏服务比慢服务更致命扫描完整性端口扫描这块我踩过一个很大的坑。之前有一道题拿过来nmap默认参数扫了一圈只有80端口开着于是我在80上翻来覆去搞了很久什么线索都没有。最后别人提醒我这个题目服务的实际入口在一个高位端口上我不信邪地把那个IP的65535个端口全扫了一遍发现果然在40000多端口上开着一个表单页面。问题的根源就在于默认端口列表太短了。nmap不加-p-的情况下默认只会扫它内置的热门端口清单可能只有一千来个。CTF题目为了让选手多走一步经常会把服务挂在高位端口上。所以现在我的流程里只要环境允许一定先跑一次全端口扫描哪怕速度慢一点也不给漏服务留机会。补充一句如果全端口扫描在比赛环境里实在慢得受不了可以分两步先快速扫常见端口比如-p 1-10000同时开一个后台全端口扫描任务慢慢跑。这样既能先上手处理已知服务又不会漏掉高位端口。5.2 结果要动手验证误报比空结果更坑目录扫描的误报问题也值得单独说一下。有些服务器配置了统一错误页面所有不存在的路径都会返回200状态码同时输出同一个页面内容。这种情况下扫描器会疯狂报结果几十个路径全是“200”但访问之后发现内容完全一样全是无用信息。怎么验证很简单随便找一个肯定不存在的路径比如/this_path_does_not_exist_12345看它返回的状态码和内容。如果不存在的路径也返回200且内容与“命中”的路径一致那这批结果全是误报直接作废。反过来如果某条命中的路径返回200而错误路径返回404那这条结果才值得进一步调查。遇到全站200的情况就应该调整策略不要再依赖目录扫描找路径而是转换思路去看参数、接口、POST行为或者直接尝试访问框架特有的路径因为这些路径即便返回相同状态码也可能有独立的处理逻辑。另一个常见问题是“访问目录显示403但文件名存在”。403不一定证明“存在且不能访问”也可能只是Web服务器对该目录的访问配置了禁止列表但目录下具体某个文件仍然可以直接读取。碰到这种情况我会对目录下的文件名做一次批量试探比如手动构造常见的备份文件名逐个尝试不少题目的隐藏入口就是这么试出来的。5.3 字典选不好等于白扫沉淀自己的工具集字典真的是信息收集的核心资产。工具是通用的你的字典决定了你能扫出什么。内置字典在真实渗透里可能够用但在CTF里往往不够针对。我现在的做法是维护一个自己的CTF字典大概几百条全都是过往比赛里考过的路径关键词admin、backup、flag、upload、download、api、console、test、tmp、logs、phpmyadmin、editor等等。每次跑完大赛之后我会把比赛中命中的路径整理下来沉淀进字典里。这个习惯坚持下来再遇到新题时命中率会越来越高。工具集也是同理。不要到比赛现场才去下载各种脚本提前把常用的信息收集工具都准备到一个干净的目录里包括端口扫描、目录扫描、git泄露恢复、DS_Store解析、指纹识别这类工具。我的个人习惯是分类放好用的时候直接按需调用。比赛期间最怕的不是工具不够而是临时找工具、装依赖时间就这么白白流走了。再有一个经验是信息收集的每一步都要留笔记。别太相信自己的记忆力扫描结果、可疑路径、已经试过的思路、还没验证的线索都用文档按时间顺序记下来。一道综合题的信息量足够大如果没有记录过半小时你很可能忘了某个端口上还有一个未验证的服务或者某个目录已经尝试过但还没深入。我自己打CTF的体会是信息收集这个环节比的从来不是谁工具多而是谁更细、更有条理。被动信息、主动扫描、源码挖掘这三个层面紧密结合几乎可以解决百分之八十的常规题目。哪怕是一些看起来需要硬核利用的题目入口往往也是从信息收集阶段的一个不起眼线索串起来的。把这套流程练熟在比赛里你会明显感觉自己不再是无头苍蝇而是一个手里有地图的人。