Бесплатно Экспресс-аудит сайта:

11.09.2020

От учетной записи к полному компрометированию домена

Автор: Haboob Team

Введение

В статье будут продемонстрированы техники, используемые пентестерами, для первоначального проникновения в сеть и последующего полного компрометирования домена без запуска сторонних приложений или повторного применения учетных записей в открытом виде. Мы рассмотрим, как работает среда на базе Windows, когда включен IPv6 (что есть по умолчанию), с целью получения контроля над DNS (при помощи утилиты MITM6) и ретранслирования учетных записей в LDAPS (LDAP поверх TLS), используя инструмент Ntlmrelayx, для создания новых машинных аккаунтов.

При помощи нового машинного аккаунта мы сможем пройти аутентификацию в LDAP и изменить некоторые свойства системы для доступа к целевой машине от имени практически любого пользователя (и даже администратора домена). Технология, которую мы рассмотрим в деталях, представляет собой ограниченное ресурсное делегирование. Впоследствии, чтобы полностью скомпрометировать сеть, мы воспользуемся уязвимостью SpoolService (PrinterBug) с целью принудительной аутентификации из контроллера домена к хосту, находящимся под нашим контролем, где включено неограниченное делегирование. Используя эту технику, мы сможем извлечь билет krbtgt для выгрузки базы данных контроллера домена.

Ресурсное и неограниченное делегирование

Если упростить концепцию делегирования в Kerberos, то можно сказать, что эта технология, позволяющая приложению повторно использовать учетные записи конечного пользователя для доступа к ресурсам, расположенным на другом сервере.

Ограниченное ресурсное делегирование

В документации от Microsoft говорится следующее: «Ограниченное делегирование в Kerberos используется в тех случаях, когда служба фронт-энда и ресурсная служба находятся в разных доменах. Администраторы службы могут настроить новое делегирование, указав аккаунты домена для служб фронт-энда, которые могут олицетворять пользователей в объектах учетных записей служб, связанных с ресурсами». Сей факт означает, что ограниченное ресурсное делегирование может быть сконфигурировано для ресурса или машинной учетной записи и управляется атрибутом (msDSAllowedToActOnBehalfOfOtherIdentity).

Неограниченное делегирование

Насчет неограниченного делегирования Олег Александров сказал следующее: «Серверу, которому доверяют неограниченное делегирование, позволено олицетворять (практически) любого пользователя любой службы внутри сети. Когда пользователь запрашивает Билет службы (Service Ticket; ST) у контроллера домена для какой-либо службы, что разрешено при делегации, контроллер домена копирует клиентский TGT (Ticket Granting Ticket; Билет на выдачу билетов) и прикрепляет этот билет к билету службы, который впоследствии презентуется соответствующей службе. Когда пользователь получает доступ к службе при помощи билета, пользовательский TGT извлекается и сохраняется в службе сервера LSASS для последующих нужд».

Соответственно, если мы контролируем хост, где включено неограниченное делегирование, то можем извлекать TGT и повторно использовать в любой службе из процесса LSASS. Более подробно о делегации в Kerberos рассказывается в статье Wagging the Dog .

Что такое SPN

SPN (Service Principal Name; Первичное имя сервиса) представляет собой уникальный идентификатор экземпляра службы. SPN’ы используются во время аутентификации в Kerberos для связи экземпляра службы с аккаунтом авторизации в службе, что позволяет клиентскому приложений запрашивать у службы аутентификацию учетной записи, даже если у клиента нет имени аккаунта.

Более подробно эта тема рассматривается в следующих статьях:

  • Service Principal Names

  • resource based constrained delegation abuse

  • kerberos constrained delegation overview

IPV6 в Windows и WPAD

