Detect C2 через DNS-over-HTTPS: какие алерты настроить SOC-аналитику

Varonis Threat Labs взяли открытый инструмент GoDoH, подняли C2-канал через DNS-over-HTTPS — и убедились: вредоносный домен, завёрнутый в HTTPS-запрос к Cloudflare или Google DNS, полностью невидим для стандартных DNS-логов и большинства IDS. В перехваченном трафике конечный адресат — не C2-сервер атакующего, а dns.google.com. По данным hunt.io, 70% ransomware-атак в 2023 году опирались на C2-инфраструктуру, а DoH делает обнаружение этой инфраструктуры задачей другого уровня. Множество образцов вредоносного ПО уже используют DNS-over-HTTPS для C2-коммуникаций и эксфильтрации данных. Разберу конкретные точки детекта, покажу Sigma-правило и SIEM-запрос — чтобы дежурный SOC-аналитик мог настроить алерты в свою смену.

Зачем атакующие прячут C2 в DoH-трафике

C2 (Command and Control) — канал связи между вредоносом на заражённом хосте и сервером атакующего. Через него передаются команды: загрузи модуль, выгрузи файлы, перемещайся по сети к ценным активам. В классификации MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1071 — её идентификаторы) использование протоколов прикладного уровня для C2 описано в технике T1071 — Application Layer Protocol, тактика Command and Control.

Классический C2 через DNS работает просто: вредонос кодирует данные в поддоменах — скажем, exfil-base64.evil.com — и отправляет DNS-запрос через штатный резолвер организации. SOC видит эти запросы в логах и ловит аномалии: длинные поддомены с высокой энтропией, необычные типы записей (TXT, ANY). Это классический dns tunneling, для него давно написаны рабочие правила.

DoH (DNS-over-HTTPS) — протокол, передающий DNS-запросы внутри зашифрованного HTTPS-соединения (RFC 8484, принят в 2018 году). Для SOC-аналитика это переворачивает картину:

• DNS-запрос уходит не к корпоративному резолверу, а к публичному DoH-провайдеру по порту 443
• Содержимое зашифровано TLS — IDS не видит, какой домен запрашивается
• В сетевых логах фигурирует только IP Cloudflare или Google — адрес, который никто не заблокирует по умолчанию
• DNS-логи корпоративного резолвера остаются чистыми: запрос к нему просто не приходит

Публичный DoH-провайдер работает как бесплатный прокси для вредоносного трафика. Varonis формулируют точно: «бесплатный domain fronting для вредоносной активности через DNS».

Зачем это атакующему: скрытый C2-канал позволяет месяцами удерживать связь с заражённым хостом. Через него загружают дополнительные модули, выгружают украденные данные (exfiltration), координируют lateral movement — перемещение от хоста к хосту в направлении ценных активов. По CrowdStrike Global Threat Report 2025, среднее время lateral movement после первичного доступа — 62 минуты (рекорд — 51 секунда). Пока C2-канал жив, атакующий действует свободно. По Mandiant M-Trends 2025, медианное время нахождения злоумышленника в сети до обнаружения — 11 дней. Если C2 зашифрован, этот срок может быть значительно больше.

Как устроен C2-канал через DNS-over-HTTPS

Разберём механику на примере. Атакующий контролирует домен c2.evil.example и использует инструмент вроде GoDoH (открытый proof-of-concept, протестированный Varonis Threat Labs в лабе).

Вредонос формирует DNS-запрос к encoded-cmd.c2.evil.example. Вместо отправки через корпоративный DNS-резолвер запрос оборачивается в HTTPS и уходит на публичный DoH-эндпоинт — скажем, https://dns.google/dns-query?name=encoded-cmd.c2.evil.example&type=TXT. Google DNS разрешает запрос и возвращает TXT-запись от авторитативного DNS-сервера атакующего — всё внутри зашифрованного HTTPS.

Что видит SOC-аналитик в логах: HTTPS-соединение с dns.google (IP 8.8.8.8) на порту 443. Домена c2.evil.example в логах нет — он спрятан внутри зашифрованного payload. Varonis зафиксировали этот эффект при тестировании GoDoH: FQDN (полное доменное имя) C2-сервера оказывался либо в GET-параметрах URL (зашифрованных TLS), либо в теле HTTP POST-запроса.

Вариации, которые дополнительно усложняют обнаружение c2 через dns:

• HTTP POST вместо GET — домен C2 в теле запроса, вообще не виден даже при дешифровке URL
• Собственный DoH-сервер атакующего вместо публичного — трафик идёт на неизвестный IP по стандартному порту 443, неотличимый от обычного HTTPS
• Domain fronting через CDN — техника, описанная исследователями RedTeam.pl: SNI (Server Name Indication — расширение TLS, где клиент указывает имя сервера открытым текстом при установке соединения) показывает домен CDN-провайдера, а реальный запрос уходит на DoH-сервер атакующего

Каждая из этих вариаций требует своего подхода к детекту.

Слепые зоны: почему мониторинг DNS запросов SOC не ловит DoH C2

Типичный SOC-мониторинг DNS опирается на три источника данных. Каждый из них «слеп» к DoH-каналам.

Рекомендации NIST CSF v2.0 (подкатегория DE.AE-01) требуют установленного baseline сетевых операций и ожидаемых потоков данных для пользователей и систем. Без понимания, какие процессы на каких хостах легитимно используют DoH, обнаружение аномалий невозможно.

Отдельная засада: начиная с Windows 11 и Windows Server 2022, DoH настраивается на уровне ОС — не только в браузере. Запрет DoH через браузерные GPO (Group Policy Object — механизм централизованного управления настройками Windows в домене) и рекомендации DISA STIG для Chrome, Edge и Firefox — шаг нужный, но недостаточный. Любой бинарник на хосте может самостоятельно открыть HTTPS-соединение к 1.1.1.1, минуя все браузерные ограничения. Varonis прямо пишут: «организации должны понимать, что отключение DoH через GPO в корпоративных браузерах — это не финальное решение».

Обнаружение C2 через зашифрованный DNS: три метода detection engineering

TLS SNI и IP-фильтрация: базовый doh c2 детект

До массового внедрения ECH (Encrypted Client Hello) значение SNI в TLS-соединениях передаётся открытым текстом и доступно в сетевых логах. Это самая простая точка обнаружения: если хост устанавливает TLS-соединение с SNI dns.google или cloudflare-dns.com — он использует DoH.

Публичные DoH-эндпоинты для мониторинга:

Ключевой вопрос — кто именно инициирует соединение. Chrome или Firefox с DoH в настройках — нарушение политики, но не инцидент. А вот powershell.exe, rundll32.exe или неизвестный бинарник, стучащий на 1.1.1.1 по порту 443, — красный флаг, требующий эскалации.

Ограничение метода: если атакующий поднял собственный DoH-сервер, его IP не окажется ни в каком публичном списке. Для таких сценариев нужны следующие два метода.

JA3-фингерпринтинг DoH-сессий

JA3 — метод фингерпринтинга TLS-клиентов по параметрам сообщения ClientHello: версия TLS, наборы шифров (cipher suites), расширения протокола. JA3S — аналогичный фингерпринт серверного ответа (ServerHello). Каждое приложение — Chrome, Firefox, GoDoH, кастомный C2-агент на Python — генерирует свой JA3-хэш.

Зачем это для detection engineering doh трафика: TLS-соединение к 1.1.1.1 с JA3-хэшем, не совпадающим ни с одним из корпоративных браузеров — аномалия. GoDoH или скрипт на Python дадут JA3, отличный от браузерного.

Предусловие: Zeek (ранее Bro) развёрнут на span-порту или TAP с модулем JA3 — установка через zkg install ja3. Zeek вычисляет JA3/JA3S для каждого TLS-соединения и записывает в ssl.log. Suricata поддерживает JA3 начиная с версии 4.1.

Порядок действий:

1. Собери baseline легитимных JA3-хэшей — запусти Chrome, Edge, Firefox на тестовом хосте с включённым DoH и запиши их хэши из Zeek ssl.log. Это твой «белый список»
2. Настрой фильтр в SIEM: TLS-соединения к IP из таблицы DoH-провайдеров, где JA3 не совпадает с baseline
3. Каждое несовпадение — алерт на расследование

Ограничение: продвинутый вредонос может имитировать JA3-параметры браузера, подставляя нужные cipher suites и extensions. Это требует дополнительной разработки со стороны атакующего и встречается реже, чем стандартные C2-клиенты. Но знать об этом стоит — чтобы не полагаться на один метод.

DNS beaconing detection: ловим скрытые каналы c2 по поведению

C2-маяки (beacons) «стучат» на сервер с определённой периодичностью — каждые 30 секунд, минуту, 5 минут. Даже при полном шифровании ритм соединений виден в метаданных. Этот метод работает против любого зашифрованного канала, включая кастомные DoH-серверы, где фильтрация по IP/домену бесполезна.

На что смотреть:

• Периодичность — регулярные соединения к одному IP с постоянным интервалом. Jitter (отклонение от среднего) ниже 20% указывает на автоматику, а не на живого человека
• Соотношение download/upload — метрика D3-PHDURA (Per Host Download-Upload Ratio Analysis, классификация MITRE D3FEND) выявляет аномальный обмен данными: C2-маяки обычно передают маленькие пакеты (команды), а exfiltration — большие
• Длительность сессий — DoH C2 может поддерживать длинные HTTPS-сессии с минимальным объёмом payload, что нетипично для веб-браузинга
• Время активности — соединения к DoH-провайдерам от рабочих станций в 3 часа ночи заслуживают проверки

Полезен и паттерн D3-RPA (Relay Pattern Analysis по D3FEND) — анализ паттернов ретрансляции в исходящем интернет-трафике, который помогает выявить хосты, работающие как relay-точки для C2.

Сводная таблица методов обнаружения:

Оптимальная стратегия — комбинация всех трёх. Первый ловит большинство случаев (публичные провайдеры). Второй выявляет нестандартных клиентов. Третий работает как страховка против продвинутых сценариев с собственными DoH-серверами.

Настройка алертов на dns tunneling через DoH: Sigma и SIEM-запросы для SOC-аналитика

В репозитории SigmaHQ по тегу attack.t1071 (Application Layer Protocol) доступно 79 правил детекции. Специализированного правила именно для doh malware c2 среди них пока нет. Ниже — правило, которое можно адаптировать под конкретную инфраструктуру.

Предусловие: нужны логи сетевых соединений с endpoint-агента — Sysmon Event ID 3 (Network Connection) или EDR-телеметрия, содержащая процесс-инициатор и IP назначения. Без информации о процессе правило даёт только IP-фильтрацию без контекста.

title: DoH Non-Browser Process (T1071)
logsource:
  category: network_connection
  product: windows
detection:
  doh: {DestinationIp: ['8.8.8.8','1.1.1.1','9.9.9.9'], DestinationPort: 443}
  ok: {Image|endswith: ['\chrome.exe','\firefox.exe','\msedge.exe']}
  condition: doh and not ok
level: high

Что делает правило: срабатывает, когда любой процесс кроме Chrome, Firefox и Edge устанавливает HTTPS-соединение к IP публичных DoH-провайдеров. Уровень high — легитимных причин для такого поведения почти нет.

При срабатывании алерт покажет хост-источник, процесс-инициатор (Image), IP назначения. Если в Image окажется powershell.exe, python.exe, curl.exe или неизвестный бинарник — эскалируй.

Конвертация: утилита sigma-cli (pip install sigma-cli) переводит YAML в запросы для Splunk SPL, Elastic KQL, Microsoft Sentinel и других SIEM.

Эквивалентный запрос для Splunk, если Sysmon-логи поступают в индекс:

index=sysmon EventCode=3
  dest_ip IN ("8.8.8.8","8.8.4.4","1.1.1.1","1.0.0.1","9.9.9.9")
  dest_port=443
  NOT (Image="*\\chrome.exe" OR Image="*\\firefox.exe"
       OR Image="*\\msedge.exe")
| stats count by src_ip Image dest_ip
| sort - count

В выводе — таблица с колонками src_ip, Image, dest_ip и count. Браузеры отфильтрованы, всё что осталось — подозрительно. Нулевой результат — норма; любая строка заслуживает разбора.

Практика: настраиваем обнаружение doh c2 за три шага

Шаг 1. Собрать watchlist DoH-эндпоинтов и whitelist процессов.

Возьми таблицу DoH-провайдеров из этой статьи и создай в SIEM lookup-таблицу или watchlist с их IP-адресами и доменами. Параллельно составь whitelist процессов, которым разрешено обращаться к DoH — обычно это Chrome, Edge и Firefox. Если в инфраструктуре есть приложения, легитимно использующие DoH (некоторые VPN-клиенты, агенты мониторинга), добавь их в исключения, чтобы снизить число ложных срабатываний.

Как проверить: lookup содержит минимум 10 IP-адресов и 5 доменов. Whitelist — не более 5–7 записей. Если whitelist растёт за 10, стоит разобраться, почему столько приложений используют DoH — возможно, часть из них стоит заблокировать.

Шаг 2. Развернуть Sigma-правило в SIEM.

Конвертируй Sigma-правило через sigma-cli в формат твоего SIEM. Загрузи результат как correlation rule или scheduled search. Установи schedule — раз в 5–15 минут в зависимости от нагрузки.

Предусловие: Sysmon должен быть развёрнут на endpoint с включённым EventCode 3 (Network Connection). Без Sysmon правило не получит данных о процессах. Если Sysmon не развёрнут — используй логи файрвола или EDR-телеметрию, но потеряешь информацию о процессе-инициаторе.

Как проверить: запусти запрос вручную за последние 24 часа. Если в организации есть хосты с Windows 11 и включённым системным DoH — увидишь срабатывания от svchost.exe. Это ожидаемый false positive: добавь svchost.exe в whitelist, если DoH на уровне ОС разрешён корпоративной политикой.

Шаг 3. Протестировать детект на живом трафике.

Чтобы убедиться в работоспособности правила, сгенерируй тестовый DoH-запрос не из браузера. Предусловие: доступ к командной строке на хосте с Sysmon. Выполни из терминала:

curl -s -H "accept: application/dns-json" \
  "https://dns.google/resolve?name=example.com&type=A"

В ответе — JSON с IP-адресом example.com. В SIEM через 5–15 минут (зависит от schedule) появится алерт: curl.exe обратился к 8.8.8.8:443. Если алерт есть — детект работает. Если нет — проверь, поступают ли Sysmon Event ID 3 в SIEM. Частая причина: EventCode 3 отключён в конфигурации Sysmon из-за объёма логов. Тогда включи его хотя бы с фильтром по dst_port 443.

После подтверждения добавь suppression для curl.exe на тестовом хосте, чтобы тестовые запросы не засоряли production-алерты.

Большинство рекомендаций по DoH в корпоративной среде сводятся к «заблокируй в браузерах через GPO и добавь IP DoH-резолверов в deny list на файрволе». Формально верно, на практике закрывает процентов восемьдесят. Проблема в остальных двадцати: любой бинарник может открыть HTTPS-соединение к произвольному IP на порту 443 и передать DNS-запрос внутри — никакой GPO этого не остановит. А если атакующий поднял собственный DoH-сервер, IP-фильтрация тоже бесполезна.

Настоящий навык SOC-аналитика — не знание конкретного списка DoH-провайдеров (он меняется), а умение строить детект по поведению: периодичность соединений, аномальное соотношение upload/download, нестандартные JA3-хэши, активность за рамками рабочего графика. Этот навык переносится на любой зашифрованный C2-канал — не только DoH. Наработать его по отдельным гайдам тяжело: нужна системная тренировка на реальных логах с разбором ложных срабатываний и выстраиванием приоритетов. Если SOC-мониторинг — направление, в которое вы переходите, и хочется пройти базу системно — на IB Basics показывают не теорию, а как джуны реально решают задачи в blue team.