INDEX.PHP: Trellix Case Study: история одной попытки компрометации
Если оценить предыдущие атаки, которые нам приходилось видеть, становится ясно, что сначала происходит разведка через проникновение внутрь организации. Хакеры как грабители: они не открывают первую попавшуюся дверь, а сначала присматриваются к потенциальным жертвам и оценивают свои шансы на успех.
И хотя компании не могут стопроцентно и навсегда защититься от инцидентов, в их силах существенно снизить риски, используя правильные решения.
Так, один из крупнейших заказчиков вендора Trellix в Украине недавно столкнулся с атакой, но благодаря оперативным действиям решения она была своевременно обнаружена и нейтрализована.
Команде BAKOTECH удалось заглянуть внутрь данного инцидента, и теперь мы хотим поделиться с вами увиденным и сделать выводы.
Дисклеймер: BAKOTECH осуществляет свою деятельность через партнерскую сеть и не ведет прямые продажи заказчикам.
Что произошло
Решение Trellix Endpoint Detection and Response (далее — EDR) заметило две подозрительные активности на рабочих станциях организации. Единственное отличие в них — дата и время, когда все это происходило. Данные действия со стороны злоумышленника логичны: он реализовывал стратегию разведки и изучения потенциальной жертвы. Все атаки, проводимые таким путем, направлены на обеспечение удаленного доступа к рабочей станции и в дальнейшем на повышение привилегий, осуществляя «вертикальное перемещение».
Если говорить об обеспечении надлежащего уровня безопасности, нам недостаточно иметь решение, способное только к реагированию. Нужно иметь полное представление о том, как инцидент мог произойти и какие последствия имел бы. Система EDR обнаружила аномальное поведение, вызванное скомпрометированным LNK-файлом. Это включало использование бинарных файлов Living off the Land (далее — LotL) для выполнения обфусцированного VBScript и инициирования связи в дополнение к многочисленным DNS-запросам к подозрительному домену estaca[.]ru.
Компания Trellix связала эту активность с Gamaredon — российской группировкой, ежедневно пытающейся терроризировать украинские цифровые системы. Данное предположение было сделано на основе того, как были использованы тактики, техники и процедуры в ходе атаки.
Почему следует обратить внимание на данный инцидент
Современный мир решений по информационной безопасности не стоит на месте — и хакеры тоже. Они осознают, что все системы могут обнаруживать подозрительные файлы на основе имеющихся сигнатур. Так что хакеры пытаются замаскировать свои следы, используя подход LotL-атак. Тактика проста: скрыть противоправные действия под предлогом легитимного программного обеспечения. Поэтому использования стандартных сигнатур недостаточно: следует уделять больше внимания поведенческому анализу.
В нашем случае злоумышленники использовали бинарные системные файлы, такие как mshta.exe и обфускованные скрипты, доставляемые через вредоносные документы или ярлыки (файлы LNK). Стоит отметить, что это очень эффективный способ обхода традиционных средств безопасности.
Если представить этот процесс как дерево, мы увидим следующее:

Из этого дерева процессов вытекает достаточно много разных операций с разными задачами, что позволяет запутать систему Intrusion Detection System (далее — IDS).
Разберем несколько маркеров, говорящих о компрометации.
Прежде всего, это e.run, который просто производит запуск файла или открытие диска съемного носителя. Он дает пользователю представление о легитимном действии, однако в это время осуществляется запуск вредоносного скрипта. Далее в скрипте происходит запуск e.run («w»+»s»+»cr»+»ip»+»t»+».e»+»x «+»e …»). Скриптовая команда производит разбивание фразы запроса на части и сформирована таким образом, чтобы обойти обнаружение wscript.exe. Во время выполнения происходит склеивание этих частей в одно целое. Далее через команду .bin происходит запуск замаскированного бинарного файла. Последний шаг — Windows close(), закрытие окна, что визуально скрывает весь процесс.
Отчет от Trellix
Команда Trellix сформировала отчет на основе (TTPs), связанных с ATT&CK.
Вот как это примерно выглядит:



Вывод
В случае возникновения подобного инцидента команда BAKOTECH рекомендует выполнить следующие действия:
- Изолировать рабочую станцию и образ. Так вы можете не допустить распространения атаки на другие хосты в вашей сети. Инициируйте процесс аудита и проверки рабочих станций на наличие уязвимого ПО и, в случае необходимости, произведите переустановку.
- Изменить учетные данные на рабочей станции, пострадавшей в результате злонамеренной активности.
- Зафиксировать индикаторы компрометации (IoCs) и заблокировать их.
- Сделать аудит политик выявления, особенно касающихся работы с медиафайлами.
- Просмотреть настройки и политики контроля приложений.
- Установить контроль за запущенными процессами на рабочих станциях.
- Повысить киберосведомленность сотрудников.
- Обновить патчи безопасности.
Если вам нужна консультация по решению, пожалуйста, напишите нам на почту: [email protected]