Протокол IPv6 активирован по умолчанию во всех версиях Windows, начиная с Vista. Во время загрузки Windows сначала ищется конфигурация для DHCP, а затем для WPAD. При реализации атаки мы получим контроль над DNS при помощи утилиты MITM6 с целью перенаправления всего трафика на наш DNS сервер, и когда хост начнет искать конфигурацию для WPAD через DNS, целевые машины будут подключаться к нашему прокси-серверу с целью аутентификации на нашем сервере, где используется скрипт ntlmrelax. Кроме того, учетные записи будут ретранслироваться в LDAPS для создания новых машинных аккаунтов.

Полная схема атаки

Чтобы применить вышеуказанные концепции и техники на практике, была создана тестовая среда, состоящая из Windows Server 2012R2 (контроллер домена), клиентского хоста с Windows 10 (Mark-pc), AppServer с Windows 10 и нашей машины с Kali Linux, откуда будет осуществляться атака. Предполагается, что наша рабочая система находится в той же подсети вместе с целевыми машинами.

Рисунок 1: Полная схема атаки

Демонстрация атаки

Как было упомянуто выше, предполагается, что наша рабочая система (с Kali Linux) находится в одной подсети с целевыми машинами. Реализация атаки начинается с проверки подписывания в SMB при помощи утилиты CrackMapExec, поскольку в нашем случае требуется, чтобы эта функция была отключена.

CrackMapExec можно загрузить из официального репозитория или установить, используя следующую команду:

apt-get install crackmapexec

Начинаем с проверки IP-конфигурации нашей машины:

Рисунок 2: IP-конфигурация рабочей системы

Затем запускаем CrackMapExec с целью проверки подписывания и детектирования живых хостов:

Рисунок 3: Сканирование сети при помощи CrackMapExec

Теперь мы знаем, что имя внутреннего домена – «contoso». Кроме того, было обнаружено три живых хоста, на двух из которых подпись в SMB отключена (в контроллере домена подпись в SMB включена по умолчанию). Далее проверяем, включено ли разрешение имен LLMNR и NBT-NS. Для решения этой задачи я буду запускать ответчик в течение короткого промежутка времени и проверять, смогу ли поймать какие-либо запросы.

Рисунок 4: Ответчик

Как видно на рисунке выше, ответчик начал ловить запросы и отвечать на разрешения имен LLMNR и NBT-NS, из чего мы делаем вывод, что эта функция работает.

Также, поскольку мы создаем новый машинный аккаунт, нужно проверить, настроен ли LDAP поверх TLS (LDAPS). Запускаем nmap и сканируем контроллер домена на предмет присутствия открытого порта 636:

Рисунок 5: Сканирование на предмет присутствия LDAPS

Теперь, когда все требования для реализации атаки выполняются, переходим к использованию фреймворка MITM6 и скрипта ntlmrelayx для ретранслирования перехваченных учетных записей в LDAPS и создание нового машинного аккаунта на основе перехваченных данных. Чтобы успешно осуществить запланированный сценарий, нужно добавить цели в белый список, которые будут перезагружены (клиентские машины). Наш же сервер с MITM6 используется для перенаправления трафика от целевых систем на подконтрольный нам DNS сервер.

Для упрощения задачи я добавил в белый список машину Mark-pc, которая будет перезагружаться из моей рабочей среды.

Рисунок 6: Конфигурация MITM6

Далее запускаем скрипт ntlmrelayx с указанием протокола LDAPS и контроллера домена, как показано на рисунке ниже.

Рисунок 7: Подключаем ретранслирование в LDAPS

После перезагрузки Mark-pc этой машине был назначен IP адрес с нашего DNS сервера. Как видно на скриншоте ниже, IPv6 DNS обладает более высоким приоритетом, чем IPv4 DNS.

Рисунок 8: У IPv6 DNS выше приоритет

Если все прошло по плану, мы увидим, что ntlmrelayx начал собирать учетные записи и пытаться атаковать LDAPS на контроллере домена.

Рисунок 9: Результаты работы ntlmrelayx

