Друзья, всем привет. Недавно мы анонсировали серию публикаций о детектировании атак (attack detection) и тех вызовах, c которыми сталкиваются пользователи средств защиты. В первой статье этого цикла материалов мы уже раскрыли секреты attack detection в привязке к SIEM-решениям (системам мониторинга событий ИБ и выявления инцидентов, security information and event management) и поделились лайфхаками, как облегчить работу операторов и автоматизировать часть рутинных задач. В этом материале — подробнее о том, как механизм построения цепочек запускаемых процессов в MaxPatrol SIEM помогает выявлять атакующих в сети.
Любая интерактивная атака злоумышленников на инфраструктуру компании не обойдется без запуска каких-либо процессов независимо от операционной системы, в которой у злоумышленника появилась возможность выполнять команды. Большое количество правил корреляции для выявления TTP, то есть tactics, techniques, and procedures (тактики, техники, процедуры), атакующих в MaxPatrol SIEM основано на событиях, в которых присутствуют данные о процессе.
Во время анализа сработок правил корреляции у специалистов SOC Positive Technologies много времени уходит на «раскручивание» цепочки запускаемых процессов (последовательности запуска связанных между собой процессов), так как для принятия решения, что это — true positive или false negative, — зачастую недостаточно данных только о родителе процесса. Это было основным фактором, побудившим нас, сотрудников PT Expert Security Center (PT ESC), разработать механизм, автоматизирующий построение цепочек запускаемых процессов на основе событий безопасности Windows EID 4688, Sysmon EID 1 и событий подсистемы аудита Linux (auditd). Мы придумали механизм, обогащающий любое скоррелированное событие, в котором есть информация о процессе, его полной цепочкой и записывающий данную информацию в отдельное поле таксономии.
Это решение позволило не только разгрузить операторов SOC за счет автоматизации задач по «раскручиванию» цепочек процессов, но и расширить возможности продукта: новое поле таксономии с данными о цепочках процессов в некоторых случаях облегчает написание правил корреляции, используется для вайтлистинга, блэклистинга, применение моделей Machine learning (ML).
По собственному опыту работы с другими продуктами этого класса и по результатам анализа их возможностей могу сказать, что я пока нигде больше не встречал реализации подобной функциональности. Некоторые производители применяют визуализацию цепочек процессов при реагировании на инциденты, используя данные от своих же EDR-решений или расширения, которые анализируют соответствующие события из базы данных и визуализируют деревья процессов при необходимости (кстати, для MaxPatrol SIEM есть подобное расширение — найти его можно вот тут (см. рис. 3)). При активации механизма в MaxPatrol SIEM цепочки процессов строятся независимо от данных EDR или дополнительных расширений в режиме реального времени и без участия человека; с этими данными можно работать как с любым другим полем таксономии. Об этом поговорим дальше.
Анализ атомарных сработок правил корреляции
В сработках правил корреляции нам, как правило, не хватало дополнительного контекста о цепочке процессов. Задача механизма построения цепочки запускаемых процессов состоит не в их визуализации как таковой для расследования, а в записи в отдельное поле таксономии для быстрого визуального анализа прямо из карточки события или практического применения этих данных в корреляциях, обогащениях и т. д.
Наличие в карточке события данных о цепочке процессов в разы сокращает время, необходимое операторам на понимание контекста сработки даже путем визуального анализа данных. Любая сработка правила корреляции в MaxPatrol SIEM, имеющая данные о процессе (имя процесса и его PID), будет обогащаться цепочкой запускаемых процессов независимо от типа события.
Рассмотрим несколько практических примеров обнаружения различных TTP, относящихся к данному разделу.
1. Discovery. Account Discovery. Пример сработки правила корреляции на рекогносцировку активности пользователей через взломанный сервер Exchange.
2. Discovery. Remote System Discovery. Пример сработки правила корреляции на рекогносцировку контроллера домена, основанного на событии запуска процесса без данных о цепочке процессов, и та же сработка правила корреляции с данными о цепочке процессов.
3. Discovery. System Network Configuration Discovery. Пример сработки правила корреляции на рекогносцировку конфигурации сетевого подключения в операционной системе Linux с механизмом построения цепочек запускаемых процессов.
4. Discovery. System Network Connections Discovery. Пример сработки правила корреляции после запуска пользователем вредоносного офисного документа.
Даже квалифицированному сотруднику потребуется немало времени для нахождения вредоносного процесса, который инициировал последующую активность, и сработки правил корреляции. Однако, имея в карточке события поля с цепочкой процессов, относящиеся к конкретной сработке, оператор MaxPatrol SIEM освободит себя от необходимости выяснять это.
Написание правил корреляции на основе данных о цепочке процесса
Для того чтобы учесть в корреляции цепочку из нескольких процессов, необходимо писать минимум два правила корреляции или использовать табличный список для записи временных данных. Благодаря наличию поля таксономии с данными о цепочке процесса, оператору не нужно будет писать дополнительные правила корреляции или использовать дополнительные табличные списки.
В данном случае хорошими кейсами являются правила, выявляющие аномальную активность процессов веб-серверов, и правила, выявляющие целевой фишинг через мессенджеры.
Особенности механизма построения цепочек процессов
Как будет выглядеть цепочка процесса, когда пользователем был запущен файл, загруженный через мессенджер или браузер? И как она будет выглядеть до процесса, если злоумышленнику удастся мигрировать в другой процесс и продолжить свою активность в нем?
При анализе сработок правил корреляции бывают случаи, когда с первого взгляда оператор может посчитать сработку false positive, но активность является нелегитимной. Рассмотрим два сценария.
Первый сценарий. Пользователю пришло фишинговое письмо, он перешел по ссылке, скачал и запустил вредоносный файл — у злоумышленника появилась возможность выполнять команды на зараженном компьютере. В случае, если какое-либо правило корреляции сработает на последующую активность данного вредоносного процесса, то цепочка до процесса будет начинаться от процесса explorer.exe. Однако разработанный нами механизм предусматривает такой сценарий и продолжает выстраивать цепочку процесса с момента загрузки файла из браузера.
Второй сценарий. Часто после успешного «пробива» узла злоумышленнику необходимо мигрировать в другой процесс для сохранения доступа на скомпрометированном компьютере или для сокрытия следов активности за счет работы внутри легитимного процесса. В случае если такая ситуация произошла, а после этого сработало правило на какую-либо последующую активность, то в цепочке процессов будет формироваться цепочка до процесса, в который произошла миграция. Разработанный нами механизм предусматривает и такие кейсы и строит всю цепочку процессов до момента миграции.
После визуального анализа только по одному полю с цепочкой процессов можно сразу сделать вывод, что компьютер пользователя был скомпрометирован.
«Тюнинг» сработок правил корреляции
Данные о цепочке процесса можно использовать при осуществлении «тюнинга» системы — вайтлистинга. Иногда целесообразнее добавить в исключение цепочку процессов, вместо того чтобы писать регулярные выражения. А в случае, если цепочка процессов является вредоносной, ее можно добавить в блэклист. Подробнее о механизмах работы с исключениями в MaxPatrol SIEM мы рассказали тут и тут.
Надеюсь, что данный материал был полезен и вы найдете добавленному в продукт механизму свое применение. Мы будем продолжать знакомить вас с историями о том, как наша экспертиза помогает делать продукты еще более удобными для специалистов по ИБ. Так что следите за выходом новых материалов ????
До новых встреч!
Автор: Алексей Потапов, эксперт отдела обнаружения атак, PT Expert Security Center