Поиск сетевых аномалий в KATA NDR

Введение

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

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

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

Вместо поиска явных индикаторов атак технология NAD (Network Anomaly Detection) анализирует весь трафик на предмет подозрительных признаков, которые не соответствуют типичной сетевой активности узла. Среди решений «Лаборатории Касперского» эту технологию, в частности, реализует платформа Kaspersky Anti Targeted Attack (КАТА).

Система анализирует данные пакетов сетевого трафика (например, DNS, DCE/RPC, Kerberos и др.) и извлекает из них важные параметры, которые используются для выявления аномального поведения. Такой подход позволяет искать атаки на контроллеры домена, признаки туннелирования и эксфильтрации трафика, C2-коммуникации и другие сценарии, которые могут указывать на факт компрометации сетевой инфраструктуры.

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

Обнаружение атаки Kerberoasting в KATA NDR

Почему Kerberoasting сложно обнаружить стандартными средствами

Атака Kerberoasting основана на штатной логике работы протокола Kerberos. Атакующий находит сервисные учетные записи с идентификатором Service Principal Name (SPN), запрашивает для них TGS-билет (Ticket-Granting Service) и пытается подобрать пароль, используя полученный билет и перебор по словарю. Если пароль слабый или давно не менялся, злоумышленник при помощи брутфорса может получить его в открытом виде. Впоследствии скомпрометированные учетные данные могут использоваться для вертикального и горизонтального перемещения по сети.

Суть атаки Kerberoasting заключается в том, что злоумышленник, имея скомпрометированную учетную запись с низкими привилегиями, а также действительный TGT-билет (Ticket-Granting Ticket) для этой учетной записи, может запрашивать TGS-билеты с ослабленным шифрованием для сервисных учетных записей с SPN. При этом не имеет значения, есть ли у скомпрометированной учетной записи права на доступ к этому сервису.

Получив эти билеты, злоумышленник может расшифровать их локально, без сетевой активности, путем перебора паролей. Таким образом он получает хэш пароля сервисной учетной записи.

Цель злоумышленника — найти сервисную учетную запись с простым паролем. Скорее всего, это будет учетная запись, созданная администраторами инфраструктуры или конкретного сервиса вручную. Именно поэтому злоумышленников не интересуют системные сервисные учетные записи с SPN (например, CIFS/fileserver.company.local), так как они создаются автоматически и имеют очень сложные пароли, которые невозможно подобрать методом брутфорса.

Следует отметить, что запросы билетов TGS, которые делают злоумышленники, не отличаются от обычных запросов. В любом домене всегда будет много трафика Kerberos. В этом и заключается сложность детектирования Kerberoasting: легитимные запросы на получение билетов для служб (TGS-REQ) неотличимы от запросов атакующих. Поэтому основным методом выявления является корреляция косвенных признаков, а не сигнатурный поиск.

Ключевые индикаторы включают: аномальный источник запроса (нетипичный хост или учетная запись), резкое увеличение числа запрашиваемых SPN за короткий временной интервал, попытки получения сервисных билетов для чувствительных или привилегированных сервисных учетных записей, а также нестандартное время и количество запросов в сравнении с историческим профилем пользователя и конечного хоста.

Большинство этих признаков позволяет детектировать технология NAD, помогая аналитику перейти от большого массива Kerberos-трафика к конкретной гипотезе: кто мог начать атаку Kerberoasting, какие сервисные учетные записи оказались в зоне риска и почему эта активность отличается от обычной.

В рамках рассматриваемой атаки сетевой аномалией является то, что за короткий промежуток времени один хост, вероятно, используя одну учетную запись (cname), получает TGS-билеты ("msg_type": "KRB_TGS_REP") для множества уникальных сервисов с SPN (sname). Эти сервисные учетные записи не являются системными.

Пример пары событий «запрос TGS-REQ — ответ TGS-REP» из атрибутов сетевой сессии

Для детектирования этой аномалии в правиле технологии NAD «Признаки атаки Kerberoasting» реализована следующая логика:

1. Среди сетевых сессий по протоколу Kerberos за период, равный глубине поиска правила, отбираются только те, в которых был получен успешный Kerberos-ответ TGS-REP. При этом необходимо соблюдение следующих условий:
   • IP-адрес, с которого была инициирована сессия, не должен быть исключен в переменной excl_sip;
   • имя клиента, отправившего запрос (cname), не должно быть в списке исключенных пользователей (переменная excl_users);
   • SPN (sname) не должно быть исключено из самого правила. Из логики исключены системные SPN. Они присутствуют в большинстве инфраструктур и не представляют интереса для злоумышленников в рамках подобной атаки, однако если они будут учитываться в общем количестве уникальных SPN, то могут вызвать ложное срабатывание правила за счет превышения заданного порога.
2. Из таких сессий извлекается cname (имя клиента, отправившего TGS-REQ) и sname (сам SPN).
3. Сессии группируются по IP-адресу источника запроса и имени учетной записи клиента (cname), агрегируя сессии с уникальными SPN.
4. Если для одного IP-адреса под одной учетной записью клиента в рамках периода, равного глубине поиска, были получены ответы TGS-REP для N уникальных имен SPN (где N больше или равно значению переменной порога count_spns) — генерируется алерт.
5. В течение периода, равного времени разрешения повтора события, все последующие алерты, связанные с одним и тем же IP-адресом клиента, будут объединены в первый алерт. Это позволит избежать создания новых событий за счет увеличения счетчика агрегации алертов (показатель «Всего появлений»).

Следует отметить, что подобную логику не получится реализовать с помощью IDS-сигнатур. Представим, что мы создали правило Suricata для обнаружения пакетов Kerberos типа TGS-REP. Чтобы избежать ложных срабатываний, исключим из сигнатуры список системных SPN со сложными паролями и установим порог для количества таких ответов, получаемых одним клиентом. Однако в подобном правиле невозможно учесть уникальность имен SPN; остается ориентироваться только на число пакетов. Из-за этого количество ложных срабатываний для такой сигнатуры будет очень большим, так как в любом домене будет множество полностью идентичных легитимных TGS-REP-сообщений.

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

Создание правила обнаружения сетевых аномалий

Правила технологии NAD представлены в виде SQL-запросов к БД KATA NDR на основе ClickHouse. Далее мы покажем, как добавить и запустить в работу такое правило.

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

Интерфейс страницы «Обнаружение сетевых аномалий»

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

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

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

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

Интерфейс создания нового правила NAD

Для корректной работы правила мы рекомендуем перед его запуском перейти на вкладку «SQL-запрос» и ознакомиться с используемыми в правиле переменными (описание каждой переменной доступно при наведении курсора на знак вопроса).

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

В нашем примере при помощи переменных правило «Признаки атаки Kerberoasting» можно настроить следующим образом без внесения изменений в сам SQL-запрос:

• исключить из области проверки IP-адрес источника запросов TGS-REQ (здесь можно указать одиночное значение, маску подсети или справочник со списком адресов и масок), а также учетную запись клиента, отправляющего запрос (допустимы одно значение или справочник с несколькими значениями);
• изменить пороговое значение для генерации алерта по количеству уникальных SPN из сообщений TGS-REQ.

Содержимое запроса и используемые переменные нового правила

На этой же странице можно проверить работоспособность правила перед сохранением.

Результат проверки работоспособности правила

При срабатывании такого правила будет сгенерирован алерт типа NDR:NAD. В карточке алерта аналитик видит базовую информацию: IP-адреса, порты и участников сетевого взаимодействия.

Карточка алерта правила технологии NAD

Далее можно перейти в связанное с алертом событие, где представлены подробное описание аномалии и ссылки на затронутые узлы.

Событие срабатывания правила технологии NAD

При необходимости аналитик может посмотреть и выгрузить сетевые сессии, связанные со срабатыванием правила. Их можно открыть из алерта или из самого события через выпадающее меню «Показать связи».

Сетевые сессии, вызвавшие срабатывание правила

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

Атрибуты сетевой сессии

Обнаружение DNS-туннелирования в KATA NDR

Как устроен DNS-туннель

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

Например, одним из способов реализации DNS-туннелирования является использование TXT-записей. В этом случае клиент генерирует DNS-запросы TXT-записей для доменных имен, где правая часть доменного имени (домены первых нескольких уровней) статична, а левая часть (домен нижнего уровня) используется для передачи кодированных или шифрованных данных клиентом на сервер. Структура доменного имени в таком случае будет следующая: например, ZFcABQAIBA[.]testlab[.]local, где testlab[.]local — статичная правая часть домена, а ZFcABQAIBA — изменяемая левая часть, в которой и передаются данные от клиента.

Сервер в ответ на эти запросы отправляет команды или сообщения в поле данных TXT-ответа. За счет статичности правой части доменного имени все клиентские запросы всегда попадут на один и тот же C2-сервер, даже если DNS-серверы, к которым клиент отправляет запросы, меняются.

DNS-запрос (слева) и ответ на него (справа) в рамках DNS-туннелирования через записи TXT

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

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

В результате анализа DNS-трафика в контексте задачи детектирования мы выделили три поля, представляющие интерес:

• запрошенное DNS-имя;
• тип DNS-записи;
• поле TXT-данных из ответа.

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

Обмен данными в рамках DNS-туннеля

Таким образом, в случае использования DNS-туннелирования сетевой аномалией является ситуация, когда один хост — источник запросов, отправляя данные в левой, меняющейся части доменных имен при статичной правой части (rrname), получает в ответах от DNS-сервера TXT-записи (rtype) с различными данными (rdata). При этом суммарный объем данных, переданных в левой части запрошенного доменного имени и в TXT-данных из ответа (rdata + rrname), должен быть больше заданного порога.

События запроса и ответа из атрибутов DNS-сессии

При обнаружении DNS-туннелирования следует учитывать следующие особенности:

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

Эти сложности создают вероятность ложных срабатываний при детектировании DNS-туннелирования, в частности средствами IDS. Написать точное IDS-правило на подобную активность практически невозможно. За редкими исключениями, инструменты для DNS-туннелирования имеют статичные маркеры, которые можно использовать в сигнатурном методе обнаружения. Однако если таких маркеров нет, то этот метод не сможет обеспечить высокую точность обнаружения без множества ложных срабатываний. В таких случаях необходимо применять комплексный подход, который объединяет различные признаки для повышения качества детектирования.

Логика детектирования DNS-туннелирования

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

• user_DNS_servers — список адресов внутренних DNS-серверов в инфраструктуре для корректной работы правила и снижения числа потенциальных ложных срабатываний;
• excl_sip — исключаемые из работы правила IP-адреса (можно указать один адрес, маску подсети или список из адресов и масок);
• traffic_size — пороговое значение по объему данных (в байтах), переданных в туннеле.

Переменные, используемые в правиле «DNS-туннелирование данных через записи TXT»

Правило выявления этой сетевой аномалии формируется по следующему принципу:

1. Среди сетевых сессий по протоколу DNS за временной промежуток, равный глубине поиска правила, выбираются те сессии, в которых зафиксирован хотя бы один TXT-ответ.
   При этом:
   • IP-адрес, с которого была инициирована сессия, не должен быть исключен в переменной excl_sip;
   • IP-адрес, с которого была инициирована сессия, не относится к внутренним DNS-серверам, перечисленным в переменной user_DNS_servers;
   • Запрашиваемые клиентом DNS-имена не относятся к исключаемым внутри правила.
2. Подходящие DNS-сессии разбиваются на отдельные строки, каждая из которых соответствует отдельному запросу или ответу. Из этих строк выбираются только DNS-ответы, содержащие TXT-данные.
3. Из DNS-ответов извлекаются DNS-имена и TXT-данные, соответствующие этим именам. Оставляются только уникальные значения.
4. Все строки группируются по IP-адресу источника сессий. Агрегируются все уникальные DNS-имена и TXT-данные.
5. Если для одного IP-адреса в рамках окна глубины поиска объем байт, собранных в уникальных DNS-именах и TXT-данных, больше задаваемого порога (параметр traffic_size) — генерируется алерт.
6. В течение периода, равного времени разрешения повтора события, все последующие алерты, связанные с одним и тем же IP-адресом клиента, будут объединены в первый алерт. Это позволит избежать создания новых событий за счет увеличения счетчика агрегации алерта (показатель «Всего появлений»).

Событие срабатывания правила «DNS-туннелирование данных через записи TXT»

Главная ценность технологии NAD в этом сценарии — снижение шума за счет сокращения ложных срабатываний и ускорение расследования. DNS-туннель редко выглядит как один явный вредоносный запрос. Он оставляет поведенческий след: повторяемость, длину, структуру имен, необычные типы записей, множество поддоменов с неизменной «основой» и отклонение от нормы конкретного хоста. KATA NDR собирает эти признаки в один алерт и показывает аналитику проверяемую гипотезу атаки, а не набор разрозненных DNS-событий.

Готовые правила поиска сетевых аномалий в KATA NDR

Пользователям KATA важно учитывать, что по умолчанию в продукте правила поиска сетевых аномалий (NAD) не включены. Правила необходимо добавлять вручную описанным в предыдущих разделах образом. Это обусловлено тем, что большинство правил требует ручной настройки аналитиком через переменные, что позволяет более гибко подстроить правило под конкретную сетевую инфраструктуру.

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

1. Добавить правило из готового шаблона и внести изменения в пользовательские переменные. В этом случае правило будет считаться системным.
2. Добавить правило из готового шаблона и внести изменения в его SQL-запрос (для этого потребуется активировать опцию «Разблокировать все шаблонные значения»), реализовав свое правило на основе шаблона. В таком случае правило перестает быть системным и становится пользовательским.
3. Создать пользовательское правило с нуля, для чего понадобится знать основы языка запросов к СУБД ClickHouse и ознакомиться с инструкцией.

На момент публикации в продукт поставляется 59 готовых шаблонов правил поиска сетевых аномалий (новые шаблоны могут поставляться с обновлениями продукта). Одновременно в продукте может быть включено до 200 правил.

Готовые правила делятся на 6 категорий:

• Large Data Transfers — отслеживание аномально больших сетевых сессий по различным протоколам в обычное время, ночное или в выходные дни;
• Suspicious Connections — выявление подозрительных соединений, которые потенциально могут говорить об опасной активности, теневых ИТ, попытках сокрытия от средств детектирования атак и др.;
• Domain Attacks — детектирование классических атак на доменные сетевые инфраструктуры с использованием хакерских инструментов;
• Reconnaissance Activity — подозрительная активность в рамках сетевых сессий по доменным протоколам (Kerberos, DCERPC, LDAP, DNS), похожая на разведку в домене;
• Connections to Suspicious Resources — детектирование действий, нарушающих политики ИБ, потенциальной эксфильтрации данных за пределы периметра, нелегитимного доступа в интернет из защищенных сегментов сети;
• С2 Communication — обнаружение сетевых сессий, характерных для возможного канала связи или туннеля с C2-сервером.

В таблице ниже приведен перечень шаблонов правил выявления сетевых аномалий в KATA NDR.

Заключение

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

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

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