DNS как вектор утечки данных: как работает DNS tunneling и как его обнаружить

DNS часто воспринимают как вспомогательный сетевой протокол: пользователь открыл сайт, приложение обратилось к сервису, сервер получил обновление. На практике DNS давно перестал быть просто «телефонной книгой интернета». Через него можно не только находить IP-адреса, но и передавать данные, обходить ограничения, поддерживать скрытую связь с внешней инфраструктурой и выводить информацию из корпоративной сети.

Один из таких сценариев — DNS tunneling, или DNS-туннелирование. Это техника, при которой данные упаковываются в DNS-запросы и ответы. Для легитимных задач она может использоваться администраторами, исследователями или сетевыми инструментами. Но в контексте ИБ DNS-туннель чаще рассматривают как способ скрытой коммуникации: злоумышленник использует разрешенный DNS-трафик, чтобы передавать команды, получать ответы от вредоносного ПО или эксфильтрировать данные.

Опасность DNS-туннелирования в том, что DNS почти всегда разрешен. Даже в закрытых корпоративных сетях устройствам нужно обращаться к доменам: для обновлений, облачных сервисов, почты, мессенджеров, систем мониторинга, CDN и внутренних приложений. Поэтому DNS-трафик часто проходит через периметр легче, чем другие виды соединений. Если его не анализировать, в нем может появиться скрытый канал, который долго остается незамеченным.

При этом DNS-туннель не всегда выглядит как очевидная атака. В логах это могут быть частые запросы к одному домену, длинные и постоянно меняющиеся поддомены, необычное распределение типов записей или активность, нехарактерная для конкретного устройства. Один такой признак сам по себе не доказывает инцидент. Но сочетание нескольких аномалий дает аналитику важный сигнал: DNS используется не только для разрешения имен, а как канал передачи данных.

Что такое DNS tunneling

DNS tunneling — это способ передавать произвольные данные через DNS-протокол. Вместо того чтобы открывать прямое соединение к внешнему серверу по HTTP, HTTPS, SSH или другому протоколу, устройство кодирует данные и помещает их в DNS-запросы. Внешний сервер, контролируемый атакующим, принимает эти запросы через авторитетный DNS-сервер для специально подготовленного домена.

Упрощенно схема выглядит так:

1. злоумышленник регистрирует домен, например example-attacker[.]com;
2. настраивает для него авторитетный DNS-сервер, который умеет принимать и обрабатывать нестандартные запросы;
3. на зараженном устройстве запускается клиент туннеля или вредоносный модуль;
4. клиент кодирует данные и отправляет их в виде поддоменов;
5. корпоративный DNS-резолвер пересылает запросы дальше по цепочке;
6. авторитетный DNS-сервер злоумышленника получает запросы и извлекает из них данные;
7. при необходимости сервер возвращает ответ, в котором тоже может быть закодирована команда или полезная нагрузка.

Например, вместо обычного запроса:

mail.company[.]com

в логах могут появиться запросы вида:

dGhpcy1pcy1kYXRhLXBheWxvYWQ.attacker-domain[.]com

q8f3k2sd9a1m4x7p.attacker-domain[.]com

part001.session45.device17.attacker-domain[.]com

Для DNS это все еще выглядит как обращение к поддомену. Но на самом деле левая часть имени может содержать фрагмент файла, идентификатор устройства, команду, результат выполнения команды или служебные данные туннеля.

Почему DNS удобен для скрытой передачи данных

DNS удобен злоумышленникам по нескольким причинам.

Во-первых, DNS нужен почти всем устройствам. Если полностью заблокировать DNS, большая часть инфраструктуры перестанет нормально работать. Поэтому в компаниях обычно разрешают DNS-запросы хотя бы к корпоративным резолверам.

Во-вторых, DNS часто воспринимается как низкорисковый технический трафик. Команды ИБ могут глубоко анализировать HTTP, TLS, почтовые события, EDR-алерты и сетевые сессии, но DNS-логи при этом хранить ограниченно или использовать только для базовой диагностики.

