做安全測試或者資產盤點的時候我最怕聽到一句話“目標沒幾個子域名隨便測測就行。”說這話的人往往在后面的測試里被自己的信息盲區狠狠坑一把。子域名收集這件事表面上看是跑幾個工具拼字典實際上決定了你對目標資產暴露面的認知上限也直接決定了后續測試是從“已知范圍”出發還是從“盲人摸象”開始。這篇內容我按“被動收集—主動爆破—關聯挖掘—自動化整合”這條主線把這些年用過的子域名收集方法完整梳理一遍。既有直接能抄的命令和工具也講清楚每個姿勢的原理和適用場景同時把所有踩過的坑一并列出來。適合剛入門信息收集的新手也適合覺得自己流程不夠系統的老手對照著查漏補缺。1. 子域名收集的意義與合規邊界1.1 子域名暴露了真正的攻擊面很多人覺得子域名無非就是www、mail、api這幾個前綴實際測試中完全不是這么回事。一個中型企業的子域名數量動輒成百上千而且歷史遺留的子域名往往比在用的還多。這些子域名背后可能掛著測試環境、后臺管理系統、舊版本的 API 網關、內部使用的 GitLab、未做鑒權的跳板機、第三方云廠商的存儲桶甚至直接是某個開發同事臨時開的云主機。我舉個實際例子之前做某企業授權測試時目標主站example.com防護做得滴水不漏WAF、態勢感知、主機加固全都有。但通過證書透明度日志和字典爆破找到一個dev.example.com上面跑著一個未打補丁的舊版 Tomcat 管理后臺弱口令直接進去了然后通過內網穿透拿到整個業務網段權限。這類路徑在紅隊實戰里是最常見的突破口而它的起點就是一次高質量的子域名收集。換句話說子域名收集的完整度直接決定了你對目標資產暴露面的判斷。收集得全你就能找到防護薄弱的老舊資產收集得少你就只能在別人精心布置的正面防線上硬碰硬。1.2 收集子域名的合法前提與測試原則在展開所有姿勢之前必須先強調合規邊界。子域名收集本身屬于信息收集手段技術上是中性的但使用場景必須嚴格限定在企業自有資產的梳理與安全加固獲得書面授權的滲透測試、紅隊演練、攻防演習安全研究中對公開信息的整理分析任何未經授權對他人系統進行掃描、探測、爆破的行為都可能觸及相關法律法規。即便只是 DNS 查詢和字典枚舉也會產生實際的網絡請求可能被目標的安全設備記錄。我在所有項目中堅持一個原則先確認授權范圍再開始收集授權范圍之外的一律不碰。這一點希望每個做安全的人都能刻在腦子里。另外還有一條行業慣例值得提一下大多數子域名收集手段都基于公開數據證書日志、DNS 記錄、搜索引擎緩存這類被動收集的合規風險相對較低而主動爆破、批量 DNS 查詢這類行為會產生大量流量優先級和強度需要根據授權書內容嚴格控制。后面講到的每個姿勢我都會標注清楚屬于被動還是主動方便你按場景取舍。2. 被動收集不碰目標的“撈魚”技術被動收集的思路是“不直接給目標發請求從第三方數據源把已經存在的子域名撈出來”。優勢是隱蔽、高效、幾乎不會觸發目標防護劣勢是覆蓋面取決于數據源的豐富程度。真正的高手做收集一定是被動優先主動補漏。2.1 證書透明度日志查詢證書透明度Certificate TransparencyCT是目前被動收集中信息量最大、最值得優先使用的方法。CA 機構簽發 TLS 證書時會把證書信息寫入公開的 CT 日志任何人可以查詢某個域名下簽發過的所有證書。這意味著只要某個子域名申請過 HTTPS 證書它就會在 CT 日志里留下記錄。查詢 CT 日志的方式有不少最直接的是通過crt.sh這個在線平臺也支持命令行拉取。比如查詢example.com的所有子域名curl -s https://crt.sh/?q%25.example.comoutputjson | jq -r .[].name_value | sort -u這條命令里%25是通配符%的 URL 編碼sort -u做去重。實際使用中你會發現 crt.sh 的響應有時候比較慢尤其是查詢大域名時數據量巨大。我的習慣是配合超時重試或者直接用下面這幾個替代接口# 使用 Censys 的 CT 查詢 curl -s https://search.censys.io/api/v2/certificates/search?qnames%3Aexample.comper_page100 # 使用 Google 的 Certificate Transparency 接口 curl -s https://certificate.transparency.googleapis.com/v1beta1/domains/example.com/at-versionCT 日志的價值不僅僅是“拿到子域名列表”更關鍵的是能發現那些已經不再使用但證書未過期的“僵尸子域名”這類域名往往是最容易出問題的歷史遺留資產。2.2 搜索引擎與第三方測繪平臺搜索引擎收錄也是被動收集的重要渠道。Google、Bing 都支持site:語法能找出被搜索引擎爬蟲收錄的二級域名。比如site:example.com -www這個語法能排除www主站把其他被收錄的子域名列出來。國內環境的話微步在線、奇安信鷹圖、鐘馗之眼等平臺也都有子域名查詢功能覆蓋的數據源有時比國外平臺更貼近實際。不過要注意搜索引擎收錄存在滯后性新上線的子域名可能要過幾周甚至幾個月才會被爬蟲發現所以它只能作為輔助手段不能當主力。第三方測繪平臺本質上是“別人提前幫你收集好了”。這些平臺通過長期全球掃描積累了大量域名與 IP 的對應關系查詢時只需要一個 API 調用。以 FOFA 為例語法大致是domainexample.com返回結果會包含子域名、對應 IP、開放端口、標題等信息等于把收集和指紋識別一步做完了。這類平臺的優點是信息量大、速度快缺點是免費額度有限而且有部分數據是掃描器推斷出來的可能存在誤報需要交叉驗證。2.3 DNS 歷史記錄與被動 DNS 數據還有一種被動收集思路容易被忽略查詢 DNS 歷史記錄。一個子域名可能在某個時間點解析到某個 IP后來業務下線、IP 釋放、域名被重定向但 DNS 歷史數據里仍然有記錄。SecurityTrails和DNSDumpster都是常用的 DNS 歷史查詢平臺。SecurityTrails 的 API 返回的數據很詳細會列出每個子域名在歷史不同時間段的解析記錄DNSDumpster 則提供可視化的域名-IP 關系圖適合做資產梳理時畫拓撲用。被動 DNS 數據的另一個來源是威脅情報平臺。一些惡意域名檢測平臺會存儲全球 DNS 解析記錄查詢某個根域名時能返回關聯的所有子域名。這類平臺包括 VirusTotal 的 Domain 頁面、AlienVault OTX、ThreatMiner 等。我實際測試的感受是這些平臺的數據源和 CT 日志有交叉單獨用哪一個都不夠全把多個源的結果合并去重之后覆蓋度能提升 30% 以上。3. 主動收集字典爆破與枚舉的正確姿勢被動收集做完拿到的子域名數量基本能覆蓋目標暴露面的 60% 到 70%。剩下的部分就得靠主動枚舉來補也就是字典爆破和 DNS 查詢。主動收集的本質是“猜”猜得準不準全看字典質量和過濾策略。3.1 字典爆破的核心思路字典爆破的原理很簡單準備一份常見子域名詞典逐個拼到根域名前面然后構造 DNS 查詢A 記錄、CNAME 記錄等如果返回了解析結果說明這個子域名存在。admin.example.com - 解析成功 api.example.com - 解析成功 nonexist123.example.com - 解析失敗這里最核心的變量是字典的質量。很多人直接用網上找的“通用大字典”幾千幾萬個詞往里砸結果不是漏掉真實存在的子域名就是被泛解析干擾到懷疑人生。我的經驗是字典需要分場景定制通用前綴www、mail、ftp、ssh、api、app、dev、test、stage、prod、admin、manage、portal、oa、erp、crm、wiki、git、jenkins、grafana、kibana等這類詞覆蓋大多數常見業務場景。業務關鍵詞結合目標公司的名稱、產品線、品牌詞做組合。比如公司叫“某某云”那cloud、yun、pan、store這類詞匯優先級就要提高。數字和短詞v1、v2、test1、new、old、backup、temp、bak這類容易出現在測試環境和備份系統的前綴實戰里經常能漏出驚喜。工具自帶字典不少工具自帶基礎字典SecLists的subdomains-top1million-5000.txt就是常用的參考字典可以基于它做增刪。爆破過程中有個參數需要重點控制并發數。并發太高DNS 服務器直接把你限流或者丟包并發太低幾萬詞的字典要跑到天荒地老。我用puredns或massdns時一般把并發控制在 1000 到 2000同時開啟重試機制。這個值不是固定的建議根據網絡狀況和目標 DNS 的響應速度動態調整。3.2 泛解析的識別與過濾泛解析是主動爆破里最惡心的問題。所謂泛解析就是域名配置了*.example.com的解析任何不存在的子域名都會被解析到一個固定的 IP通常是負載均衡器或者宣傳頁。這時候你爆破出來的“有效子域名”可能大部分是假的。泛解析的識別方法很簡單先隨機生成一個幾乎不可能存在的子域名比如qwertyuiop12345.example.com解析一下看是否返回結果。如果返回了說明目標開了泛解析。過濾策略我提供一個實操過的方案通過massdns拿到的爆破結果先記錄每個子域名解析到的 IP然后和隨機生成的泛解析 IP 做比對解析到相同 IP 且域名特征明顯是隨機詞的直接過濾掉。注意有些目標配置了多條泛解析記錄比如*.test.example.com和*.example.com各自指向不同 IP所以過濾時要按“IP 分組統計 域名后綴特征”雙重判斷。泛解析的存在也讓“字典質量”變得更重要。如果目標開了泛解析爆破結果的含金量就取決于字典里的詞和目標實際業務詞的匹配度窮舉式的超大字典在泛解析面前效率會急劇下降。3.3 主流爆破工具對比與選擇工具選型是很多人糾結的點我把用過的主流工具做了一張對比表方便你按場景選擇。工具類型核心特性適用場景subfinder被動收集調用大量 API 源速度快配置簡單首選快速收集amass被動主動OWASP 項目接口豐富支持數據源擴展大型目標全面收集oneforall被動主動國內開發者維護內置字典和子功能較多中文目標資產收集puredns主動爆破精確處理泛解析支持大規模字典字典爆破主力massdnsDNS 查詢引擎萬級 QPS高速批量解析底層解析引擎layer子域名挖掘機主動爆破老牌圖形化工具操作門檻低快速驗證少量域名關于最后這個工具需要多說兩句。Layer子域名挖掘機在早期安全圈里確實流傳很廣圖形界面開箱即用不少新手是從它入門的。但問題也很明顯一是年久失修內置字典和去重邏輯已經跟不上現在的目標環境二是這類閉源工具流傳版本魚龍混雜無法確認有沒有被植入后門在測試環境里使用風險極高。我的建議是如果你只是臨時驗證一兩個域名的解析情況可以用它圖個方便真正做完整的子域名收集流程還是用開源工具鏈更穩妥畢竟你能看到它到底發了什么請求、執行了什么邏輯。4. 關聯挖掘從已收集域名繼續深挖很多人的子域名收集做到第三步就停了其實還有幾層姿勢能把結果質量再拉高一個檔次。核心思路是“從已拿到的信息反查和關聯”。4.1 域名注冊信息反查與兄弟域名通過已收集子域名的 IP 做反查是發現“兄弟域名”的經典手法。同一個 IP 上可能綁定了多個域名這些域名往往屬于同一家企業或同一個業務集群。實現上可以用Robtex、ViewDNS.info這類平臺的反查接口也可以用Shodan的reverse DNS查詢。操作邏輯是拿到已確認的子域名解析 IP 列表對每個 IP 做 PTR反向指針查詢得到該 IP 綁定的域名列表把域名列表里屬于同一主域的其他二級域名合入結果集注意這里有個效率問題幾十個子域名解析出的 IP 可能只有幾個所以先對 IP 做去重能減少大量無效查詢。另外CDN 背后的 IP 反查出的域名可能屬于 CDN 廠商過濾時需要結合域名后綴判斷是否屬于目標資產。4.2 JS 文件與頁面源碼中的域名泄露前端代碼里泄露內網域名是我在實戰中命中率很高的一個信息收集姿勢。現在的 Web 應用前端代碼動不動就幾百 KB里面引用的 API 地址、WebSocket 地址、資源域名經常藏著新子域名。推薦的工具是subjs和LinkFinder它們的原理都是拉取目標頁面后自動提取 JS 文件中的 URL 和域名。我經常配合使用的一個命令流程是# 先收集 JS 文件 URL cat urls.txt | subjs # 再從 JS 內容中提取子域名 cat js_urls.txt | unfurl -u domains其中unfurl是一個提取 URL 各個部分的工具很輕量。如果嫌命令行麻煩手動打開瀏覽器開發者工具在網絡面板搜索http關鍵字也能從請求列表里看到頁面實際調用的內部域名。這個方法對 SPA單頁應用特別有效因為前端代碼會把部分配置暴露在打包產物中。4.3 子域名接管漏洞檢測收集到足夠多的子域名之后別忘了做一輪接管檢測。子域名接管Subdomain Takeover的原理是某個子域名的 CNAME 記錄指向了第三方托管服務如 GitHub Pages、AWS S3、Heroku但托管服務上對應的資源已經被釋放此時攻擊者可以重新注冊資源讓域名解析到自己控制的內容實現對該子域名的完全控制。檢測的核心思路是檢查“已解析但是沒有任何有效內容”的子域名。實操中我用subjack和nuclei的接管檢測模版# subjack 檢測 subjack -w subdomains.txt -t 100 -timeout 30 -o takeover.txt # nuclei 檢測 nuclei -l subdomains.txt -t http/takeovers/這里要提醒的是檢測結果需要人工復核。有些托管服務返回的報錯頁面和可接管狀態的報錯非常接近但實際服務仍在使用只是返回了特定的 404 頁面還有些 CDN 服務商對未配置資源的返回頁面從設計上就長得很“可接管”。我見過最離譜的一次誤報是一個內部系統用的自定義 404 頁面長得跟某個第三方服務的釋放頁面一模一樣差點被當成接管點提進報告還好復核時多看了一眼響應頭。所以自動化檢測結果必須經過人工確認這一點在輸出基線報告時尤其重要。5. 自動化整合與工作流設計單點姿勢掌握之后要把流程串成自動化流水線效率和覆蓋率才會有質變。一個完整的子域名收集流程至少包含數據源匯總、去重過濾、驗證存活、輸出整理四個階段。5.1 一個可落地的半自動化流程我用了一個 Bash 腳本把被動收集、主動爆破和驗證串起來。這個流程不復雜勝在結構清晰你可以按自己環境調整。#!/bin/bash # 子域名收集工作流示例 TARGETexample.com OUTDIRsubdomain_$TARGET mkdir -p $OUTDIR # 階段一被動收集 subfinder -d $TARGET -all -silent $OUTDIR/passive.txt curl -s https://crt.sh/?q%25.$TARGEToutputjson | jq -r .[].name_value | sort -u $OUTDIR/passive.txt # 階段二去重并生成基礎字典 sort -u $OUTDIR/passive.txt -o $OUTDIR/passive_uniq.txt # 階段三主動爆破結合已有子域名和字典 puredns bruteforce wordlist.txt $TARGET -r resolvers.txt -q $OUTDIR/brute.txt # 階段四合并所有結果 cat $OUTDIR/passive_uniq.txt $OUTDIR/brute.txt | sort -u $OUTDIR/all_subs.txt # 階段五存活驗證 httpx -l $OUTDIR/all_subs.txt -title -status-code -web-server -tech-detect -o $OUTDIR/alive.txt echo 收集完成存活結果: $OUTDIR/alive.txt這里步驟五用的httpx是目前我用下來最順手的存活驗證工具支持并發請求、狀態碼、標題、Web 框架指紋識別一個命令能同時完成存活驗證和基礎指紋收集省去后續很多重復請求。5.2 結果去重與多源交叉驗證多數據源合并后的去重不是簡單去個字符串就完了有幾個細節值得注意大小寫歸一化DNS 解析對大小寫不敏感WWW.Example.COM和www.example.com是同一個域名去重前統一轉小寫。通配符條目處理有些數據源會返回*.example.com或*.dev.example.com這類通配符條目這類記錄本身不是具體的子域名但能從側面說明該層級下有其他子域名。我通常把通配符條目單獨存一個文件作為字典擴充的線索不直接并入結果。去尾點處理部分數據源返回的域名末尾會帶一個點FQDN 格式需要統一去掉。正則過濾用正則過濾掉明顯的無效格式比如包含空格、引號、括號的異常記錄。這些格式異常數據很多是 CT 日志里證書的 SAN使用者備用名稱字段解析異常產生的。多源交叉驗證還有一個妙用同一個子域名如果只在某個單一數據源出現可信度要打折扣如果出現在 CT 日志和一個被動數據源里同時爆破字典也能解析那基本可以確認它是真實存活的資產。5.3 輸出格式與報告整理子域名收集結果最終要落到報告里。我見過的報告千奇百怪有的就是一個 txt 文件丟給客戶后面的人根本不知道這些域名對應什么業務。一個合格的結果輸出至少應該包含字段說明子域名完整域名去掉協議和路徑解析 IP當前解析的 IP 列表多個 IP 用逗號分隔CNAME如果有 CNAME記錄目標域名用于判斷 CDN 或第三方托管HTTP 狀態碼存活驗證后的訪問狀態碼標題頁面標題快速判斷業務類型指紋信息Web 服務器、中間件、技術棧等來源被動收集、爆破、JS 提取等方便復測和溯源備注是否疑似接管、是否有敏感路徑、是否內部系統等實操中我一般輸出為 CSV字段用逗號分割方便導入 Excel 或禪道。輸出到 CSV 時記得統一字符集為 UTF-8否則中文標題會在部分系統里亂碼這個坑我踩過不止一次。6. 常見問題排查與避坑心得6.1 泛解析誤判導致結果“虛胖”這是最常見的翻車現場。爆破出來的子域名幾萬個但其中 90% 是被泛解析污染的無效結果。處理方案前面提過我再補充一個更細的操作思路把爆破結果按解析 IP 分組如果某個 IP 下掛了海量隨機命名的域名那這個 IP 大概率是泛解析地址再結合隨機域名是否包含有意義的業務詞如admin、api做二次過濾。有時候目標會設置泛解析“白名單”只對不在白名單內的前綴返回固定 IP這時候需要對比泛解析 IP 和白名單域名解析的 IP逐條核對。6.2 速率過于激進導致查詢超時或者封禁DNS 爆破本質上就是高頻查詢。在某些嚴格環境下目標 DNS 服務器的 QPS 限制觸發后后續查詢會全部超時表現為爆破結果后半段全是失敗記錄但前半段正常。排查時看爆破時間線如果失敗集中在后半段基本能確認是速率問題。解決方法是降并發、加重試或者換用更本地的 DNS 解析源。我自己常用的解析源是各大云廠商公共 DNS 混搭并通過dnsvalidator每次先校驗一批可用解析源的可靠性。6.3 數據源接口報錯導致結果缺失CT 日志平臺和第三方測繪平臺都有訪問頻率限制短時間內連續請求很容易被攔截。遇到接口報錯不要死磕換個數據源或者降低請求頻率讓腳本做“指數退避重試”更穩妥。另外crt.sh的查詢有時候會返回空結果并不是真沒有數據而是查詢超時或者數據庫負載高換個時間點再跑一次往往就有數據了。6.4 工具誤報與蜜罐干擾最后提一個被很多人忽略的點有些目標和安全設備會故意在 DNS 層做“蜜罐”。它們可以監測到哪些 IP 在批量查詢自己的子域名字典這是最早暴露測試行為的渠道之一。尤其是規模大的攻防演練場景目標的安全團隊確實會盯著 DNS 請求日志做預警。所以做主動收集前務必確認授權范圍是否允許并且嚴格控制爆破強度和時段。被動收集則相對安全因為它不直接觸碰目標系統。6.5 Layer子域名挖掘機這類老工具的后續使用建議關于老牌工具“Layer子域名挖掘機”我再說點實際建議。如果你手頭確實有這個工具并且只是快速驗證少量域名可以用但要注意幾點一是不要直接用它內置的字典跑大型目標字典陳舊導致漏報嚴重二是運行前先對文件做病毒掃描這類停更多年的閉源工具在社區里的傳播鏈極不透明三是它的結果最好再經過puredns或者massdns的驗證不能直接當最終結論。從效率角度講同樣是圖形界面操作我更推薦直接用OneForAll這類開源項目跑一套完整流程覆蓋面、準確率和可解釋性都不是老工具能比的。7. 最后的實戰心得關于子域名收集我自己后期最大的轉變是從“收集完就開測”變成“收集完先梳理、再驗證、再做交集分析”。花半個小時把結果整理成清晰的資產列表提煉出哪些是老舊系統、哪些是第三方托管、哪些是內部應用后續的滲透測試方向會清晰非常多。急急忙忙拿著一個爆破出來的列表就到處打點反而容易被安全設備盯上而且浪費時間在無效目標上。另外一個小技巧是每次做完一個目標的子域名收集把高價值子域名和對應 IP 記到自己的筆記里。不同項目之間同一個企業下面可能有多個不同根域名比如主站和子公司它們的子域名記錄經常有交叉。比如一個母公司下多個品牌域名通過自有歷史數據做關聯經常能提前發現目標自己都沒梳理出來的資產。這一點在大型企業資產盤點時特別有用。子域名收集永遠沒有一個“最全”的終點每次換一個數據源、換一份字典、換一種關聯思路都可能發現新的遺漏資產。但有一個相對確定的結論把被動收集做扎實、把爆破字典調對口、把多源結果交叉驗證到位、再結合人工經驗去判斷這四步到位你的子域名收集水平已經能超過八成做安全測試的人。剩下的功夫就是在一次次實戰里不斷積累對目標行業、目標業務的理解這比任何一個工具都值錢。