Как только ntlmrelayx успешно пройдет аутентификацию в LDAPS при помощи ретранслируемых аккаунтов, то далее будет пытаться создать новую машинную учетную запись на базе тех аккаунтов и модифицировать атрибут «msDS-AllowedToActOnBehalfOfOtherIdentity» на машине Mark-pc, чтобы была возможность выступать от имени любого пользователя этой системы.

Рисунок 10: Успешная аутентификация и создание новой машинной учетной записи

Сразу же возникает вопрос: «Почему возможно создание новой учетной записи в домене на базе перенаправляемых аккаунтов?». Судя по скриншоту ниже, любой пользователь в Active Directory может создать до 10 машинных учетных записей.

Рисунок 11: Квота на создание машинных аккаунтов

При просмотре пользователей контроллера домена и компьютеров видно, что атака завершена успешно и ntlmrelayx добавил новую машину.

Рисунок 12: Машинные аккаунты контроллера домена

Кроме того, ntlmrelayx будет выгружать информацию о домене, если мы подключимся к LDAPS, используя ретранслируемую учетную запись ( ldapdomaindump ).

Рисунок 13: Выгрузка информации о домене

Поскольку у нас появился машинный аккаунт и модифицировано свойство «msDS-AllowedToActOnBehalfOfOtherIdentity», то теперь можно воспользоваться скриптом getST.py из проекта Impacket для запроса билета службы и получения привилегий администратора домена (contosoAdministrator) на машине Mark-pc.

Рисунок 14: Запрос билета службы

Как видно на рисунке выше, мы успешно запросили билет службы при помощи машинного аккаунта от имени учетной записи «Administrator» и сохранили полученные данные в файл CCACHE.

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

Рисунок 15: Пользователи домена

Теперь добавляем Kerberos-билет из файла CCACHE в переменную окружения «KRB5CCNAME» при помощи команды «export»:

export KRB5CCNAME=/root/Desktop/Administrator.ccache

Далее при помощи скрипта Impacket Wmiexec будем запускать команды с привилегиями администратора домена. Обратите внимание, что CIFS SPN пригоден только для доступа к общим файловым ресурсам (например, при помощи Smbclient), однако Wmiexec осуществит попытку автоматической смены на HOST SPN, чтобы мы могли выполнять WMI-запросы и команды.

Рисунок 16: Запуск скрипта wmiexec на машине Mark-pc

После успешного завершения откроется полуинтерактивный шелл с привилегиями «contosoAdministrator».

Рисунок 17: На машине Mark-pc появился шелл

При помощи билета Kerberos-службы и скрипта Impackеt SecretsDump выгружаем локальные хэши.

Рисунок 18: Выгрузка локальных хэшей на машине Mark-pc

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

Рисунок 19: Выгрузка учетных записей в открытом виде на машине Mark-pc

После первоначального закрепления внутри сети попробуем выполнить полное компрометирование домена. Начинаем с изучения ранее выгруженной информации при помощи ntlmrelayx.

Сразу же замечаем, что AppServer настроен на неограниченное делегирование, и в случае компрометирования мы сможем экспортировать и повторно использовать билеты из памяти или при помощи уязвимости SpoolService заставить контроллер домена подключиться к AppServer, а затем выгрузить базу данных, используя TGT.

Рисунок 20: Компьютеры домена

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

Снова возвращаемся к выгруженной информации и находим интересную группу домена с именем «Servers Admins».

Рисунок 21: Группы домена

Для нахождения членов этой группы воспользуемся скриптом bloodhound.py , учетной записью mark и данными, импортированными в приложение BloodHound .

Рисунок 22: Выполнение скрипта Bloodhound.py

Используя запросы в Bloodhound, мы обнаружили, что аккаунт машины Mark-pc$ является частью группы «Servers Admins».

Рисунок 23: Члены группы Servers Admins

Попробуем воспользоваться аккаунтом машины Mark-pc$, полученным при помощи скрипта Secretsdump, и, используя CrackMapExec проверим, какие у нас будут привилегии на AppServer.