В-третьих, DNS-запрос появляется до соединения. Это делает DNS ценным источником ранних сигналов, но одновременно дает атакующим возможность использовать его как самостоятельный канал. Даже если прямое соединение к C2-серверу заблокировано, устройство может продолжать передавать короткие сообщения через DNS.

В-четвертых, DNS-трафик хорошо маскируется в большом потоке легитимных запросов. В корпоративной сети ежедневно могут проходить миллионы обращений к доменам: обновления, аналитика, SaaS, CDN, телеметрия, мессенджеры, почтовые сервисы. На этом фоне несколько тысяч подозрительных запросов от одного хоста могут затеряться, если не смотреть на поведение.

Наконец, DNS дает атакующему гибкость. Через него можно передавать данные маленькими фрагментами, менять частоту запросов, использовать разные типы записей, добавлять случайные задержки и подстраиваться под ограничения сети.

Как DNS-туннель используется в атаке

DNS-туннелирование может появляться на разных этапах атаки. Чаще всего его связывают с C2-коммуникацией и эксфильтрацией данных, но сценариев больше.

Командное управление

Вредоносное ПО может использовать DNS для связи с управляющей инфраструктурой. Зараженное устройство отправляет запросы к домену злоумышленника, а в ответ получает команды: продолжить ожидание, скачать следующий модуль, выполнить команду, передать системную информацию или изменить режим работы.

Такой канал может быть медленным, но для C2 не всегда нужна высокая скорость. Иногда достаточно коротких сообщений: «устройство активно», «пользователь вошел», «модуль установлен», «готово к следующему этапу». DNS подходит для такого обмена, потому что запросы выглядят как обычная сетевая активность.

Эксфильтрация данных

DNS-туннель может использоваться для вывода данных из сети. Файл, токен, фрагмент базы, список учетных записей или результат команды разбивается на маленькие части, кодируется и отправляется через последовательность DNS-запросов.

Например, вредоносное ПО может взять содержимое файла, закодировать его в Base32 или похожий формат, разделить на фрагменты и отправлять их как поддомены:

001.kj3h4k2h4k2h4k2h.attacker[.]com

002.l9s8d7f6g5h4j3k2.attacker[.]com

003.m4n5b6v7c8x9z1a2.attacker[.]com

На стороне злоумышленника авторитетный DNS-сервер собирает эти фрагменты обратно. Для пользователя и многих средств защиты это может выглядеть как серия DNS-запросов, а не как передача файла.

Обход сетевых ограничений

DNS-туннели могут использоваться и для обхода ограничений доступа. Например, если в сети заблокированы прямые соединения наружу, но разрешены DNS-запросы, атакующий инструмент может попытаться построить поверх DNS канал для обмена данными.

В легитимной среде похожие техники иногда применялись для обхода captive portal в публичных Wi-Fi или для тестирования сетевой фильтрации. В корпоративной инфраструктуре такой паттерн должен рассматриваться как подозрительный, если он не согласован и не связан с понятной бизнес-задачей.

Доставка данных внутрь сети

DNS-туннель может работать не только наружу, но и внутрь. Ответы DNS-сервера тоже могут содержать данные. Через них можно передавать команды, конфигурацию, фрагменты полезной нагрузки или параметры следующего этапа атаки.

Особенно важно, что вредоносному ПО не всегда нужно загружать большой файл. Иногда достаточно получить короткую строку: адрес следующего узла, ключ, режим работы, команду на запуск процесса или список доменов для дальнейшей связи.

Как данные помещаются в DNS-запросы

DNS имеет ограничения: максимальная длина имени, длина отдельной метки, допустимые символы, особенности типов записей. Поэтому данные перед передачей обычно кодируются и дробятся на фрагменты.

Чаще всего подозрительные поддомены выглядят как длинные строки из букв и цифр. Они могут напоминать Base32, Base64u и прочие Base подобные кодировки (в зависимости от тех, что позволяют DNS серверы), hex или собственный формат вредоносного ПО. Важный признак — не сама кодировка, а то, что поддомены становятся длинными, меняются от запроса к запросу и не похожи на нормальные имена сервисов.

Например, легитимные поддомены часто имеют смысловую структуру:

api.service.company[.]com

mail.company[.]com

cdn.static.example[.]com

login.region.product[.]com

Подозрительные имена при туннелировании могут выглядеть иначе:

jbswy3dpeblw64tmmq.attacker[.]com

k5xxe3deojxw4zzamfxgi33n.attacker[.]com

A8d91f0b7c92e31b4a6f.session.attacker[.]com

При этом злоумышленник может специально делать имена менее заметными: добавлять слова, имитировать служебные поддомены, менять длину фрагментов, использовать низкую частоту запросов или распределять активность по времени.

Используемые DNS- записи

Часто DNS-туннелирование связывают с TXT-записями, потому что они позволяют возвращать текстовые данные. Но ограничиваться только TXT при поиске туннеля нельзя. В зависимости от инструмента и сценария могут использоваться разные типы запросов:

• A и AAAA — для маскировки под запросы IPv6. Поле IPv6-адреса позволяет представить данные в шестнадцатеричном формате, поэтому некоторые инструменты используют ответы AAAA для передачи закодированных фрагментов данных или команд;
• TXT — для передачи текстовых фрагментов или команд;
• NULL — исторически использовался некоторыми инструментами, но в реальных сетях встречается редко;
• CNAME — для построения цепочек и маскировки;
• MX — реже, но тоже может использоваться в нестандартных сценариях;
• NS — в схемах с делегированием и управляемой зоной.

В нормальной инфраструктуре преобладают A и AAAA-запросы, но это не универсальное правило.Например, почтовые системы обращаются к MX-записям, а также чаще запрашивают TXT-записи, в которых публикуются данные SPF, DKIM и DMARC. У облачных сервисов могут быть CNAME-цепочки. У систем верификации доменов встречаются TXT. Поэтому важно смотреть не на сам факт использования TXT или CNAME, а на отклонение от нормы конкретного устройства, сегмента и домена.

Если рабочая станция внезапно начинает отправлять сотни TXT-запросов к неизвестному домену, это подозрительно. Если почтовый шлюз запрашивает TXT для известных доменов отправителей, это может быть нормой. Контекст решает.

Почему DNS-туннель сложно заметить

DNS-туннель часто не выглядит как яркий инцидент. В отличие от загрузки вредоносного файла или подключения к известному C2-адресу, здесь может не быть одного очевидного события. Есть набор слабых сигналов, которые нужно собрать вместе.

Первая сложность — объем. В крупных сетях DNS-запросов очень много. Без агрегации, нормализации и поведенческого анализа вручную искать туннель почти невозможно.

Вторая сложность — легитимные шумные сервисы. Некоторые приложения действительно генерируют длинные поддомены, используют CDN, обращаются к телеметрии, создают уникальные идентификаторы в DNS-именах или часто меняют адреса. Если не учитывать нормальный профиль, можно получить много ложных срабатываний.

Третья сложность — низкая скорость передачи. Атакующий может не пытаться вывести мегабайты за минуту. Он может передавать данные медленно: по несколько запросов в минуту, с паузами, в рабочее время, с небольшими фрагментами. Такой канал сложнее отличить от фоновой активности.

Четвертая сложность — шифрование и кодирование. Даже если аналитик видит длинные поддомены, он не всегда может понять, что именно передается. Но для обнаружения это не обязательно. Важно заметить сам паттерн: DNS используется как транспорт.

Пятая сложность — обход прямого контроля. Если устройства могут обращаться к внешним DNS-резолверам напрямую или использовать DoH/DoT вне корпоративной политики, часть DNS-активности может быть скрыта от стандартных журналов. В таком случае команда ИБ видит только фрагмент картины.

Признаки DNS tunneling в логах

DNS-туннелирование редко определяется по одному признаку. Надежнее искать комбинации аномалий.

