На внутреннем пентесте банковской сети мы запустили
dig axfr @ns2.target.bank target.bank - и получили полный дамп зоны с 340+ записями. Четыре минуты работы. Вторичный NS оказался legacy-BIND с дефолтной конфигурацией: AXFR разрешён для любого IP. В дампе - имена вроде dc01-prod, jenkins-build, vault-backup. Субдомены дали карту инфраструктуры, паттерны именования хостов - подсказки для брутфорса учёток. Дальнейший lateral movement и выход на domain admin - три дня. Пропорция показательная.DNS - точка входа, которую многие считают «тривиальной». А потом удивляются, когда именно через неё раскручивается весь engagement.
Дальше - конкретные техники DNS-разведки, cache poisoning, DNS rebinding и туннелирования с командами, ограничениями каждого метода и привязкой к MITRE ATT&CK.
Как работает DNS-протокол и где он ломается
Прежде чем ломать протокол, надо понимать его на уровне пакетов. Когда ты набираешьdig @8.8.8.8 example.com, разворачивается цепочка:Stub resolver - DNS-клиент на твоей машине - формирует UDP-пакет и отправляет его рекурсивному резолверу (здесь - 8.8.8.8). Резолвер лезет в кэш. Если записи нет - запускает цепочку запросов: к корневому серверу, затем к серверу зоны
.com, затем к авторитативному серверу домена example.com. Авторитативный сервер отвечает конкретной записью (A, MX, TXT). Резолвер кэширует ответ на время, определённое полем TTL (Time To Live) - число в секундах, после которого запись считается устаревшей.Каждый DNS-пакет несёт Transaction ID - 16-битное число, связывающее запрос с ответом. Если атакующий угадает Transaction ID и отправит поддельный ответ быстрее настоящего сервера - резолвер примет фальшивые данные. На этом строится cache poisoning.
Ключевые типы DNS-записей для пентестера:
| Тип | Содержимое | Зачем атакующему |
|---|---|---|
| A / AAAA | IPv4 / IPv6 адрес | Карта инфраструктуры |
| MX | Почтовый сервер | Вектор фишинга, определение почтовой платформы |
| NS | Авторитативные серверы | Цели для zone transfer |
| TXT | Произвольный текст (SPF, DKIM, верификации) | Утечка конфигурации |
| AXFR | Полная копия зоны | Дамп всех записей домена |
| CNAME | Алиас на другой домен | Dangling CNAME - вектор subdomain takeover |
| SRV | Сервисные записи (Kerberos, LDAP) | Обнаружение AD-контроллеров |
Корень проблемы: UDP на порту 53 без шифрования и без аутентификации ответов. Из этого растут почти все DNS-атаки.
DNS-разведка: пассивная и активная
DNS-разведка - первый этап любого пентеста. По MITRE ATT&CK это техники Gather Victim Network Information: DNS (T1590.002, Reconnaissance) и Search Open Technical Databases: DNS/Passive DNS (T1596.001, Reconnaissance).Пассивная DNS-разведка
Пассивная разведка не генерирует трафик к целевой инфраструктуре - работаешь с публичными источниками.Certificate Transparency Logs - через crt.sh находятся субдомены, для которых выпускались SSL-сертификаты. Запрос
curl -s "https://crt.sh/?q=%.target.com&output=json" | jq -r '.[].name_value' | sort -u возвращает уникальные имена. Passive DNS базы - SecurityTrails, VirusTotal хранят историю DNS-резолвов. Субдомен, который больше не резолвится, но когда-то указывал на IP - потенциальный dangling record и вектор subdomain takeover. WHOIS - whois target.com покажет NS-серверы, иногда IP-диапазоны в поле inetnum, контактные email.Инструмент subfinder (ProjectDiscovery, активно поддерживается, 10k+ звёзд на GitHub) автоматизирует сбор из десятков пассивных источников:
subfinder -d target.com -silent. По данным WhoisXML API, Amass и Subfinder - отраслевой стандарт для subdomain enumeration в пентесте.Ограничение: пассивная разведка показывает только то, что было публично. Внутренние субдомены, split-horizon DNS и свежие записи не попадут в результаты. Это начало, не финиш.
DNS zone transfer атака и subdomain enumeration
Zone transfer (AXFR) - первое, что проверяется на engagement. Если авторитативный NS разрешает AXFR с произвольных IP, атакующий получает полный дамп зоны - полный DNS enumeration одной командой:
Код:
dig axfr @ns1.target.com target.comTransfer failed. Проверять стоит каждый NS-сервер отдельно: конфигурация может различаться между первичным и вторичным. На практике вторичные NS чаще оказываются misconfigured - по документам всё закрыто, а вторичный NS просто забыли.Subdomain brute-force - перебор поддоменов по словарю.
dnsenum --dnsserver <DNS_IP> --enum -p 0 -s 0 -o subdomains.txt -f /path/to/wordlist target.com выполняет zone transfer, затем словарный перебор. dnsrecon -d target.com -a -n <DNS_IP> добавляет reverse lookup и cache snooping.Decision tree: когда какой инструмент использовать
| Условие | Действие | Инструмент |
|---|---|---|
| Начало engagement, нужна максимальная тишина | Пассивный сбор из CT logs, Passive DNS | subfinder, amass -passive |
| Есть IP авторитативного NS | Попробовать zone transfer | dig axfr, dnsrecon |
| Zone transfer закрыт, нужны субдомены | Словарный перебор | dnsenum, dnsx |
| Внутренний пентест, ищем AD-контроллеры | SRV-записи для Kerberos/LDAP | dig -t SRV _ldap._tcp.dc._msdcs.domain.com |
| Bug bounty, широкий скоуп | Комбинация пассива и актива с дедупликацией | amass + subfinder + dnsx |
Разведка AD через DNS: SRV-записи выдают контроллеры домена, серверы Kerberos и LDAP -
dig -t SRV _kerberos._tcp.corp.target.com @<DNS_IP>. Эти записи нужны самому AD, удалить их нельзя. На внутреннем пентесте это первый шаг к пониманию структуры домена.Контекст применимости: на внешнем пентесте открытый AXFR ожидаем разве что на legacy-инфраструктуре или второстепенных доменах. На внутреннем - шансы выше, особенно в сетях с DNS-серверами разных поколений.
DNS cache poisoning и DNS spoofing
DNS cache poisoning - атака, при которой поддельная запись внедряется в кэш рекурсивного резолвера. Все клиенты, обращающиеся к этому резолверу, получают подменённый IP-адрес. По MITRE ATT&CK ближайшая техника - Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001) в контексте name resolution poisoning.Атака Камински: механика и ограничения
В 2008 году Дэн Камински показал, что рандомизация Transaction ID сама по себе недостаточна. Механика такая:Атакующий отправляет резолверу запрос на несуществующий субдомен -
random123.target.com. Резолвер обращается к авторитативному серверу. Пока идёт ожидание ответа, атакующий засыпает резолвер поддельными ответами, перебирая Transaction ID. Ключевой трюк: в поддельном ответе атакующий не просто подменяет A-запись, а добавляет Additional Section, заявляя, что NS для всего домена target.com теперь находится по IP атакующего. Если Transaction ID совпал - резолвер кэширует подмену, и все последующие запросы к target.com идут через DNS spoofing.Пространство перебора: Transaction ID - 16 бит, 65 536 возможных значений. При скорости тысяч пакетов в секунду вероятность попадания ненулевая. Source port randomization (RFC 5452) добавляет ещё 16 бит, увеличивая пространство до ~1 миллиарда комбинаций.
Ограничения в современных средах:
- DNSSEC - цифровая подпись записей. Поддельный ответ не пройдёт валидацию. Но DNSSEC до сих пор внедрён далеко не везде.
- Source port randomization - стандарт с 2008 года. Проверка:
dig +short porttest.dns-oarc.net TXT @<resolver>покажет, насколько предсказуемы source-порты целевого резолвера. - DNS over HTTPS (DoH) / DNS over TLS (DoT) - шифрование транспорта закрывает MITM между клиентом и резолвером, но не защищает участок «резолвер - авторитативный сервер». DoH bypass - отдельная головная боль для blue team: если пользователь включил DoH в браузере, корпоративный DNS-прокси его не видит.
DNS rebinding атака
DNS rebinding эксплуатирует не кэш резолвера, а same-origin policy в браузере. Это отдельный вектор DNS-атаки, который пентестеры часто упускают - а зря.Атакующий владеет доменом
evil.com со своим авторитативным DNS-сервером. Жертва заходит на evil.com - браузер резолвит домен, получает IP атакующего, загружает JavaScript. DNS-сервер настроен на TTL в 1-2 секунды. Через несколько секунд JavaScript делает новый запрос к evil.com. На этот раз DNS отвечает уже внутренним IP жертвы - например, 192.168.1.1 (роутер) или 169.254.169.254 (AWS metadata endpoint). Браузер считает, что origin не изменился - домен тот же. JavaScript получает доступ к ресурсам внутренней сети.Где это стреляет: DNS rebinding атака работает против внутренних веб-интерфейсов (роутеры, принтеры, IoT), облачных метаданных (SSRF через браузер), localhost-сервисов разработчиков - Jupyter, Docker API, Redis без аутентификации. По сути, это мост между внешним и внутренним пентестом: атакующий снаружи получает доступ к сервисам за NAT через браузер жертвы.
Ограничения: Chrome с версии 94+ реализует Private Network Access (PNA) - блокировку обращений публичных сайтов к приватным IP. Firefox внедряет аналогичную защиту. На практике PNA не покрывает все edge-кейсы, а не все внутренние сервисы проверяют соответствующие заголовки.
DNS-туннелирование: C2 и exfiltration через порт 53
DNS-туннелирование - кодирование произвольных данных внутри DNS-запросов и ответов. По MITRE ATT&CK: Application Layer Protocol: DNS (T1071.004, Command and Control) и Protocol Tunneling (T1572, Command and Control).Что видит защита при DNS-атаках - и где слепые зоны
По данным CyberDefenders, ключевые индикаторы DNS-туннелирования:- Длина поддоменов - легитимные запросы короткие и читаемые. Туннельные содержат base32/base64-строки, приближающиеся к лимиту 255 символов. Порог для алерта: поддомены длиннее 50 символов.
- Shannon entropy - высокая энтропия (выше 4.0) указывает на закодированные данные. Для понимания: у слова
loginэнтропия низкая, уdGhpcy1pcw==- высокая. - Объём запросов - один хост, генерирующий тысячи запросов к одному obscure-домену, - явная аномалия.
- Редкие типы записей - всплеск TXT и NULL-запросов от одного источника.
- Возраст домена - домены младше 30 дней без веб-контента.
Красивые числа. Но вот реальность.
Слепые зоны стандартного стека:
Stateful firewall видит факт DNS-запроса на порт 53, но не анализирует содержимое. Стандартный IDS/NGFW проверяет репутацию домена и базовые сигнатуры. DNS-туннель через легитимный облачный домен с короткими запросами и низкой частотой обходит эти правила. Если в организации нет dedicated DNS security-решения или DNS-прокси с глубоким анализом - DNS-туннель невидим.
Рекомендация для обеих сторон: blue team должен форсировать весь DNS через корпоративный резолвер (блокировать прямые обращения на 53/UDP к внешним DNS), включить логирование запросов и мониторить аномалии. Пентестеру стоит проверять: если прямой DNS к внешнему серверу заблокирован - iodine не заработает. В таком случае надо использовать внутренний резолвер как транзит, что iodine поддерживает по умолчанию.
Восемь техник MITRE ATT&CK, которые мы разобрали (T1590.002, T1596.001, T1071.004, T1572, T1557.001, T1568.001, T1583.002, T1048.003), покрывают DNS-вектор от разведки до эксфильтрации. Но в реальных проектах я вижу устойчивый паттерн: команды тратят 80% усилий на web-exploitation и AD-атаки, а DNS-разведку считают тривиальной. Ошибка. Zone transfer, который «не должен работать», работает на каждом пятом внутреннем пентесте, с которым я сталкивался за последние два года. DNS-туннель спасает engagement, когда всё остальное заблокировано. DNS rebinding атака даёт доступ к внутренним сервисам вообще без присутствия в сети - через браузер жертвы. Каждый из этих векторов по отдельности выглядит «нишевым», но вместе они складываются в целый слой атаки, который многие защитные команды просто не мониторят.
Мой совет: на следующем engagement начните не с nmap, а с полного DNS-аудита скоупа - количество находок удивит. Если хочешь повторить DNS-разведку и попробовать туннелирование в контролируемой инфре - на HackerLab.pro есть задачи, где DNS-вектор нужно раскручивать от первого запроса до получения данных.