Рисунок 24: Проверка доступа при помощи CrackMapExec

Как видно нас скриншоте выше, мы успешно прошли аутентификацию в AppServer, и теперь при помощи скрипта Impacket Wmiexec передадим хэши аккаунтов машины с целью получения шелла и выполнения команд на AppServer.

Рисунок 25: Запуск скрипта wmiexec на AppServer

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

Рисунок 26: Запуск скрипта secretsdump на AppServer

Теперь добавляем новый SPN в AppServer при помощи скрипта addspn из проекта krbrelayx , который нужен, чтобы наша жертва (в данном случае – контроллер домена) искала этот SPN и перенаправляла трафик на подконтрольный нам сервер.

При помощи машинного аккаунта в AppServer добавляем новый SPN (HOST/attacker1.contoso.local) в AppServer$.

Рисунок 27: Добавление SPN при помощи скрипта addspn

Затем при помощи скрипта dnstool.py (тоже из проекта krbrelayx) в контроллере домена добавляем новую DNS-запись для только что созданного SPN (attacker1.contoso.local), которая будет указывать на нашу машину с Kali Linux.

Рисунок 28: Добавление новой DNS-записи

После обновления DNS запускаем Nslookup вместе с именем attacker1.contoso.local с целью проверки, что резолвинг происходит на IP-адрес нашей машины с Kali Linux.

Рисунок 29: Проверка DNS

Теперь настраиваем сервер на перехват krbtgt TGT при помощи скрипта krbrelayx и AES265-ключа от машины AppServer.

Рисунок 30: Настройка перехвата при помощи скрипта krbrelayx

Затем при помощи скрипта printerbug.py (который можно найти там же в проекте krbrelayx) принуждаем контроллер домена на поиск SPN HOST/Attacker1.contoso.local, который инициирует обратный вызов к нашей рабочей системе с Kali Linux, поскольку ранее мы настроили DNS-записи соответствующим образом. Во время аутентификации мы использовали аккаунт машины AppServer$.

Рисунок 31: Запуск скрипта printerbug.py

По результатам успешной отработки скрипта мы получим перехваченный билет krbtgt TGT на нашем сервере, который впоследствии будет расшифрован при помощи AES256-ключа машинного аккаунта для AppServer$ и сохранен в формате CCACHE.

Рисунок 32: Перехват TGT

Теперь добавляем в файл CCACHE в наши переменные окружения при помощи команды export и при помощи скрипта Impackets-secretsdump выгружаем базу данных контроллера домена.

Рисунок 33: Выгрузка базы данных контроллера домена

Теперь у нас есть все NTLM-хэши для аккаунтов домена contoso, и мы можем воспользоваться утилитой Impacket wmiexec для передачи этих хэшей и получения шелла в домене contoso.

Рисунок 34: Получение шелла

Меры по предотвращению угрозы

Вышеуказанные техники, касательно ретранслирования учетных записей и получения контроля над DNS-сервером, были использованы при стандартной конфигурации, которая есть сразу же после установки Windows. Защита от подобного рода атака – отключение преобразование имен LLMNR и NBT-NS, использование подписи в LDAP и привязка канала для LDAP поверх TLS. Что касается printerbug, старайтесь избегать неограниченного делегирования везде, где возможно, и отключите службу принтеров Spooler или заблокируйте исходящее подключение к порту 445 в критически важных системах.

Ссылки

  • https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constraineddelegation-ove...

  • https://blog.stealthbits.com/resource-based-constrained-delegation-abuse/

  • https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html

  • https://dirkjanm.io/exploiting-CVE-2019-1040-relay-vulnerabilities-for-rce-and-domainadmin/

  • https://chryzsh.github.io/relaying-delegation/

  • https://dirkjanm.io/krbrelayx-unconstrained-delegation-abuse-toolkit/

  • https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/