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 . Что такое SPNSPN (Service Principal Name; Первичное имя сервиса) представляет собой уникальный идентификатор экземпляра службы. SPN’ы используются во время аутентификации в Kerberos для связи экземпляра службы с аккаунтом авторизации в службе, что позволяет клиентскому приложений запрашивать у службы аутентификацию учетной записи, даже если у клиента нет имени аккаунта. Более подробно эта тема рассматривается в следующих статьях:
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 в критически важных системах. Ссылки
|
|
Проверить безопасность сайта
