Dicas e Truques de Purple team: Revisitando a Enumeração do Kerberos

Existem diferentes metodologias propostas para definir as etapas de uma avaliação da Red team. Independentemente da metodologia escolhida, a maioria concorda com a importância da fase de reconhecimento e enumeração, nas fases inicial e interna.

Ao realizar a enumeração, somos capazes de validar as informações coletadas ou obter novas informações adicionais ao que temos atualmente. Além disso, estamos interagindo de forma mais ativa com o alvo e, se certas precauções não forem tomadas durante o processo, o alvo poderá detectar nossas intenções e a operação poderá ser interrompida sem alcançar os objetivos propostos.

Entre os diferentes métodos de enumeração existentes, o objetivo deste documento é analisar a enumeração do Kerberos, um processo realizado em ambientes que utilizam os serviços do Active Directory e permite a validação de usuários existentes.

Vamos dar uma olhada no próprio Protocolo Kerberos.

O Kerberos é um protocolo de autenticação de rede que funciona com base no princípio de emissão de tickets, permitindo que cada usuário seja identificado por meio deles.

Alguns dos termos comumente encontrados ao falar sobre o protocolo Kerberos são:

• Client: usuário que realiza autenticação via Kerberos para obter um ticket de autenticação TGT (Ticket Granting Ticket);
• Ticket Granting Ticket (TGT): É um ticket atribuído ao usuário e é usado para autenticação no ambiente do AD (Active Directory) sem a necessidade de usar as credenciais novamente;
• Key Distribution Center (KDC): Em um ambiente Kerberos, o servidor de autenticação é logicamente dividido em três partes: um banco de dados (DB), um Servidor de Autenticação (AS) e um Servidor de Concessão de Tickets (TGS). Essas três partes, por sua vez, existem em um único servidor chamado Centro de Distribuição de Chaves (KDC, Key Distribution Center).
• Authentication Server (AS): O AS realiza a autenticação do cliente desejado. Se a autenticação ocorrer com sucesso, o AS emite ao cliente um ticket TGT. Este ticket assegura aos outros servidores que o cliente está autenticado;
• Ticket Granting Server (TGS): O TGS é um servidor de aplicativos que emite tickets de serviço conforme necessário.

Durante o processo de autenticação, o cliente envia uma solicitação AS-REQ para o KDC com informações do usuário para validação e também solicita a criação de um ticket TGT; essas informações contêm o nome de usuário e o timestamp criptografados usando o hash da senha do usuário; o KDC valida as credenciais e primeiro verifica se o usuário existe no banco de dados e, se existir, começa a descriptografar o timestamp recebido com o hash correspondente ao usuário encontrado.

Se for bem-sucedido (significa que o usuário e a senha são válidos), o KDC começa a gerar o ticket de autenticação TGT e retorna uma resposta AS-REP contendo o ticket TGT criado.

Todo o processo de comunicação ocorre na porta de serviço TCP 88 do KDC, que comumente é um dos Controladores de Domínio em uma organização.

A enumeração do Kerberos aproveita o processo de autenticação do usuário, pois para interagir com a porta de serviço TCP 88, não é necessário ter nenhuma credencial; além disso, o protocolo Kerberos possui uma configuração pré-definida de respostas de erro, o que permite obter informações sobre contas de usuário existentes no sistema.

Tipos interessantes de erros são:

• KDC_ERR_C_PRINCIPAL_UNKNOWN – Usuário não encontrado no banco de dados;
• KDC_ERR_CLIENT_REVOKED – Usuário encontrado, mas bloqueado;
• KDC_ERR_PREAUTH_FAILED – Usuário encontrado, mas senha incorreta;
• KDC_ERR_PREAUTH_REQUIRED – Usuário encontrado, mas solicitação incompleta.

Ao longo dos anos, várias ferramentas têm utilizado respostas de erro para serem capazes de enumerar informações em ambientes Kerberos. Mais comumente, são vistas ferramentas de força bruta sendo usadas para enumeração, pois se aproveitam da mensagem de erro KDC_ERR_PREAUTH_FAILED, indicando que o usuário é válido, mas a senha está incorreta. Um exemplo disso é a ferramenta Rubeus e seu módulo de força bruta, que faz uso dessa mensagem de erro.

Podemos usar o Rubeus da seguinte forma:

.Rubeus.exe brute /password:' ' /users:users.txt /domain:purple /dc:10.194.208.106

Usando um espaço em branco como senha, o Rubeus funciona como uma ferramenta de enumeração, exibindo os usuários válidos encontrados na saída.

Durante uma Operação da Equipe Vermelha, é possível obter listas de usuários vazadas na internet ou planilhas com essas informações em compartilhamentos públicos dentro da rede corporativa. Validar as informações é muito importante para o operador, pois fornece material utilizável durante a avaliação e pode acelerar o processo de comprometimento do ambiente. Mas, como falamos no início, é importante ter cuidado ao realizar uma validação como essa, pois é possível alertar a Equipe Azul sobre as intenções na rede.

No caso de usar o Rubeus, o processo de validação do usuário gera um Evento do Windows conhecido e é principalmente utilizado por ferramentas SIEM para identificar e detectar ameaças. Este evento é o WinEvent 4771.

O WinEvent 4771 é gerado por várias razões, sendo uma delas o uso da senha errada para autenticação, e um aumento considerável desses eventos pode alertar a Equipe Azul sobre as intenções de um Operador da Equipe Vermelha (ou atacante) na rede.

