НОВОСТИ Как обнаруживать перемещение атакующих по сети

NewsBot
Оффлайн

NewsBot

.
.
Регистрация
21.07.20
Сообщения
40.408
Реакции
1
Репутация
0
На проектах по анализу защищенности корпоративных информационных систем в 2019 году нашим пентестерам удалось преодолеть . При этом в сеть 50% компаний можно было проникнуть всего за один шаг. Чтобы не дать реальным атакующим достичь цели, важно вовремя выявлять их активность. Один из критически важных этапов атаки — перемещение внутри периметра (lateral movement), когда злоумышленники расширяют свое присутствие в сети.

В этой статье я покажу, какая активность относится к перемещению внутри периметра и как, используя сетевой анализ, выявить применение такой тактики.

Что относится к перемещению внутри периметра


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

28d048cba6e6b990440f9bc498c14ad2



Первая схема иллюстрирует жизненный цикл и отражает действия злоумышленника во время атаки на информационную систему:


  1. Атакующий проводит внешнюю разведку (Recon)


  2. Компрометирует систему (Initial Compromise)


  3. Старается сохранить свое присутствие на этой системе (Establish Persistence)


  4. Повышает права (Escalate Privileges)


  5. Проводит внутреннюю разведку (Internal Recon)


  6. Выбирает удобный для себя транспорт и осуществляет подключение к жертве (Lateral Movement)


  7. Собирает и анализирует найденные данные (Data Analysis)


  8. Опционально повторяет действия 4―7 (для других компонентов системы)


  9. В завершение злоумышленник выносит найденные ценные данные (Exfiltration and Complete Mission)

Для Active Directory существует понятие Kill Chain, которое отражает цепочку действий, необходимых для полной компрометации домена.

b2588ea5ea9dad44fbd05f1d8229a7f3



  1. Атакующий компрометирует первую машину и проводит внутреннюю разведку


  2. Повышает на машине локальные права


  3. Получает привилегированные учетные данные


  4. Проводит разведку с правами администратора


  5. Использует удобный способ для удаленного выполнения кода


  6. Повторяет шаги 2—5 до получения учетных данных доменного администратора


  7. Добивается максимальных привилегий в домене и окончательно закрепляется в системе


  8. Находит ценные данные, используя полный доступ ко всем частям системы


  9. Выносит найденные данные

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

66a58b84dee97f6e60cf122195678a50

ATT&CK Matrix for Enterprise

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

Lateral movement (или перемещение внутри периметра) характеризует то, как атакующий, используя существующие в системе механизмы, может перемещаться от одной машины к другой. К таким механизмам может относиться DCOM, программы для удаленного обновления приложений, удаленное копирование файлов или протокол удаленного рабочего стола. При успешной начальной компрометации системы с использованием техник перемещения внутри периметра злоумышленник может завладеть учетными записями привилегированных пользователей и быстро расширить свое присутствие вплоть до полного контроля над инфраструктурой.

Пример перемещения злоумышленника внутри периметра


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

Итак, в инфраструктуре есть:


  • сервер для тестирования приложений с ASP и .NET, находящийся в DMZ;


  • devops-инженер agusev, ответственный за этот сервер;


  • системный администратор gpavlov с двумя учетными записями;


  • контроллер домена DC с учетной записью Administrator.

У пользователей agusev и gpavlov есть личные компьютеры внутри домена с соответствующими именами.

fbbe3299bd1420fc58e18b791d4c46f1


1. Изначальная компрометация

Мы начинаем с того, что гипотетический атакующий смог попасть и закрепиться на сервере для тестирования приложений. На нем он находит учетные данные некоего devops-инженера agusev, который использовал этот сервер со своей доменной машины. Но перед злоумышленником стоит вопрос о том, как можно развить атаку внутрь инфраструктуры.

2. Внутренняя разведка с BloodHound через DCOM (T1021.003)

Он начинает с разведки с помощью BloodHound. Как выяснилось, agusev ранее использовал Distributed Component Object Model (DCOM). Поэтому злоумышленник использует этот же протокол для запуска SharpHound (ингестор ПО BloodHound) на машине AGUSEV. В нашем случае для запуска был использован объект Microsoft Management Console (MMC) 2.0.

ca35b2d1a9054248efeaa7f05db046ee


Сам по себе DCOM служит для поддержки связи между объектами на различных компьютерах и часто используется в приложениях из нескольких компонентов, которые общаются друг другом через сеть. Существует множество стандартных объектов, которые можно использовать через DCOM. В их числе и объекты, которые позволяют удаленно выполнить код (такие как MMC 2.0). Подробнее об этом можно почитать и .

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

eaabe80be170f0595ba21a686d4678a2


Анализ связей объектов AD в ПО BloodHound

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

3. Подбор пароля через RDP-сессию (T1021.001 и T1570)

Злоумышленник организует RDP-сессию с подконтрольного сервера на машину AGUSEV. Через эту RDP-сессию он передает инструмент kerbrute ( ), с помощью которого хочет подобрать пароль к учетной записи gpavlovAdm.

b8d89a955e1fefbf8a6e4af11933c215


Kerbrute проходится по словарю и не получает ни одной успешной аутентификации. Атакующий делает вывод, что для этой учетной записи был выбран достаточно стойкий пароль. Просмотрев повторно похожие по имени учетные записи через BloodHound, он находит учетную запись gpavlov. Исходя из похожести имен есть все основания полагать, что на машине GPAVLOV сохранились учетные данные и gpavlov, и gpavlovAdm.

9792da5aafc59c63881a99a3e4d8c104


Просмотр пользователей домена в ПО BloodHound

Следующим шагом злоумышленник успешно подбирает к ней пароль с помощью того же словаря и kerbrute.

4. Получение учетной записи системного администратора c помощью smbexec (T1021.002)

Итак, у атакующего под контролем учетная запись gpavlov и пользователь является администратором на своей машине (а значит, открыты системные шары). Это позволяет без препятствий воспользоваться скриптом smbexec из Impacket. Цель та же, что и была, — получение учетных данных gpavlovAdm. Он использует mimikatz в качестве полезной нагрузки и библиотеку ( ).

4a818c3dd963673756d42aa4e9fe6f85


SharpSploit неслучайно имеет сходство в названии с известным PowerSploit. Если последний представляет из себя набор модулей и функций для разных целей на PowerShell, то SparpSploit — это одна DLL на C# с использованием .NET . Этот инструмент системы защиты, построенные на анализе событий.

5. Компрометация контроллера домена

С помощью mimikatz и SharpSploit злоумышленник получил учетные данные системного администратора. На этапе разведки он узнал, что этот аккаунт является привилегированным и позволяет произвести дамп ntds.dit. Осуществить план позволяет скрипт secretsdump из Impacket ( ).

b21a636ec9f4a7871bff62b594d96493


После этого домен полностью переходит под контроль атакующего. Для наглядности мы сделали маппинг такой атаки на матрицу ATT&CK.

5acfeb2c66d3b6d23aa5ca5ba5cb8e13

Список техник в атаке

Рассмотрим анализ такой атаки на примере NTA-системы . PT NAD анализирует трафик на уровнях L2—L7, выявляет атаки и хранит сырой трафик и метаданные, что полезно при расследованиях.

Расследование инцидента


Были ли нетипичные соединения внутри инфраструктуры?

С помощью дашбордов по серверам и, особенно, по основным протоколам можно выявлять несанкционированную активность. К примеру, анализ протоколов показывает количество сессий по RDP — что были за данные, кто был клиентом, а кто сервером. Анализ этой информации показывает, что клиент находился внутри DMZ, а RDP-сервер внутри домена. Это странно, так как в легитимном сценарии активность могла бы идти с компьютера devops-инженера на сервер, а не наоборот.

334687106fe4f7ba8947af4a3c9d556a

Дашборды PT Network Attack Discovery

Что еще было между узлами, кроме подозрительной RDP-сессии?

Нашлась SMB-активность с использованием DCERPC. Анализ операций RPC позволяет быстро обнаружить использование DCOM-протокола и ПО Impacket. Эта активность четко относится системой к lateral movement и помечается соответствующим образом.

bcf482e6d09f775e76be53e1c4493f6c

Оповещение о найденной атаке с использованием DCOMExec из Impacket

Далее можно найти дополнительные подробности в сессиях — например, выявить паттерны инструментов Impacket. Вызов cmd.exe из system32 также выглядит подозрительно. Внутри команды мы видели HTTP-ссылку.

Загружалось ли что-то на АРМ для развития атаки?

Дашборд файлов показал, что был загружен файл со случайным именем; сетевой анализ сам по себе не позволит понять, что это за файл. Однако анализ «соседних» сессий позволит обнаружить активность, похожую на разведку домена — например, анализ SPN-имен служб в Active Directory. Вероятно, злоумышленники таким образом выбирают цель для атаки.

e69b1895f479e4ab521311b8ed3e8050

Оповещение о найденной атаке по протоколу LDAP

Система обнаруживает разведку по протоколу LDAP. Примечательно, что все действия произошли в рамках одной сессии. Это говорит о том, что для атаки, скорее всего, использовался автоматизированный инструмент и, вероятно, им был BloodHound. Вернувшись к начальным шагам анализа, можно осуществить фильтрацию трафика, но уже по протоколу Kerberos. Было обнаружено 8380 сессий за короткий интервал времени с одного узла: это явно ненормально. PT NAD просигнализировал о возможном подборе пароля по протоколу Kerberos.

e1308d8deff904ebc0b8f622c9538efd

Сессии по протоколу Kerberos

К чему подбирали пароль? Удалось или нет?

Анализ сессий позволяет узнать, что подбирался пароль к учетным записям пользователей gpavlovAdm и gpavlov. При ошибке аутентификации Kerberos-сервер (KDC) отправляет сообщение с ошибкой. PT NAD позволяет исключить сессии с неудачной аутентификацией и найти только успешные сессии. Успешной аутентификации за время атаки для пользователя gpavlovAdm не было найдено, значит — пароль не был подобран. Для gpavlov была найдена успешная аутентификация, это значит, что пароль был скомпрометирован.

df82b494c2d3ad5df6de696fc6cf4e2a

Использование аккаунта gpavlov для загрузки SharpSploit

Использовались ли скомпрометированные данные? Если да, то для чего?

Зная это, мы можем проанализировать любые соединения с использованием этих учетных данных. Так можно увидеть попытку открытия Service Control Manager с помощью Impacket, создание сервиса и загрузку файла sharpsloit.dll.

65d7a6636529e4696b4ceec15f06c382

Подтверждение факта загрузки SharpSploit

Ранее пароль подбирался только к двум учетным записям, а первые неудачные соединения были с учетной записью gpavlovAdm. Исходя из этого можно предположить, что цель атакующего — аккаунт gpavlovAdm. На дашборде мы видим успешную аутентификацию с его использованием и подключение к контроллеру домена. Вкладка PT NAD с атаками показывает, что аккаунт был использован для доступа к SCM, а также дампа данных, включая SAM, LSA, SECURITY и NTDS. На этой стадии можно сказать, что домен был полностью скомпрометирован и находится под контролем злоумышленника.

3e9eb08f3c83a228ad8c5f4ff1eb4e25

Оповещения о дампе реестра контроллера домена
Как противодействовать lateral movement


Существует ряд шагов, которые позволяют минимизировать риск или полностью предотвратить атаки, подобные описанной выше. Для этого следует:


  • ограничить избыточное использование системных COM-объектов, не связанных с приложением (например, MMC 2.0);


  • блокировать учетные записи после большого количество ошибок аутентификации;


  • ограничить права учетных записей helpdesk и использовать подход Just Enough Administration;


  • запретить удаленный вход для учетных записей локальных администраторов;


  • блокировать использование System.Management.Automation.dll.

Автор: Егор Подмоков, специалист отдела экспертных сервисов (PT ESC)
 
Сверху Снизу