Погоня за исключением False Positive приводит к периодическому False Negative, который, как известно, случается в самый неподходящий момент. С осознанием этого факта в мир SOC пришло такое явление, как Threat Hunting, призванное усилить классический процесс по мониторингу и закрыть указанные выше недостатки.
Само понятие Threat Hunting сейчас мелькает на всех коммерческих буклетах, но вопросов и споров о том, что это и как организовать процесс проактивного поиска угроз при работе SOC, достаточно много. Даже в своей команде мы периодически любим поспорить на эту тему, и наш лагерь JSOC в этом вопросе делится на две группы:
1. Одни верят, что процесс Threat Hunting основывается на гипотезах, которые уже были выдвинуты различными исследователями или были сформированы в результате анализа работы вредоносного файла или деятельности какой-либо хакерской группировки.
2. Другие верят, что процесс Threat Hunting основывается на гипотезах, которые специалист формирует и проверяет сам в нужный момент времени.
Так как определиться мы не смогли, стали использовать оба подхода к слову, оба они имеют достоинства и недостатки. Давайте чуть ближе посмотрим на то, что же мы делаем вокруг каждого из вариантов.
Вариант 1
Сюда мы относим написанные нами правила корреляции на различные атомарные события, простые детекты, которые могут косвенно свидетельствовать о происходящем инциденте, при этом данные детекты в отрыве от контекста могут быть абсолютно малозначимы, их логически сложно профильтровать на признаки False Positive и однозначно построить вокруг них workflow для инженеров с линии не представляется возможным.
О чем же речь? Приведем примеры двух правил, чтобы понять особенности неправильных инцидентов.
В этой категории у нас есть, например, правило, выявляющее наличие в параметрах запускаемого процесса IP-адреса или FQDN. В действительности данное правило очень сложно пропустить сквозь сито False Positive, но при этом оно достаточно эффективное при обнаружении подозрительной активности.
Или вот, например, правило, детектирующее запуск макроса при открытии Word-документа (отслеживается запись в так называемые Trusted Records Registry Key значения, содержащего последовательность FF FF FF 7F). В большой инфраструктуре такое правило будет срабатывать очень часто, но при современных объёмах фишинга с использованием технологии макросов игнорировать его нельзя.
Понятное дело, что степень фолсовости у этих правил разная. Поэтому для каждого из них мы прописываем (а после запуска у заказчиков динамически изменяем) некий внутренний скоринг, который, используя механизмы ретроспективного анализа, показывает вероятность боевого детекта. Правила с высоким скорингом в том числе попадают в ServiceDesk для подсвечивания активностей по отношению к типовым инцидентам.
Workflow вокруг таких правил выглядит иначе. Сработки попадают не на линию, а к аналитикам, занимающимся проактивным поиском угроз. Они в свою очередь ищут взаимосвязи между сработками данных правил и инцидентами, которые ушли на линию (по ключевым параметрам хост, учетная запись, процесс), параллельно подключая механизм ретроспективного анализа инцидентов, о котором мы рассказывали выше. Стоит отметить, что в этом моменте отсутствует понятие SLA, так эти сработки не подразумевают сразу же возникновения инцидента и необходимости реагирования. При таком подходе мы получаем расширенную картину происходящего и минимизируем вероятность пропуска подозрительной активности.
Вариант 2
В данном варианте работы к аналитику, занимающемуся проактивным поиском угроз, в качестве входных данных поступают не сработки каких-либо детектирующих правил, а так называемые raw events, вокруг которых можно строить гипотезы. И уже результатом этой активности становятся задачи по разработке правил, если удалось найти действительно что-то интересное, не покрытое текущими детектами. И снова приведем два примера.
Событие создания процесса Event id 4688 (Sysmon id 1)
Обрабатывая и анализируя данные по всем запущенным в инфраструктуре процессам, аналитик угроз ищет подозрительные события, анализируя различную информацию. Например:
параметры запускаемых процессов: собрать статистику, обратить внимание на самые редкие командлайны, поискать в них ключевой набор слов/фраз, поискать наличие кодировки base64;
путь до исполняемого файла: обратить внимание на запуск из особых директорий
(например, С:\User\Public, C:\Windows\Temp, C:\Windows\Debug\wia, C:\Windows\Tracing\ в указанные директории возможно писать и запускать исполняемые файлы, не имея прав локального администратора);
поискать интересные взаимосвязи Parent -> Process, которые не покрыты текущими правилами детекта.
Событие создания именного канала Pipe (Sysmon id 17)
Как известно, вредоносное программное обеспечение очень часто создает именованный канал для собственного межпроцессорного взаимодействия. И зачастую именованный канал имеет определенную маску в имени и какой-то генерируемый параметр, например, Evil_090920 (Evil маска, 090920 генерируемый параметр). Если имя именованного канала не находится в индикаторах компрометации, то само создание данного pipe не вызовет подозрения, тем не менее аналитик может обратить внимание на то, что в определенный момент времени (или через любой интервал времени) подобные неизвестные именованные каналы создавались на нескольких системах, что может косвенно свидетельствовать о распространении вредоносного кода.
_________
В данном посте, рассказывая о том, как мы строим процесс Threat Hunting, мы опирались на события ОС Windows и Sysmon, выступающие в качестве источника для SIEM-системы. В действительности же источник событий и конечная система (лишь бы она это позволяла) для работы по проактивному поиску угроз для аналитика значения не имеет ровно такую же философию можно применить, например, к EDR или NTA.
Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети
