Subdomain enumeration CTF: находим скрытые поддомены с dig, dnsx и Sublist3r

Subdomain enumeration CTF: находим скрытые поддомены с dig, dnsx и Sublist3r

На квалификации одного из онлайн-CTF я убил полтора часа, гоняя gobuster по директориям веб-сервера. Коллега подошёл, глянул на экран и молча набрал dig target.ctf TXT +short. Флаг лежал в TXT-записи поддомена третьего уровня — с самого старта. Три минуты против полутора часов слепого фаззинга. С того раза subdomain enumeration в CTF-задачах у меня всегда идёт первым шагом: до сканирования портов, до веб-интерфейса, до чего бы то ни было. DNS-разведка CTF-стендов — тот этап, который новички пропускают чаще всего, и именно поэтому застревают на задачах, где ответ буквально торчит наружу.

Место DNS-разведки в цепочке атаки CTF

Поиск поддоменов — не галочка из чеклиста. Это первый шаг reconnaissance в kill chain, и от него зависит вся дальнейшая поверхность атаки. В терминологии MITRE ATT&CK сюда попадают три техники:

• Gather Victim Network Information: DNS (T1590.002, Reconnaissance) — сбор DNS-записей цели: A, AAAA, MX, NS, TXT, CNAME
• Search Open Technical Databases: DNS/Passive DNS (T1596.001, Reconnaissance) — запросы к публичным базам DNS-данных: Certificate Transparency логи, DNS-агрегаторы, поисковые системы
• Active Scanning: Wordlist Scanning (T1595.003, Reconnaissance) — брутфорс поддоменов по словарю, прямые DNS-запросы к серверу цели

В CTF цепочка выглядит так: получил домен в условии → собрал все типы DNS-записей → нашёл скрытые поддомены → проверил каждый на живой сервис → атакуешь конкретные точки входа. Пропустил первое звено — видишь 20% поверхности и ломишься вслепую.

В реальном пентесте DNS enumeration стоит на том же месте — initial access начинается с понимания, что торчит наружу. Принципиальная разница: на CTF-стендах zone transfer часто открыт намеренно (это часть задачи), а на боевых серверах — практически никогда. Но набор инструментов и логика одни и те же.

Требования к окружению

Минимальный набор для воспроизведения всех команд из статьи:

• ОС: Kali Linux 2024.x или любой Linux-дистрибутив с пакетным менеджером. macOS подойдёт для dig, но dnsx и Sublist3r удобнее разворачивать на Linux
• RAM: 2 ГБ минимум для одиночных запросов, 4 ГБ если гонять dnsx с wordlist на 100k+ записей
• Сеть: доступ к интернету для пассивной разведки (Sublist3r ходит к внешним API) и к DNS-серверу цели для активной (dig, dnsx). На CTF-платформах — стабильное VPN-соединение
• Инструменты:
• dig — пакет dnsutils (Debian/Ubuntu) или bind-utils (CentOS). Установка: sudo apt install dnsutils
• dnsx — бинарь от ProjectDiscovery на Go. Установка: go install -v github.com/projectdiscovery/dnsx/cmd/dnsx@latest (Go 1.21+)
• Sublist3r — Python-скрипт. Клонирование: git clone https://github.com/aboul3la/Sublist3r.git, затем pip install -r requirements.txt
• Wordlists: SecLists (на Kali — /usr/share/seclists/Discovery/DNS/). Для быстрого прохода — subdomains-top1million-5000.txt, для глубокого — subdomains-top1million-110000.txt

dig — утилита DNS для ручной разведки записей

Ключевые флаги dig для CTF-задач

dig из пакета BIND — в CTF незаменим для ручного разбора DNS. Не потому что мощнее автоматических инструментов, а потому что показывает сырой ответ DNS-сервера: заголовки, секции Authority и Additional, флаги ответа, TTL каждой записи. Когда таск построен на нестандартной DNS-конфигурации, именно сырой ответ dig позволяет понять, что вообще происходит.

Базовый запрос A-записи — dig target.ctf A, но в CTF одного типа записи никогда не хватает. Стандартный набор, который стоит прогонять первым делом:

