Как расследовать облачные инциденты в Yandex SIEM

KQL (Kusto Query Language) позволяет аналитикам SOC искать события, проверять гипотезы, создавать правила корреляции и вести расследование в единой логике. В статье разберём этот процесс на двух сценариях сервиса Yandex SIEM.

Почему разные инструменты замедляют расследование инцидентов

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

Во время такой работы могут возникнуть три проблемы.

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

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

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

В Yandex SIEM для этих задач используется KQL. На одном языке можно проводить интерактивный поиск, анализировать сохранённые результаты, готовить потоковые и ретроспективные правила.

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

Как обрабатываются события в Yandex SIEM

Yandex SIEM получает события из облачной и гибридной инфраструктур. Это могут быть аудитные логи ресурсов Yandex Cloud, события Windows и Linux, сетевые данные и другие источники.

Коллекторы передают поток сырых событий. Затем система фильтрует и нормализует данные: приводит события разных поставщиков к единой схеме, которую используют запросы и правила корреляции. Аналитики получают доступ как к сырым, так и к нормализованным событиям. На их основе можно проводить расследования, создавать правила на потоке и запускать ретроспективные правила. Срабатывания правил поступают в модуль алертов Yandex Security Deck.

Технические метрики Yandex SIEM:

• Входящий поток сырых событий — 3 млн EPS
• Поток после фильтрации и нормализации — 2 млн EPS
• Хранение сырых событий — 5 лет
• Архив нормализованных событий — 90 дней горячего хранения, 5 лет холодного хранения
• Горячее хранение нормализованных событий — до 90 дней
• Среднее время поиска по одному часу данных — менее 20 секунд
• Среднее время поиска по данным за сутки — менее 60 секунд

Скорость зависит от селективности запроса. Фильтр по индексированному полю обычно выполняется быстрее, чем запрос с регулярными выражениями, многократным разбором структур и преобразованием большого объёма данных.

Как устроены запросы KQL

Запрос KQL начинается с источника данных. Далее операторы обработки последовательно связываются через вертикальную черту — пайп.

Типовая логика выглядит так:

1. Выбрать таблицу событий.
2. Отфильтровать нужные записи.
3. Извлечь или преобразовать поля.
4. Сгруппировать данные.
5. Отсортировать результат.
6. Оставить поля, необходимые для анализа или работы правила.

На вебинаре мы показывали такие конструкции:

К примеру, сочетание summarize и bin позволяет сгруппировать события по временным интервалам. Аналитик может увидеть аномальный пик на гистограмме, сузить диапазон и перейти к изучению конкретных событий.

Актуальный список поддерживаемых конструкций — в справочнике KQL.

Зачем сохранять результаты запросов в датасеты

Во время расследования результат запроса можно сохранить как именованный датасет. Он появляется в интерфейсе вместе со схемой полей, а обратиться к нему в новом запросе можно через external_table.

Так аналитик сохраняет не только текст запроса, но и полученную выборку. Это позволяет:

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

Датасеты внутри расследования доступны его участникам. Кроме того, в системе можно использовать глобальные справочные наборы данных, где перечислены подозрительные индикаторы (например, известные вредоносные команды) — лукапы.

Сценарий № 1. Поиск закрепления через Cloud Functions

Первый сценарий начинается с гипотезы threat hunting — проактивного поиска угроз.

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

Как работает проверяемая техника

Для демонстрации подготовили функцию на Python^®, которая импортировала SDK Yandex Cloud и при запуске:

• создавала сервисный аккаунт;
• назначала ему роль администратора каталога;
• создавала статический ключ;
• возвращала полученные данные в HTTP-ответе.

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

Задача аналитика — обнаружить критичные действия, которые выполнила учётная запись запуска функции.

Проверяем гипотезу с помощью KQL

Сначала отбираем события, где инициатором действия выступала учётная запись запуска Yandex Cloud Functions. Затем оставляем только успешно завершённые операции.

После этого запрос ограничиваем критичными событиями управления доступом:

• изменением привязок ролей на уровне каталога;
• изменением привязок ролей на уровне облака.

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

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

Как подготовить запрос для правила корреляции

Для интерактивного поиска может быть достаточно исходного JSON-события. Карточка алерта должна содержать понятные поля, по которым можно быстро оценить ситуацию.

Поэтому дополняем запрос:

1. Через extend извлекаем необходимые значения из нормализованного события.
2. С помощью coalesce выбираем первое заполненное поле для нескольких типов событий.
3. Через mv-expand разворачиваем массив назначенных ролей.
4. Извлекаем идентификатор и имя субъекта, назначенную роль, ресурс и тип действия.
5. Через project формируем итоговый набор полей.
6. Добавляем время события, название и критичность правила.

