Модуль BAD: как ML-алгоритмы помогают отслеживать хакеров

О чем статья

Помимо классических правил корреляции, в MaxPatrol SIEM применяется модуль поведенческого анализа BAD (Behavioral Anomaly Detection). Он выявляет аномалии в инфраструктуре с помощью ML-моделей. Рассказываем, как устроен BAD и для решения каких задач его можно использовать. 

BAD работает как система second opinion: сравнивает активность процессов и их действия с легитимными действиями и присваивает всем событиям определенный risk score. Для этого модуль анализирует каждое поступающее из ОС событие с помощью множества атомарных ML-моделей. 

ML-модели изучают отдельные аспекты и характеристики событий и тем самым обеспечивают многогранную оценку любой активности в системе. Например, одна модель может сосредоточиться на поиске редких или уникальных процессов, а другая — на коммуникации конкретного процесса с сетевыми ресурсами. При этом у каждой модели есть определенный вес (значимость), который учитывается при формировании финального risk score. Кроме того, в модуле есть функция поиска и специальный алгоритм, который позволяет объединять разные типы событий в единую сущность, чтобы учитывать вердикты моделей в общем профайлере процессов. 

Отметим, что традиционные методы обнаружения угроз заточены на выявление конкретных хакерских инструментов или артефактов, которые злоумышленники оставляют в системе. В свою очередь, модуль BAD оперирует индикаторами поведения атакующих (indicators of behavior, IoB). IoB срабатывают, когда ML-модели фиксируют подозрительные действия. Активация индикаторов служит сигналом для дальнейшего изучения события: BAD автоматически отправляет соответствующее оповещение в MaxPatrol SIEM. 

Итоговый risk score для отдельных процессов и связанных с ними цепочек формируется путем агрегирования веса моделей, которые зафиксировали IoB: срабатывания для каждого уникального идентификатора процесса (GUID) консолидируются. В результате аналитики, работающие с SIEM-системой, видят полную картину взаимодействия процесса с ОС, могут правильно оценивать риски, приоритизировать задачи и оперативно реагировать на критичные события. 

Значение risk score отображается в карточке события в интерфейсе SIEM-решения. Ориентируясь на поле bad.risk_score, аналитики могут принимать более взвешенные решения при анализе срабатываний правил корреляции.  На рис. 3 представлен пример правила с importance = high, однако BAD проанализировал активность процесса, который стал триггером для срабатывания, и присвоил событию низкий risk score. Скорее всего, это корреляция с низким уровнем важности, а срабатывание на самом деле ложное.

Отметим, что почти все алерты, которые генерируются в MaxPatrol SIEM, автоматически отправляются в модуль BAD для обогащения данными. Благодаря этому аналитики и операторы могут использовать поле bad.risk_score при написании продвинутых правил корреляции и обогащения, а также для фильтрации событий.

Наконец, переходим к кейсам. В качестве примера разберем две атаки, которые мы зафиксировали во время кибербитвы Standoff. 

Кейс № 1

Рассмотрим инцидент, в рамках которого атакующие запустили на рабочей станции пользователя вредонос gostbypass.exe. Файл функционировал как SOCKS-прокси и стал каналом для развития атаки, но никаких процессов при этом не порождал.

Атакующие провели разведку доменной сети и получили доступ к нескольким серверам и приложениям (см. рис. 7).

На эту активность сработали правила корреляции с низким уровнем важности (см. рис. 8), однако BAD проанализировал весь профиль поведения gostbypass.exe и выдал альтернативное мнение. Зайдя в карточку оценки риска, оператор может подтвердить или опровергнуть оценку модуля (см. рис. 9). Если BAD правильно определил risk score, мы можем исключить эту активность из обучающей выборки.

BAD проанализировал поток данных с рабочей станции скомпрометированного пользователя. Опираясь на атомарные ML-модели и IoB, модуль выявил необычные шаблоны в последовательности и поведении процессов (см. рис. 11). Аномальное поведение привело к повышению risk score и стало сигналом о возможной вредоносной активности.

Кейс № 2

Теперь рассмотрим инцидент, в рамках которого компьютер пользователя подвергся атаке с использованием вредоносного документа Microsoft Office. Запущенный из этого документа скрипт PowerShell загрузил и активировал целый ряд вредоносных компонентов, в том числе процесс ss.exe, который послужил атакующим прокси-сервером и стал каналом развития атаки. Злоумышленник провел разведку узла, затем переместился внутри периметра и получил доступ к нескольким компьютерам в сети. 

Отфильтруем срабатывания правил корреляции с высоким значением bad.risk_score.

На рис. 15 представлен список сработавших моделей, рассмотрим некоторые из них подробнее:

1. Подозрительная цепочка запусков процессов (windows). MaxPatrol SIEM может строить цепочки запускаемых процессов, для этого у нас есть специально обученная ML-модель.
2. Нетипичный для процесса целевой узел (windows). Эта модель ищет аномальные процессы, которые авторизуются в ОС.
3. Нетипичный для пользователя процесс (windows). Модель выявляет факт запуска уникальных для пользователя процессов на узле и предупреждает, если процесса не было в обучающей выборке.

Из сработавших атомарных моделей сложились индикаторы поведения (см. рис. 16), на основе которых BAD сформировал итоговый risk score.

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

***

Модуль BAD повышает точность и скорость реагирования на угрозы, помогает оптимизировать процессы обнаружения атак и сокращает время нейтрализации инцидентов. Мы планируем развивать механизмы скоринга, дорабатывать атомарные модели и разрабатывать новые IoB: все это позволит точнее идентифицировать аномалии и характерные признаки хакерской активности. Кроме того, мы видим большой потенциал в создании единой комплексной ML-модели, которая будет описывать поведение хакера в целом.