Мониторинг DNS-трафика как инструмент Threat Hunting

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

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

Почему DNS важен для Threat Hunting

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

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

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

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

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

Что именно искать в DNS-трафике

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

1. Обращения к вредоносным и подозрительным доменам

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

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

2. DGA-домены

Domain Generation Algorithm — техника, при которой вредоносное ПО генерирует множество доменных имен по алгоритму. Злоумышленнику достаточно зарегистрировать один или несколько доменов из этой последовательности, чтобы зараженные устройства смогли найти командный сервер.

В DNS-логах DGA-активность может проявляться так:

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

Например, если рабочая станция за короткий период отправляет десятки запросов к доменам вроде xj39asdqwe[.]com, pqlz91mna[.]net, mvd83akl[.]org, это может быть признаком автоматической генерации доменов. Не каждый случайный домен вредоносен, но сочетание таких признаков требует проверки.

Важно учитывать, что DGA-домены не всегда выглядят как набор случайных символов. Некоторые алгоритмы используют словари и генерируют домены из обычных слов, дат или коротких фраз. Такие домены менее подозрительны на вид и хуже выявляются простыми правилами на «случайность» имени. В таких случаях важнее анализировать массовость запросов, повторяемость паттерна, возраст доменов, долю NXDOMAIN и связь активности с конкретным устройством.

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

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

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

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

Пример подозрительного паттерна:

KRUGK4TFEBUXGIDBEBWGSZ3IOQQGC5BAORUGKIDFNZSCA33GEBSXMZLSPEQHI5L.example[.]com

ONZSWYLRAKNXW2ZJAOR2W43TFNRZSAYLSMUQGU5LTOQQGY33OM5SXEIDUNBQW4I.example[.]com

XEIDUNBQW4I.example[.]com

DPORUGK4TTFY.example[.]com

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

4. Обращения к недавно зарегистрированным доменам

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

Для Threat Hunting важны не только сами недавно зарегистрированные домены, но и контекст:

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

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

5. Typosquatting и lookalike-домены

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

В DNS-трафике стоит искать домены, похожие на:

• корпоративный домен компании;
• популярные почтовые сервисы;
• банковские ресурсы;
• облачные платформы;
• сервисы документооборота;
• системы удаленного доступа;
• мессенджеры и платформы для совместной работы.

Например, если сотрудники обычно обращаются к company.com, а в логах появляется cornpany.com, где вместо m использовано сочетание rn, это может быть признаком фишинга или попытки перехвата учетных данных.

6. Beaconing через DNS

Beaconing — это регулярная связь зараженного устройства с внешней инфраструктурой. Вредоносное ПО может периодически «стучаться» к командному серверу, проверять наличие команд или передавать короткие сообщения о состоянии.

В DNS это может выглядеть как:

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

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

Важно учитывать, что вредоносное ПО не всегда обращается к командной инфраструктуре через строго одинаковые интервалы. Чтобы усложнить обнаружение, многие beacon-механизмы используют jitter — случайное отклонение от базового интервала. Поэтому beaconing часто приходится искать на больших объемах данных с помощью статистических и поведенческих методов: анализа распределения интервалов между запросами, скользящих окон, автокорреляции, кластеризации похожих паттернов, спектрального анализа или сравнения с baseline для похожих устройств. Кроме времени важно учитывать и постоянство объема: стабильное количество запросов, похожая длина поддоменов, одинаковые типы DNS-записей, близкий размер ответов или повторяющийся объем данных за единицу времени могут указывать на автоматизированную связь даже при наличии jitter.

7. Необычные типы DNS-записей

В большинстве сред основной объем DNS-запросов связан с A и AAAA-записями, но нормальный профиль зависит от роли устройства, SaaS-сервисов, CDN, почтовой и облачной инфраструктуры. Поэтому в Threat Hunting важно смотреть не только на тип записи, а на отклонение от привычного поведения.

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