• dig target.ctf ANY — все типы записей разом. Работает не на всех DNS-серверах (многие блокируют ANY-запросы после RFC 8482), но CTF-стенды обычно отвечают
• dig target.ctf TXT — текстовые записи. Флаги и подсказки в CTF прячут именно в TXT чаще всего
• dig target.ctf MX — почтовые серверы. Иногда указывают на отдельный поддомен с уязвимым сервисом
• dig target.ctf NS — NS-записи домена. Критично для zone transfer. По данным Recorded Future, dig -t mx с указанием конкретного типа записей — одна из базовых техник DNS enumeration

Три флага, которые экономят время на CTF. +short убирает весь шум и оставляет только значение записи — удобно для пайплайнов. +noall +answer чуть подробнее: сохраняет TTL и тип, но режет секции Authority и Additional. @ns.target.ctf направляет запрос на конкретный DNS-сервер цели — без этого zone transfer не заведётся, да и публичные резолверы часто не знают о внутренних записях стенда.

Отдельный нюанс: dig числится в GTFOBins как утилита для чтения произвольных файлов через dig -f /path/to/file. В CTF-задачах на privilege escalation это иногда всплывает — если dig стоит с SUID-битом или доступен через sudo без пароля.

[Применимо: CTF (всегда), внешний пентест (первичная разведка), внутренний пентест (запросы к внутреннему DNS)]

DNS zone transfer — AXFR на практике

Zone transfer (AXFR) — механизм репликации DNS-зон между primary и secondary серверами. В нормальной инфраструктуре AXFR ограничен ACL-списком разрешённых IP. На CTF это один из самых частых намеренно оставленных мисконфигов — проверять нужно всегда.

Последовательность: сначала узнаём NS-сервер через dig target.ctf NS +short, затем шлём AXFR-запрос именно к нему. Без указания конкретного NS запрос улетит на системный резолвер (8.8.8.8, провайдерский), который ничего не знает о зоне цели и вернёт пустоту.

dig @ns1.target.ctf target.ctf AXFR

; <<>> DiG 9.18.24 <<>> @ns1.target.ctf target.ctf AXFR
;; ANSWER SECTION:
target.ctf.        86400  IN  SOA  ns1.target.ctf. admin.target.ctf. 2024010101 ...
target.ctf.        86400  IN  NS   ns1.target.ctf.
admin.target.ctf.   86400  IN  A    10.10.10.5
dev.target.ctf.     86400  IN  A    10.10.10.6
secret.target.ctf.  86400  IN  TXT  "FLAG{dns_zone_transfer_example}"
target.ctf.        86400  IN  SOA  ns1.target.ctf. admin.target.ctf. 2024010101 ...

AXFR вернул полную зону — задача по сути решена: все поддомены перед вами в одном ответе. Пришёл Transfer failed. или connection timed out — zone transfer закрыт, переходим к брутфорсу.

Когда AXFR не работает:

На 99%+ боевых серверов: BIND 9.x по умолчанию запрещает AXFR для неавторизованных IP, PowerDNS — аналогично. Если firewall фильтрует TCP/53 — тоже мимо: AXFR работает по TCP, не по UDP. Открытый UDP/53 для обычных DNS-запросов ничего не гарантирует. На CTF-стендах с modern-конфигурацией организаторы специально закрывают zone transfer и ждут от участника брутфорс.

По данным Outpost24, зона трансфера — «самая простая и базовая техника» subdomain enumeration. Правда. Именно поэтому в продвинутых CTF-задачах она намеренно закрыта, и нужны другие подходы.

Sublist3r — поиск поддоменов через OSINT

Sublist3r — Python-инструмент для пассивного поиска поддоменов. Он не шлёт DNS-запросы к серверу цели напрямую, а собирает данные из публичных источников: поисковых систем (Google, Bing, Yahoo), баз Certificate Transparency (crt.sh), VirusTotal, DNSdumpster. По данным Outpost24, Sublist3r агрегирует результаты из множества источников, включая Bing, VirusTotal и crt.sh.

Запуск: python sublist3r.py -d target.com. Для сохранения в файл: python sublist3r.py -d target.com -o subdomains.txt. Встроенный модуль subbrute активируется флагом -b и добавляет DNS-брутфорс по словарю к пассивным результатам.

Sublist3r хорош как первый проход по реальному домену в начале внешнего пентеста: за одну-две минуты можно собрать десятки или сотни записей без единого запроса к инфраструктуре цели. Чистая passive reconnaissance.

Ограничения Sublist3r и когда инструмент бесполезен

У Sublist3r есть конкретные ситуации, где он не даёт ничего или даёт мусор:

