Обзор PT XDR 3.2, системы для обнаружения угроз и реагирования на них

1. Введение
2. Функциональные возможности PT XDR
3. Архитектура PT XDR
4. Системные требования PT XDR
5. Сценарии использования PT XDR
   1. 5.1. Сценарий 1: вредоносная программа внутри защищённого паролем файла, доставленного через мессенджеры
   2. 5.2. Сценарий 2: установка вредоносных плагинов для Microsoft IIS
   3. 5.3. Сценарий 3: техника «DLL Hijacking»
6. Выводы

Введение

Системы класса XDR уже не являются новинкой на рынке систем защиты от целевых атак, но в то же время компании-клиенты зачастую не понимают их назначения и функциональных возможностей, ограничиваясь защитой конечных точек на уровне стандартного антивируса. Иные организации выбирают EDR для расширения телеметрии и мониторинга угроз, в т. ч. сетевых атак. В целом возможно определить XDR-системы как эволюцию технологий EDR. Основная разница состоит в том, что XDR собирает и анализирует информацию не только с конечных точек, но и из продуктов классов Sandbox (песочница), Web Application Firewall (брандмауэр веб-приложений) и Network Traffic Analysis (анализ сетевого трафика), а также из систем управления уязвимостями. Это даёт расширенный набор данных: ключи запуска процессов из командной строки, результаты проверок процессов с помощью YARA-правил, контрольные суммы исполняемых файлов и другие полезные сведения, обогащающие события.

Рисунок 1. Статистика Positive Technologies о проблемах клиентов в части обеспечения ИБ

Как видно из статистики Positive Technologies за 2022 год, небольшое количество компаний используют хотя бы EDR, не говоря уже об XDR. Ситуацию ухудшает то, что кадровый и экспертный голод не позволяет в полной мере управлять инцидентами и полноценно отслеживать имеющиеся в инфраструктуре СЗИ. По этой причине расширенная телеметрия и автоматизация множества процессов ИБ важны для защиты от комплексных и сложных угроз. Ведь даже небольшая команда специалистов может охватить большой объём работы по мониторингу и защите инфраструктуры, если автоматизировать часть процессов реагирования, усилить аналитику и экспертизу.

Функциональные возможности PT XDR

Система относится к средствам обеспечения информационной безопасности на базе клиент-серверной архитектуры, предназначена для обнаружения и отработки угроз на серверах и рабочих станциях корпоративной сети. PT XDR встраивается в экосистему продуктов Positive Technologies и использует экспертные знания об угрозах для выявления атак. PT XDR представляет собой решение, которое возможно применять совместно с MaxPatrol SIEM, системой нового поколения для управления уязвимостями MaxPatrol VM и индивидуализируемой песочницей PT Sandbox. Ещё эффективнее система будет работать при доставке в неё потоков данных со знаниями об угрозах — PT Feeds. В этой связке MaxPatrol SIEM является агрегирующим звеном, а также средством визуализации и мониторинга событий. Устанавливаемый на конечные устройства EDR-агент выполняет функции сборщика телеметрии и логов, помогает обнаруживать атаки с помощью инструментов статического и поведенческого анализа, является основным инструментом для реагирования с широким набором предлагаемых действий. PT Sandbox отвечает за сложный анализ полученных файлов, их запуск и изучение в безопасной среде.

Рисунок 2. Концептуальная схема интеграции продуктов Positive Technologies

Назовём основные особенности PT XDR.

Во-первых, он помогает обнаруживать инциденты и реагировать на них в автоматическом или ручном режиме. Полезен на всех основных этапах обработки инцидентов:

• Подготовка (Preparation): PT XDR умеет собирать инвентаризационные и конфигурационные данные об узлах, которые затем передаются в MaxPatrol VM (при его наличии) для расчёта уязвимостей на конечных точках. Снижение количества уязвимостей и ошибок конфигурации помогает сократить количество потенциальных инцидентов в организации и затруднить злоумышленнику перемещение по инфраструктуре.
• Обнаружение инцидента и анализ произошедшего (Identification): PT XDR собирает телеметрию, обогащает её дополнительным контекстом, выявляет угрозы с помощью корреляционного ядра на агенте, обеспечивает дополнительный анализ файлов и процессов с помощью YARA-сканирований (в том числе с помощью пользовательских правил) и репутационных данных.
• Сдерживание атакующего и локализация инцидента (Containment): агент XDR может частично или полностью изолировать узел, завершить подозрительные и вредоносные процессы.
• Устранение последствий (Eradication): PT XDR позволяет удалить вредоносные файлы, вычистить инструменты закрепления из автозагрузки, заблокировать учётные записи.
• Восстановление систем после инцидента (Recovery): с помощью PT XDR можно удалённо управлять системами, на которые установлен агент. PT XDR предоставляет возможность выполнения произвольных консольных команд на агенте, этот механизм может применяться как на этапах восстановления, так для реагирования в настоящем времени (Live Response).