Длинные поддомены

Один из самых заметных признаков — необычно длинные поддомены. При передаче данных клиенту нужно разместить фрагмент полезной нагрузки в имени. Поэтому левая часть домена становится длинной и плохо читаемой.

Подозрительно выглядит ситуация, когда одно устройство регулярно обращается к доменам вида:

KRUGK4TFEBUXGIDBEBWGSZ3IOQQGC5BAORUGKIDFNZSCA33GEBSXMZLSPEQHI5L.example[.]com

ONZSWYLRAKNXW2ZJAOR2W43TFNRZSAYLSMUQGU5LTOQQGY33OM5SXEIDUNBQW4I.example[.]com

XEIDUNBQW4I.example[.]com

DPORUGK4TTFY.example[.]com

Особенно важно смотреть не только на общую длину FQDN, но и на длину отдельных меток. Если одна метка постоянно приближается к техническому пределу, это сильный сигнал.

Высокая энтропия имени

Поддомены при туннелировании часто выглядят случайными: много букв и цифр, нет слов, нет понятной структуры, символы распределены не так, как в обычных доменах. Это связано с кодированием данных.

Высокая энтропия не всегда означает атаку. Легитимные сервисы тоже используют хеши, идентификаторы, токены и уникальные поддомены. Но если высокая энтропия сочетается с частыми запросами, одним базовым доменом и нетипичным устройством, это уже повод для проверки.

Много уникальных поддоменов к одному домену

При DNS-туннелировании базовый домен часто остается одним и тем же, а поддомены постоянно меняются. Например:

a1.attacker[.]com

b2.attacker[.]com

c3.attacker[.]com

d4.attacker[.]com

В реальной атаке имена будут длиннее и сложнее, но принцип тот же: много уникальных значений слева от одного домена. Для аналитика это выглядит как высокий показатель уникальных FQDN при небольшом количестве базовых доменов.

Нестандартное распределение типов записей

Резкий рост TXT-запросов, необычное использование NULL, частые CNAME-запросы к одному неизвестному домену или нетипичная активность по MX от пользовательской рабочей станции могут указывать на туннель.

Важно сравнивать устройство с похожими устройствами. Если все рабочие станции отдела делают в среднем 100 DNS-запросов в час, а одна делает 5000, причем значительная часть относится к TXT и неизвестному домену, это аномалия.

Повышенный объем DNS-трафика

DNS обычно не предназначен для передачи больших объемов данных. Поэтому попытка использовать его как транспорт часто приводит к росту числа запросов. Особенно подозрительны хосты, у которых DNS-трафик резко вырос без изменения роли устройства.

Но здесь есть нюанс: не каждый туннель шумный. Медленная эксфильтрация может не давать огромного объема. Поэтому объем нужно анализировать вместе с длиной имен, частотой уникальных поддоменов, типами записей и временем активности.

Регулярность запросов

Некоторые туннели работают с равномерной периодичностью: запрос каждые несколько секунд или минут. Это может напоминать beaconing. Вредоносное ПО проверяет команды или отправляет данные порциями.

Более продвинутые инструменты добавляют jitter — случайное отклонение от базового интервала. Поэтому искать нужно не только идеально ровные интервалы, но и устойчивые повторяющиеся паттерны.

Нетипичная активность от серверов и IoT

Особое внимание стоит уделять устройствам, которые обычно не должны активно ходить в интернет через DNS: серверы баз данных, внутренние сервисы, камеры, принтеры, терминалы, промышленные устройства, сетевое оборудование.

Если такой актив начинает регулярно обращаться к неизвестному внешнему домену с длинными поддоменами, это более подозрительно, чем аналогичная активность от пользовательского ноутбука с большим количеством приложений.

Высокая доля NXDOMAIN

Некоторые инструменты DNS-туннелирования могут генерировать большое количество ответов NXDOMAIN. Это связано с особенностями их протокола обмена, ошибками формирования запросов или способом обработки передаваемых фрагментов.

