EDR
Защита конечных точек. Тестирование

Рады приветствовать вас во 2 статье блока KEDR из цикла «Kaspersky Symphony XDR» на портале TS University!

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

Обзор интерфейса офицера безопасности

После добавления лицензии KEDR у нас появился новый функционал на уже известных по KATA разделах (а также добавились новые разделы).

Пройдёмся по категориям в рамках KEDR по порядку.

Разделы в рамках KATA мы рассматривали в этой статье.

Мониторинг

Первое, что мы видим при входе под учетной записью офицера безопасности — это Мониторинг.

С новой лицензией KEDR нас появились и новые виджеты: топ хостов и топ правил Target Attack Analyzer. А также в уже знакомых виджетах, которые мы видели при обзоре функционала KATA, добавились новые технологии обнаружения.

Поиск угроз

Этот инструмент позволяет путем формирования запросов через конструктор или код искать по всей базе телеметрии, собранной с хостов.

Если, к примеру, мы хотим увидеть телеметрию по конкретному хосту, то в запросе мы можем указать как условие поиска host сontains и имя хоста. Для тех критериев, где система сможет подставить вам данные — она это сделает.

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

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

Поддерживается создание групп условий.

Как видите, инструмент поиска угроз очень гибкий, но этим его функциональность не ограничивается.

При составлении поискового запроса мы можем создать на его основе правило TAA.

Правила TAA в общем понимании — это индикаторы атак IOA. Индикаторы атак содержат информацию о том, какое произошедшее событие или цепочку событий можно идентифицировать как подозрительную активность на узле.

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

После нажатия на кнопку Сохранения как правила TAA вас попросит задать информацию об этом правиле: имя, описание, важность, надежность и необходимость отображать события по этому правилу во вкладке «Обнаружения».

Стоит также дополнительно сказать про такие параметры, как важность и надежность:

• Важность правила TAA определяется тем, какое потенциальное влияние может оказать найденное событие на безопасность сети;
• Надежность правила TAA в свою очередь определяет вероятность ложного обнаружения

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

Задачи

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

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

Политики

Условие, по которому будет происходить блокировка, — это сравнение с MD5 или SHA256 хэшем. Также вы можете добавить имя для правила и указать необходимость уведомления пользователя о блокировке. Запрет может действовать как для всех хостов сети, так и для определенных.

В разделе политик, помимо самих правил запрета, есть дополнительная вкладка «Предустановки».

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

Создание автоматических правил запрета может оказаться полезной функцией в связке с NTA-функциональностью в рамках лицензии KATA.

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

Пользовательские правила

В рамках функционала KEDR нам доступно управление правилами TAA, IOC, YARA и Sandbox.

Этот раздел похож на тот, который мы видели в интерфейсе администратора.

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

Помимо этого, при открытии дополнительной панели хоста (клик на пустом месте строки с хостом) мы можем посмотреть сведения о нем, а также увидеть примененные правила запрета и задачи.

Параметры

Ранее в разделе пользовательских правил мы рассматривали индикаторы компрометации. А в разделе параметров мы можем настроить время запуска проверки хостов индикаторами компрометации, а также максимальную продолжительность проверки.

Максимальная продолжительность проверки может быть от 1 до 23 часов. По умолчанию установлено 23 часа. Важно отметить, что время запуска проверки указывается по UTC.

Второй параметр, который настраивается в этом разделе, — включение автоматической отправки файлов в Sandbox. В случае с правилами TAA, разработанными Лабораторией Касперского, платформа может отправлять файлы с подключенных узлов в песочницу на проверку.

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

• Исключения

Решения класса EDR часто реагируют на легитимную активность. Например: работа системного администратора в PowerShell. Обычным процессом тонкой настройки EDR решения является создания исключений для такой активности. В разделе параметров можно посмотреть все созданные исключения и отменить их. Создание исключений происходит в разделе Обнаружения. Мы обязательно посмотрим, как создаются исключения, когда перейдем к тестированию на вирусных образцах.