1. Локальные CTF-стенды. Домены вроде target.htb или target.thm не зарегистрированы в публичном DNS. Поисковики о них не знают, CT-логов нет, VirusTotal их не видел. Sublist3r вернёт пустой результат. Для HackTheBox, TryHackMe и аналогичных платформ пассивная разведка бесполезна — нужен активный брутфорс.

2. Свежесозданные домены. Организаторы CTF зарегистрировали домен за неделю до соревнований — пассивные источники ещё не проиндексировали его поддомены. CT-логам нужно время на попадание в агрегаторы.

3. Устаревшие результаты. Sublist3r полагается на пассивные данные и не проверяет, резолвятся ли найденные поддомены прямо сейчас. В выводе могут быть записи, которые существовали год назад, но давно удалены — классический NXDOMAIN. Выход — верифицировать каждый результат через dnsx.

4. Wildcard DNS. Если домен отвечает на любой поддомен (*.target.com → один IP), пассивные источники могут содержать случайные записи из кэшированных запросов, которые не являются реальными сервисами.

Перед использованием стоит проверить актуальность репозитория Sublist3r на GitHub — проект обновляется заметно реже альтернатив. Для боевых пентестов лучше присмотреться к Subfinder от ProjectDiscovery: написан на Go, поддерживает больше источников данных, активно обновляется. По данным YesWeHack, Subfinder использует десятки баз данных включая Censys, Shodan и SecurityTrails. Установка: go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest, запуск: subfinder -d target.com.

Но для CTF, где Sublist3r уже предустановлен на Kali и нужен быстрый пассивный проход по реальному домену — он свою задачу выполняет.

[Применимо: внешний пентест с реальным доменом. Не применимо: CTF на локальных стендах (HTB, THM), внутренний пентест]

dnsx — сканирование поддоменов и активный брутфорс

Резолвинг и фильтрация wildcard DNS

dnsx от ProjectDiscovery решает конкретную задачу: массовый DNS-резолвинг и верификация. Sublist3r или другой OSINT-инструмент выдал список из 500 потенциальных поддоменов — dnsx за секунды проверит, какие из них реально резолвятся. По данным WhoisXML API, dnsx — один из ключевых инструментов для DNS brute-forcing и resolving наряду с PureDNS.

Базовая проверка: cat subdomains.txt | dnsx -silent. Флаг -silent убирает баннер. Для получения IP-адресов: cat subdomains.txt | dnsx -silent -a -resp — -a запрашивает A-записи, -resp показывает ответ DNS-сервера.

dnsx поддерживает запрос разных типов записей через соответствующие флаги: -aaaa, -cname, -mx, -txt, -ns. В CTF комбинация -a -aaaa -cname -txt покрывает большинство сценариев: CNAME может указать на внешний сервис (потенциальный subdomain takeover), TXT может содержать флаг или подсказку.

Отдельная сильная сторона — встроенная фильтрация wildcard DNS. Флаг -wd target.ctf шлёт запрос с заведомо несуществующим поддоменом (случайная строка), получает ответ и автоматически фильтрует все записи с таким же IP. Без этого при wildcard-конфигурации весь wordlist вернётся как «найденный» — сотни ложноположительных результатов.

Брутфорс поддоменов с DNS bruteforce wordlist

dnsx работает и как полноценный брутфорсер, заменяя связку massdns + постобработку. Флаг -w принимает путь к wordlist, -d задаёт целевой домен:

dnsx -d target.ctf -r 10.10.10.2 -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -silent -a -resp -retry 3 -t 50

Здесь -r 10.10.10.2 — DNS-сервер цели (на локальных CTF-стендах без этого никуда), -retry 3 повторяет неудачные запросы (спасает при нестабильном VPN), -t 50 — количество параллельных горутин. По сравнению с gobuster dns, dnsx заметно быстрее за счёт конкурентной архитектуры на Go.

Три нюанса для CTF, которые сэкономят нервы:

Выбор резолвера. По умолчанию dnsx использует системный DNS. На CTF-стендах HackTheBox и TryHackMe домены типа .htb или .thm резолвятся только через DNS-сервер машины. Без флага -r с IP этого сервера запросы улетят на 8.8.8.8 и вернут NXDOMAIN для каждого поддомена. Я на этом терял минут по двадцать, пока не вбил в мышечную память.

Скорость vs надёжность. -t 300 разгоняет до 300 параллельных запросов, но на VPN-соединении с HackTheBox это приводит к потерям пакетов — часть валидных поддоменов не ответит вовремя и будет пропущена. Для HTB оптимально -t 50, для стабильных сетей можно поднять до -t 200.

Размер wordlist. Начинайте с subdomains-top1million-5000.txt — 5000 записей прогоняются за 10-30 секунд. Ничего не нашли — переходите на 110k, но готовьтесь ждать 5-15 минут. В CTF поддомены обычно имеют очевидные имена (admin, dev, secret, staging, internal), и короткий wordlist покрывает 90% случаев.

[Применимо: CTF (локальные и онлайн), внешний пентест, внутренний пентест. Ограничение: stateful firewall или IDS с rate limiting на DNS-запросы (Snort, Suricata) зафиксирует массовый перебор — снижайте -t до 10-20 или используйте пассивные методы]

Пошаговый разбор: DNS enumeration в CTF-сценарии

Полный workflow для типовой CTF-машины. Вводные: подключились к стенду, получили доменное имя target.ctf и IP DNS-сервера 10.10.10.2.

Шаг 1 — Сбор DNS-записей через dig. Запрашиваем NS: dig @10.10.10.2 target.ctf NS +short. Получаем имя авторитетного DNS-сервера. Проверяем TXT: dig @10.10.10.2 target.ctf TXT +short — флаги и подсказки часто лежат именно здесь. MX: dig @10.10.10.2 target.ctf MX +short — почтовые серверы иногда указывают на отдельные поддомены.

Шаг 2 — Попытка zone transfer. dig @10.10.10.2 target.ctf AXFR. Вернулась полная зона — собираем все поддомены из ответа и прыгаем к шагу 5. Transfer failed. — идём дальше.

Шаг 3 — Пассивная разведка (только для реальных доменов). Домен зарегистрирован в публичном DNS: python sublist3r.py -d target.com -o passive_subs.txt. Домен локальный (.htb, .ctf, .thm) — пропускаем, тут пассивка бесполезна.

Шаг 4 — Активный брутфорс поддоменов. Прогоняем dnsx с SecLists wordlist:

dnsx -d target.ctf -r 10.10.10.2 \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -silent -a -resp -retry 3 -t 50 \
  | tee found_subs.txt

Вывод сохраняется в файл и одновременно отображается в терминале. Каждая строка — subdomain.target.ctf [IP].

Шаг 5 — Сбор дополнительных записей. По найденным поддоменам запрашиваем TXT и CNAME: cat found_subs.txt | cut -d' ' -f1 | dnsx -silent -txt -cname -resp. CNAME-записи могут указывать на внешние сервисы — потенциальный вектор для subdomain takeover.

Шаг 6 — HTTP-проверка. Не все резолвящиеся поддомены обслуживают веб-сервер. Если стоит httpx: cat found_subs.txt | cut -d' ' -f1 | httpx -silent -status-code -title — покажет HTTP-статус и заголовок страницы. Это фильтрует шум и показывает реальные точки входа.

Весь workflow занимает 5-10 минут на стандартном CTF-стенде. Wordlist на 5000 записей не дал результатов — переходите на 110k. И он пуст — пересмотрите предположения: возможно, нужно искать поддомены не через DNS, а через virtual host fuzzing (перебор заголовков Host: в HTTP-запросах через gobuster vhost или ffuf).

Сравнение subdomain enumeration инструментов

Критерий	dig	Sublist3r	dnsx
Тип разведки	Ручной запрос, AXFR	Пассивный (OSINT)	Активный (брутфорс, резолвинг)
Работает на локальных CTF (.htb)	Да	Нет	Да
Скорость на 5000 записей	Не применимо (ручной)	30-60 сек	5-15 сек
Wildcard фильтрация	Нет (ручная проверка)	Нет	Да (флаг -wd)
Зависимости	Пакет dnsutils	Python + pip	Go binary
Детектируемость IDS	Низкая (единичные запросы)	Нулевая (запросы к сторонним API)	Средняя-Высокая (массовые DNS-запросы)
Когда использовать	Первичная разведка, AXFR, анализ записей	Внешний пентест, реальный домен	Активный брутфорс, верификация списков
Когда НЕ использовать	Массовый перебор	Локальные стенды, свежие домены	Нестабильная сеть без retry

Альтернативы, которых нет в заголовке, но которые стоит знать:

• Subfinder (ProjectDiscovery) — современная замена Sublist3r для пассивной разведки. Активно поддерживается, больше источников данных
• Amass (OWASP) — тяжёлый комбайн: пассивные и активные методы в одном. По данным TheHacker.Recipes, поддерживает DNS bruteforcing, zone walking, web archives. Для простых CTF-задач избыточен
• Gobuster с режимом dns — популярная альтернатива для DNS-брутфорса. По данным YesWeHack, эффективен, но не фильтрует wildcard автоматически (в отличие от dnsx)
• Fierce — по данным Recorded Future, инструмент DNS-разведки с встроенным обнаружением NS-записей и опцией расширенного сканирования подсетей (--wide)

Для CTF рекомендуемый стек: dig для ручной разведки записей → dnsx для брутфорса. Sublist3r или Subfinder подключаются только для реальных публичных доменов.

Ограничения техник DNS-разведки в современных средах

Каждая техника DNS enumeration имеет границы. Понимание этих границ отличает осознанный выбор инструмента от слепого запуска всего подряд.

Zone transfer (AXFR) не работает на боевых серверах в подавляющем большинстве случаев. BIND 9.x и PowerDNS по умолчанию ограничивают AXFR ACL-списками. Даже если DNS-сервер настроен небрежно, firewall может фильтровать TCP/53, а AXFR требует именно TCP. На DNSSEC-signed зонах есть альтернатива — NSEC walking — но она сложнее в реализации и выходит за рамки типовых CTF.

DNS-брутфорс ограничен качеством wordlist и конфигурацией сети. DNS-провайдеры с rate limiting (Cloudflare, AWS Route 53) дропают массовые запросы после определённого порога. IDS/IPS с правилами на DNS query rate (Snort, Suricata с сигнатурами на DNS flood) фиксируют перебор и могут заблокировать IP. Wildcard DNS без фильтрации превращает результаты в мусор. Стандартные wordlists покрывают общие имена (dev, staging, api, admin), но не найдут нетипичные поддомены вроде jenkins-ci-prod-eu-west-1 — для таких случаев нужны permutation-инструменты (типа altdns или gotator).

Пассивная разведка зависит от полноты публичных баз. Если поддомен никогда не попадал в Certificate Transparency логи, поисковые индексы или DNS-датасеты (вроде тех, что упоминает Outpost24 в контексте Rapid7 Forward DNS) — пассивный инструмент его не увидит. Данные могут быть устаревшими: запись была в CT-логе год назад, поддомен давно удалён. На внутренних доменах Active Directory (.local, .corp) пассивная разведка бесполезна полностью.

По данным Recorded Future, реальные злоумышленники комбинируют несколько техник: пассивную разведку для первичного списка, активный брутфорс для расширения, reverse DNS (T1595.001, Scanning IP Blocks) для обнаружения поддоменов через PTR-записи. Malware Smoke Loader использует fast flux (T1568.001, Command and Control) для быстрой ротации IP-адресов — в таких условиях результаты DNS-разведки устаревают за минуты.

Большинство CTF-игроков запускают один инструмент и сразу бегут к эксплуатации. Самые интересные задачи построены именно на том, что автоматика пропускает: нестандартные TXT-записи, SPF-записи, указывающие на внутреннюю инфраструктуру, CNAME-цепочки, ведущие к заброшенным сервисам. Я видел десятки CTF, где участники зависали на часы, пытаясь ломать веб-приложение на основном домене, а флаг лежал на поддомене, который находился за 30 секунд ручного dig с перебором нескольких типов записей.

Умение читать сырой вывод DNS-ответа и понимать, что означает каждая секция — Authority, Additional, флаги AA и TC — это навык, который отличает решающего от копирующего writeup.

Есть распространённое заблуждение, что subdomain enumeration — это «запусти subfinder и подожди». На практике пассивная разведка даёт базу, а дальше начинается ручная работа: проверка каждого найденного поддомена на нетипичные записи, поиск паттернов в именовании (есть dev1 — стоит проверить dev2, dev3, staging1), анализ CNAME-цепочек. Организаторы CTF часто закладывают подсказки в DNS-записи — SRV, HINFO, даже LOC — которые стандартные инструменты просто не запрашивают. Если хочешь не просто writeup прочитать, а пройти всю атаку самому — на WAPT эту цепочку разбирают с лабами на каждый кейс.

🚀 Хочешь закрепить на практике? Реши задачи по теме на HackerLab — категория «pentest-machines».