О чем материал
Рассказываем, как мы выявили APT-атаку PhantomCore во время внедрения PT X
Эта история началась 19 января, когда мы внедряли продукт новому заказчику (подробнее — в статье). Уже 20 января заказчик приступил к установке первых EDR-агентов — все шло по плану.
К сожалению, спокойствие длилось всего неделю…
Таймлайн обнаружения и реагирования
26 января. Понедельник, 9:50
Приступаем к очередному этапу профилирования, к этому моменту в инфраструктуре уже работают около 130 EDR-агентов. Почти сразу — тревожный сигнал. Бросаются в глаза сработки правил корреляции: доменный администратор запускал странные запланированные задачи на нескольких хостах. Такие корреляции фолзят крайне редко: либо администраторы используют нетипичный инструментарий, либо в инфраструктуре происходит что-то нехорошее…
Обнаруживаем, что кто-то использовал Atexec. Это утилита для горизонтального перемещения по ИТ-инфраструктуре, которая запускает запланированные задачи через SMB для выполнения произвольных команд на целевой системе.
10:04
Направляем клиенту срочный запрос на верификацию активности. На время ее проведения даем рекомендацию: заблокировать доменную учетную запись (УЗ) подозрительного администратора.
11:24
Получаем от клиента сообщение: «Коллеги, похоже инцидент. Администратор причастность отрицает, в воскресенье этой учетной записью не пользовался».
Итак, инцидент подтвержден! УЗ доменного администратора скомпрометирована, а значит, под угрозой весь домен. Уже через семь минут направляем первые рекомендации по реагированию (опустим конкретные IP-адреса, имена учетных записей, идентификаторы машин и др. ):
- Изолировать скомпрометированные хосты, соответствующий сервер и АРM.
- Заблокировать учетную запись скомпрометированного пользователя, разорвать все активные сессии.
- Заблокировать на межсетевых экранах C2-сервер злоумышленников (задачи, которые запускали атакующие, прокидывали на него шелл при помощи SSH).
- Дважды сменить пароль учетной записи krbtgt и начать сброс паролей для всех привилегированных учеток. Эта рекомендация была связана с нашим предположением об утечке базы ntds.dit (компрометация всего домена).
Поскольку скомпрометирован доменный админ, мы присваиваем инциденту высокую критичность, сразу запускаем процедуру эскалации и начинаем формировать оперативную команду реагирования. Затем проводим созвон со специалистами заказчика и определяем первоначальные шаги по реагированию. Также подключаем к инциденту коллег из команды Incident Response PT ESC для сбора дополнительных артефактов и локализации атаки (поскольку атакующие действовали на хостах, еще не покрытых EDR-агентами).
Параллельно проводим атрибуцию атакующих: по коду, который исполнялся с помощью Atexec, быстро выясняем, что это небезызвестные PhantomCore! В одной из последних кампаний злоумышленники эксплуатировали уязвимость в российском ВКС-сервисе. Мы предположили, что они могли воспользоваться этой лазейкой и в нашем кейсе. Уточняем, какую версию ПО использует заказчик — как раз устаревшую, в которой уязвимость еще не закрыта... После установки агента на скомпрометированную «тачку» наши предположения подтвердились.
Группировка PhantomCore впервые была обнаружена в марте 2024 г. Атаки злоумышленников преимущественно направлены на организации из России и Беларуси.
Зоны интереса: государственное управление, оборонно-промышленный и топливно-энергетический комплексы, научно-исследовательские организации, судостроение, добывающая, обрабатывающая и химическая промышленность, ИТ-компании.
Основная мотивация — кибершпионаж. PhantomCore стремятся к длительному скрытному пребыванию в скомпрометированной сети и краже конфиденциальной информации. Однако некоторые ранние атаки злоумышленников были направлены на остановку бизнес-процессов и нанесение финансового/репутационного ущерба.
12:20
Работа набирает обороты: выявляем еще четыре скомпрометированные учетные записи. Отметим, что на ряде хостов мы обнаружили следы утилиты LaZagne (инструмент для хищения сохраненных паролей).
13:19
Коллеги из ESC IR подтверждают: на одном из серверов с 13 января находится утилита для проксирования трафика micro.exe. Это значит, что злоумышленники создавали скрытые каналы связи.
***
Весь день мы посвятили противодействию и локализации инцидента.
***
Вечер
К концу дня подводим первые итоги. Скомпрометированные хосты изолированы, УЗ заблокированы, C2 перекрыт, пароли сброшены, а сервер ВКС изолирован от интернета. Также мы предупредили клиента о вероятной компрометации службы сертификатов Active Directory (в дальнейшем эти опасения подтвердятся, а значит, нас будет ждать сложнейшая процедура переразвертывания...).
Наводим порядок
После первого дня работы переходим к фазе ликвидации и восстановления. Клиент переустанавливает ADCS, ВКС и продолжает раскатывать EDR-агенты для обеспечения видимости. Мы, в свою очередь, выдаем новый набор рекомендаций:
- Провести аудит стойкости паролей в домене (чтобы определить, какие УЗ находятся в зоне риска) и усилить парольную политику. После смены паролей хакеры потеряли доступ к учетным записям с административными привилегиями. Однако они могут попытаться использовать учетки рядовых пользователей для дальнейшего продвижения.
- Провести аудит групп безопасности, чтобы проверить, не закрепились ли злоумышленники таким образом в домене. Например, они могли добавить рядового пользователя в группу администраторов.
- Настроить логирование DNS, чтобы выявить попытки обращения к новым С2-серверам.
- Провести зануление доменных зон .online и .space, которые любят использовать PhantomCore.
Отметим, что в рамках расследования команда ESC IR при помощи сетевой версии pt-dumper провела сканирование около 500 конечных узлов на наличие следов компрометации (экспресс-enterprise-форензика). В результате коллеги установили факт компрометации одного из контроллеров домена и ряда других узлов.
Параллельно продолжаем «онбординг»: проводим аудит доменных политик, периметра и оснащенных EDR-агентами хостов, а также проверяем стойкость паролей. В процессе обнаруживаем, что у нескольких пользовательских УЗ настроено неограниченное делегирование. Кроме того, 69 учетных записей используют словарные пароли: три из них уязвимы к атаке Kerberoasting, еще один — к AS-REP Roasting. Также выявляем критические мисконфиги: SSH с парольным входом и доступную из интернета бизнес-систему, которая должна находиться во внутреннем сегменте.
Реконструкция атаки
Мы выяснили, что первые следы злоумышленников появились на сервере ВКС еще 12 января. Атакующие выполняли команды локальной разведки и начали эксплуатацию цепочки уязвимостей (1, 2, 3). После этого они затихли на сутки: скорее всего, уязвимости эксплуатировал бот, который сообщил об успешном пробитии.
13 января PhantomCore возобновили активность. Со своего С2-сервера злоумышленники скачали на ВКС-сервер клиента полезную нагрузку api.php (загрузчик файлов) и br.exe (socks-proxy), а также сделали дамп памяти процесса lsass с помощью библиотеки comsvcs.dll. В дампе их ждал джекпот — пароли доменного администратора. Кроме того, в этот момент вскрылась критичная ошибка: сервер ВКС, который должен был находиться в DMZ, висел в общем сегменте. С него открывался прямой доступ к контроллерам домена и центрам сертификации.
Дальше — тихое продвижение. Атакующие прокладывали путь, запускали дополнительные прокси, проводили разведку в домене. Из-за недостаточной глубины логирования и длительного обнаружения (с момента компрометации прошло почти 2 недели) сложно сказать, чем именно занимались PhantomCore в инфраструктуре. Точно можно утверждать одно: домен был скомпрометирован в первый час атаки, злоумышленники сразу получили наивысшие привилегии и могли делать все что угодно.
Во время работы мы обнаружили, что C2-сервер PhantomCore уязвим к CVE-2024-6387. Мы предприняли попытку контратаки, но она не увенчалась успехом: сервер оказался 64-битным, а публичные PoC были только под 32-битную машину. Но попробовать стоило :)
Почему атака стала возможной
1. Использование уязвимой версии ВКС
Разработчики закрыли уязвимость еще в августе 2025 г., однако клиент оставался на старой версии ПО.
Как избежать подобного: внедрить обязательный патч-менеджмент, продукты для управления уязвимостями, проводить регулярный мониторинг бюллетеней безопасности вендоров, тестирование и оперативное развертывание критических обновлений.
2. Отсутствие корректного сетевого сегментирования
Доступный извне сервер ВКС располагался во внутреннем сегменте, а не в изолированной зоне.
Как избежать подобного: размещать все доступные из интернета сервисы в DMZ, применять принцип минимально необходимой сетевой доступности.
3. Отсутствие модели разграничения привилегий (AD Tiering)
Административные учетные записи использовались без разделения по уровням, что позволило атакующим эскалировать привилегии и распространиться по домену.
Как избежать подобного: внедрить модель Tier 0 / Tier 1 / Tier 2, использовать выделенные административные аккаунты, запретить интерактивный вход привилегированным УЗ на нижестоящие уровни, использовать PAW (Privileged Access Workstations).
4. Недостаточное покрытие и ограниченная эффективность СЗИ
В инфраструктуре заказчика были установлены система поведенческого анализа сетевого трафика от Positive Technologies PT NAD и SIEM-система другого вендора. Но при изучении сработок мы выявили, что в PT NAD трафик попадал только из маленького сегмента сети, в котором в момент инцидента все было тихо. У SIEM же покрытие было меньше, чем у PT X, в первый день работы, когда раскатка EDR-агентов только началась…
Как избежать подобного: помните, что покупка СЗИ ≠ правильному внедрению. Нужно регулярно проводить аудит фактического покрытия и устранять слепые зоны.
***
После локализации инцидента мы успешно зачистили следы злоумышленников и больше не наблюдали их активности в инфраструктуре заказчика. К слову, пока мы работали, PhantomCore взломали еще одну российскую организацию, в которой не был внедрен PT X: ее инфраструктура была успешно зашифрована… Выводы делайте сами ;)