При этом высокая доля NXDOMAIN не является универсальным признаком DNS-туннеля и характерна только для отдельных инструментов и сценариев. Несуществующие имена также могут появляться из-за ошибок пользователей, некорректной работы приложений, поисковых подсказок или DGA-активности.

Поэтому NXDOMAIN стоит рассматривать только как дополнительный сигнал. Он становится значимее, если одновременно наблюдаются длинные или случайные поддомены, множество уникальных запросов к одному базовому домену и нетипичная активность от конкретного устройства.

Какие данные нужны для обнаружения

Чтобы обнаруживать DNS-туннелирование, недостаточно хранить только домен. Нужен контекст, который позволяет связать запрос с устройством, пользователем, ответом резолвера и дальнейшей сетевой активностью.

Для первичного анализа достаточно фиксировать:

• время запроса;
• исходный IP-адрес;
• запрошенный FQDN;
• тип DNS-записи;
• код ответа: NOERROR, NXDOMAIN, SERVFAIL и другие;
• содержимое ответа резолвера.

На основе DNS-запросов и ответов можно дополнительно рассчитать:

• базовый домен;
• размер запроса и ответа;
• количество уникальных поддоменов;
• среднюю и максимальную длину меток;
• долю NXDOMAIN;
• распределение типов записей;
• частоту и периодичность запросов;
• объем DNS-трафика от конкретного источника.
• Для повышения точности обнаружения помогут дополнительные сведения:
• возраст домена;
• дата его первого появления в инфраструктуре;
• количество источников, обращавшихся к домену;
• ASN и география связанных IP-адресов;
• репутация домена и его инфраструктуры.

Для расследования DNS-события можно связать с данными инвентаризации, DHCP, Active Directory, EDR, прокси и SIEM. Это помогает определить имя устройства и пользователя, установить роль актива и понять, какой процесс инициировал запросы и какая активность происходила до и после них.

DNS сам по себе показывает попытку обращения. Чтобы понять, является ли она атакой, нужно связать ее с другими источниками. Например, DNS может показать длинные поддомены, EDR — процесс, который их генерирует, NGFW — отсутствие прямой HTTPS-сессии, а SIEM — похожую активность на другом узле.

Как строить обнаружение DNS tunneling

Для поиска DNS-туннелей лучше использовать не одно правило, а несколько уровней анализа.

1. Базовые пороговые правила

На первом уровне можно настроить простые правила:

• FQDN длиннее заданного значения;
• отдельная метка домена слишком длинная;
• много уникальных поддоменов к одному базовому домену;
• резкий рост запросов нетипичных для устройства типов;
• аномально высокий объем DNS-запросов от одного устройства;
• частые запросы к домену, который раньше не встречался в инфраструктуре.

При необходимости повышенную долю NXDOMAIN можно учитывать как дополнительный признак, но только в сочетании с другими аномалиями.

2. Поведенческий baseline

Следующий уровень — сравнение с нормой. Для каждого типа устройств нужно понимать обычный DNS-профиль:

• сколько запросов в час делает рабочая станция;
• какие домены чаще всего используются;
• какие типы записей типичны;
• сколько уникальных FQDN обычно появляется;
• какие приложения создают длинные поддомены;
• как ведут себя серверы, IoT и сетевое оборудование.

Тогда подозрение вызывает не просто «много DNS-запросов», а отклонение от нормального поведения конкретного класса устройств.

Например, 3000 DNS-запросов в час для сервера обновлений могут быть нормой, а для принтера — нет. Длинные CNAME-цепочки для CDN могут быть легитимны, а длинные случайные поддомены к неизвестному домену от бухгалтерского компьютера — нет.

3. Анализ энтропии и структуры имени

Для выявления туннелей полезно анализировать структуру доменного имени:

• длину FQDN;
• длину каждой метки;
• количество меток;
• долю цифр;
• долю согласных и гласных;
• наличие словарных токенов;
• повторяемость шаблонов;
• энтропию;
• похожесть на кодированные данные.

