Olá!
Esta é a segunda parte do artigo sobre os recursos da ferramenta de ataque ao protocolo Kerberos, Rubeus. O primeiro pode ser lido aqui . Desta vez, veremos como usar esta ferramenta é possível implementar os seguintes ataques:
- Ultrapassar Hash / Pass The Key (PTK);
- Passe o bilhete;
- Delegação sem restrições;
- Delegação restrita.
Muito já foi escrito sobre por que esses ataques são possíveis, quais mecanismos existem para sua implementação, qual princípio está no coração do Kerberos (por exemplo, colegas do Jet Infosystem publicaram um bom artigo com análise ); portanto, em meu material, vou me concentrar na implementação de ataques com usando o Rubeus.
Além das "ações" para realizar ataques e interação com o Kerberos, o Rubeus tem uma pequena ninharia agradável: com base na senha clara, ele pode calcular o hash NTLM, que às vezes é muito conveniente e útil.
Isso conclui uma pequena digressão lírica, voltemos à parte principal.
O banco de testes para realizar ataques permaneceu inalterado desde a publicação da primeira parte do artigo .
Ultrapassar Hash / Pass The Key (PTK)
—Mas e se a rede tiver a autenticação NTLM ou LM desativada e somente a autenticação Kerberos for usada e você tiver um hash de senha? É aqui que o Overpass-the-hash entra em cena - usando o hash de senha existente de um usuário, o Rubeus pode solicitar um tíquete TGT para esta conta.
Pass-the-hash — . , NTLM LM.
Aqui está um usuário do domínio Barsik decidiu estudar questões de segurança da informação; em algum lugar ele obteve um hash da senha de administrador de domínio do ADadmin, baixou o Rubeus, leu artigos inteligentes e está tentando colocá-lo em prática.
Vemos que ele não possui tickets em cache, nem acesso ao controlador de domínio
DC-16.meow.local
, mas o Barsik lança o Rubeus com uma "ação" asktgt
e argumentos /domain, /user, /rc4, /ptt
para obter um ticket TGT válido com base no hash de senha existente da conta ADadmin, argumento/ptt
fará o upload imediato do ticket recebido para a sessão atual do usuário Barsik.
O ticket é recebido e carregado, o Barsik tenta novamente fazer login no controlador de domínio como Adadmin.
E desta vez ele consegue.
Passe o bilhete (PTT)
Esse ataque é semelhante ao Overpass-the-hash / Pass-the-key, o invasor tenta obter um ticket de usuário do domínio (de preferência com privilégios máximos no domínio) e carregá-lo na sessão atual. Uma das maneiras de obter tickets TGT é despejar tickets localmente na máquina de domínio atual do processo
lsass.exe
(Servidor de autenticação de segurança local). Para fazer isso, você deve ter privilégios de administrador local, ou melhor, NT AUTHORITY / SYSTEM. O Rubeus pode despejar tickets armazenados em lsass com a ação dump, e a ação de triagem mostrará quais tickets estão atualmente armazenados no sistema.
O Rubeus descarrega tickets do
lsass
codificado base64
, enquanto a ferramenta em si tem uma observação sobre como salvar o base64
ticket recebido .kirbi
.
Salve e importe o ticket para a sessão do usuário atual.
Como você pode ver na captura de tela, o ticket do ADadmin foi carregado com sucesso e podemos visualizar o conteúdo da unidade C no controlador de domínio
DC-16.meow.local
em nome do ADadmin.
Delegação sem restrições
Delegação irrestrita é um privilégio de domínio que pode ser concedido a contas de usuário ou computador. Ele permite que uma conta seja autenticada em um serviço na rede como outra conta.
Agora é hora de ajustar um pouco a bancada de testes e ativar a delegação irrestrita: vamos dar o privilégio de delegação irrestrita ao computador BARSCOMP.
Um dos estágios da realização do teste de segurança de domínio do Active Directory é procurar contas com delegação ativada, geralmente o Powerview é usado para esses fins , mas também pode ser feito manualmente, usando o módulo padrão do ActiveDirectory.
Para realizar este ataque, usarei o Bug da impressoraque foi detalhado por Lee Christensen da SpecterOps. Qualquer usuário autenticado pode conectar-se remotamente ao servidor de impressão do controlador de domínio e solicitar a atualização de novos trabalhos de impressão solicitando que ele envie uma notificação de conta com delegação ilimitada. Lee Christensen escreveu o aplicativo SpoolSample , que acessa o serviço de impressão de CD usando o protocolo MS-RPRN.
No computador em que o ataque será realizado (BARSCOMP.meow.local), você precisa iniciar o Rubeus no modo de monitoramento usando a "ação"
monitoring
. Este modo requer privilégios NT ATHORITY / SYSTEM e escuta novos tickets TGT / TGS no processo lsass. Vou definir o argumento /interval:1
(em segundos) para o intervalo de pesquisa lsass para novos tickets, e o argumento/filteruser:DC-16$
Vou definir um filtro para exibir apenas bilhetes DC-16 $.
Rubeus está sendo executado, em paralelo em outra sessão, eu executo o SpoolSample.exe com os argumentos
dc-16.meow.local
(máquina atacada) e barscomp.meow.local
(nosso host "de escuta").
Vamos ver o que o Rubeus "monitorou".
Bilhete TGT capturado para a conta do controlador de domínio. Agora você pode, usando o já conhecido ataque de passagem, importar um ticket e usar o mimikatz para realizar um ataque DCSync para obter o hash NTLM da conta krbtgt (e como você já sabe da primeira parte do artigo, pode usar o hash dessa conta para criar Bilhete de Ouro e aquisição completa do domínio AD).
Observe que o Rubeus entende os tickets na forma de um arquivo .kirbi e em uma string codificada em base64.
Delegação restrita
Se um invasor conseguir comprometer uma conta de usuário ou um computador para o qual a delegação limitada está ativada, ele poderá representar qualquer usuário no domínio e se autenticar no serviço ao qual a delegação é permitida.
Crie um novo usuário de domínio Backup com a senha B @ ckup1234, atribua a ele um SPN para o serviço cifs no controlador de domínio.
Agora você pode definir a capacidade de delegação dos serviços ldap e cifs no controlador de domínio DC-16.meow.local para esta conta.
Contas com delegação limitada permitida também podem ser identificadas usando o Powerview ou o módulo ActiveDirectory.
Conhecendo a senha ou o hash NTLM da conta meow.local \ Backup, você pode usar o Rubeus para solicitar um tíquete TGT para ela.
Agora, usando a "ação" s4u no Rubeus, você pode solicitar o TGS para um usuário autorizado a se autenticar no serviço cifs \ dc-16.meow.local (por exemplo, o administrador de domínio do ADadmin).
Aqui, indico o ticket da conta de backup obtido anteriormente; / impersonateuser - o usuário cujos direitos eu quero obter; / domain - o domínio em que tudo acontece; / msdsspn / asltservice - serviço que requer TGS; / ptt - importa imediatamente o ticket recebido para a sessão atual.
Aqui está o que acontece no Rubeus:
Aqui você pode ver que, com delegação restrita, 2 extensões Kerberos estão ativadas: estas são S4U2self e S4U2proxy.
O S4U2self permite que os participantes do serviço solicitem um TGS especial com o sinalizador FORWARDABLE para si mesmos em nome de um usuário específico. Isso é necessário para que esse ticket possa ser usado posteriormente pela extensão S4U2proxy.
S4U2proxy permite que o chamador use esse ticket especial para solicitar o TGS do usuário para o serviço ao qual a delegação é permitida (neste caso, cifs \ dc-16.meow.local). Você pode ler mais sobre isso aqui e aqui .
No momento, o Rubeus já recebeu o ticket final e o importou para a sessão atual.
Vamos ver se conseguimos ver a unidade C no controlador de domínio com o ticket recebido.
Sim, tudo correu bem.
Isso conclui minha análise dessa ferramenta, em geral gostei, agradável e fácil de usar, com boas funcionalidades. Espero que, depois de ler esses artigos, você os leve para o serviço.
Obrigado por sua atenção, tudo de bom, não fique doente!