После этого запрос переносим из расследования в интерфейс правил корреляции Yandex SIEM.

Как получить алерт

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

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

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

Разворачиваем правило, после чего повторяем атаку. На этот раз действие появилось в системе как полноценный алерт с данными о субъекте, изменённом ресурсе и назначенных правах.

Сценарий № 2. Расследование назначения публичного IP-адреса

Во втором сценарии начинаем с готового алерта: виртуальной машине назначили публичный IP-адрес.

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

Нужно выяснить:

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

Шаг 1. Проверить сетевые соединения

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

У сетевых событий есть два направления — Ingress и Egress. С помощью case значения адресов преобразуем так, чтобы в отдельных полях всегда находились:

• адрес исследуемого инстанса;
• удалённый IP-адрес.

Удалённый адрес обогащаем геоданными с помощью пользовательской функции.

Через summarize рассчитываем количество сетевых сессий, средний объём переданных данных, время первого и последнего соединения. Результат группируем по адресу виртуальной машины, направлению трафика и удалённому адресу.

В выборке находим соединение объёмом 384 байта с адресом в Нидерландах через порт 31337. Этот признак сам по себе ещё не доказывает компрометацию, но предполагает, что на машине могло быть установлено первоначальное соединение, например reverse shell.

Шаг 2. Изучить DNS-запросы

Следующий запрос направляем к нормализованным DNS-событиям. В них обнаружились обращения к Downloads Metasploit и GitHub User Content. Вместе с подозрительным сетевым соединением это усилило гипотезу о том, что на виртуальную машину могли загружать дополнительные инструменты.

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

Шаг 3. Найти инициатора в Audit Trails

Для этого обращаемся к событиям Yandex Audit Trails.

По идентификатору виртуальной машины находим события её создания и назначения публичного адреса. В событиях — идентификатор субъекта и сведения о способе выполнения операции.

Данные указывают, что действие выполнили через консоль Yandex Cloud. После этого идентификатор пользователя использовали для поиска всей связанной с ним активности.

Шаг 4. Перейти к сырым событиям

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

Из исходного JSON извлекаем:

• время;
• тип события;
• идентификатор субъекта;
• User-Agent.

События журнала потока и DNS исключаем, поскольку их уже рассмотрели отдельно. Поиск по идентификатору учётной записи вернул около 80 событий.

В выборке обнаружились операции создания виртуальной машины, назначения публичного адреса и другие действия с ресурсами и правами. Часть назначений ролей выполнялась другим пользователем и с другим User-Agent. Это основание расширить расследование и проверить, почему учётной записи выдали соответствующие права.

Полученную таблицу сохраняем как датасет. Теперь её можно использовать в следующих запросах или передать вместе с расследованием другой команде.

Шаг 5. Перейти к реагированию

По совокупности признаков делаем вывод, что хост скомпрометирован.

Далее рекомендуется:

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

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

Как уменьшить количество лишних алертов

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

Проверять запрос на ретроспективе

Перед развёртыванием нужно выполнить запрос по историческим данным и оценить:

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

Проводить локальные тесты

Если технику можно безопасно воспроизвести в контролируемой среде, стоит проверить, что запрос обнаруживает ожидаемые действия. В сценарии с Yandex Cloud Functions мы тестировали правило на имитации конкретной атаки.

Настраивать агрегацию

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

Добавлять точечные исключения

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

Исключённые срабатывания при этом остаются доступными для анализа. Это позволяет проверить, что исключение не скрывает значимые события и не отсекает слишком большую часть данных.

Проверять цепочку от нормализации до алерта

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

Как ИИ может помочь написать KQL-запрос

KQL — распространённый язык, с которым знакомы открытые языковые модели. ИИ можно попросить написать базовый запрос по текстовому описанию гипотезы.

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

Yandex SIEM поддерживает подмножество операторов KQL. Поэтому в промпте полезно перечислить допустимые конструкции или прямо запретить использовать неподдерживаемые операторы.

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

Вопросы и ответы

Заключение

KQL связывает несколько этапов работы аналитика SOC: интерактивный поиск, threat hunting, обработку сохранённых результатов, создание правил и дальнейшее расследование алертов.

Первый сценарий показал, как гипотеза о закреплении через Yandex Cloud Functions превращается в потоковое правило. Второй — как от простого алерта о публичном IP перейти к анализу журнала потоков, DNS, Audit Trails и сырых событий, а затем сохранить результаты для следующего этапа расследования.

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