Этот подход помогает находить поддомены, которые не похожи на нормальные имена сервисов. Но его нельзя использовать изолированно: легитимные хеши, трекинговые идентификаторы и облачные платформы тоже могут выглядеть случайно.

4. Агрегация по базовому домену

Для DNS-туннеля характерно, что разные поддомены сходятся к одному базовому домену. Поэтому полезно агрегировать события не только по полному FQDN, но и по registered domain.

Например, если устройство за час обратилось к 2000 уникальным поддоменам в зоне example[.]com, это важнее, чем 2000 запросов к разным популярным доменам.

Полезные метрики:

• число уникальных FQDN на один базовый домен;
• число запросов на один базовый домен;
• средняя длина поддомена;
• максимальная длина поддомена;
• распределение типов записей;
• число устройств, обращавшихся к домену;
• первое появление домена в сети.

Можно дополнительно анализировать долю NXDOMAIN, если есть основания полагать, что используемый инструмент или сценарий туннелирования создает такие ответы.

5. Временной анализ

DNS-туннель часто имеет ритм. Это может быть регулярная отправка данных, проверка команд или поддержание сессии.

Аналитик может искать:

• равномерные интервалы между запросами;
• повторяющиеся серии;
• активность в нерабочее время;
• всплески после запуска определенного процесса;
• стабильный объем запросов в течение длительного времени;
• медленную, но постоянную передачу данных.

Важно учитывать, что современные инструменты могут добавлять случайные задержки. Поэтому полезно смотреть не только на идеальную периодичность, но и на устойчивую повторяемость.

6. Корреляция с другими событиями

DNS-аномалия становится сильнее, если рядом есть другие признаки:

• на устройстве запущен неизвестный процесс;
• EDR зафиксировал подозрительный скрипт;
• пользователь недавно открыл фишинговое письмо;
• устройство обращалось к недавно зарегистрированному домену;
• после DNS-запросов были сетевые соединения к нетипичным IP;
• активность началась после установки нового ПО;
• похожий паттерн появился на нескольких устройствах.

Так DNS превращается из отдельного журнала в точку входа для расследования.

Пример расследования

Представим, что в DNS-логах обнаружено устройство, которое за 30 минут отправило 1800 запросов к поддоменам одного внешнего домена. Большая часть поддоменов длинная, содержит случайные наборы символов, тип записей — TXT и A, домен раньше в инфраструктуре не встречался.

Первое действие аналитика — проверить базовый контекст. Что это за устройство? Рабочая станция, сервер, IoT, тестовый стенд? Кто пользователь? В каком сегменте сети оно находится? Были ли у него похожие запросы раньше?

Второй шаг — посмотреть сам домен. Когда он зарегистрирован? К какому ASN относятся IP-адреса? Есть ли репутационные данные? Обращались ли к нему другие устройства компании? Есть ли похожие домены?

Третий шаг — изучить структуру запросов. Насколько длинные поддомены? Есть ли нумерация фрагментов? Повторяются ли идентификаторы сессии? Похожи ли строки на Base32, hex или другой формат кодирования? Как часто идут запросы?

Четвертый шаг — связать DNS с событиями на хосте. Какой процесс инициировал обращения? Запускался ли PowerShell, Python, неизвестный бинарный файл, скрипт из временной директории? Были ли изменения в автозагрузке? Появлялись ли новые службы, задачи планировщика, архивы или файлы рядом по времени?

Пятый шаг — проверить сетевой контекст. Были ли прямые соединения к IP-адресам, связанным с доменом? Не пыталось ли устройство использовать внешние DNS-резолверы? Нет ли параллельной активности по HTTPS, SSH или другим протоколам?

Если подозрение подтверждается, устройство изолируется, домен блокируется, артефакты сохраняются, а команда проверяет, не было ли похожей активности на других хостах. Важно не ограничиться блокировкой домена: нужно понять, какой процесс создавал туннель, откуда и каким способом на устройство была установлена его клиентская часть, как произошло первоначальное заражение и какие данные могли быть переданы.