Во-вторых, PT XDR позволяет автоматизировать рутинные процессы SOC, связанные с реагированием на типовые угрозы.

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

Кроме того, за счёт взаимодействия со внешними системами появляется возможность проводить дополнительный углублённый анализ артефактов, что помогает снизить количество «шума» и ложноположительных срабатываний.

Как итог, PT XDR может предложить ИБ- и SOC-командам решение для мониторинга угроз в сети организации и реагирования на них, а также возможность работы над ошибками и поиска уязвимых мест в инфраструктуре. В 2022 году PT XDR был внесён в единый реестр российских программ, а также стал доступен для «пилотирования» и покупки.

Архитектура PT XDR

Рассматривая архитектуру системы, важно помнить, что хотя агенты XDR способны выполнять свои задачи по сбору данных, обнаружению атак и реагированию на инциденты, их возможности могут быть существенно расширены с помощью интеграций с другими продуктами Positive Technologies и внешними инструментами ИБ и ИТ-системами. В частности, будут присутствовать полноценная визуализация, работа с логами и отчётность по атакам, а также возможность проверки обнаруженных подозрительных файлов в песочнице. Проще говоря, чем больше информации получает сервер XDR, тем шире его функциональные возможности: более точный анализ и принятие решений, корреляция с уязвимостями на конечных точках, выявление горизонтального перемещения злоумышленника в сети защищаемой организации, а также поиск «первого звена» атаки, будь то элемент сетевого периметра, электронная почта или внешний носитель информации.

Инфраструктурная часть PT XDR состоит из сервера агентов и управляющего сервера. Последний является основным компонентом системы, который позволяет конфигурировать её через веб-интерфейс. Сервер агентов — приложение для управления агентами и модулями, а также для взаимодействия со внешними системами (MaxPatrol SIEM, PT Sandbox, Syslog-сервер). Модули — это приложения, которые запускаются на конечном устройстве для выполнения основных функций агента; в свою очередь, агент PT XDR — это приложение, которое устанавливается на конечное устройство для обеспечения работы модулей. Для передачи информации (в т. ч. команд и политик работы модулей) между агентами и сервером создаётся зашифрованный канал.

Платформа киберразведки от Positive Technologies выступает в роли поставщика всех необходимых потоков данных об угрозах (фидов) по подписке.

Рисунок 3. Архитектура PT XDR

Для понимания процессов взаимодействия между компонентами системы рассмотрим алгоритм работы PT XDR.

1. Сервер агентов передаёт модули и их конфигурацию на агенты.
2. Модули доставки и инсталляции устанавливают и настраивают инструменты сбора данных на конечном устройстве.
3. Модули сбора передают данные о событиях в модули обнаружения и в сторонние системы через сервер агентов.
4. Модули обнаружения анализируют собранные сведения, выявляют подозрительную активность на конечном устройстве и регистрируют ИБ-события.
5. Модули реагирования предоставляют возможность противодействовать подозрительной и вредоносной активности, выполняя операции в соответствии с политикой или по команде пользователя.
6. Модули интеграции обеспечивают взаимодействие со внешними системами.
7. ИБ-события сохраняются в локальную базу данных агента и пересылаются в базу данных сервера и во внешние системы.
8. Агент передаёт метрики и данные трассировки на сервер.
9. Управляющий сервер получает обновления продукта и пакетов экспертизы с сервера обновлений. Также в его возможности входят создание и редактирование политик, на основе которых конфигурация и модули передаются на агенты.

Архитектура системы вместе с дополняющими решениями Positive Technologies представлена выше на рисунке 2.