Сам по себе необычный тип записи не означает инцидент: например, TXT легитимно используется для SPF, DKIM, DMARC и верификации домена. Но если такая активность выбивается из нормы конкретного устройства, ее стоит проверить.

Какие данные нужны для DNS Threat Hunting

Чтобы DNS-мониторинг работал в Threat Hunting, аналитику мало увидеть строку с доменом. Запрос к домену может быть как обычным обращением, так и первым следом вредоносной активности. Поэтому первоочередно восстановление базового контекста DNS-события. Необходимо не просто понять, какой домен запросили, а ответить на более важные вопросы. Аналитику нужны данные, которые помогают зафиксировать событие и понять, с чем он имеет дело:

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

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

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

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

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

На этом этапе аналитику следует изучить:

• возраст домена — был ли он создан недавно или существует давно;
• дату первого появления домена в инфраструктуре — встречался ли он раньше в сети компании;
• частоту запросов — единичное это обращение или повторяющаяся активность;
• количество уникальных устройств, обращавшихся к домену — затронут один хост или сразу несколько;
• историю разрешения домена — какие IP-адреса были связаны с доменом раньше;
• ASN и географию IP-адреса — где расположена инфраструктура, к которой пытается обратиться устройство;
• связь с известными индикаторами угроз — встречается ли домен, IP-адрес или связанная инфраструктура в данных об угрозах;
• процесс или приложение, инициировавшее запрос — что именно запустило обращение;
• данные EDR, NGFW, Proxy, SIEM — подтверждается ли подозрение другими источниками;
• принадлежность устройства к подразделению или сегменту сети — насколько критичен актив и типично ли для него такое поведение.

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

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

Особенно важна связка DNS с другими источниками. DNS показывает попытку обращения, но для полноценного расследования нужно понять, что произошло дальше: был ли TCP/HTTPS-сеанс, какой процесс инициировал соединение, скачивался ли файл, были ли изменения в системе, сработали ли другие средства защиты. Так, DNS-событие может показать обращение к подозрительному домену, EDR — процесс, который инициировал активность, прокси — факт загрузки файла, NGFW — сетевую сессию, а SIEM — похожие события на других узлах. В таком виде DNS перестает быть отдельным журналом запросов и становится частью общей картины расследования.

Примеры гипотез для поиска угроз

Как правило, процесс Threat Hunting основан на тестировании гипотез: аналитик не просто просматривает DNS-логи, а заранее формулирует, какое поведение может указывать на угрозу, и проверяет это предположение на данных. Ниже несколько сценариев для SOC или ИБ-команды.

Гипотеза 1. В сети есть устройство, зараженное вредоносным ПО с DGA

Один из частых сценариев для DNS Threat Hunting — поиск устройства, которое генерирует много запросов к несуществующим или случайно выглядящим доменам. Такое поведение может быть связано с DGA: вредоносное ПО перебирает домены, созданные по алгоритму, чтобы найти командный сервер.

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

Гипотеза 2. Через DNS происходит скрытая передача данных

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

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

Гипотеза 3. Пользователи переходят по фишинговой рассылке

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

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

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

Гипотеза 4. В инфраструктуре есть неучтенное устройство

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

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

Гипотеза 5. В сети используется несанкционированный DoH или DoT

Шифрованный DNS сам по себе не является вредоносным, но в корпоративной среде может снижать видимость, если используется вне утвержденной политики. Устройство может обращаться к публичным DoH/DoT-провайдерам, приложение — использовать собственные DNS-настройки, а команда ИБ при этом перестает видеть часть DNS-запросов.

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

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

Как встроить DNS-мониторинг в Threat Hunting

Шаг 1. Определить источники DNS-данных

Сначала нужно понять, где именно собираются DNS-запросы. Источниками могут быть корпоративные DNS-серверы, защищенные резолверы, сетевые сенсоры, NGFW, EDR, Proxy, облачная инфраструктура или агенты на конечных устройствах.

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

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

Шаг 2. Нормализовать и обогатить данные

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

После нормализации данные нужно обогащать. DNS-запрос стоит дополнять данными Threat Intelligence, возрастом домена, WHOIS/RDAP, Passive DNS, географией IP-адреса, ASN, категорией домена, связью с известными кампаниями и внутренним контекстом по устройству.

Так аналитик видит не просто строку «устройство обратилось к домену», а контекст: насколько домен новый, встречался ли раньше в инфраструктуре, к каким IP-адресам разрешался, кто еще к нему обращался и насколько такое поведение типично для этого устройства.

Шаг 3. Построить базовую линию поведения

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

Без baseline любое отклонение будет выглядеть подозрительным, но базовую линию нельзя строить «средней по больнице»: пользовательские рабочие станции нужно сравнивать с похожими рабочими станциями, а не с сервером разработки или контроллером домена.

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

Шаг 4. Выбрать практические метрики

Когда данные собраны, нормализованы и сопоставлены с базовой линией, появляются практические метрики для регулярной охоты за угрозами. Их удобно рассматривать на трех уровнях: устройство, домен и инфраструктура. Так аналитик видит не только отдельное подозрительное событие, но и общую динамику: кто меняет поведение, какие домены появляются впервые и где теряется видимость.

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

• количество DNS-запросов;
• долю NXDOMAIN;
• число уникальных доменов;
• количество новых для инфраструктуры доменов;
• обращения к редким TLD и доменам с плохой репутацией;
• частоту обращений к одному домену;
• число уникальных поддоменов для одного базового домена;
• нетипичную активность по отдельным типам DNS-записей;
• запросы в нерабочее время.

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

• возраст домена;
• дату первого появления в сети компании;
• количество устройств, которые к нему обращались;
• среднюю длину поддомена;
• энтропию имени;
• количество NXDOMAIN;
• связанные IP-адреса;
• географию и ASN;
• частоту смены IP;
• наличие в TI-источниках.

На уровне инфраструктуры метрики показывают не только отдельные угрозы, но и качество самой видимости. Здесь важно отслеживать:

• долю DNS-запросов через корпоративные резолверы;
• обращения к внешним DNS-серверам;
• использование DoH/DoT;
• топ доменов и устройств по аномальной активности;
• количество новых доменов за сутки;
• заблокированные категории;
• повторяющиеся инциденты по подразделениям.

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

Шаг 5. Сформировать гипотезы

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

Шаг 6. Сопоставлять DNS с другими событиями

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

DNS-событие становится сильнее, если рядом есть другие признаки: запуск неизвестного процесса, загрузка исполняемого файла, соединение с редким IP, изменение автозагрузки, срабатывание EDR или попытка повышения привилегий.

Корреляция превращает DNS-событие из подозрения в подтвержденный инцидент. Или наоборот — помогает снять ложное срабатывание, если активность объясняется легитимным сервисом, обновлением или особенностью работы приложения.

Шаг 7. Автоматизировать проверки

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

Однако автоматизация не отменяет Threat Hunting. Она снимает рутину и помогает быстрее выделять события, с которыми уже должен работать аналитик: проверять контекст, искать связи и оценивать риск.

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

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

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

Аналитик начинает с устройства: проверяет владельца, роль, сегмент сети и критичность. Затем оценивает сам DNS-паттерн: количество запросов, интервалы, домены и ответы резолвера. После этого смотрит возраст и репутацию доменов, Passive DNS, связанные IP-адреса, географию и ASN.

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

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

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

Что дает DNS Threat Hunting

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

Раннее обнаружение компрометации

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

Выявление скрытых каналов связи

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

Контроль слепых зон

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

Обогащение расследований

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

Проверка эффективности политик безопасности

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

Главный вывод

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

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

Автор: Ярослав Яцкевич, аналитик информационной безопасности.