Как экспертиза в области мониторинга событий ИБ помогает создавать качественные продукты. Часть 2

от автора

Друзья, всем привет. Недавно мы анонсировали серию публикаций о детектировании атак (attack detection) и тех вызовах, c которыми сталкиваются пользователи средств защиты. В первой статье этого цикла материалов мы уже раскрыли секреты attack detection в привязке к SIEM-решениям (системам мониторинга событий ИБ и выявления инцидентов, security information and event management) и поделились лайфхаками, как облегчить работу операторов и автоматизировать часть рутинных задач. В этом материале — подробнее о том, как механизм построения цепочек запускаемых процессов в MaxPatrol SIEM помогает выявлять атакующих в сети.

Любая PT Expert Security Center (PT ESC), разработать механизм, автоматизирующий построение цепочек запускаемых процессов на основе событий безопасности Windows EID 4688, Sysmon EID 1 и событий подсистемы аудита Linux (auditd). Мы придумали механизм, обогащающий любое скоррелированное событие, в котором есть информация о процессе, его полной цепочкой и записывающий данную информацию в отдельное поле таксономии.

Рис. 1. Пример нормализованного события запуска процессов Sysmon EID 1
Рис. 1. Пример нормализованного события запуска процессов Sysmon EID 1
Рис. 2. Пример нормализованного события подсистемы аудита Linux (auditd)
Рис. 2. Пример нормализованного события подсистемы аудита Linux (auditd)

Это решение позволило не только разгрузить операторов SOC за счет автоматизации задач по «раскручиванию» цепочек процессов, но и расширить возможности продукта: новое поле таксономии с данными о цепочках процессов в некоторых случаях облегчает написание правил корреляции, используется для тут (см. рис. 3)). При активации механизма в MaxPatrol SIEM цепочки процессов строятся независимо от данных EDR или дополнительных расширений в режиме реального времени и без участия человека; с этими данными можно работать как с любым другим полем таксономии. Об этом поговорим дальше.

Рис. 3. Пример расширения для браузера, строящего дерево процессов по событиям из базы данных по запросу пользователя
Рис. 3. Пример расширения для браузера, строящего дерево процессов по событиям из базы данных по запросу пользователя

Анализ атомарных сработок правил корреляции

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

Наличие в карточке события данных о цепочке процессов в разы сокращает время, необходимое операторам на понимание контекста сработки даже путем визуального анализа данных. Любая сработка правила корреляции в MaxPatrol SIEM, имеющая данные о процессе (имя процесса и его PID), будет обогащаться цепочкой запускаемых процессов независимо от типа события.

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

1. Discovery. Account Discovery. Пример сработки правила корреляции на рекогносцировку активности пользователей через взломанный сервер Exchange.

Рис. 4. Сработка правила корреляции на рекогносцировку активности пользователей с механизмом построения цепочек запускаемых процессов
Рис. 4. Сработка правила корреляции на рекогносцировку активности пользователей с механизмом построения цепочек запускаемых процессов

2. Discovery. Remote System Discovery. Пример сработки правила корреляции на рекогносцировку контроллера домена, основанного на событии запуска процесса без данных о цепочке процессов, и та же сработка правила корреляции с данными о цепочке процессов.

Рис. 5. Сработка правила корреляции на рекогносцировку контроллера домена без механизма построения цепочек запускаемых процессов
Рис. 5. Сработка правила корреляции на рекогносцировку контроллера домена без механизма построения цепочек запускаемых процессов
Рис. 6. Сработка правила корреляции на рекогносцировку контроллера домена с механизмом построения цепочек запускаемых процессов
Рис. 6. Сработка правила корреляции на рекогносцировку контроллера домена с механизмом построения цепочек запускаемых процессов

3. Discovery. System Network Configuration Discovery. Пример сработки правила корреляции на рекогносцировку конфигурации сетевого подключения в операционной системе Linux с механизмом построения цепочек запускаемых процессов.

Рис. 7. Сработка правила корреляции на рекогносцировку конфигурации сетевого адаптера с механизмом построения цепочек запускаемых процессов
Рис. 7. Сработка правила корреляции на рекогносцировку конфигурации сетевого адаптера с механизмом построения цепочек запускаемых процессов

4. Discovery. System Network Connections Discovery. Пример сработки правила корреляции после запуска пользователем вредоносного офисного документа.

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

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

Написание правил корреляции на основе данных о цепочке процесса

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

Рис. 9. Пример фильтра события в правиле корреляции, обнаруживающего аномальные цепочки запуска процессов, родителем которых является агент антивируса Kaspersky klnagent
Рис. 9. Пример фильтра события в правиле корреляции, обнаруживающего аномальные цепочки запуска процессов, родителем которых является агент антивируса Kaspersky klnagent
Рис. 10. Пример фильтра события в правиле корреляции, обнаруживающего цепочку запуска процессов с утилитами веб-сервера
Рис. 10. Пример фильтра события в правиле корреляции, обнаруживающего цепочку запуска процессов с утилитами веб-сервера

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

Особенности механизма построения цепочек процессов

Как будет выглядеть цепочка процесса, когда пользователем был запущен файл, загруженный через мессенджер или браузер? И как она будет выглядеть до процесса, если злоумышленнику удастся мигрировать в другой процесс и продолжить свою активность в нем?

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

Первый сценарий. Пользователю пришло фишинговое письмо, он перешел по ссылке, скачал и запустил вредоносный файл — у злоумышленника появилась возможность выполнять команды на зараженном компьютере. В случае, если какое-либо правило корреляции сработает на последующую активность данного вредоносного процесса, то цепочка до процесса будет начинаться от процесса explorer.exe. Однако разработанный нами механизм предусматривает такой сценарий и продолжает выстраивать цепочку процесса с момента загрузки файла из браузера.

Рис. 11. Пример построения цепочки процессов
Рис. 11. Пример построения цепочки процессов

Второй сценарий. Часто после успешного «пробива» узла злоумышленнику необходимо мигрировать в другой процесс для сохранения доступа на скомпрометированном компьютере или для сокрытия следов активности за счет работы внутри легитимного процесса. В случае если такая ситуация произошла, а после этого сработало правило на какую-либо последующую активность, то в цепочке процессов будет формироваться цепочка до процесса, в который произошла миграция. Разработанный нами механизм предусматривает и такие кейсы и строит всю цепочку процессов до момента миграции.

Рис. 12. Отображение процесса, в который мигрировал злоумышленник (в фигурных скобках)
Рис. 12. Отображение процесса, в который мигрировал злоумышленник (в фигурных скобках)

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

«Тюнинг» сработок правил корреляции

Данные о цепочке процесса можно использовать при осуществлении «тюнинга» системы — вайтлистинга. Иногда целесообразнее добавить в исключение цепочку процессов, вместо того чтобы писать регулярные выражения. А в случае, если цепочка процессов является вредоносной, ее можно добавить в блэклист. Подробнее о механизмах работы с исключениями в MaxPatrol SIEM мы рассказали тут и тут.

Рис. 13. Пример шаблона исключений для данных с цепочкой процесса
Рис. 13. Пример шаблона исключений для данных с цепочкой процесса

Надеюсь, что данный материал был полезен и вы найдете добавленному в продукт механизму свое применение. Мы будем продолжать знакомить вас с историями о том, как наша экспертиза помогает делать продукты еще более удобными для специалистов по ИБ. Так что следите за выходом новых материалов ?

До новых встреч!


Автор: Алексей Потапов, эксперт отдела обнаружения атак, PT Expert Security Center


ссылка на оригинал статьи https://habr.com/ru/company/pt/blog/719438/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *