做信息收集这件事我前前后后踩了不少坑。早期拿到一个目标多半只知道用浏览器打开首页最多ping一下域名随后就开始“猜路径、试后台”结果经常是打了半天才发现真正有价值的服务根本没暴露在常见端口上或者源站在CDN后面所有请求都打在了缓存节点上。后来我养成了固定的六步收集习惯子域名、端口、指纹、目录、源码泄露、人员信息一步不跳先把资产地图画出来再谈后续测试。这篇文章适合两类人看一类是刚接触授权测试、想系统搞懂“怎么把一个目标由点及面地摸透”的新人另一类是已经有测试经验、但信息收集还停留在“一条命令梭哈”阶段的工程师。我会把每个环节的工具选型、命令参数、判断逻辑和避坑经验都交代清楚所有操作都基于授权范围内的常规测试场景。1. 整体思路六步工作流先搭起来1.1 为什么按这个顺序做信息收集最怕的不是慢而是漏。漏掉一个子域名可能就漏掉一个管理后台漏掉一个端口可能就漏掉一个未授权访问的数据库。所以顺序非常重要我自己固定的顺序是先扩面、再摸服务、后翻代码、最后关联人。先收集子域名是因为一个主域名背后往往挂着多个系统这些系统的安全水位参差不齐。主站做了层层防护但某个测试子域可能直接裸奔先通过子域名把资产面铺开后面的端口扫描才有意义。接着做端口扫描确认哪些主机开了哪些服务再针对服务做指纹识别搞清楚对面是Nginx还是IIS、是Tomcat还是WebLogic这样目录扫描时才知道该带什么字典、该关注哪些漏洞类型。目录扫描和源码泄露排查属于“翻家底”的阶段找后台入口、备份文件、代码仓库、配置文件。最后才做人员信息收集把域名、IP、邮箱、姓名关联起来形成一张完整的情报网方便后续的账号口令梳理和社工风险自查。1.2 前期准备域名绑定、字典和记录管理开工之前先把三件事准备好第一把目标的域名解析关系理清楚。如果目标站点走了CDN先不要急着对域名开扫优先找源站IP。常规做法是通过历史DNS记录、邮件头信息、子站长CNAME记录去定位真实IP一旦确认源站就在本地hosts里把域名绑定到源站IP。这样后续访问时不会频繁命中CDN缓存看到的指纹和路径才是真实状态。第二准备好字典。子域名爆破有子域名字典目录扫描有目录字典人员信息收集有用户名规则字典。字典不需要一开始就追求大而全先准备一份覆盖常见命名规则的通用字典后面根据指纹识别结果再定向扩充。我自己习惯把字典按场景分开存比如/dics/subdomain.txt、/dics/dir_common.txt、/dics/dir_php.txt、/dics/users_cn.txt避免临时抱佛脚。第三建立一个简单的记录模板。每发现一个资产就追加一行内容包括时间、来源哪个子域名/IP、端口、服务、指纹信息、状态码、备注。我常用Markdown表格或纯文本存关键是可回溯。信息收集经常会做第二遍对比前后结果时你会感谢当时记得够细。2. 子域名收集把入口先摸清楚2.1 被动收集证书透明度和测绘平台子域名收集分两个流派被动收集和主动爆破。被动收集不直接与目标产生流量靠第三方数据源拼出子域名清单优点是安静、不容易触发告警缺点是可能会有遗漏。最常用的被动数据源是证书透明度日志。证书颁发机构会把签发的SSL证书公开到日志里证书中常包含大量域名信息。查询crt.sh可以直接用curl接口拉JSONcurl -s https://crt.sh/?q%25.example.comoutputjson | jq -r .[].name_value | sed s/\*\.//g | sort -u这样拿到的子域名数量往往会让你意外。除此之外DNS历史记录查询平台、搜索引擎语法site:example.com、GitHub代码搜索example.com也属于被动收集。网络空间测绘平台同样很好用直接搜索domainexample.com能一次性看到子域名、IP、标题、开放端口算是被动收集和端口扫描的结合体。2.2 主动爆破Layer子域名挖掘机与字典选择被动收集之后再做一轮主动爆破把未出现在证书和搜索引擎里的内部命名子域挖出来。工具上我常用Layer子域名挖掘机为主力这个工具虽然界面老但胜在操作直接、线程可控、结果清晰适合日常中小规模目标。导入主域名配置好线程和字典点击开始就能批量解析结果里会标注解析IP有的版本还会直接标出CDN。字典选择直接影响效果。第一轮用通用子域名字典例如www、mail、ftp、oa、vpn、api、dev、test、demo、admin、portal、git、jenkins、jira、wiki这类高频词第二轮可以结合目标公司的业务词、产品名做定制扩展。刷完字典后把解析成功的域名统一做一次解析验证剔除无效记录。常见的一个坑是泛解析。很多域名把不存在的子域名也解析到同一个IP导致爆破结果全是“有效”。我通常先随机生成一个肯定不存在的子域名解析一下如果它也能解析出IP说明存在泛解析后续结果里要把指向相同IP的域名批量过滤掉只看解析IP有差异的记录。2.3 真实IP定位与泛解析过滤子域名收集完成后紧接着要做的不是立即开扫而是把每一个有效子域名解析到IP并判断哪些IP是源站、哪些是CDN节点。定位源站的方法很多最常用的是历史DNS记录查目标域名一年内的A记录变化往往能翻出没套CDN时期的真实IP其次是发一封邮件到目标域名邮箱查看原始邮件头里Received: from后面的IP很多企业邮箱会暴露源站出口段还有一种思路是遍历所有子域名有些子域名没有挂CDN直接解析到源站对应的C段再通过C段扫描反推主站位置。定位到源站IP后在本地hosts里做绑定然后通过curl -H Host: www.example.com http://源站IP验证是否访问到真实站点。这个步骤做扎实了后续的端口、指纹、目录探测才会建立在真实资产上不会对着Cloudflare节点空打。3. 端口扫描与服务探测把所有门都敲一遍3.1 端口扫描常用命令与输出管理端口扫描我以Nmap为主Masscan为辅。Nmap的常用命令要背熟# TCP全端口扫描带服务版本识别和系统识别结果输出到三种格式 nmap -sS -sV -O -T4 -p- -oA target_full target_ip # 如果全端口太慢先用masscan快速摸一遍 masscan -p1-65535 --rate1000 -oG masscan_output.txt target_ip # 拿到开放端口后再用nmap针对端口做服务版本确认 nmap -sV -sC -p22,80,443,3306,6379 target_ip # UDP重点端口扫描 nmap -sU --top-ports 100 -sV target_ip端口扫描不是“跑一条命令等结果”这么简单。TCP全端口扫描在带宽受限或者目标有一定防护的情况下容易超时所以我一般先用Masscan以较高速率把所有TCP端口摸一遍再把开放端口交给Nmap做详细服务识别。这样既节省时间又能拿到比较准确的服务版本信息。输出管理同样重要。每次扫描都要加-oA参数把结果同时保存为文本、XML和gnmap格式后续做资产汇总和报告时可以直接复用。3.2 常见端口与服务对应清单端口扫描的难点不在于发现端口而在于判断端口背后是什么服务。我把平时遇到的高频端口整理成了一张清单方便对照端口常见服务说明21FTP匿名登录检测是常规项目22SSH注意版本和弱口令策略23Telnet明文协议嗅探风险高25SMTP邮件服务可测用户枚举53DNS域名解析注意区域传送80 / 443HTTP/HTTPSWeb服务信息收集主战场110 / 143POP3 / IMAP邮件收发端口常见于邮件子域445SMBWindows文件共享注意永恒之蓝类风险3306MySQL数据库服务注意弱口令和未授权3389RDPWindows远程桌面5432PostgreSQL数据库服务6379Redis高危端口未授权访问频发8080 / 8443HTTP代理 / HTTPS备用常部署管理后台、API服务、监控面板9200Elasticsearch未授权访问检测5000MLflow等Python服务需要结合指纹确认不少数据科学平台默认在此16010 / 16020HBase Web UI / RegionServer若扫到HBase相关端口结合官方端口清单快速对照25734Solid Network License部分工业软件授权服务的默认端口偏门但真实存在这张表不是让你背而是提醒你端口只能说明“门开着”服务是什么必须结合指纹。比如5000端口可能是Flask开发服务器也可能是MLflow管理界面25734这种端口如果不结合服务指纹扫到也容易忽略。所以端口扫描的结果一定要跟下一阶段的指纹识别联动。3.3 端口开放背后的配置问题防火墙与端口占用做信息收集时经常绕不开两类端口问题一是目标防火墙规则限制了扫描二是本地测试环境端口被占导致工具起不来。先说目标侧。很多系统默认只对特定网段开放端口比如数据库3306只允许内网192.168.1.0/24访问你在外网扫永远看不到这个端口。这种场景下如果拿到了内网权限再回头看往往能发现大量额外暴露面。反过来如果自己部署测试环境想让指定网段访问某个端口Linux上的常用做法是放行白名单。以3306端口为例CentOS 7以上用firewalldfirewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.0/24 port port3306 protocoltcp accept firewall-cmd --reload如果习惯用iptables等价命令是iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 3306 -j ACCEPT service iptables save再说本地侧。端口被占是测试中很常见的现象比如启动Web服务时发现8080被占用报错信息含糊。排查命令很简单# Linux netstat -tlnp | grep 8080 ss -lntp | grep 8080 lsof -i:8080 # Windows netstat -ano | findstr 8080 tasklist | findstr PID找到占用端口的进程后按需停止或调整自己服务的监听端口。端口情况清楚了后续起工具、部署测试环境才不会被这些基础问题卡住。4. 指纹识别搞清楚对面是谁4.1 手工指纹识别先看响应头再翻页面指纹识别是承上启下的关键环节。上一步知道了端口是开放的这一步要确认端口背后跑的是什么程序、什么版本、什么框架。识别结果决定了下一步目录扫描该带什么字典、模糊测试该关注哪些已知漏洞。手工识别是基本功。拿到一个Web服务我一般是这么操作先看响应头。curl -I看一眼返回的Server字段和X-Powered-By字段。Server: nginx/1.18.0直接说明Web服务器X-Powered-By: PHP/7.4说明后端语言Set-Cookie字段也很有价值PHPSESSID、JSESSIONID、rememberMedeleteMe分别指向PHP、Java、Shiro框架。再看页面特征。很多CMS会在HTML里输出generator标签比如WordPress、Z-Blog、帝国CMS都有明显的meta标记。静态资源路径也是线索/wp-content/是WordPress/wp-includes/同样/Public/、/Application/多指向ThinkPHPfavicon.ico的MD5值也能用于识别很多测绘平台就是靠这个匹配指纹。最后看错误页。故意访问一个不存在的路径观察404页面样式Tomcat的404页有一张特定的猫图Nginx的404页字体和布局也有特点IIS的错误页在旧版本中特征非常明显。错误页往往能直接暴露中间件类型和版本范围。4.2 指纹识别工具与指纹库联动手工识别效率低批量场景要靠工具。我常用的组合是WhatWeb做单体网站深度识别Wappalyzer浏览器插件做交互式分析Ehole棱洞做批量资产指纹识别。# 单个目标详细识别 whatweb -v https://target.example.com # 批量识别结果输出JSON ehole -l targets.txt -json output.json识别到具体指纹后要立刻把它跟已知漏洞库关联。比如识别到目标是ThinkPHP那么根据具体版本去查历史RCE漏洞识别到Spring Boot可以直接探测/actuator、/env、/heapdump等Actuator端点识别到旧版Struts2那就往OGNL表达式注入方向看。指纹越精确后续测试的命中率越高。工具识别有误报的可能尤其是中间件套了一层产品的情况。比如常见的企业网关是nginx前面再套一层OpenResty或者Kong直接看响应头会被误导。我的习惯是工具结果只做参考最终以手工确认的响应头、页面路径和文件指纹交叉验证为准。4.3 容易混淆的概念网站指纹与指纹浏览器聊指纹识别这件事经常有人把“网站指纹识别”和“指纹浏览器”搞混。前者是识别目标网站的技术栈、服务器类型属于信息收集的一部分后者则是模拟浏览器指纹来做多账号防关联的工具比如生成不同的Canvas、WebGL、User-Agent等浏览器特征用途完全相反。如果你在搜索资料时看到“指纹浏览器开发”“指纹浏览器推荐”这类内容先想清楚自己的场景避免被带偏。本文说的指纹识别始终是站在“识别对方服务”的角度。5. 目录扫描与源码泄露排查找后门和仓库5.1 目录扫描工具与参数设置目录扫描的目标是发现后台入口、备份压缩包、敏感配置文件、接口文档、代码仓库。我首选dirsearch原因是字典组织清晰、状态码过滤方便、支持递归。常用命令python3 dirsearch.py -u https://target.example.com \ -e php,html,txt,zip,bak,sql \ -x 404,403 \ --random-agent \ -t 20 \ -r --max-recursion2 \ -o result.txt参数说明-e指定常见扩展名-x排除无意义的404和403响应403有时候有意义多半是先排除再用全量结果人工复核--random-agent是避免默认UA被WAF拦截-t控制线程-r开启递归扫描--max-recursion2限制目录深度。这里特别说下“目录深度”这个参数。很多人以为扫描递归越深越好实际上深目录里大量是静态资源、日志文件、前端JS对信息收集帮助有限还会拉慢速度、增加被拦截的概率。我的经验是默认扫两层即可后续根据指纹识别结果定向深入比如发现是ThinkPHP框架再针对/Application/、/Runtime/这类框架目录做深扫。图形化工具方面御剑目录扫描依然是很多人的首选适合本地快速跑一轮。它自带的字典覆盖面不错线程调节也方便缺点是缺少细粒度的状态码过滤扫描结果需要人工筛掉一批无用记录。我的习惯是御剑先跑一轮快速摸底再用dirsearch跑一轮定向补充。5.2 源码泄露的常见形态目录扫描过程中源码泄露往往会在不经意间跳出来。常见的泄露形态有这么几类第一类是版本控制工具目录泄露。.git目录泄露排在首位一旦.git目录可以被访问整个历史源码都有可能被扒走。.svn目录也有类似问题老项目中比较常见。第二类是开发工具留下的元文件。.DS_Store文件泄露后通过专门的解析工具能还原出目录结构和文件名顺藤摸瓜找到更多敏感文件。.idea/workspace.xml、.vscode/sftp.json这类IDE配置文件里经常出现服务器连接信息、账号密码。第三类是备份文件。运维常用压缩包备份网站代码文件名常见www.zip、site.zip、web.zip、backup.tar.gz、db.sql目录扫描时加上zip,tar,gz,sql,bak这些扩展名就能覆盖到。index.php.bak这类编辑器备份文件也很常见轻则泄露源码重则直接把配置一起带出来。第四类是敏感配置文件。.env文件在不少现代框架中存放数据库账号、密钥、第三方API Key一旦能直接访问后续测试就顺畅很多。config.php.bak、web.config、application.yml、settings.py也是重点关注对象。看到这些文件先判权限再判内容有些只是目录列表开了文件本身不可读有些则直接明文暴露。判断标准是访问状态码和响应内容200且包含源码特征才算有效泄露。5.3 Git目录泄露的完整利用Git目录泄露是很典型的问题单独拿出来讲一下。首先是确认是否存在泄露curl -s https://target.example.com/.git/config如果返回内容包含[core]段比如repositoryformatversion、[remote origin]这些字段基本可以确认.git目录可访问。接下来下载源码我常用的工具有两个git-dumper和GitHack。git-dumper更适合恢复完整仓库git-dumper https://target.example.com/.git ./repo它会根据index文件把工作目录里的文件恢复到本地完成后等于拿到了源码副本。GitHack的优势在于轻量适合快速恢复指定文件但完整度通常不如git-dumper。如果下载过程中对象不完整可能出现文件缺失的情况。这时候试着在目标站点访问/.git/logs/HEAD看能不能读到commit记录根据commit哈希再尝试拉取objects。实操中有些目标只开放了部分.git路径的访问就要灵活判断哪些对象拉得到、哪些拉不到。源码拿到手之后重点看这么几类内容数据库配置、加密密钥、内部API地址、后台逻辑代码、敏感接口。这些内容既能用来做漏洞挖掘也能反过来帮助企业自查代码仓库是否对公网开放。6. 人员信息收集与资产整理把人和资产关联起来6.1 人员信息从哪里找人员信息收集是很多测试报告里容易忽略的一块但它对风险评估和口令管理很有价值。这里只讨论公开渠道信息且所有用途都限定在授权范围内。常规来源有WHOIS信息查域名注册人姓名和邮箱ICP备案查企业主体信息企业官网和新闻稿里常见的员工职务与联系方式。更深入一些可以在GitHub和码云上搜目标企业域名和用户名很多人喜欢在公开仓库里提交代码git log里的提交邮箱经常暴露企业内部邮箱格式和员工真实姓名。招聘平台也很值得翻。公司的JD会写自己用什么技术栈、有没有内部OA、CRM系统叫什么名字这些信息能帮你快速拼出目标的技术画像。历史漏洞报告平台和企业安全公告则是了解目标系统构成、历史漏洞的快捷渠道补天、漏洞盒子上的公开报告能提供不少线索。邮箱格式确认后可以通过SMTP VRFY或正常的注册找回流程做存在性验证这类操作要特别谨慎必须在授权范围内并且不要并发大量探测否则容易被判为异常流量。6.2 从人员信息到口令字典的落地人员信息收集的核心价值之一是生成企业自检用的弱口令字典。掌握员工的姓名拼音、生日、手机尾号后可以组合出常见弱口令规则比如zhangsan、zhangsan123、zs123456、ZhangSan2024、zs123、zhangsan2024等。做这一步的目的是帮助企业自查弱口令风险而不是鼓励爆破。现实里很多系统已经强制多因素认证弱口令爆破的空间越来越小但账号信息泄露导致的撞库风险依然是企业面临的主要威胁之一。把人员信息和资产关联起来重点在于判断哪些员工在哪些系统有权限以及这些账号的凭证管理是否规范。6.3 信息汇总与报告输出信息收集的最后一步是汇总。我的输出模板大概长这样资产类型名称IP / 域名端口 / 服务指纹信息关键发现风险等级域名example.com1.2.3.480/443 NginxThinkPHP 5.1.git目录泄露、后台路径暴露高子域名git.example.com5.6.7.822 SSH/443 HTTPSGitea 1.18存在公开注册入口中报告不要求漂亮但要求完整。每一项发现都要注明来源和验证方式哪个工具扫出来的、响应码多少、有没有截图。后续复测或者漏报追查时这份记录就是最可靠的依据。7. 常见问题与排查技巧实录7.1 高频问题速查表信息收集环节的坑很多我整理了一份高频问题速查表基本都是实操中反复遇到的现象可能原因处理办法Nmap扫不到任何端口目标防火墙封禁了扫描来源、禁ping、端口过滤换TCP连接扫描-sT或从不同网络位置重试确认目标是否存活全端口扫描太慢网络带宽、目标防火墙丢包先用Masscan快速摸再用Nmap针对开放端口细扫目录扫描全是403源IP被封、默认UA被WAF拦截换出口IP、加--random-agent、降线程、加延时目录扫描结果大量301站点做了统一跳转看Location字段判断是否登录跳转必要时关闭跟随重定向子域名爆破结果全是同一个IP域名存在泛解析随机不存在的子域名做对照过滤掉泛解析IP.git目录能访问但下载失败服务器对某些对象路径做了限制用git-dumper重试结合logs/HEAD补拉关键对象系统提示端口被占本地软件已监听该端口netstat -ano或ss -lntp查占用进程按需停用指纹识别结果前后矛盾响应头被网关改写、指纹库老化结合HTML特征、favicon哈希、错误页交叉验证扫描一段时间后目标无响应WAF触发封禁策略降低并发、增加随机延时、分批分时段扫描7.2 我的几条实操心得最后聊几条我这些年沉淀下来的经验。第一扫描记录一定要留痕。每次跑完Nmap、dirsearch都把原始输出和筛选结果保留下来命名带上时间戳。信息收集往往不是一次性的后面前期结论被推翻时历史记录能帮你快速定位是哪一步判断出了问题。第二小字典优先。子域名爆破、目录扫描都一样先用高频小字典跑一遍拿到基础资产后再用大字典补充。一上来就全量字典不仅慢还容易触发封禁反而影响效率。第三指纹和目录要联动。没有指纹依据就盲目跑全量目录等于拿散弹枪打鸟。识别出具体框架后手里要有一套“框架默认目录和默认文件清单”比如ThinkPHP的/Runtime、Spring Boot的/actuator、WordPress的/wp-admin这些都是高价值命中点。第四所有动作都要有授权边界。信息收集的很多技术本身是中性的但必须在合法的授权测试框架内使用。收集中发现企业公开了不该公开的源码、密钥、内部信息正确的做法是记录下来并写进报告而不是继续深入利用。我自己的习惯是不管项目大小信息收集都不会跳过任何一步。子域名和端口解决“有什么”指纹解决“是什么”目录和源码泄露解决“能拿到什么”人员信息解决“能关联到什么”。这四层做扎实后续的测试就会顺畅得多。系统性的信息收集其实是整个授权测试过程中投入产出比最高的一环。
做信息收集这件事我前前后后踩了不少坑。早期拿到一个目标多半只知道用浏览器打开首页最多ping一下域名随后就开始“猜路径、试后台”结果经常是打了半天才发现真正有价值的服务根本没暴露在常见端口上或者源站在CDN后面所有请求都打在了缓存节点上。后来我养成了固定的六步收集习惯子域名、端口、指纹、目录、源码泄露、人员信息一步不跳先把资产地图画出来再谈后续测试。这篇文章适合两类人看一类是刚接触授权测试、想系统搞懂“怎么把一个目标由点及面地摸透”的新人另一类是已经有测试经验、但信息收集还停留在“一条命令梭哈”阶段的工程师。我会把每个环节的工具选型、命令参数、判断逻辑和避坑经验都交代清楚所有操作都基于授权范围内的常规测试场景。1. 整体思路六步工作流先搭起来1.1 为什么按这个顺序做信息收集最怕的不是慢而是漏。漏掉一个子域名可能就漏掉一个管理后台漏掉一个端口可能就漏掉一个未授权访问的数据库。所以顺序非常重要我自己固定的顺序是先扩面、再摸服务、后翻代码、最后关联人。先收集子域名是因为一个主域名背后往往挂着多个系统这些系统的安全水位参差不齐。主站做了层层防护但某个测试子域可能直接裸奔先通过子域名把资产面铺开后面的端口扫描才有意义。接着做端口扫描确认哪些主机开了哪些服务再针对服务做指纹识别搞清楚对面是Nginx还是IIS、是Tomcat还是WebLogic这样目录扫描时才知道该带什么字典、该关注哪些漏洞类型。目录扫描和源码泄露排查属于“翻家底”的阶段找后台入口、备份文件、代码仓库、配置文件。最后才做人员信息收集把域名、IP、邮箱、姓名关联起来形成一张完整的情报网方便后续的账号口令梳理和社工风险自查。1.2 前期准备域名绑定、字典和记录管理开工之前先把三件事准备好第一把目标的域名解析关系理清楚。如果目标站点走了CDN先不要急着对域名开扫优先找源站IP。常规做法是通过历史DNS记录、邮件头信息、子站长CNAME记录去定位真实IP一旦确认源站就在本地hosts里把域名绑定到源站IP。这样后续访问时不会频繁命中CDN缓存看到的指纹和路径才是真实状态。第二准备好字典。子域名爆破有子域名字典目录扫描有目录字典人员信息收集有用户名规则字典。字典不需要一开始就追求大而全先准备一份覆盖常见命名规则的通用字典后面根据指纹识别结果再定向扩充。我自己习惯把字典按场景分开存比如/dics/subdomain.txt、/dics/dir_common.txt、/dics/dir_php.txt、/dics/users_cn.txt避免临时抱佛脚。第三建立一个简单的记录模板。每发现一个资产就追加一行内容包括时间、来源哪个子域名/IP、端口、服务、指纹信息、状态码、备注。我常用Markdown表格或纯文本存关键是可回溯。信息收集经常会做第二遍对比前后结果时你会感谢当时记得够细。2. 子域名收集把入口先摸清楚2.1 被动收集证书透明度和测绘平台子域名收集分两个流派被动收集和主动爆破。被动收集不直接与目标产生流量靠第三方数据源拼出子域名清单优点是安静、不容易触发告警缺点是可能会有遗漏。最常用的被动数据源是证书透明度日志。证书颁发机构会把签发的SSL证书公开到日志里证书中常包含大量域名信息。查询crt.sh可以直接用curl接口拉JSONcurl -s https://crt.sh/?q%25.example.comoutputjson | jq -r .[].name_value | sed s/\*\.//g | sort -u这样拿到的子域名数量往往会让你意外。除此之外DNS历史记录查询平台、搜索引擎语法site:example.com、GitHub代码搜索example.com也属于被动收集。网络空间测绘平台同样很好用直接搜索domainexample.com能一次性看到子域名、IP、标题、开放端口算是被动收集和端口扫描的结合体。2.2 主动爆破Layer子域名挖掘机与字典选择被动收集之后再做一轮主动爆破把未出现在证书和搜索引擎里的内部命名子域挖出来。工具上我常用Layer子域名挖掘机为主力这个工具虽然界面老但胜在操作直接、线程可控、结果清晰适合日常中小规模目标。导入主域名配置好线程和字典点击开始就能批量解析结果里会标注解析IP有的版本还会直接标出CDN。字典选择直接影响效果。第一轮用通用子域名字典例如www、mail、ftp、oa、vpn、api、dev、test、demo、admin、portal、git、jenkins、jira、wiki这类高频词第二轮可以结合目标公司的业务词、产品名做定制扩展。刷完字典后把解析成功的域名统一做一次解析验证剔除无效记录。常见的一个坑是泛解析。很多域名把不存在的子域名也解析到同一个IP导致爆破结果全是“有效”。我通常先随机生成一个肯定不存在的子域名解析一下如果它也能解析出IP说明存在泛解析后续结果里要把指向相同IP的域名批量过滤掉只看解析IP有差异的记录。2.3 真实IP定位与泛解析过滤子域名收集完成后紧接着要做的不是立即开扫而是把每一个有效子域名解析到IP并判断哪些IP是源站、哪些是CDN节点。定位源站的方法很多最常用的是历史DNS记录查目标域名一年内的A记录变化往往能翻出没套CDN时期的真实IP其次是发一封邮件到目标域名邮箱查看原始邮件头里Received: from后面的IP很多企业邮箱会暴露源站出口段还有一种思路是遍历所有子域名有些子域名没有挂CDN直接解析到源站对应的C段再通过C段扫描反推主站位置。定位到源站IP后在本地hosts里做绑定然后通过curl -H Host: www.example.com http://源站IP验证是否访问到真实站点。这个步骤做扎实了后续的端口、指纹、目录探测才会建立在真实资产上不会对着Cloudflare节点空打。3. 端口扫描与服务探测把所有门都敲一遍3.1 端口扫描常用命令与输出管理端口扫描我以Nmap为主Masscan为辅。Nmap的常用命令要背熟# TCP全端口扫描带服务版本识别和系统识别结果输出到三种格式 nmap -sS -sV -O -T4 -p- -oA target_full target_ip # 如果全端口太慢先用masscan快速摸一遍 masscan -p1-65535 --rate1000 -oG masscan_output.txt target_ip # 拿到开放端口后再用nmap针对端口做服务版本确认 nmap -sV -sC -p22,80,443,3306,6379 target_ip # UDP重点端口扫描 nmap -sU --top-ports 100 -sV target_ip端口扫描不是“跑一条命令等结果”这么简单。TCP全端口扫描在带宽受限或者目标有一定防护的情况下容易超时所以我一般先用Masscan以较高速率把所有TCP端口摸一遍再把开放端口交给Nmap做详细服务识别。这样既节省时间又能拿到比较准确的服务版本信息。输出管理同样重要。每次扫描都要加-oA参数把结果同时保存为文本、XML和gnmap格式后续做资产汇总和报告时可以直接复用。3.2 常见端口与服务对应清单端口扫描的难点不在于发现端口而在于判断端口背后是什么服务。我把平时遇到的高频端口整理成了一张清单方便对照端口常见服务说明21FTP匿名登录检测是常规项目22SSH注意版本和弱口令策略23Telnet明文协议嗅探风险高25SMTP邮件服务可测用户枚举53DNS域名解析注意区域传送80 / 443HTTP/HTTPSWeb服务信息收集主战场110 / 143POP3 / IMAP邮件收发端口常见于邮件子域445SMBWindows文件共享注意永恒之蓝类风险3306MySQL数据库服务注意弱口令和未授权3389RDPWindows远程桌面5432PostgreSQL数据库服务6379Redis高危端口未授权访问频发8080 / 8443HTTP代理 / HTTPS备用常部署管理后台、API服务、监控面板9200Elasticsearch未授权访问检测5000MLflow等Python服务需要结合指纹确认不少数据科学平台默认在此16010 / 16020HBase Web UI / RegionServer若扫到HBase相关端口结合官方端口清单快速对照25734Solid Network License部分工业软件授权服务的默认端口偏门但真实存在这张表不是让你背而是提醒你端口只能说明“门开着”服务是什么必须结合指纹。比如5000端口可能是Flask开发服务器也可能是MLflow管理界面25734这种端口如果不结合服务指纹扫到也容易忽略。所以端口扫描的结果一定要跟下一阶段的指纹识别联动。3.3 端口开放背后的配置问题防火墙与端口占用做信息收集时经常绕不开两类端口问题一是目标防火墙规则限制了扫描二是本地测试环境端口被占导致工具起不来。先说目标侧。很多系统默认只对特定网段开放端口比如数据库3306只允许内网192.168.1.0/24访问你在外网扫永远看不到这个端口。这种场景下如果拿到了内网权限再回头看往往能发现大量额外暴露面。反过来如果自己部署测试环境想让指定网段访问某个端口Linux上的常用做法是放行白名单。以3306端口为例CentOS 7以上用firewalldfirewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.0/24 port port3306 protocoltcp accept firewall-cmd --reload如果习惯用iptables等价命令是iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 3306 -j ACCEPT service iptables save再说本地侧。端口被占是测试中很常见的现象比如启动Web服务时发现8080被占用报错信息含糊。排查命令很简单# Linux netstat -tlnp | grep 8080 ss -lntp | grep 8080 lsof -i:8080 # Windows netstat -ano | findstr 8080 tasklist | findstr PID找到占用端口的进程后按需停止或调整自己服务的监听端口。端口情况清楚了后续起工具、部署测试环境才不会被这些基础问题卡住。4. 指纹识别搞清楚对面是谁4.1 手工指纹识别先看响应头再翻页面指纹识别是承上启下的关键环节。上一步知道了端口是开放的这一步要确认端口背后跑的是什么程序、什么版本、什么框架。识别结果决定了下一步目录扫描该带什么字典、模糊测试该关注哪些已知漏洞。手工识别是基本功。拿到一个Web服务我一般是这么操作先看响应头。curl -I看一眼返回的Server字段和X-Powered-By字段。Server: nginx/1.18.0直接说明Web服务器X-Powered-By: PHP/7.4说明后端语言Set-Cookie字段也很有价值PHPSESSID、JSESSIONID、rememberMedeleteMe分别指向PHP、Java、Shiro框架。再看页面特征。很多CMS会在HTML里输出generator标签比如WordPress、Z-Blog、帝国CMS都有明显的meta标记。静态资源路径也是线索/wp-content/是WordPress/wp-includes/同样/Public/、/Application/多指向ThinkPHPfavicon.ico的MD5值也能用于识别很多测绘平台就是靠这个匹配指纹。最后看错误页。故意访问一个不存在的路径观察404页面样式Tomcat的404页有一张特定的猫图Nginx的404页字体和布局也有特点IIS的错误页在旧版本中特征非常明显。错误页往往能直接暴露中间件类型和版本范围。4.2 指纹识别工具与指纹库联动手工识别效率低批量场景要靠工具。我常用的组合是WhatWeb做单体网站深度识别Wappalyzer浏览器插件做交互式分析Ehole棱洞做批量资产指纹识别。# 单个目标详细识别 whatweb -v https://target.example.com # 批量识别结果输出JSON ehole -l targets.txt -json output.json识别到具体指纹后要立刻把它跟已知漏洞库关联。比如识别到目标是ThinkPHP那么根据具体版本去查历史RCE漏洞识别到Spring Boot可以直接探测/actuator、/env、/heapdump等Actuator端点识别到旧版Struts2那就往OGNL表达式注入方向看。指纹越精确后续测试的命中率越高。工具识别有误报的可能尤其是中间件套了一层产品的情况。比如常见的企业网关是nginx前面再套一层OpenResty或者Kong直接看响应头会被误导。我的习惯是工具结果只做参考最终以手工确认的响应头、页面路径和文件指纹交叉验证为准。4.3 容易混淆的概念网站指纹与指纹浏览器聊指纹识别这件事经常有人把“网站指纹识别”和“指纹浏览器”搞混。前者是识别目标网站的技术栈、服务器类型属于信息收集的一部分后者则是模拟浏览器指纹来做多账号防关联的工具比如生成不同的Canvas、WebGL、User-Agent等浏览器特征用途完全相反。如果你在搜索资料时看到“指纹浏览器开发”“指纹浏览器推荐”这类内容先想清楚自己的场景避免被带偏。本文说的指纹识别始终是站在“识别对方服务”的角度。5. 目录扫描与源码泄露排查找后门和仓库5.1 目录扫描工具与参数设置目录扫描的目标是发现后台入口、备份压缩包、敏感配置文件、接口文档、代码仓库。我首选dirsearch原因是字典组织清晰、状态码过滤方便、支持递归。常用命令python3 dirsearch.py -u https://target.example.com \ -e php,html,txt,zip,bak,sql \ -x 404,403 \ --random-agent \ -t 20 \ -r --max-recursion2 \ -o result.txt参数说明-e指定常见扩展名-x排除无意义的404和403响应403有时候有意义多半是先排除再用全量结果人工复核--random-agent是避免默认UA被WAF拦截-t控制线程-r开启递归扫描--max-recursion2限制目录深度。这里特别说下“目录深度”这个参数。很多人以为扫描递归越深越好实际上深目录里大量是静态资源、日志文件、前端JS对信息收集帮助有限还会拉慢速度、增加被拦截的概率。我的经验是默认扫两层即可后续根据指纹识别结果定向深入比如发现是ThinkPHP框架再针对/Application/、/Runtime/这类框架目录做深扫。图形化工具方面御剑目录扫描依然是很多人的首选适合本地快速跑一轮。它自带的字典覆盖面不错线程调节也方便缺点是缺少细粒度的状态码过滤扫描结果需要人工筛掉一批无用记录。我的习惯是御剑先跑一轮快速摸底再用dirsearch跑一轮定向补充。5.2 源码泄露的常见形态目录扫描过程中源码泄露往往会在不经意间跳出来。常见的泄露形态有这么几类第一类是版本控制工具目录泄露。.git目录泄露排在首位一旦.git目录可以被访问整个历史源码都有可能被扒走。.svn目录也有类似问题老项目中比较常见。第二类是开发工具留下的元文件。.DS_Store文件泄露后通过专门的解析工具能还原出目录结构和文件名顺藤摸瓜找到更多敏感文件。.idea/workspace.xml、.vscode/sftp.json这类IDE配置文件里经常出现服务器连接信息、账号密码。第三类是备份文件。运维常用压缩包备份网站代码文件名常见www.zip、site.zip、web.zip、backup.tar.gz、db.sql目录扫描时加上zip,tar,gz,sql,bak这些扩展名就能覆盖到。index.php.bak这类编辑器备份文件也很常见轻则泄露源码重则直接把配置一起带出来。第四类是敏感配置文件。.env文件在不少现代框架中存放数据库账号、密钥、第三方API Key一旦能直接访问后续测试就顺畅很多。config.php.bak、web.config、application.yml、settings.py也是重点关注对象。看到这些文件先判权限再判内容有些只是目录列表开了文件本身不可读有些则直接明文暴露。判断标准是访问状态码和响应内容200且包含源码特征才算有效泄露。5.3 Git目录泄露的完整利用Git目录泄露是很典型的问题单独拿出来讲一下。首先是确认是否存在泄露curl -s https://target.example.com/.git/config如果返回内容包含[core]段比如repositoryformatversion、[remote origin]这些字段基本可以确认.git目录可访问。接下来下载源码我常用的工具有两个git-dumper和GitHack。git-dumper更适合恢复完整仓库git-dumper https://target.example.com/.git ./repo它会根据index文件把工作目录里的文件恢复到本地完成后等于拿到了源码副本。GitHack的优势在于轻量适合快速恢复指定文件但完整度通常不如git-dumper。如果下载过程中对象不完整可能出现文件缺失的情况。这时候试着在目标站点访问/.git/logs/HEAD看能不能读到commit记录根据commit哈希再尝试拉取objects。实操中有些目标只开放了部分.git路径的访问就要灵活判断哪些对象拉得到、哪些拉不到。源码拿到手之后重点看这么几类内容数据库配置、加密密钥、内部API地址、后台逻辑代码、敏感接口。这些内容既能用来做漏洞挖掘也能反过来帮助企业自查代码仓库是否对公网开放。6. 人员信息收集与资产整理把人和资产关联起来6.1 人员信息从哪里找人员信息收集是很多测试报告里容易忽略的一块但它对风险评估和口令管理很有价值。这里只讨论公开渠道信息且所有用途都限定在授权范围内。常规来源有WHOIS信息查域名注册人姓名和邮箱ICP备案查企业主体信息企业官网和新闻稿里常见的员工职务与联系方式。更深入一些可以在GitHub和码云上搜目标企业域名和用户名很多人喜欢在公开仓库里提交代码git log里的提交邮箱经常暴露企业内部邮箱格式和员工真实姓名。招聘平台也很值得翻。公司的JD会写自己用什么技术栈、有没有内部OA、CRM系统叫什么名字这些信息能帮你快速拼出目标的技术画像。历史漏洞报告平台和企业安全公告则是了解目标系统构成、历史漏洞的快捷渠道补天、漏洞盒子上的公开报告能提供不少线索。邮箱格式确认后可以通过SMTP VRFY或正常的注册找回流程做存在性验证这类操作要特别谨慎必须在授权范围内并且不要并发大量探测否则容易被判为异常流量。6.2 从人员信息到口令字典的落地人员信息收集的核心价值之一是生成企业自检用的弱口令字典。掌握员工的姓名拼音、生日、手机尾号后可以组合出常见弱口令规则比如zhangsan、zhangsan123、zs123456、ZhangSan2024、zs123、zhangsan2024等。做这一步的目的是帮助企业自查弱口令风险而不是鼓励爆破。现实里很多系统已经强制多因素认证弱口令爆破的空间越来越小但账号信息泄露导致的撞库风险依然是企业面临的主要威胁之一。把人员信息和资产关联起来重点在于判断哪些员工在哪些系统有权限以及这些账号的凭证管理是否规范。6.3 信息汇总与报告输出信息收集的最后一步是汇总。我的输出模板大概长这样资产类型名称IP / 域名端口 / 服务指纹信息关键发现风险等级域名example.com1.2.3.480/443 NginxThinkPHP 5.1.git目录泄露、后台路径暴露高子域名git.example.com5.6.7.822 SSH/443 HTTPSGitea 1.18存在公开注册入口中报告不要求漂亮但要求完整。每一项发现都要注明来源和验证方式哪个工具扫出来的、响应码多少、有没有截图。后续复测或者漏报追查时这份记录就是最可靠的依据。7. 常见问题与排查技巧实录7.1 高频问题速查表信息收集环节的坑很多我整理了一份高频问题速查表基本都是实操中反复遇到的现象可能原因处理办法Nmap扫不到任何端口目标防火墙封禁了扫描来源、禁ping、端口过滤换TCP连接扫描-sT或从不同网络位置重试确认目标是否存活全端口扫描太慢网络带宽、目标防火墙丢包先用Masscan快速摸再用Nmap针对开放端口细扫目录扫描全是403源IP被封、默认UA被WAF拦截换出口IP、加--random-agent、降线程、加延时目录扫描结果大量301站点做了统一跳转看Location字段判断是否登录跳转必要时关闭跟随重定向子域名爆破结果全是同一个IP域名存在泛解析随机不存在的子域名做对照过滤掉泛解析IP.git目录能访问但下载失败服务器对某些对象路径做了限制用git-dumper重试结合logs/HEAD补拉关键对象系统提示端口被占本地软件已监听该端口netstat -ano或ss -lntp查占用进程按需停用指纹识别结果前后矛盾响应头被网关改写、指纹库老化结合HTML特征、favicon哈希、错误页交叉验证扫描一段时间后目标无响应WAF触发封禁策略降低并发、增加随机延时、分批分时段扫描7.2 我的几条实操心得最后聊几条我这些年沉淀下来的经验。第一扫描记录一定要留痕。每次跑完Nmap、dirsearch都把原始输出和筛选结果保留下来命名带上时间戳。信息收集往往不是一次性的后面前期结论被推翻时历史记录能帮你快速定位是哪一步判断出了问题。第二小字典优先。子域名爆破、目录扫描都一样先用高频小字典跑一遍拿到基础资产后再用大字典补充。一上来就全量字典不仅慢还容易触发封禁反而影响效率。第三指纹和目录要联动。没有指纹依据就盲目跑全量目录等于拿散弹枪打鸟。识别出具体框架后手里要有一套“框架默认目录和默认文件清单”比如ThinkPHP的/Runtime、Spring Boot的/actuator、WordPress的/wp-admin这些都是高价值命中点。第四所有动作都要有授权边界。信息收集的很多技术本身是中性的但必须在合法的授权测试框架内使用。收集中发现企业公开了不该公开的源码、密钥、内部信息正确的做法是记录下来并写进报告而不是继续深入利用。我自己的习惯是不管项目大小信息收集都不会跳过任何一步。子域名和端口解决“有什么”指纹解决“是什么”目录和源码泄露解决“能拿到什么”人员信息解决“能关联到什么”。这四层做扎实后续的测试就会顺畅得多。系统性的信息收集其实是整个授权测试过程中投入产出比最高的一环。
