Рассказываем про DNS-туннелирование, чем оно опасно, и что делать, если в вашем периметре появился туннель
DNS используется практически при каждом обращении к интернет-ресурсам: он преобразует доменные имена в IP-адреса и помогает устройствам находить нужные серверы. Из-за своей критической роли DNS-трафик обычно разрешен во всех сегментах корпоративной сети и может восприниматься как технический фон.
Этим пользуются злоумышленники. Они могут скрывать данные и команды внутри DNS-запросов и ответов, превращая привычный протокол в канал связи с зараженным устройством. Такой механизм называют DNS-туннелированием. Его применяют для управления вредоносным ПО, обхода сетевых ограничений и вывода информации за пределы корпоративного периметра.
Сам по себе необычный DNS-запрос еще не доказывает наличие атаки. Для обнаружения туннеля необходимо анализировать одновременно содержимое запросов, их частоту, длину доменных имен, структуру поддоменов, используемые типы записей и поведение конкретного устройства.
В этой статье я расскажу, как работает DNS-туннелирование, какие задачи с его помощью решают злоумышленники, по каким признакам можно обнаружить скрытый канал и какие меры помогают защитить корпоративную инфраструктуру.
Каждый тип сетевого взаимодействия в интернете использует свой протокол. Система доменных имён (DNS) работает по простой схеме: клиент отправляет запрос на доменное имя, а сервер отвечает соответствующим ресурсом — например, IP-адресом. Для просмотра таких запросов можно использовать nslookup — стандартную утилиту, доступную во многих операционных системах. Также популярны инструменты dig и host, которые предоставляют более подробную информацию. В случае A-запросов утилита возвращает IP-адрес домена, но существуют и другие типы записей — MX, TXT, CNAME и др. Далее разберем, как именно работает этот механизм и как его можно использовать для туннелирования данных.
DNS работает по модели запрос–ответ: клиент отправляет запрос на доменное имя, а сервер возвращает соответствующие данные, например IP-адрес. Однако механизм DNS можно использовать нестандартным способом — передавать данные, встроив их в доменное имя. Например, злоумышленник может закодировать информацию в виде поддомена и отправить такой запрос на подконтрольный ему DNS-сервер.
Если атакующий контролирует DNS-сервер, он может принимать такие запросы и извлекать из них полезную нагрузку: украденные данные, настройки, логи. В ответах злоумышленник может передавать команды, которые вредоносное ПО будет выполнять на скомпрометированной машине — например, инициировать передачу файлов или запуск определённых процессов. Команды или данные кодируются в поля DNS-ответов — например, в TXT или A-записи.
Чтобы скрыть такой обмен от базовых систем мониторинга, данные кодируются в base32/base64 или шифруются. Эти техники позволяют обходить фильтры, ориентированные на открытый текст, хотя продвинутые системы анализа трафика способны выявлять такие аномалии.
Злоумышленники применяют DNS-туннелирование несколькими способами.
Главная выгода для злоумышленника в том, что DNS-трафик почти всегда разрешен и редко глубоко проверяется. Киберпреступники этим пользуются и создают скрытый канал связи для кражи данных или управления вредоносным ПО, маскируя его под обычную сетевую активность.
К основным рискам относятся:
Базы клиентов, ноу-хау, логины и пароли незаметно утекают из сети, когда злоумышленники прячут ее прямо в DNS-запросах, кодируя данные в поддоменах. Потери вскрываются, когда уже поздно: данные давно проданы или использованы против компании.
Атакующие могут получить долгосрочный контроль над зараженными системами. Через скрытые команды в DNS-ответах они годами обновляют вредоносное ПО, производят запуск новых атак и свободно перемещаются по сети.
Традиционные средства защиты, такие как фаерволы и прокси, продолжают выполнять свои задачи, но без анализа и фильтрации DNS-трафика не могут обнаружить скрытый канал управления и защитить инфраструктуру от DNS-туннелей.
Прямой ущерб от кражи данных могут дополнить административные штрафы. В России за утечку персональных данных юридическому лицу грозит от 3 до 15 млн рублей в зависимости от количества пострадавших, а при повторном нарушении — оборотный штраф в размере 1–3% годовой выручки, но не менее 20 млн и не более 500 млн рублей. Дополнительный штраф от 1 до 3 млн рублей предусмотрен за несвоевременное уведомление Роскомнадзора об утечке. Не менее серьезным последствием становится репутационный ущерб и потеря доверия клиентов и партнеров.
Обнаружить такую атаку сложно, поскольку она маскируется под нормальный DNS-трафик. Стандартные системы мониторинга часто ее пропускают. Даже после выявления, расследование требует кропотливого анализа DNS-логов и специнструментов, съедая время и ресурсы.
DNS-туннель сам по себе не распространяет вредоносное ПО, но используется как скрытый канал управления и передачи данных. Через него злоумышленники отправляют команды зараженным устройствам, загружают дополнительные инструменты и координируют дальнейшие действия в сети, включая распространение шифровальщиков и атаки на критичные системы.
Лучше всего масштаб и последствия DNS-туннелирования показывают реальные атаки.
Эксперты из SentinelLabs и Recorded Future фиксируют тревожную тенденцию: государственные хакерские группы (APT) все чаще запускают программы-вымогатели. Целью является прибыль и маскировка шпионажа, сбивание с толку защитников и усложнение поиска виноватых.
Группа ChamelGang (или CamoFei), связанная с Китаем, с 2021 года бьет по госструктурам и критической инфраструктуре по всему миру с помощью троянца-шифровальщика CatB. Для скрытного управления атаками и передачи данных группа активно применяла DNS-туннелирование, маскируя вредоносные команды под легитимные DNS-запросы и усложняя их обнаружение.
В ноябре 2022-го ChamelGang атаковала администрацию президента Бразилии, где под удар попали 192 компьютера. В финале группа осуществила развертывание CatB и предоставили записку с требованием выкупа. Почти тогда же пострадал Всеиндийский институт медицинских наук (AIIMS). Атака CatB парализовала работу больницы, сорвав помощь пациентам.
Исследователи видят следы ChamelGang и в других атаках: на учреждение в Восточной Азии и авиаорганизацию в Индии. Там хакеры использовали свой софт BeaconLoader, используя DNS-каналы для скрытой связи с серверами управления.
Отдельная их волна атак затронула 37 компаний в Северной (основной удар), Южной Америке и Европе. Вместо CatB там применяли шифрование через Jetico BestCrypt (на серверах) и встроенный BitLocker (на рабочих станциях). Атаки шли через кастомную веб-оболочку China Chopper (miPing) и скомпрометированные контроллеры домена. Некоторые операции длились до 9 дней, другие обрабатывались за считанные часы.
Но зачем шпионам вымогатели? Ransomware создает цифровой хаос, отвлекает ИБ-команды и запутывает следы. Граница между госшпионажем и киберпреступностью размывается. Жертва может решить, что это просто бандиты, преследующие лишь финансовую выгоду, не видя настоящей цели — кражи данных. Атрибуция атаки усложняется, а истинные виновники остаются в тени. ChamelGang — живой пример такой тактики: меняя инструменты, они прикрывают следы, но добиваются своего.
В августе 2020 года были впервые раскрыты детали первой известной успешной атаки группы OldGremlin. Их мишенью стала крупная российская медицинская компания с филиалами по всей стране. Все началось с фишингового письма, искусно замаскированного под рассылку медиахолдинга РБК.
На первом этапе взломщики использовали уникальный бэкдор TinyNode. Эта программа тайно загружала дополнительное вредоносное ПО. Получив доступ к компьютеру сотрудника, злоумышленники начали разведку сети: искали ценные данные и точки для распространения. Как и многие профессиональные группы, OldGremlin применяла инструмент Cobalt Strike для максимальной эффективности. DNS-туннель маскировал вредоносные команды и передачу данных под видом легитимных DNS-запросов, помогая избежать обнаружения.
Действуя методично, хакеры продвигались по корпоративной сети. Обнаружив нужный домен, они получили права администратора и даже создали скрытую резервную учетку на случай блокировки основной. DNS-туннелирование, созданное с помощью TinyNode, продолжало обеспечивать скрытый канал управления на этом этапе.
Резервные копии компании не спасли положение. Спустя недели после проникновения взломщики просто стерли их. В выходные, всего за несколько часов, их вирус-шифровальщик TinyCryptor захватил сотни компьютеров сети.
В понедельник сотрудники увидели на экранах сообщение: "Ваши файлы зашифрованы. Свяжитесь с нами по адресу...". Контакт — каждый раз новый почтовый ящик на ProtonMail. Региональные отделения клиники остановились. Цена расшифровки — 50 000 долларов в криптовалюте.
Пауза у OldGremlin была недолгой. Уже 13-14 августа 2020 года эксперты Group-IB зафиксировали две новые волны атак. Хакеры снова маскировались под РБК, а также под горно-металлургическую компанию. За два дня около 250 вредоносных писем ушли в финансовый и промышленный сектор России. В этот раз отправители были вымышленными.
Группа быстро адаптировалась к новостной повестке. 19 августа, используя тему протестов в Беларуси, они разослали письма якобы от Минского тракторного завода (МТЗ). Цели — российские банки.
Впоследствии, группа злоумышленников разослала фишинговые письма вместо обычного спама, ловко вплетая в них свежие новостные заголовки. Ссылки в письмах вели на вредоносные ZIP-архивы, а для маскировки злоумышленники использовали сервисы сокращения URL вроде bit.ly.
DanaBot — классическая ПО-услуга (MaaS). Админы сдавали его в аренду за $500+ в месяц. Этот модульный инструмент, стоящий в одном ряду с Emotet или QakBot, крадет данные и открывает двери для вымогателей. За ним стоят группы Scully Spider и Storm-1044.
Написанный на Delphi, он вычищает жертв под ноль: банковские сессии, пароли, криптокошельки, историю браузера. Злоумышленники получают полный контроль: запись клавиатуры, удаленный доступ, даже съемку экрана.
Связь с командными серверами идет через многоуровневую цепочку прокси. С помощью DNS-туннелирования они незаметно прятали управляющие команды и украденные данные в потоке обычных DNS-запросов, помогая обходить простые системы защиты. Одновременно работало 5-6 промежуточных серверов. Основные жертвы — в Бразилии, Мексике и США.
Особо опасна была вторая версия, атаковавшая по заказу военные и правительственные структуры США и Европы с 2021 года. Она записывала все действия пользователя, а DNS-туннели тихо прокладывали путь для этой утечки, маскируя передачу под легитимный трафик.
Вместо явных подключений к C2, бот отправлял данные через зашифрованные DNS-запросы к подконтрольным доменам. Для сетевых фильтров это выглядело как разрешение имен — рутинная операция. На стороне злоумышленников специальные серверы расшифровывали спрятанную в запросах информацию.
Поймать злоумышленников, злоупотребляющих DNS, — задача, недосягаемая для базовых фаерволов или обычных систем мониторинга, поскольку они просто пропускают эту угрозу. Хакеры мастерски прячут краденые данные и команды управления внутри "легитимных" DNS-запросов. Чтобы их выявить, нужны два типа глубокого анализа, и оба требуют специализированных инструментов.
Анализ содержимого запросов (Payload) — это поиск аномалий в самих DNS-пакетах. Специализированные решения проверяют структуру доменных имен, типы DNS-записей и передаваемые данные. Признаками туннелирования могут быть неестественно длинные и плохо читаемые домены, редкие типы записей или последовательности, похожие на кодирование base64. При ручном сравнении такие домены часто заметно отличаются от обычных и могут бросаться в глаза. Однако человек физически не способен просматривать большие объемы DNS-трафика, поэтому для постоянного контроля нужны алгоритмы, которые автоматически анализируют миллионы запросов и выявляют отклонения.
Анализ поведения трафика, фокусируемый на объемах и частоте. DNS-туннель неизбежно создает аномальную активность: тысячи запросов к одному подозрительному домену-призраку, резкие, необъяснимые всплески DNS-трафика, которые кричат о скрытой утечке. Но чтобы их услышать, нужны системы, которые постоянно отслеживают ваш сетевой фон, знают вашу норму и мгновенно реагируют на малейшие отклонения.
Ни один признак сам по себе не подтверждает наличие DNS-туннеля. Для точного обнаружения необходимо учитывать их совокупность: структуру запросов, статистические аномалии, репутацию домена, поведение устройства и контекст из других средств защиты. Расшифровать передаваемые данные удается не всегда, но для выявления подозрительного канала это не обязательно.
Такой многоуровневый анализ используется в SkyDNS. Наше решение проверяет поддоменные имена на признаки закодированной информации, включая различные системы счисления, базовое кодирование и Base64. Подозрительные запросы направляются в отдельный контур обработки, где их содержимое декодируется и передается языковой модели. Она определяет, присутствуют ли в нем осмысленный текст, команды или инструкции, характерные для скрытого канала управления.
Дополнительно SkyDNS анализирует поля EDNS, через которые могут передаваться фрагменты файлов, служебная информация или инструкции для вредоносного ПО. Такой подход позволяет выявлять DNS-туннели не только по внешним аномалиям трафика, но и по содержимому запросов. При подтверждении угрозы нелегитимный запрос блокируется автоматически.
DNS-туннель может месяцами маскироваться под обычные запросы, пока злоумышленники передают команды или выводят конфиденциальные данные небольшими фрагментами. В результате компания рискует столкнуться с утечкой, потерей контроля над зараженными устройствами и развитием атаки внутри сети.
SkyDNS анализирует структуру поддоменов, признаки кодирования и поля EDNS, декодирует подозрительные данные и блокирует нелегитимные запросы.
Протестируйте SkyDNS и проверьте, нет ли в вашей инфраструктуре скрытых DNS-туннелей, через которые данные могут уходить прямо сейчас. Регистрация
Автоматические средства помогают обнаруживать подозрительную активность в реальном времени, однако при расследовании инцидента аналитикам могут потребоваться инструменты для изучения сетевых дампов и восстановления отдельных DNS-сообщений.
DNShunter. Python-инструмент для анализа DNS-трафика в .pcap-файлах, разработанный для MercenaryHunt Framework и Mercenary Linux. Он извлекает DNS-запросы и ответы, а также дополняет сведения о доменах и связанных IP-адресах географическими данными. Инструмент может быть полезен при ручном расследовании подозрительной DNS-активности, однако не является специализированной системой автоматического обнаружения DNS-туннелей.
reassemble_dns. Инструмент для извлечения и восстановления DNS-сообщений из .pcap-файлов. Он собирает фрагментированные IP-пакеты и DNS-соединения по TCP, поддерживает IPv4, IPv6, UDP и TCP. Сам по себе инструмент не определяет, является ли трафик туннельным, но помогает подготовить данные для ручного расследования или обработки другими средствами.
Для создания DNS-туннелей злоумышленники могут использовать готовые утилиты, которые находятся в открытом доступе. Эти же инструменты применяются специалистами по информационной безопасности в рамках пентестов. Они позволяют воспроизвести типичный сценарий атаки и проверить, обнаруживает ли система скрытый канал, определяет ли источник запросов и формирует ли событие для расследования.
Многие инструменты для создания DNS-туннелей находятся в открытом доступе и сопровождаются документацией. Для человека, который понимает основы сетей и кибербезопасности, а также умеет работать с кодом или командной строкой, порог входа сравнительно невысок: готовое решение можно развернуть значительно быстрее, чем разрабатывать его с нуля. При этом настройка сервера, клиента и сетевой инфраструктуры все равно требует времени и технической подготовки, поэтому для пользователя, который не привык работать с такими инструментами, задача может оказаться заметно сложнее.
Таким образом, доступность готовых утилит упрощает создание DNS-туннелей, но не делает запуск атаки полностью автоматическим. Опасность заключается в другом: при отсутствии постоянного контроля такой канал может долго оставаться незамеченным. Для противодействия нужны специализированные системы, которые в реальном времени анализируют DNS-трафик, выявляют подозрительные паттерны, аномальные объемы запросов, необычную структуру доменных имен и признаки кодирования данных.
DNS-запросы корпоративных устройств следует направлять через контролируемые резолверы. Прямой доступ к публичным DNS-сервисам, а также несанкционированным провайдерам DoH и DoT необходимо ограничивать в соответствии с политиками компании. Это позволяет сохранить видимость трафика и применять единые правила анализа.
При этом важно учитывать не только рабочие станции в офисе, но и удаленных сотрудников, филиалы, серверы, IoT-устройства и гостевые сегменты. Если часть инфраструктуры использует сторонние резолверы или собственные DNS-настройки приложений, у команды ИБ возникает слепая зона.
На возможное туннелирование могут указывать:
Энтропия помогает оценить степень случайности строки: обычные “читабельные” домены чаще содержат знакомые слова и повторяющиеся сочетания, тогда как передаваемые через туннель данные могут выглядеть как бессмысленный набор букв и цифр. Однако единого порогового значения не существует. Этот показатель необходимо оценивать вместе с длиной домена, частотой запросов, типами DNS-записей и обычным поведением конкретного устройства. Исследования действительно рассматривают энтропию как один из признаков DNS-туннелирования, но не как самостоятельное доказательство атаки.
Подозрительную активность полезно сопоставлять с данными о домене: его возрастом, репутацией, историей разрешения, связанными IP-адресами и инфраструктурой. Обращение к недавно зарегистрированному или ранее не встречавшемуся домену не доказывает атаку, но в сочетании с длинными поддоменами, высокой частотой запросов и необычным поведением устройства повышает уровень риска.
Такой контекст помогает отделять возможный туннель от легитимной активности сервисов, которые также могут создавать большое количество динамических поддоменов.
DNS-события полезно передавать в SIEM и сопоставлять с телеметрией EDR, NGFW, IDS/IPS и систем инвентаризации. Такая корреляция помогает связать запрос с устройством, пользователем и процессом, а также определить, является ли подозрительная активность частью более крупной атаки.
Например, аналитик может проверить, какой процесс инициировал обращения, запускался ли перед этим неизвестный файл, были ли соединения с другими подозрительными ресурсами и наблюдалась ли похожая активность на соседних хостах.
DNS в этом случае становится не изолированным источником событий, а полноценным контекстом для расследования.
В рамках согласованного тестирования специалисты могут использовать те же утилиты, которые применяются злоумышленниками для создания DNS-туннелей. Это позволяет проверить инфраструктуру на реальных техниках и оценить, обнаруживает ли система подозрительные запросы, определяет ли их источник и запускает ли предусмотренный сценарий реагирования.
Такие проверки необходимо проводить только в изолированной или заранее согласованной среде. Важно оценивать не только сам факт срабатывания, но и полноту события: исходное устройство, домен, тип DNS-записи, частоту обращений, временной диапазон и связанные сетевые действия.
Результаты тестирования помогают понять, проходят ли все DNS-запросы через контролируемую инфраструктуру, видит ли система медленные туннели и разные способы кодирования, а также получает ли команда достаточно данных для расследования.
При подозрении на DNS-туннель важно действовать не только на уровне домена.
Одной блокировки домена недостаточно. DNS-туннель является каналом управления и передачи информации, поэтому важно установить источник компрометации, удалить вредоносное ПО и исключить повторное появление канала через другой домен.
DNS-туннелирование редко обнаруживается по одному очевидному признаку. Надежное выявление строится на сочетании анализа содержимого запросов, поведения устройств, репутации доменов и контекста из других средств защиты.
Ручной анализ полезен при расследовании, но для постоянного контроля необходима автоматическая обработка DNS-трафика. Она позволяет анализировать большие объемы запросов, выявлять подозрительные последовательности, замечать медленные туннели и связывать события с конкретными устройствами.
Контроль DNS-трафика помогает обнаружить скрытый канал управления или передачи данных до того, как он станет частью более масштабной атаки. Поэтому DNS должен рассматриваться не как технический фон, а как самостоятельный и информативный уровень корпоративной защиты.
