Давайте подключимся | LinkedIn | Твиттер
Пару месяцев назад я наткнулся на несколько сообщений в блогах об обнаружении угроз путем анализа деревьев процессов или отношений между родительскими и дочерними процессами. Идея этого метода заключается в создании деревьев процессов и поиске редких шаблонов, которые могут указывать на злонамеренную активность. Чтобы было понятнее, давайте рассмотрим пример:
Вы открываете полученный документ и нажимаете «включить контент». Затем, внезапно, вы попадаете на компромисс. Когда вы открыли документ и нажали «включить содержимое», произошло следующее (оранжевым цветом):
Создавая деревья процессов и анализируя их, мы можем обнаружить аномальное дерево процессов (выделено оранжевым цветом) и исследовать, является оно вредоносным или нет. Этот метод может помочь нам обнаружить множество атак, которые не обнаруживаются. Однако проблема этого метода в том, что создавать деревья процессов и анализировать их непросто. Я нашел один метод - использовать PowerShell и анализировать журналы Sysmon на конечной точке, но он не масштабируемый. Машинное обучение - отличный метод, но он требует знаний, опыта и значительных инвестиций. На момент написания этой статьи, вероятно, всего несколько организаций могут использовать ML.
Итак, как мы можем сделать это волшебство без значительных дополнительных вложений?
В Защитнике Microsoft для конечных точек (MDE / MDATP) я решил эту загадку с помощью KQL, потратив некоторое время, и разработал запрос, который выполняет анализ дерева процессов. Я также разработал аналогичные запросы для журналов Sysmon для Azure Sentinel и Splunk. Решение также должно работать в других продуктах, в которых есть возможности соединения SQL, но у меня нет возможности протестировать.
Посмотрим, как работает решение
Вкратце, нам нужно сделать следующее:
- Разработайте запрос для генерации деревьев процессов
- Используйте метод анализа с длинным хвостом, чтобы найти и отобразить редкие случаи.
- Найдите, какому устройству принадлежит это редкое явление, и получите подробную информацию о дереве процессов, особенно о командной строке.
Создание дерева процессов
Чтобы создать дерево процессов, должно быть уникальное и общее значение в качестве ключа между двумя событиями создания процесса, чтобы мы могли объединить их. Если ключ не уникален, операция соединения дает неверные результаты и потребляет слишком много ресурсов, не выполняя ее. В MDE DeviceProcessEvents нет поля, которое можно было бы использовать в качестве ключа, но мы можем его создать! У нас есть следующие поля в DeviceProcessEvents:
- Идентификатор устройства
- ProcessCreationTime / InitiatingProcessCreationTime
- ProcessId / InitiatingProcessId
- FileName / InitiatingProcessFileName
Комбинируя эти четыре поля, мы получаем ключевое поле, которое мы можем использовать для правильного присоединения к событиям. В качестве альтернативы мы можем использовать все эти 4 поля в условии соединения.
Поскольку у нас есть ключевое поле, мы можем итеративно объединять события для создания деревьев процессов. Есть два варианта создания дерева процессов:
- Начните с процесса и найдите его ребенка, внука и т. Д.
- Начните с процесса и найдите его родителя, бабушку или дедушку, прадедушку и т. Д.
Самое интересное начинается здесь!
Если вы начнете генерировать деревья процессов, просто используя один или два варианта, у вас возникнут проблемы. Например, если существует дерево процессов с 4 процессами, у вас будет 3 разных дерева процессов, 2 из которых являются подмножеством основного дерева. Следовательно, оба варианта вызывают дублирование и проблемы с производительностью, а запрос не выполняется должным образом или не выполняется вообще.
Вы должны знать, где дерево процессов начинается или заканчивается, чтобы избежать дублирования и проблем с производительностью. Знать, где заканчивается дерево процессов, невозможно, потому что мы не знаем, сколько процессов имеет дерево процессов. Мы можем сделать предположение, но даже в этом случае у нас будут деревья процессов, которые являются подмножеством основного дерева. Однако, если мы знаем, где начинается дерево, мы можем спуститься до x-го уровня, даже не зная, где заканчивается дерево, и иметь только одно уникальное дерево без деревьев подмножеств.
Как мы узнаем, где начинается дерево?
Сделайте глубокий вдох и ответьте на вопрос: каков главный вектор атаки по статистике? Эл. адрес! И в большинстве случаев атаки по электронной почте связаны с вредоносным документом! Это означает, что большинство атак, вероятно, около 85% или выше, нацелены на приложения Office и PDF. Если мы сможем создать деревья процессов для приложений Office и PDF, мы сможем обнаружить большинство атак на их начальных этапах!
Таким образом, нам не нужно создавать все деревья процессов. Создание только необходимых деревьев процессов позволяет нам узнать, где начинается дерево, и повышает производительность запросов. Я провел быстрый анализ и обнаружил, что только ~ 1% событий процесса принадлежал приложениям Office. Это огромная разница и, скорее всего, решает проблему с производительностью.
Теперь, когда у нас есть все необходимое, давайте сгенерируем деревья процессов. Чтобы упростить понимание, вот что вы видите в DeviceProcessEvents для сценария выше:
Winword.exe - создан → cmd.exe
Cmd.exe - создан → powershell.exe
Powershell.exe - создан → msbuild.exe
После фильтрации процессов, созданных winword.exe, мы можем присоединиться к событиям процесса, используя поля DeviceId, InitiatingProcessCreationTime, InitiatingProcessId, InitiatingProcessFileName в качестве ключа. Тип соединения следует оставить внешним, потому что мы не знаем, будет ли последующий процесс или нет.
Результат запроса будет следующим:
<DeviceId> | winword.exe | cmd.exe | powershell.exe | msbuild.exe
Анализ длинного хвоста
Поскольку у нас есть все деревья процессов в формате таблицы, мы можем легко получить количество каждого дерева процессов после удаления поля DeviceId и фильтрации редких деревьев процессов:
| project-away DeviceId | summarize count() by <Field1>, <Field2>, <Field3>, <Field3> | where count_ < 10 // you can increase or decrease this threshold.
Поиск устройств и получение сведений
Теперь, когда у нас есть редкие деревья процессов в виде таблицы, мы можем присоединить их обратно к исходной таблице деревьев процессов, чтобы получить подробности. Затем мы можем проанализировать результаты, чтобы увидеть, есть ли подозрительная / вредоносная активность, и провести углубленный анализ.
Запрос генерирует около 500–1000 результатов для «winword.exe», «excel.exe», «powerpnt.exe», «acrord32.exe» в очень большом среда за последние 2 дня. На анализ результата уходит около 1-2 часов. Если хотите, вы можете легко проанализировать его с помощью Excel. Потратив некоторое время, можно найти и удалить постоянные ложные срабатывания и значительно сократить количество результатов (мне удалось сократить количество результатов до 100–200).
Мы можем использовать тот же запрос и анализировать деревья процессов IIS / Apache, чтобы обнаруживать веб-оболочки или вторжения общедоступных приложений.
Заключение
На мой взгляд, анализ дерева процессов имеет огромный потенциал для обнаружения угроз на их начальных стадиях. Более того, его также можно использовать для обнаружения других тактик, таких как боковое движение и анализа отдельной машины.
Я разработал три запроса: один для Microsoft Defender for Endpoint (MDATP / MDE / M365D), один для Azure Sentinel (для журналов Sysmon) и один для Splunk (для журналов Sysmon); Все запросы вы можете найти в моем репозитории на Github.
Будущая работа
Я работаю над улучшением этого метода. Кажется, есть потенциал для использования этого метода для обнаружения поведения без попыток обнаружения использования техники (процедур).
использованная литература
Https://www.varonis.com/blog/sysmon-threat-detection-guide/#part-iii
