DOOM через DNS: как легитимный протокол становится транспортом для вредоносных нагрузок

Инженер по безопасности Адам Райс (Adam Rice), специализирующийся на создании CTF-задач, регулярно использует DNS TXT-записи для доставки полезных нагрузок в своих сценариях. Идея проста: TXT-записи - это произвольные текстовые поля без какой-либо валидации содержимого. Если через них можно доставить шеллкод, то почему не целую программу?

DNS — протокол без встроенного контроля содержимого. Именно это свойство делает его удобным транспортом не только для резолвинга имён, но и для произвольных данных. Инженер по безопасности Адам Райс наглядно показал это, реализовав запуск DOOM целиком через TXT-записи одной DNS-зоны.

Как это реализовано

Архитектура проекта состоит из двух частей: серверной (подготовка и загрузка данных в DNS) и клиентской (скачивание и запуск).

Серверная часть

1. За основу взят managed-doom - порт оригинального движка DOOM на чистый C#. Выбор не случаен: .NET-сборки (managed assemblies) можно загрузить в память через Assembly.Load() из массива байт, без записи файлов на диск (удобный метод для "стелс"-вирусов, кстати).

2. Форк движка (doom-over-dns) потребовал серьёзных модификаций:

• Убрана работа с файловой системой - загрузка WAD-файла переведена на MemoryStream.
• Заменена нативная оконная библиотека GLFW на прямые Win32 API-вызовы через P/Invoke.
• Полностью удалён звук (для экономии места в DNS-записях).
• Компиляция переведена с Native AOT на framework-dependent .NET 8 - иначе рефлексия невозможна.

3. С компрессией WAD-файл сжимается с 4 МБ до 1.7 МБ, бандл DLL - с 4.4 МБ до 1.2 МБ. Итого ~3 МБ данных, закодированных в base64, распределённых по 1 966 TXT-записям в одной DNS-зоне (в целом не рекордное количество и DNS-хостинги такое позволяют).

4. Загрузка записей выполняется через CloudFlare API (скрипт Publish-DoomOverDNS.ps1). Процесс занимает около 15 минут. Используется зона CloudFlare Pro (до 3 400 записей).

Клиентская часть

PowerShell-скрипт Start-DoomOverDNS.ps1 - около 250 строк кода:

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

2. Последовательно резолвит ~2 000 TXT-записей через стандартный Resolve-DnsName.

3. Декодирует base64, собирает данные в памяти, проверяет целостность по хешу.

4. Загружает .NET-сборки через рефлексию (Assembly.Load()) и запускает игру.

Весь процесс занимает 10–20 секунд. На диск не записывается ни одного файла.

Параметры проекта

DNS как транспорт - давно не шутка

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

DNS-туннелирование

Инструменты Iodine и dnscat2 существуют уже много лет. Iodine позволяет туннелировать полноценный IPv4-трафик через DNS-запросы - создаётся виртуальный сетевой интерфейс, и удалённые машины работают как будто в одной сети. Dnscat2 ориентирован на создание зашифрованных C2-каналов (Command & Control) через DNS, поддерживая типы записей A, AAAA, CNAME, MX, TXT.

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

Реальные атаки

• SUNBURST (SolarWinds, 2020) - один из крупнейших инцидентов в истории кибербезопасности. Бэкдор использовал DNS-запросы для C2-связи: идентификаторы жертв кодировались в поддоменах.

• OilRig (APT34) - иранская APT-группировка с 2016 года использует кастомные инструменты DNS-туннелирования (Helminth, ISMAgent, BONDUPDATER) как основной метод C2-коммуникации.

• Cobalt Strike DNS Beacon - утёкшие версии легитимного инструмента стали стандартом у реальных атакующих. DNS Beacon полностью управляет заражённой системой через DNS-запросы к порту 53.

Доставка малвари через TXT-записи

В июле 2025 года исследователи DomainTools задокументировали малварь Joker Screenmate - код был разбит на фрагменты и спрятан в DNS TXT-записях нескольких поддоменов. Каждый фрагмент по отдельности выглядел безобидно, но при последовательном запросе и сборке превращался в рабочий payload. Рядом с «шуточным» кодом обнаружился PowerShell-стейджер, способный загрузить и выполнить произвольную нагрузку.

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

ICMP-туннели и другие «творческие» протоколы

DNS - не единственный протокол, который эксплуатируют подобным образом.

ICMP-туннелирование - данные инкапсулируются в ICMP Echo Request/Reply (обычный ping). RFC 792 не ограничивает содержимое поля data в ICMP-пакетах, поэтому туда можно вложить произвольную полезную нагрузку:

• icmptunnel - туннелирует весь IP-трафик через ICMP echo/reply, создавая виртуальный интерфейс. Используется для обхода captive-порталов и файрволов.

• ptunnel - туннелирует TCP-соединения через ICMP, обеспечивая ~50 Kbps пропускной способности.

• icmpsh - реверс-шелл, полностью работающий по ICMP.

pingfs - файловая система, хранящая данные исключительно «в интернете» в виде ICMP Echo-пакетов, постоянно летающих между хостами. По сути - delay line memory образца XXI века. Данные существуют только пока пинги ходят туда-обратно.

Сравнение техник скрытых каналов

Почему это важно для ИБ

Проект DOOM over DNS наглядно демонстрирует то, о чём специалисты по безопасности (и мы) говорим: DNS - часто слепая зона корпоративных сетей. Более 91% вредоносного ПО использует DNS на тех или иных этапах атаки, при этом почти 60% организаций не осуществляют мониторинг DNS-трафика на регулярной основе.

Всё, что показал Райс - base64-кодирование данных в TXT-записях, побайтовая сборка в памяти, запуск через рефлексию без записи на диск - является точным описанием техники, которую уже используют реальные атакующие.

С точки зрения защиты здесь сходятся несколько факторов:

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

• Отсутствие артефактов на диске. Ни одного файла не создаётся - антивирусные сканеры, работающие с файловой системой, бесполезны.

• Массовость запросов. Пачка из 2 000 TXT-запросов за 10–20 секунд - это аномалия, которую можно и нужно детектировать.

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

Именно для закрытия этой «слепой зоны» существуют решения уровня DNS Security: анализ энтропии доменных имён, эвристики по частоте и объёму запросов, ML-модели для детектирования аномального поведения. Как подробно разобрано в нашем обзоре, фильтрация DNS-трафика - это первый рубеж, который блокирует угрозу ещё до установления TCP/TLS-соединения.

Выводы

Проект DOOM over DNS - красивая инженерная работа, наглядно показывающая возможности протокола, которому почти 45 лет. Но для индустрии безопасности это одновременно и напоминание: каждая «весёлая демонстрация» - это proof of concept для атакующих.