Existem outras ferramentas além do Rubeus que podem realizar essa enumeração e não geram o WinEvent 4771. Um exemplo disso é o nmap (https://nmap.org/) e seu script NSE krb5-enum-users (https://nmap.org/nsedoc/scripts/krb5-enum-users.html), que permite a validação de usuários sem gerar esse evento do Windows.

Podemos usar o nmap da seguinte forma:

nmap -Pn -n -p88 –script krb5-enum-users –script-args krb5-enum-users.realm=’purple.local’,userdb=’valid.txt’ 10.194.208.106

A figura a seguir mostra que a execução não gerou novos eventos do Windows no momento da execução.

Da perspectiva de um Operador da Equipe Vermelha, devemos sempre minimizar o ruído e evitar ser detectados pelo Agente da Equipe Azul. Devemos estar sempre atentos às variações no comportamento dos sistemas: é necessário entender os processos pelos quais os dados passam ao usar uma ferramenta ou outra e sempre nos adaptarmos às necessidades, seja de um Operador da Equipe Vermelha ou de um Agente da Equipe Azul.

Tendo isso em mente, por que uma ferramenta gera logs e a outra não? Como detectamos ameaças quando os logs não são gerados?

Analisamos os pacotes gerados por ambas as ferramentas, verificando os processos realizados, o que nos permitiu identificar as diferenças entre elas.

Quando vemos os dados transmitidos usando o Wireshark, identificamos que o Rubeus gera uma comunicação semelhante à realizada normalmente por qualquer processo legítimo de autenticação via Kerberos, gerando todas as informações relevantes para o protocolo, especialmente os dados no campo PA-DATA.

Por outro lado, quando vemos as informações transmitidas pelo uso do nmap, podemos identificar a ausência do campo PA-DATA, onde os dados PADATA-ENC-TIMESTAMP são enviados, contendo o timestamp criptografado usando o hash da senha do usuário.

As respostas também foram analisadas. No caso das respostas à solicitação feita com o Rubeus, elas não diferem das solicitações de um processo Kerberos normal, recebendo o erro KDC_ERR_PREAUTH_FAILED devido ao uso de uma senha incorreta.

No caso da resposta ao usar o nmap, o campo de erro é diferente, sendo KDC_ERR_PREAUTH_REQUIRED, indicando o campo ausente na solicitação. A resposta indica quais informações estão faltando e quais tipos de criptografia são esperados.

Aprofundando na falta de logs gerados referentes ao Kerberos, identificamos uma postagem da Microsoft sobre Eventos do Kerberos, em https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-kerberos-event-logging. Neste artigo, há informações sobre logs suplementares do protocolo Kerberos, mas as recomendações da Microsoft são para ignorá-los, pois muitas vezes são falsos positivos. Infelizmente, é aqui que encontramos o log correspondente ao erro KDC_ERR_PREAUTH_REQUIRED.

Portanto, da perspectiva de um Operador da Equipe Vermelha, conseguimos mostrar qual das ferramentas fornecerá um uso mais silencioso, no que diz respeito aos logs do protocolo Kerberos, e com base nesta análise, pudemos identificar diferenças entre as ferramentas sendo usadas para o mesmo propósito, considerando a necessidade de reduzir suspeitas durante a operação.

E sobre a perspectiva de um operador Blue Team?

Bem, agora que sabemos o que acontece durante o processo de enumeração e que estamos cientes da recomendação da Microsoft de não gerar os logs necessários para identificar atividades relacionadas à descoberta de usuários, pois isso causa muitos falsos positivos, nesse caso, é necessário adotar uma abordagem diferente para contornar o problema.

Já sabemos o que acontece ao identificar usuários válidos em um processo de enumeração/validação, mas e quando o usuário é inválido? Vamos dar outra olhada nas ferramentas e ver o que acontece nos pacotes de solicitação e resposta do protocolo Kerberos.

Analisamos os pacotes gerados em ambas as ferramentas utilizadas, as solicitações AS-REQ permanecem iguais às anteriores, mas as respostas AS-REP têm uma modificação, especificamente no campo de erro Kerberos. Independentemente da ferramenta usada, os pacotes de resposta são os mesmos e contêm o mesmo erro KDC_ERR_C_PRINCIPAL_UNKNOWN. Esse erro possui um evento vinculado que é gerado pelo sistema, o Evento do Windows da Microsoft 4768.

O WinEvent 4768 possui certas informações que podemos vincular às ferramentas usadas na solicitação, mas essas informações podem ser modificadas ao longo do tempo para tentar se parecer com solicitações de sistemas Windows. Mesmo assim, é bom ficar de olho nelas.

As principais informações são as seguintes:

• eventID: Número do evento, neste caso, 4768;
• ticketEncryptionType: Identificador do tipo de criptografia usado, neste caso, 0xFFFFFFFF, pois indica que a conta não existe e não há criptografia disponível para ela;
• ticketOptions: Múltiplos valores, é importante analisar as ferramentas de forma recorrente para mapear variações na implementação das ferramentas.

Usando as informações anteriores, é possível criar regras eficazes de SIEM para identificar processos de enumeração do Kerberos de forma mais robusta e completa.

Como visto ao longo deste texto, a análise dos processos aos quais os dados são submetidos para gerar informações é de vital importância para saber quando ou não usar determinadas ferramentas, de que maneiras evitar processos de detecção, bem como modificar as detecções e evoluir as regras ao longo do tempo, acompanhando a evolução das ferramentas e abordagens para este fim, independentemente de ser um Agente de Blue team ou um Operador de Red team.