Всем привет! Меня зовут Сережа Куценко, я ведущий эксперт направления защиты ИТ-инфраструктуры в К2 Кибербезопасность. В прошлом году мы получили специализацию «IT Cybersecurity» «Лаборатории Касперского» по защите ИТ-инфраструктуры при помощи экосистемы решений вендора. Для этого мы развернули и настроили стенд Kaspersky Symphony XDR. Нам, как ИБ-интегратору, он нужен для имитации реальной инфраструктуры заказчиков, реализации различных атак и отслеживания их выполнения с помощью средств защиты (например, KATA или KUMA).
По итогам проекта наш ведущий системный инженер Антон Пуник написал эту статью, чтобы на практике продемонстрировать возможности стенда и других продуктов экосистемы Касперского. С технической частью материала ему помогали коллеги: системный инженер Максим Утенков и аналитик SOC Илья Дегтярь.
Немного теории и терминологии
Экосистема Касперского
Какие средства защиты входят в стенд Kaspersky Symphony XDR:
Kaspersky Endpoint Security (KES) — антивирусная защита.
Kaspersky Web Traffic Security (KWTS) — решение для защиты HTTP-, HTTPS- и FTP-трафика, проходящего через прокси-сервер.
Kaspersky Secure Mail Gateway (KSMG) — инструмент для защиты входящей и исходящей почты от вредоносных объектов, спама и фишинга, выполняет контентную фильтрацию сообщений.
Kaspersky Anti-Targeted Attack Platform (KATA), включая Kaspersky Anti-Targeted Attack Sandbox (KATA Sandbox) — решение для защиты ИТ-инфраструктуры организации и своевременного обнаружения таких угроз, как атаки «нулевого дня», целевые атаки и сложные целевые атаки Advanced Persistent Threats (APT).
Kaspersky Unified Monitoring and Analysis Platform (KUMA) — комплексное программное решение, сочетающее в себе многие функциональные возможности по мониторингу событий информационной безопасности.
Kaspersky Cyber Trace (CT) — платформа анализа киберугроз (Threat Intelligence Platform), обеспечивающая агрегацию индикаторов компрометации из различных источников, в том числе из потоков данных об угрозах «Лаборатории Касперского», и интеграцию с SIEM-системами (Security Information and Event Management) для автоматического поиска индикаторов компрометации (IoC) в журналах событий безопасности и формирования уведомлений об инцидентах в рамках существующих процессов центра информационной безопасности организации.
Помимо средств защиты в стенде были развернуты инфраструктурные сервисы: MS Active Directory, MS Exchange. В качестве рабочих станций мы используем виртуальные машины с серверными ОС Windows.
Весь стенд был полностью развернут в облачной инфраструктуре K2 Cloud. Исключением стала только песочница KATA Sandbox — ее вынесли на отдельный сервер в ЦОД и интегрировали с нашей облачной инфраструктурой.
XDR
Перед погружением в техническую часть давайте также разберемся, что такое XDR.
XDR (Extended Detection and Response) — это своего рода концепция, позволяющая осуществлять расширенное обнаружение и реагирование на сложные угрозы и целевые атаки. В нашем случае используются продукты экосистемы «Лаборатории Касперского», но можно использовать СЗИ от других вендоров.
Концепция XDR предполагает не только сбор и анализ событий с конечных точек, как в EDR, но и анализ событий с других средств защиты. Например, с межсетевых экранов, анализаторов трафика, почтовых шлюзов и т.д. Таким образом, используя XDR, мы получаем более широкую информацию о вредоносных активностях в нашей инфраструктуре.
Преимущества экосистемы решений от одного вендора — это в первую очередь про простоту и полноту интеграций. Зачастую все интеграции у одного вендора работают «из коробки».
Безусловно, стандартные СЗИ (межсетевые экраны, антивирусы, антиспам-системы и т.д.) защитят компанию, но только от уже известных атак (сигнатурный анализ). К тому же, не будет полноценной картины об атаке, мы увидим только детект в средстве защиты. Тут к нам на помощь и приходит XDR.
Концепция XDR строится вокруг ядра системы. В нашем случае это SIEM, в который собираются события из различных источников. Таким образом, при расследовании атаки гораздо больше шансов вычислить всю цепочку атаки и провести мероприятия по устранению последствий или недопущения подобного впредь.
Перейдем к практике.
Без XDR — как сигнатурные антивирусы детектят вредоносы
Рассмотрим сценарий:
Пользователь получает фишинговое письмо.
Скачивает и запускает файл для «экстренного обновления».
С помощью вредоносного файла злоумышленник осуществляет действия по цели
Наш Kill-Chain будет следующим:
Шаг 1. Разведка — допустим, мы ее провели и получили информацию об email-ах сотрудников.
Шаг 2. Действия — с помощью фишингового письма доставляем наш «вредонос» в инфраструктуру:
Увидев письмо от Администратора, пользователь решает выполнить установку апдейта.
Шаг 3. Первоначальный доступ
В итоге наша утилита установлена, запустился процесс update_installer.exe и, вуаля, поднялась сессия с Telegram-ботом злоумышленника.
Давайте посмотрим, что же у нас происходит с СЗИ. Мы имеем starter-pack среднестатистической компании: антиспам, прокси-сервер, антивирус (МСЭ не берем в расчет, считаем, что он есть у каждого).
Как видим — ничего не происходит. Все логично — наш файл не вредоносный, на него нет сигнатур. Как следствие — нет и детекта.
Шаг 4. Действия по цели:
злоумышленник смотрит список запущенных программ;
завершает выполнение диспетчера задач;
стягивает NetNTLM-хеш пользователя;
запускает PowerShell и выполняет различные команды;
Используя даже такие базовые механизмы, можно совершить большое количество различных действий по внутренней разведке и компрометации пользователей и инфраструктуры цели.
Наш сигнатурный антивирус до сих пор молчит.
Прокси сервер также видит только запросы в API Telegram.
Злоумышленник переходит к вредоносной активности — запускает mimikatz. Только в этот момент срабатывает антивирус и детектит наш вредоносный файл. Сам файл мы заблокировали, но нет информации, как он попал в инфраструктуру, что с его помощью делали, какие изменения вносили и т.д.
Завершен процесс с PID 4660 — процесс нашего вредоноса.
Почему же этот файл не детектился? Ответ — это обычный exe-файл, который сам по себе ничего вредоносного не несет, а угрозой тут являются команды, которые он будет выполнять. Наш «волшебный» файл после инсталляции устанавливает сессию с Telegram-ботом по API, из которого мы будем давать различные команды на выполнение.
Вывод кейса — с помощью стандартных средств защиты мы видим только финальную часть атаки, не имея представления о том, как файл к нам попал и что злоумышленник уже успел сделать внутри инфраструктуры.
Как с этим же кейсом справился наш стенд Symphony XDR
Первым делом смотрим в SIEM — в нем сработали алерты и аналитик отправился в долгий путь разбора логов. Рассмотрим все шаги детально.
17:15:40 — запуск браузера Chrome и скачивание файла.
17:18:31 — запуск вредоносного файла Downloads\update_installer.exe.
17:19:39 — множественные обращение к api.telegram.org от процесса «update_installer.exe».
17:21:07 — закрытие Диспетчера задач.
По данному событию видно, что закрытие Диспетчера было выполнено из доверенной УЗ. Но сопоставив время запроса к api.telegram.org (по сетевой активности) и время появления события, делаем вывод, что это выполнял злоумышленник. К тому же, в KATA данное событие также зафиксировано, а инициатором является наш файл update_installer.
17:22:14 — запуск powershell.exe.
Тут ситуация аналогична предыдущему пункту.
17:22:15 — запуск скрипта «Get-NetNTLM.ps1» с командой «Get-NetNTLM-Hash».
17:22:53 — выполнение PowerShell команды «whoami».
17:23:03 — запуск PowerShell команды «net user».
17:26:27 — установка соединения с узлом 172.31.32.6:8000
Примечание — наш стенд носит образовательный характер, поэтому мы не стали публиковать Kali-Linux в интернете и обращаться к ней на внешний IP.
17:26:28 — запуск вредоносного ПО «mimikatz» с выгрузкой паролей в файл .txt. ПО было загружено на хост с узла 172.31.32.6:8000.
На протяжении всей атаки наблюдаются такие сетевые обращения с хоста pc2web по адресу api.telegram.org.
Смотрим в KATA
В KATA мы видим 5 обнаружений. 3 из них — со статусом «критично».
Разобрав обнаружение, мы можем увидеть полностью всю цепочку атаки, начиная от загрузки файла, заканчивая попыткой запуска mimikatz. Проведя небольшое расследование, мы уже можем приступать к реагированию, а затем и к усилению защиты и отдельных СЗИ, чтобы в дальнейшем такие ситуации не повторялись.
2. Мы получаем подозрительный файл.
3. Cоздаем правило запрета для всех хостов.
Вывод
Безусловно, XDR не является ответом на все угрозы. ИТ-инфраструктура — это живой организм, который необходимо регулярно модернизировать. Это должно быть непрерывным процессом с учетом усложнения механик злоумышленников, которые постоянно меняют векторы атак и адаптируют их под текущие реалии.
Тем не менее XDR — одна из важнейших составляющих эффективной киберзащиты. Использование стандартных СЗИ (антивирус, антиспам и т.д.) позволит нам детектировать вредоносы по сигнатурам, а XDR — зафиксировать что-то неладное еще на раннем этапе направленной атаки, которую могут пропустить стандартные СЗИ.
Мы в К2 Кибербезопасности стараемся поддерживать наш стенд в актуальном состоянии, регулярно обновляя СЗИ, тестируя различные конфигурации и механизмы защиты, используя стенд для демонстрации работы решений «Лаборатории Касперского» заказчикам.
