Сегодня расскажем ещё одну поучительную историю из
практики наших пентестов.
Однажды на проекте мы сами себе создали задачу: у нас было RCE от SYSTEM на контроллере домена, но мы не хотели создавать новые учетные записи или добавлять существующие в администраторы домена. А получить привилегии админа было нужно. Мы придумали несколько решений, и хотя не все они сработали, это был интересный опыт.
Условия задачи:
— Есть исполнение на доменном хосте от SYSTEM и NT-хеш пароля этого хоста.
— Есть привилегии администратора домена в корневом домене в другом лесу AD (двухстороние трасты).
— Есть RCE на контроллере домена (
уязвимость в Veritas Backup Exec Agent). Не очень удобно исполнять команды (нет вывода), но можно читать и записывать файлы, запись через экплойт очень медленная.
— Есть возможность подключения по SSH на linux-хост (без root-а).
— Настрой на то, что чем меньше изменений и чем меньше придется чистить затем заказчику, тем лучше.
Варианты решения:1. Запустить агента Mythic— c SYSVOL на контроллере домена в другом лесу. Результат: ошибка Access Denied.
— загрузить файл с
агентом Mythic через эксплойт. Результат: запустить удалось, но правила файрвола не позволили установить ни bind, ни реверс-соединение.
2. Получить сертификат— выгрузить сертификат с приватным ключом из хранилища (командлеты
Get-ChildItem -Path Cert:\CurrentUser\My\ для получения списка и
Export-PfxCertificate для экспорта). Результат: не было сертификатов, для которых разрешен экспорт приватного ключа.
— запросить новый сертификат. Результат: проанализировали шаблоны сертификатов и не нашли такого, чтобы контроллер мог запросить сертификат, использовать его для аутентификации и с возможностью экспорта приватного ключа.
3. Unconstrained delegationТак как уже были привилегии админа домена в другом лесу, а для контроллеров домена настроено неограниченное делегирование, можно было бы попробовать. Но в
trustAttributes не было флага, разрешающего делегирование. Так что даже не пробовали.
4. Прочитать пароль LAPSНекоторые учетные записи компьютеров имели много привилегий (например, Exchange-сервера или центр сертификации) и получение привилегий админов на этих хостах могло бы помочь продвинуться дальше. Но модули с командлетами
Get-LapsADPassword и
Get-AdmPwdPassword не были установлены.
5. РелеиЭто была скоре абстрактная идея. Linux-хостов с root-ом не было, и
освобождать 445 порт на доменном хосте не хотелось. А служба WebClient для коерса на другой порт на контроллере не была установлена. Кроме того, на LDAP требовалась подпись, а шаблонов сертификатов, подходящих для
ESC8, не было.
6. Сохранить учетные данные из реестраС помощью
reg save или
Silent Harvester можно было получить учетные данные из реестра. Получили бы NT-хеш контроллера домена и могли бы сделать DCSync. Но пришлось бы сохранять файлы в SYSVOL, чтобы получить к ним доступ с имеющейся учеткой.
7. Resource-based Constrained DelegationТак как у нас была скомпрометированная учетная запись хоста (её NT-хеш), удалось провести атаку на ограниченное делегирование на основе ресурсов. Модифицировать
msDS-AllowedToActOnBehalfOfOtherIdentity учетной записи контроллера:
Set-ADComputer -Identity DC_Name -Properties PrincipalsAllowedToDelegateToAccount owned$
И затем сгенерировать TGS с имперсонацией учетной записи администратора домена или другого контроллера домена. Результат: успех.
8. Rubeus и т.п.Можно было бы загрузить на контроллер
Rubeus или другие утилиты для дампа Kerberos-билетов, но после проверки идеи (1) мы поняли, что загрузить файл будет непросто.
Мораль:
Даже очень простая (на первый взгляд) задача "от RCE на контроллере до администратора домена" может иметь множество решений, если не пойти по первому пришедшему на ум пути.