Как снизить риск DNS-туннелирования

Защита от DNS-туннелей должна сочетать профилактику, мониторинг и реагирование. Просто запретить DNS нельзя, но можно сделать так, чтобы использовать его как скрытый канал было значительно сложнее.

Направлять DNS-запросы через корпоративные резолверы

Устройства не должны напрямую обращаться к произвольным внешним DNS-серверам. DNS-запросы стоит направлять через утвержденные корпоративные резолверы, где включены журналирование, политики безопасности и мониторинг.

Прямые обращения к внешним резолверам нужно ограничивать или контролировать. Иначе часть DNS-активности будет обходить видимость команды ИБ.

Контролировать DoH и DoT

DNS over HTTPS и DNS over TLS полезны для конфиденциальности, но в корпоративной среде могут снижать видимость, если используются вне политики. Приложение может отправлять DNS-запросы на публичный DoH-сервер, и стандартные DNS-логи этого не увидят.

Поэтому нужно определить, какие DoH/DoT-сценарии разрешены, какие запрещены, и как они контролируются. Задача не в том, чтобы объявить шифрованный DNS вредоносным, а в том, чтобы не потерять управляемость DNS-трафика.

Вести полноценные DNS-логи

Для обнаружения туннелей нужны детальные логи. Хранить только факт обращения к домену недостаточно. Желательно фиксировать FQDN, тип записи, код ответа, исходное устройство, время, резолвер, действие политики и дополнительные атрибуты.

Также важен срок хранения. DNS-туннель может быть медленным, а расследование может начаться через несколько дней или недель после первого события. Если логи уже удалены, восстановить картину будет сложно.

Настроить поведенческие правила

Полезно отслеживать:

• длинные поддомены;
• большое число уникальных поддоменов к одному домену;
• резкий рост TXT-запросов;
• регулярные запросы от одного устройства;
• нетипичные DNS-запросы от серверов, IoT и сетевого оборудования;
• обращения к новым или редким доменам;
• DNS-активность в нехарактерное время.

Правила должны учитывать baseline. Иначе команда быстро столкнется с большим количеством ложных срабатываний.

Использовать allowlist для критичных сегментов

Для отдельных сегментов можно ограничить DNS-активность сильнее. Например, сервер баз данных, промышленный контроллер или кассовое оборудование не должны свободно обращаться к произвольным внешним доменам.

Для таких активов можно определить список разрешенных доменов и сервисов. Все остальное должно блокироваться или уходить на проверку. Это особенно важно для систем, где установка агентских средств защиты невозможна или ограничена.

Связывать DNS с EDR, NGFW, Proxy и SIEM

DNS показывает ранний сигнал, но не всегда дает полный ответ. Для расследования нужно видеть, что произошло на устройстве и в сети после запроса.

Если DNS-лог показывает подозрительные поддомены, EDR помогает найти процесс. NGFW показывает сетевую сессию. Proxy может показать HTTP-запросы. SIEM связывает события по времени, пользователю и устройству.

Без такой корреляции DNS-аномалия может остаться просто строкой в журнале. С корреляцией она превращается в расследуемый инцидент.

Проверять инструменты администраторов и пентестеров

Не весь DNS-туннелинг вредоносен. Иногда его используют в тестах на проникновение, лабораторных задачах или сетевой диагностике. Но такие активности должны быть согласованы, ограничены по времени и известны команде мониторинга.

Если в сети разрешены тестовые DNS-туннели без уведомления SOC, это создает шум и мешает отличать проверку от реальной атаки.

Что делать при обнаружении подозрительного DNS-туннеля

При подозрении на DNS-туннель важно действовать не только на уровне домена.

Первое — ограничить активность. Подозрительный домен следует заблокировать, а устройство при наличии признаков компрометации — изолировать от сети. Блокировка домена сама по себе не мешает последующему сбору артефактов и позволяет быстрее остановить возможную передачу данных.

