Kerberos é o procotolo de autenticação padrão do Windows e um alvo dos hackers.
O que é
Vamos entender kerberos como o esquema responsável pela autenticação segura do Windows. Um comparativo interessante é a ida ao cinema. Não basta apenas ir até o cinema, alguém precisa validar o ticket que você comprou tem casa. O ticket validado mostra sua identificação, qual filme, a sala, horário e poltrona.
Por trás do kerberos temos a conta KRBTGT. É uma conta do AD, utilizada pelo serviço Kerberos Distribution Center e que fica desativada, utilizada apenas para autenticar os tickets Kerberos. Estar desabilitada não significa que não está em uso, no caso KRBTGT opera sob restrições de segurança que impedem seu uso como conta comum.
Como funciona a autenticação
A autenticação baseada em domínio precisa de um “terceiro” para confirmar o acesso. Quando você acessa um servidor qualquer, não é este servidor que autentica, mas o controlador de domínio, através do KDC.
Na primeira autenticação, o usuário envia uma requisição ao KDC com o hash NTLM da sua senha. Confirmando a autenticação, o KDC envia de volta um TGT criptografado (Ticket Granting Ticket), porém ainda não concede acesso.
Ao tentar acessar um servidor qualquer, o TGT do usuário é enviado ao KDC, requisitando o devido acesso.
O KDC descriptografa o ticket e reenvia novo ticket para acessar o servidor.
O servidor recebe o ticket e valida usando o hash da KRBTGT e garante o acesso por um período especificado.
Assim, o TGT usado para acessar o servidor A não pode ser usado para acessar o servidor B.
KRBTGT é mais seguro que o NTLM?
Sim. Na autenticação NTLM o hash do usuário é armazenado na estação, no DC e no servidor acessado. São muitos lugares a disposição para pegar.
Com o KRBTGT, o hash não fica armazenado na memória dos computadores por aí. É preciso acessar o DC diretamente para obter o hash do KRBTGT.
Com o Kerberos, um invasor não vai muito longe, consegue ir apenas aonde o usuário tem acesso. O problema é quando o usuário é privilegiado e tem acesso ao DC, o que permite obter o hash do KRBTGT. Com esse hash é possível forjar tickets para qualquer recurso. Nesse ponto, o domínio não é mais seu.
Como proteger
Trocar com frequência a senha da conta KRBTGT. 180 dias é um número recomendado pelas agências de segurança.
Rastrear usuários com acesso administrativo e de serviço.
Executar auditoria nos tickets gerados, que tem por padrão tempo de vida de 10 horas
Implantar ferramentas de segurança em todos os pontos de acesso
Implantar o credential guard, que monitora o uso das contas e detecta tentativa de dump de hashes.
Implantar a política do privilégio mínimo.
Fico sem acesso se trocar a senha do KRBTGT?
A conta KRBTGT mantém as duas últimas senhas, então, ao trocar uma vez a antiga continua valida para o ticket gerado. Para o próximo ticket a nova senha será usada. O problema ocorre se uma segunda troca ocorrer antes do sincronismo dos DCs. Nesse caso perde-se acesso aos servidores, principalmente aquele baseados em Unix, já que guardam o hash por mais tempo, e essa troca invalida os dois hashes.
Duas trocas simultâneas é a primeira ação diante da possibilidade de vazamento dos dois hashes. O atacante precisa acessar o DC novamente para reiniciar seu trabalho. Essa troca rápida força a reautenticação de praticamente tudo pois invalida hash usado para forjar tickets e força a reautenticação com os novos hashes.
Conclusão
Proteja a conta KRBTGT, pois todo acesso depende desta. Proteja ainda mais todo ponto de acesso, independente se é acessado ou não por alguém com nível administrativo.