Как уже было указано, визуализация «сырых» логов и данных, отчётность, проверка сложных угроз или сбор телеметрии с сетевых устройств — это задачи дополнительных СЗИ.

Как и у любого другого агентского решения для конечных точек, у агента PT XDR есть самозащита: без прав на уровне «SYSTEM» удалить или остановить его не получится. Факты повышения привилегий отслеживаются, ИБ-специалист имеет возможность отреагировать, когда существует вероятность неправомерного воздействия на агент.

PT XDR лицензируется по количеству подключаемых агентов.

Системные требования PT XDR

Система поставляется только в виде локального решения внутри инфраструктуры клиента (on-premise). PT XDR рекомендуется устанавливать на чистую 64-разрядную ОС Debian версии 10 или 11. Также PT XDR совместим с операционными системами «ОсНова» 2.5.1 и РЕД ОС 7.3.1. Полная таблица совместимостей на момент выхода обзора выглядит следующим образом.

Таблица 1. Совместимость с операционными системами (сервер и агент)

Требования к аппаратным ресурсам серверов зависят от конфигурации системы. Существуют следующие варианты:

• низконагруженная система (1–5 тыс. подключённых агентов, одновременно активны 1–3 тыс.);
• средненагруженная система (5–10 тыс. подключённых агентов, одновременно активны около 5 тыс.);
• высоконагруженная система (10–30 тыс. подключённых агентов, одновременно активны около 10 тыс.).

В зависимости от нагрузки применяются разные аппаратные требования. Укажем вариант для односерверной конфигурации.

Таблица 2. Аппаратные требования для односерверной конфигурации

Таблица 3. Рекомендуемые аппаратные требования к серверу агентов

Таблица 4. Аппаратные требования к управляющему серверу

Таблица 5. Аппаратные требования для функционирования агента

В случае недоступности сервера агентов события накапливаются в журнале агента. Под эту задачу резервируется пространство на жёстком диске. Объём выделяемого пространства можно изменить.

Сценарии использования PT XDR

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

Ядром всех процессов на конечных точках являются агент и модули. Коротко перечислим и опишем их особенности и решаемые задачи.

• Доставка и установка: инсталляция Sysmon.
• Сбор данных: извлечение информации из журналов Windows или auditd.
• Обнаружение: анализ файлов и процессов, YARA-сканирование, корреляция, поиск поведенческих аномалий.
• Реагирование: удаление файлов, изоляция узла, завершение процессов, интерпретация консольных команд и произвольного Lua-кода, блокировка по IP-адресу, перенаправление DNS-запросов, удаление из автозагрузки (в разработке), помещение файла в карантин (в разработке).
• Интеграция: отправка событий на Syslog-сервер и в MaxPatrol SIEM, отправка отчётов в MaxPatrol VM, проверка файлов в PT Sandbox, отправка в иные внешние системы.

Модули управляются политиками, каждая из которых определяет пул активных модулей и их настройки, с которыми они отрабатывают на конечных точках. «Из коробки» доступен набор стандартных политик обнаружения и реагирования на угрозы, основанных на рекомендациях экспертов Positive Technologies.

Сценарий 1: вредоносная программа внутри защищённого паролем файла, доставленного через мессенджеры

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

Для обнаружения сложных угроз подобного рода используются системы класса «песочница», где можно запустить файлы в изолированной среде и провести поведенческий анализ. Агент PT XDR, в частности, умеет отправлять созданные мессенджерами и браузерами (а также любыми другими процессами, которые можно указать в настройках) файлы на анализ в PT Sandbox.

Усложним ситуацию: предположим, что файл защищён паролем. В таком случае провести полноценный анализ в песочнице не получится, если пароль неизвестен. В таком случае PT XDR снова окажется полезен: он поможет правильным образом упаковать файл для передачи в песочницу на анализ и автоматически купировать угрозу.

Рассмотрим пример. Для начала эмулируем создание файла процессом «telegram.exe» с помощью самораспаковывающегося архива. Получаем файл защищённый паролем.

Рисунок 4. Тестируемый файл

Внутри файла — нагрузка в виде сжатой и закодированной в Base64 вредоносной DLL, которая при запуске помещается в папку %TEMP% со случайным 10-символьным именем и расширением «.db», после чего запускается через rundll32 с нужными параметрами (кейлогер, инструменты разведки и снифер буфера обмена), передающимися в качестве параметров командной строки при запуске файла.

Откроем документ, введя пароль, и запустим содержащиеся в нём макросы. В консоли PT XDR видим, что продукт обнаружил скачивание файла с помощью Telegram. Заметим, что вердикт о вредоносности уже был в кеше, поэтому файл помечен как вредоносный. Если бы такая информация отсутствовала, то файл был бы помечен как подозрительный.

Рисунок 5. Лог консоли XDR с событиями по вредоносному файлу

Видим также информацию о том, что Microsoft Word запустил «cmd.exe», а из «cmd.exe» был запущен «rundll32.exe».

Рисунок 6. Событие запуска «cmd.exe» и «rundll32.exe» через Microsoft Word

Далее видим, что PT XDR завершил несколько процессов, которые были запущены («cmd.exe», «rundll32.exe» и «conhost.exe»).

Рисунок 7. Событие завершения подозрительных процессов модулем PT XDR

Также агент PT XDR создал самораспаковывающийся архив, упаковав в него файл с расширением «.db», исходный документ и считанные из командной строки запуска параметры. Этот архив затем будет передан в PT Sandbox для анализа.

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

После выполнения проверки PT Sandbox возвращает вердикт о том, что файл проверен и признан вредоносным, и сопроводительные метаданные, включая контрольные суммы файла.

Рисунок 9. Отчёт об обработке файла в PT Sandbox

Рассмотрим результаты анализа в интерфейсе PT Sandbox.

Рисунок 10. Интерфейс обработки и результата события в PT Sandbox

Возможно сделать выводы о логике работы вредоносного кода: он генерирует в папке %TEMP% файл со случайным названием и расширением «.db» (обфусцированная библиотека, о которой мы рассказывали в начале), затем запускает его с помощью rundll32 с параметрами «christmas_tree recon keylog clip». Далее запускаются процессы «ipconfig.exe», «cmd.exe», «rundll32.exe» и «conhost.exe» — те самые, которые агент PT XDR завершил на машине пользователя.

Мы убедились в том, что PT XDR помог защитить машину пользователя, запустившего вредоносный файл, а также помог аналитику SOC восстановить логику работы вредоносного кода с помощью PT Sandbox. Все действия были выполнены автоматически.

Отметим, что PT XDR передаёт вердикты PT Sandbox другим подключённым агентам, обеспечивая проактивную защиту. При необходимости можно настроить политики таким образом, чтобы файлы с вердиктом «вредоносный» удалялись из файловой системы, а связанные с ними процессы завершались.

Сценарий 2: установка вредоносных плагинов для Microsoft IIS

Ещё один сценарий, который часто используется хакерами в атаках, — установка вредоносных плагинов для Microsoft Internet Information Services, которые могут быть использованы, например, для резервирования канала управления скомпрометированной инфраструктурой.

Пример использования описан в материале «Мастера маскировки: новая группировка ChamelGang и её арсенал». Данная техника была описана ранее в статье «IIS Raid — Backdooring IIS Using Native Modules» и эксплуатировалась APT-группой OilRig. В начале августа 2021 года на конференции Black Hat компания ESET представила подробный материал о семействе вредоносных IIS-модулей, что говорит о росте популярности этой техники среди атакующих.

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

Рисунок 11. Пример рекомендованных исключений

Эмулируем установку вредоносного плагина, который после установки выполняет команду на скомпрометированном сервере (в данном примере это «whoami»). Для начала проделаем операцию без установленного агента PT XDR.

Рисунок 12. Лог успешной установки плагина для IIS

Попробуем повторить установку плагина со включённым агентом PT XDR. Сразу замечаем, что установка и подключение завершаются неуспешно.

Рисунок 13. Лог неуспешной установки плагина для IIS

Теперь посмотрим в консоль PT XDR. Видим событие по обнаружению установки вредоносного плагина.

Рисунок 14. Событие установки вредоносного плагина для IIS

Вредоносным он признан на основании вердикта от YARA-сканера, который автоматически проверяет все устанавливаемые в каталог плагинов IIS файлы.

Рисунок 15. Событие ответа YARA-сканера

Модуль реагирования деавторизовывает вредоносный модуль, чтобы его можно было удалить без остановки работы Microsoft IIS.

Рисунок 16. Событие деавторизации вредоносного плагина для IIS

Происходит удаление вредоносного модуля.

Рисунок 17. Событие удаления вредоносного плагина для IIS

Работа IIS при этом не нарушена. Убеждаемся в этом.

Рисунок 18. Проверка работоспособности IIS

Сценарий 3: техника «DLL Hijacking»

Техника «DLL Hijacking» подразумевает подмену DLL, используемой легитимными процессами, на библиотеку с нагрузкой, которую атакующий может эксплуатировать в собственных целях. Часто встречается инъекция DLL в службу распределённых транзакций MSDTC. Уже упомянутая выше группировка ChamelGang тоже использует этот приём. Техника широко распространена и встречается весьма часто. Ознакомиться с ней подробнее возможно по ссылке.

Для тестирования возможностей PT XDR по обнаружению этой техники будем использовать образец программы, имитирующий загрузку вредоносной библиотеки с именем «oci.dll», которая должна быть внедрена в службу распределённых транзакций MSDTC.

Запустим его.

Рисунок 19. Процесс запуска программы

После этого перейдём в консоль PT XDR. Видим, что была зафиксирована попытка инъекции библиотеки с именем «oci.dll».

Рисунок 20. Событие по запуску образца вредоносной программы в консоли PT XDR

После обнаружения модуль «hijacking_detector» останавливает службу MSDTC, чтобы обеспечить возможность удаления «oci.dll», а затем перезапускает её. Убедимся, что файл успешно удалён, а служба перезапущена и работает.

Рисунок 21. Лог удаления подозрительного файла

Рисунок 22. Проверка работоспособности MSDTC

Выводы

PT XDR 3.2 имеет все необходимые возможности для выявления сложных комплексных угроз и таргетированных атак на конечных точках. С помощью различных методов сбора, обработки и корреляции телеметрии он определяет как вредоносные те файлы и процессы, которые не видит антивирусное ПО, работающее по сигнатурному и эвристическому методам обнаружения угроз. При этом PT XDR анализирует множество потоков данных из различных источников и на их основе повышает корректность срабатываний и обнаружений. На примерах мы подтвердили возможности несигнатурного анализа вредоносных файлов и библиотек, их удаления и восстановления системных процессов к первоначальному работоспособному виду.

Достоинства:

• Доступно расширенное обнаружение угроз с использованием как экспертизы от аналитиков Positive Technologies, так и собственных правил.
• Возможность гранулярной настройки политик обнаружения и реагирования, управление утилитами расширенного мониторинга из консоли.
• Возможность оперативного реагирования на обнаруженные угрозы, в том числе в автоматическом режиме. Реагирование, которое не подразумевает взаимодействия со внешними системами, доступно и в автономном режиме.
• Агент PT XDR может использоваться для локального сбора событий по ИБ с конечных устройств и для доставки их в SIEM, а также в целях сбора информации для расчёта уязвимостей в MaxPatrol VM.
• Возможность настроить принудительную отправку файлов, созданных конкретными приложениями, на анализ в песочницу. Такой подход обеспечивает защиту от вредоносных программ, которые проникают по неохваченным прочими СЗИ каналам.
• Потенциал интеграции с любыми российскими СЗИ при участии партнёров и разработчиков Positive Technologies.

Недостатки:

• Полноценная двунаправленная интеграция, применение фидов и доступность всех возможностей защиты гарантированы только между продуктами Positive Technologies. Возможна компенсация за счёт написания индивидуальных модулей для интеграции с другими инструментами обеспечения ИБ и ИТ-решениями.
• Только локальное развёртывание (on-premise), нет возможности предоставления в виде SaaS. Выделение аппаратных ресурсов и системное администрирование ложатся на персонал заказчика. В качестве альтернативы возможно рассматривать предоставление MSSP-сервисов партнёрами Positive Technologies.
• Без иных решений Positive Technologies система XDR теряет часть функциональных возможностей: например, без PT Sandbox не будет поведенческого анализа в изолированной среде, точность которого выше, чем на агенте, а потребление ресурсов — меньше. Тем не менее агент PT XDR позволяет обнаруживать эксплуатацию уязвимостей, использование и загрузку хакерского инструментария, повышение привилегий, закрепление в системе путём создания задач планировщика, попытки изменения реестра и т. д. с помощью коррелятора, обеспечивающего поведенческий анализ.