Теперь, когда мы располагаем знаниями о соотношении сырых событий, событий безопасности (алертов) и инцидентов в MDR, мы можем углубиться в аналитику срабатываний, и начнем с анализа комбинаций хантов. Как отмечалось ранее, важным критерием для подъема размеченного хантом события до алерта является его конверсия, - поэтому есть целый ряд хантов, которые так и остаются на уровне разметки и постепенно дорабатываются различными фильтрами, а после достижения удовлетворительной конверсии могут быть переведены в алерты.
Однако, несмотря на жесткий контроль за количеством ложных срабатываний, все равно можно найти ханты, которые за год так и не произвели сконвертировавшихся в инцидент алертов, но только ложные срабатывания. При разработке правил обнаружения мы придерживаемся стратегии широкого покрытия сценария атаки, т.е. на одну и ту же реализацию техники мы разрабатываем много правил обнаружения, основанных на разных подходах: на продуктовых детектах, на TTP-based хантах, на облачном ML, и т.п. – такой подход затрудняет обход обнаружения злоумышленником. В связи с этим, очевидная идея для повышения конверсии – найти комбинации хантов, которые по отдельности показывают плохую конверсию, но в комбинации с другими – практически никогда не ошибаются.
На первом этапе поставим задачу следующим образом: найдем ханты, которые за год не сконвертиловались в инцидент ни разу, а потом найдем комбинации, где эти же ханты за тот же период имели конверсию 100%, т.е. безошибочно обнаруживали подтвержденный инцидент. Для решения этой задачи выгрузим все алерты за исследуемый период и сгруппируем их по комбинациям хантов, которыми размечены события в составе алертов. В результате получим таблицу, приведенную ниже. Таблица достаточно большая, поэтому приедем первые несколько строк. Размер таблицы зависит от количества хантов и разнообразия наблюдаемых инцидентов, в нашем случае по данным за 2023 год размер таблицы составил 11 227 строк.
В таблице следующие колонки:
- Hunts – комбинация хантов, записанных через пробел
- All – количество алертов с такой комбинацией
- Published – сколько из этих алертов в итоге были связаны с опубликованными заказчикам инцидентами
- Conversion – конверсия, отношение количества published к количеству all.
Как отмечали выше, для начала сфокусируемся на комбинациях хантов (понятно, что «хант» – это то же, что «комбинация хантов» с одним хантом в комбинации), которые срабатывали часто, но имели нулевую конверсию. Допустим, что «часто» означает «более чем раз в день», поэтому из множества комбинаций хантов с нулевой конверсией выберем те, которые сработали не менее 365 раз за год. Таких комбинаций также очень много, поэтому снова приведем несколько первых строк таблицы.
Подавляющее большинство комбинаций хантов с нулевой конверсией – из одного ханта, но попадаются и комбинации, например, на скриншот попала комбинация spawning_lolbin_by_ms_office_app, spawning_process_from_ms_office_packager, в фактическом результате таких, практически всегда «фолсящих» довольно много. Следует отметить, что такие «фолсящие» комбинации тоже предмет анализа, поскольку это один из методов определения дублеров. Когда количество хантов измеряется тысячами, добавление новых может частично (в некоторых сценариях) дублировать существующие. Как в школе учитель определяет списывающего, точь-в-точь повторяющего ошибки первоисточника, так и здесь одинаково ошибающиеся ханты – претенденты на ревью.
Итак, получив комбинации с нулевой конверсией, давайте посмотрим на комбинации с конверсией 100%, или около того, а чтобы выявить какие-то системные случаи, возьмем комбинации, которые срабатывали более 10 раз (выбор этого числа не основан ни на чем, поэтому им можно управлять и получать результат, нужный конкретно вам). Таблица ниже, как и прежде, представлена несколькими первыми строками.
Итак, имея комбинации хантов, дающие конверсию 0 – «фолсящие комбинации», и комбинации с хорошей конверсией – «точные комбинации», попробуем ответить на вопрос: в комбинации с какими другими хантами «фолсящие комбинации» дают хорошую конверсию, т.е. превращаются «в точные комбинации». Для решения этой задачи надо найти точные комбинации, в которые входят фолсящие комбинации. Для проведения анализа я построил такую табличку, как обычно, приводедены первые несколько строк.
К известной ранее табличке с фолсящими комбинациями в колонке «hunts» и количеством срабатываний за период в колонке «all» добавилась колонка «combination_to1», содержащая перечень точных комбинаций, в которых повторяется данная фолсовая. Очевидно, что фолсовая комбинация может встречаться в нескольких разных точных комбинациях, поэтому в колонке «combination_to1» приведен список точных комбинаций, при этом, ханты в комбинации разделены пробелом, а сами комбинации в строке разделены символом «#». Не упомянутая ранее колонка «hunts_num» - это количество хантов в фолсящей комбинации. По ней удобно проверять гипотезу, например, что в подавляющем большинстве случаев комбинация из более одного ханта не фолсит, за исключением полных или частичных дублеров.
Полученную таблицу надо уже отсматривать вручную и черпать из нее идеи корреляционных правил для алертов на точные комбинации хантов. Для примера рассмотрим как мог бы выглядеть анализ.
Фолсящая комбинация: system_information_discovery – получение информации о системе, using_wmic_or_powershell_for_remote_execution_via_wmi – информацию о системе получали удаленно через WMI. Несмотря на то, что в комбинации два ханта, она часто является следствием легитимной работы служб ИТ, как раз в части получения системной информации. Посмотрим на соответствующую ей точную комбинацию (в данном случае она -–одна): local_users_discovery – получение информации о локальных пользователях, possible_virtual_machine_environment_discovery – проверка работы в виртуализации, и, описанная ранее, комбинация получения информации о системе через WMI – (system_information_discovery, using_wmic_or_powershell_for_remote_execution_via_wmi). В целом, достаточно весомый вклад в конверсию этой комбинации вносит обнаружение проверки работы в виртуализации, однако, увеличение количества действий по сбору информации – вполне себе метод обнаружения злоумышленника, даже с условием очевидной сложности обнаружения на тактике Discovery. Аналогично, монтирование папки ADMIN$ (mount_remote_admin_share_as_disk) само по себе по данным 2023 продемонстрировало нулевую конверсию, однако, в комбинации с использованием psexec и сбором информации о сети (mount_remote_admin_share_as_disk, network_connections_discovery, process_started_by_psexec) имело конверсию 100%.
Успех приведенного здесь анализа сильно зависит от операционных процессов SOC и насколько аналитики точно выполняют свои инструкции. В частности, все нефолсовые алерты должны быть аккауратно связаны с соответствующими инцидентами, иначе корректно сработавший алерт будет интерпретирован как ложноположительный и это повлияет на конверсию ханта, на основе которого был создан алерт.
Для проведения данной аналитики, аналогично и для подсчета всяческих метрик по работе SOC, я использовал Python и pandas. При всех моей нелюбви к Python :) , альтернативного инструмента, с тем же уровнем удобства работы с более-менее большими данными, я пока не нашел.