Тестирование

Вредоносный файл

После запуска мы получили обнаружение в соответствующем разделе.

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

Перейдем к карточке обнаружения:

В целом карточка обнаружения похожа на то, что мы уже рассматривали в статье тестирования KATA.

Из интересного: мы можем перейти в результатах проверки к правилу TAA, которое сгенерировало обнаружение.

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

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

Настройка условий для исключений происходит привычно поиску угроз. Тут действуют такие же механизмы. Создавать условия исключения можно как в конструкторе, так и в редакторе.

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

Из карточки обнаружения, как и из правила TAA, можно перейти к событиям, которые послужили триггером для этого правила.

Давайте перейдем к событию запуска командной строки cmd.exe.

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

Если пролистать ниже, то можно увидеть дополнительные сведения, вплоть до параметров запуска командной строки.

Если мы перейдем во вкладку «События», то сможем посмотреть связанные события.

В данном случае мы видим, что в 14:56 был запущен процесс rundll32. exe, а в 15:06 сам процесс cmd. exe был завершен. Все события мы можем перенести на граф расследования с помощью значка глаза.

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

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

Удаленное управление узлом

Как можно реализовать подобную проверку на базе инструментария Metasploit, мы описывали в статье тестирования KATA. Здесь мы сразу запустим полезную нагрузку.

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

На такие подключения должен дополнительно реагировать IDS на уровне сети. Это было продемонстрировано при тестировании KATA. В данном случае мы уже смотрим на развитие этой атаки.

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

Наш EDR сразу отреагировал. Каждое обнаружение мы можем детально изучить.

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

Как видим: прародителем процесса powershell стал payload.exe.

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

Реагирование

Удобно, что можно при создании правила изоляции указать исключения.
Например: оставим входящее соединение на порт 3389 со своего рабочего места открытым, чтобы подключиться по RDPи в случае необходимости продолжить расследование непосредственно на самом хосте.

Помимо этого, есть встроенные исключения для DNS, DHCP служб и административных служб продуктов Лаборатории Касперского. Это сделано для того, чтобы сохранить управляемость устройством.

После того как вы нажали «Сохранить» — потребуется некоторое время для применения изоляции. Это связано с таймаутом связи агента с сервером. По умолчанию до 5 минут.

Теперь кнопки изменились, и они показывают, что можно изменить параметры изоляции и снять её. Кнопка снятия изоляции станет активна, когда изоляция применится.

Для того чтобы убедиться, что она применилась, запускаем ping. ICMP тоже становится недоступно, поэтому мы сразу увидим результат.

Помимо этого, пользователю покажет уведомление.

А злоумышленник увидит разрыв соединения.

Теперь давайте получим список процессов. Перейдем в Задачи и нажмем Добавить, Собрать данные и Форензика.

Тут мы можем собрать набор разных данных. Давайте соберем процессы и точки автозапуска. В хостах укажем требуемый.

Задача после создания перейдет в состояние «В обработке». Подождем завершения выполнения.

После завершения мы можем скачать данные.

Данные скачиваются в виде архива с файлами формата CSV. Откроем файл с процессами в EXCEL.

Из списка всех процессов мы нашли наш вредоносный. Скопируем путь до него. Теперь можем перейти в раздел задач и создать задачу завершения процесса.

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

Дополнительно мы можем создать правило запрета запуска файла. Оно создается по хэшу. Его можно почерпнуть из информации о файле в графе расследования или в таблице процессов. Распространим наш запрет на все хосты сети. Можно также указать, уведомлять ли пользователя об этом.

Заключение

Итак, в этой статье мы изучили инструментарий офицера безопасности, а также рассмотрели несколько сценариев атаки и варианты реагирования.
Данной статьёй мы завершаем блок KATA/KEDR, но обязательно продолжим знакомить вас с продуктами Symphony XDR в следующих материалах нашего цикла.

Оставайтесь с нами!