На проектах по анализу защищенности корпоративных информационных систем в 2019 году нашим пентестерам удалось преодолеть сетевой периметр 93% компаний. При этом в сеть 50% компаний можно было проникнуть всего за один шаг. Чтобы не дать реальным атакующим достичь цели, важно вовремя выявлять их активность. Один из критически важных этапов атаки — перемещение внутри периметра (lateral movement), когда злоумышленники расширяют свое присутствие в сети.
В этой статье я покажу, какая активность относится к перемещению внутри периметра и как, используя сетевой анализ, выявить применение такой тактики.
Что относится к перемещению внутри периметра
Для начала давайте рассмотрим несколько схем, которые помогут понять, на какие этапы делится атака.
Первая схема иллюстрирует жизненный цикл операций red team и отражает действия злоумышленника во время атаки на информационную систему:
Атакующий проводит внешнюю разведку (Recon)
Компрометирует систему (Initial Compromise)
Старается сохранить свое присутствие на этой системе (Establish Persistence)
Повышает права (Escalate Privileges)
Проводит внутреннюю разведку (Internal Recon)
Выбирает удобный для себя транспорт и осуществляет подключение к жертве (Lateral Movement)
Собирает и анализирует найденные данные (Data Analysis)
Опционально повторяет действия 4―7 (для других компонентов системы)
В завершение злоумышленник выносит найденные ценные данные (Exfiltration and Complete Mission)
Для Active Directory существует понятие Kill Chain, которое отражает цепочку действий, необходимых для полной компрометации домена.
Атакующий компрометирует первую машину и проводит внутреннюю разведку
Повышает на машине локальные права
Получает привилегированные учетные данные
Проводит разведку с правами администратора
Использует удобный способ для удаленного выполнения кода
Повторяет шаги 2—5 до получения учетных данных доменного администратора
Добивается максимальных привилегий в домене и окончательно закрепляется в системе
Находит ценные данные, используя полный доступ ко всем частям системы
Выносит найденные данные
Первая и вторая схемы часто используются на практике, но не отражают конкретных вариантов действий злоумышленника на том или ином этапе.
Многие наверняка слышали о матрице ATT&CK, она решает эту проблему. Ее разработала и поддерживает некоммерческая организация MITRE. Матрица отражает тактики и техники атакующих и основана на реальных наблюдениях большого количества экспертов. В заголовках находятся тактики, в ячейках таблицы – техники. Ее часто используют при моделировании угроз и классификации атак. Мы тоже руководствуемся ею при изучении атак, после чего экспертиза поступает в наши продукты.
Lateral movement (или перемещение внутри периметра) характеризует то, как атакующий, используя существующие в системе механизмы, может перемещаться от одной машины к другой. К таким механизмам может относиться DCOM, программы для удаленного обновления приложений, удаленное копирование файлов или протокол удаленного рабочего стола. При успешной начальной компрометации системы с использованием техник перемещения внутри периметра злоумышленник может завладеть учетными записями привилегированных пользователей и быстро расширить свое присутствие вплоть до полного контроля над инфраструктурой.
Пример перемещения злоумышленника внутри периметра
Рассмотрим детально один из вариантов действий злоумышленника внутри инфраструктуры. В данном случае изначальная компрометация нас мало интересует, так как она может быть любой и мало влияет на ход дальнейшей атаки.
Итак, в инфраструктуре есть:
сервер для тестирования приложений с ASP и .NET, находящийся в DMZ;
devops-инженер agusev, ответственный за этот сервер;
системный администратор gpavlov с двумя учетными записями;
контроллер домена DC с учетной записью Administrator.
У пользователей agusev и gpavlov есть личные компьютеры внутри домена с соответствующими именами.
1. Изначальная компрометация
Мы начинаем с того, что гипотетический атакующий смог попасть и закрепиться на сервере для тестирования приложений. На нем он находит учетные данные некоего devops-инженера agusev, который использовал этот сервер со своей доменной машины. Но перед злоумышленником стоит вопрос о том, как можно развить атаку внутрь инфраструктуры.
2. Внутренняя разведка с BloodHound через DCOM (T1021.003)
Он начинает с разведки с помощью BloodHound. Как выяснилось, agusev ранее использовал Distributed Component Object Model (DCOM). Поэтому злоумышленник использует этот же протокол для запуска SharpHound (ингестор ПО BloodHound) на машине AGUSEV. В нашем случае для запуска был использован объект Microsoft Management Console (MMC) 2.0.
Сам по себе DCOM служит для поддержки связи между объектами на различных компьютерах и часто используется в приложениях из нескольких компонентов, которые общаются друг другом через сеть. Существует множество стандартных объектов, которые можно использовать через DCOM. В их числе и объекты, которые позволяют удаленно выполнить код (такие как MMC 2.0). Подробнее об этом можно почитать здесь и здесь.
Таким образом, злоумышленник получил основную информацию о домене, пользователях, группах и доменных машинах.
Анализ связей объектов AD в ПО BloodHound
С помощью анализа графа BloodHound атакующий выбирает своей целью учетную запись системного администратора gpavlovAdm, так как она входит в группы локальных и доменных администраторов.
3. Подбор пароля через RDP-сессию (T1021.001 и T1570)
Злоумышленник организует RDP-сессию с подконтрольного сервера на машину AGUSEV. Через эту RDP-сессию он передает инструмент kerbrute (https://github.com/ropnop/kerbrute), с помощью которого хочет подобрать пароль к учетной записи gpavlovAdm.
Kerbrute проходится по словарю и не получает ни одной успешной аутентификации. Атакующий делает вывод, что для этой учетной записи был выбран достаточно стойкий пароль. Просмотрев повторно похожие по имени учетные записи через BloodHound, он находит учетную запись gpavlov. Исходя из похожести имен есть все основания полагать, что на машине GPAVLOV сохранились учетные данные и gpavlov, и gpavlovAdm.
Просмотр пользователей домена в ПО BloodHound
Следующим шагом злоумышленник успешно подбирает к ней пароль с помощью того же словаря и kerbrute.
4. Получение учетной записи системного администратора c помощью smbexec (T1021.002)
Итак, у атакующего под контролем учетная запись gpavlov и пользователь является администратором на своей машине (а значит, открыты системные шары). Это позволяет без препятствий воспользоваться скриптом smbexec из Impacket. Цель та же, что и была, — получение учетных данных gpavlovAdm. Он использует mimikatz в качестве полезной нагрузки и библиотеку SharpSploit (Github).
SharpSploit неслучайно имеет сходство в названии с известным PowerSploit. Если последний представляет из себя набор модулей и функций для разных целей на PowerShell, то SparpSploit — это одна DLL на C# с использованием .NET для всего. Этот инструмент способен обходить системы защиты, построенные на анализе событий.
5. Компрометация контроллера домена
С помощью mimikatz и SharpSploit злоумышленник получил учетные данные системного администратора. На этапе разведки он узнал, что этот аккаунт является привилегированным и позволяет произвести дамп ntds.dit. Осуществить план позволяет скрипт secretsdump из Impacket (Github).
После этого домен полностью переходит под контроль атакующего. Для наглядности мы сделали маппинг такой атаки на матрицу ATT&CK.
Рассмотрим анализ такой атаки на примере NTA-системы PT Network Attack Discovery. PT NAD анализирует трафик на уровнях L2—L7, выявляет атаки и хранит сырой трафик и метаданные, что полезно при расследованиях.
Расследование инцидента
Были ли нетипичные соединения внутри инфраструктуры?
С помощью дашбордов по серверам и, особенно, по основным протоколам можно выявлять несанкционированную активность. К примеру, анализ протоколов показывает количество сессий по RDP — что были за данные, кто был клиентом, а кто сервером. Анализ этой информации показывает, что клиент находился внутри DMZ, а RDP-сервер внутри домена. Это странно, так как в легитимном сценарии активность могла бы идти с компьютера devops-инженера на сервер, а не наоборот.
Что еще было между узлами, кроме подозрительной RDP-сессии?
Нашлась SMB-активность с использованием DCERPC. Анализ операций RPC позволяет быстро обнаружить использование DCOM-протокола и ПО Impacket. Эта активность четко относится системой к lateral movement и помечается соответствующим образом.
Далее можно найти дополнительные подробности в сессиях — например, выявить паттерны инструментов Impacket. Вызов cmd.exe из system32 также выглядит подозрительно. Внутри команды мы видели HTTP-ссылку.
Загружалось ли что-то на АРМ для развития атаки?
Дашборд файлов показал, что был загружен файл со случайным именем; сетевой анализ сам по себе не позволит понять, что это за файл. Однако анализ «соседних» сессий позволит обнаружить активность, похожую на разведку домена — например, анализ SPN-имен служб в Active Directory. Вероятно, злоумышленники таким образом выбирают цель для атаки.
Система обнаруживает разведку по протоколу LDAP. Примечательно, что все действия произошли в рамках одной сессии. Это говорит о том, что для атаки, скорее всего, использовался автоматизированный инструмент и, вероятно, им был BloodHound. Вернувшись к начальным шагам анализа, можно осуществить фильтрацию трафика, но уже по протоколу Kerberos. Было обнаружено 8380 сессий за короткий интервал времени с одного узла: это явно ненормально. PT NAD просигнализировал о возможном подборе пароля по протоколу Kerberos.
К чему подбирали пароль? Удалось или нет?
Анализ сессий позволяет узнать, что подбирался пароль к учетным записям пользователей gpavlovAdm и gpavlov. При ошибке аутентификации Kerberos-сервер (KDC) отправляет сообщение с ошибкой. PT NAD позволяет исключить сессии с неудачной аутентификацией и найти только успешные сессии. Успешной аутентификации за время атаки для пользователя gpavlovAdm не было найдено, значит — пароль не был подобран. Для gpavlov была найдена успешная аутентификация, это значит, что пароль был скомпрометирован.
Использовались ли скомпрометированные данные? Если да, то для чего?
Зная это, мы можем проанализировать любые соединения с использованием этих учетных данных. Так можно увидеть попытку открытия Service Control Manager с помощью Impacket, создание сервиса и загрузку файла sharpsloit.dll.
Ранее пароль подбирался только к двум учетным записям, а первые неудачные соединения были с учетной записью gpavlovAdm. Исходя из этого можно предположить, что цель атакующего — аккаунт gpavlovAdm. На дашборде мы видим успешную аутентификацию с его использованием и подключение к контроллеру домена. Вкладка PT NAD с атаками показывает, что аккаунт был использован для доступа к SCM, а также дампа данных, включая SAM, LSA, SECURITY и NTDS. На этой стадии можно сказать, что домен был полностью скомпрометирован и находится под контролем злоумышленника.
Как противодействовать lateral movement
Существует ряд шагов, которые позволяют минимизировать риск или полностью предотвратить атаки, подобные описанной выше. Для этого следует:
ограничить избыточное использование системных COM-объектов, не связанных с приложением (например, MMC 2.0);
блокировать учетные записи после большого количество ошибок аутентификации;
ограничить права учетных записей helpdesk и использовать подход Just Enough Administration;
запретить удаленный вход для учетных записей локальных администраторов;
блокировать использование System.Management.Automation.dll.
Автор: Егор Подмоков, специалист отдела экспертных сервисов PT Expert Security Center (PT ESC)