Второе — зафиксировать события и собрать артефакты. Нужно сохранить DNS-логи, временной диапазон, список FQDN, исходные устройства, ответы резолвера и связанные сетевые события. Также важно зафиксировать процессы, сетевые соединения, файлы, задачи планировщика, службы и другие данные с подозрительного хоста.

До завершения сбора не следует перезагружать устройство, удалять файлы, завершать процессы без фиксации или выполнять другие действия, которые могут уничтожить временные данные и следы активности.

Третье — проверить хост. Нужно понять, какой процесс создавал запросы, как он появился, какие права имел, к каким файлам обращался и были ли признаки закрепления в системе.

Четвертое — оценить возможную утечку. Для этого смотрят объем запросов, период активности, направление передачи, размер фрагментов, типы записей и содержимое доступных логов. Расшифровать данные не всегда возможно, но можно оценить масштаб и временные рамки.

Пятое — проверить похожую активность. Один зараженный хост может быть частью более широкой кампании. Нужно искать тот же домен, похожие поддомены, аналогичные паттерны и обращения к связанным инфраструктурам.

Шестое — закрыть причину. Если туннель появился из-за вредоносного ПО, нужно устранить первичный вектор: фишинг, уязвимость, слабые учетные данные, открытый удаленный доступ, небезопасный скрипт или неучтенное устройство.

Частые ошибки компаний

Одна из частых ошибок — считать DNS слишком простым и неопасным протоколом. Если DNS воспринимается только как техническая служба, его редко анализируют как источник угроз. В результате скрытая активность может идти через него неделями.

Вторая ошибка — смотреть только на известные вредоносные домены. DNS-туннель может использовать новый домен, который еще не попал в индикаторы угроз. Поэтому важны поведенческие признаки, а не только репутационные списки.

Третья ошибка — контролировать только TXT-запросы. Да, TXT часто встречается в туннелях, но не является единственным вариантом. Подозрительным может быть сочетание длинных поддоменов, частоты, уникальности и неизвестного базового домена даже при A-запросах.

Четвертая ошибка — не учитывать роль устройства. Один и тот же DNS-паттерн может быть нормальным для почтового сервера и странным для камеры видеонаблюдения. Без привязки к типу актива правила будут либо шумными, либо слишком слабыми.

Пятая ошибка — блокировать домен и закрывать инцидент. Блокировка прекращает канал, но не отвечает на главные вопросы: откуда взялся процесс, какие данные он мог передать, есть ли другие зараженные устройства и не появится ли новый туннель через другой домен.

Что важно запомнить

DNS tunneling — это не экзотическая техника, а практичный способ использовать разрешенный DNS-трафик как скрытый канал связи. Через него можно передавать команды, служебные данные, результаты выполнения команд или фрагменты украденной информации.

Главная сложность в том, что DNS-туннель редко обнаруживается по одному признаку. Длинный поддомен, необычный тип записи или высокая частота запросов сами по себе не доказывают атаку. Но если одно устройство регулярно обращается к неизвестному домену, генерирует множество уникальных длинных поддоменов, использует нетипичные типы записей и выбивается из обычного поведения, это уже сильный повод для расследования.

Для обнаружения нужны DNS-логи, поведенческий анализ и связь с другими источниками: EDR, NGFW, Proxy, SIEM, инвентаризацией активов и данными о пользователях. DNS дает ранний сигнал, но контекст помогает понять, является ли он инцидентом.

Защита от DNS-туннелирования строится не на одном правиле, а на управляемости DNS. Запросы должны идти через корпоративные резолверы, прямые обращения к внешним DNS-сервисам должны контролироваться, DoH и DoT — использоваться по понятной политике, а DNS-аномалии — попадать в мониторинг.

DNS нельзя оставлять слепой зоной. Если злоумышленник использует его для вывода данных, компания может долго не видеть полноценного соединения наружу, но следы все равно останутся в запросах. Вопрос только в том, собирает ли организация эти следы и умеет ли отличать нормальный DNS-шум от скрытого канала передачи данных.