eladshamir/internal-monologueInternal Monologue Attack: Recuperando Hashes NTLM sem Tocar no LSASS
Mimikatz, desenvolvido por Benjamin Delpy (@gentilkiwi), é uma ferramenta de pós-exploração bem conceituada, que permite que adversários extraiam senhas em texto claro, hashes NTLM e tickets Kerberos da memória, bem como realizem ataques como pass-the-hash, pass-the-ticket ou construir um golden ticket. Sem dúvida, o uso principal do Mimikatz é recuperar credenciais de usuário da memória do processo LSASS para uso em movimentação lateral pós-exploração.
Recentemente, a Microsoft introduziu o Credential Guard no Windows 10 Enterprise e no Windows Server 2016, que usa segurança baseada em virtualização para isolar segredos, e é muito eficaz em impedir que o Mimikatz recupere hashes diretamente da memória. Além disso, o Mimikatz tornou-se um alvo principal da maioria das soluções de proteção de endpoint, e elas são muito agressivas em seus esforços para detectá-lo e impedi-lo. Embora esses esforços estejam fadados ao fracasso, eles estão se tornando cada vez mais um incômodo.
NetNTLM é o protocolo de desafio-resposta do Windows, usado principalmente onde o Kerberos não é suportado. No NetNTLM, o servidor envia ao cliente um nonce aleatório de 8 bytes como desafio, e o cliente calcula uma resposta que processa o desafio com o hash NTLM como chave, que é o hash MD4 da senha do usuário. Existem duas versões do protocolo de autenticação NetNTLM, e ambas são vulneráveis a certos ataques. Naturalmente, a versão 1 é significativamente mais fraca que a versão 2 e, portanto, a partir do Windows Vista/2008, o NetNTLM versão 1 é desabilitado por padrão.
Como o hash NTLM é a chave para calcular a resposta, um adversário não precisa necessariamente obter a senha em texto claro da vítima para autenticar; portanto, recuperar o hash da memória do LSASS usando o Mimikatz é quase equivalente a roubar uma senha em texto claro. Chris Hummel publicou um artigo descrevendo essa técnica em 2009 e a chamou de "Pass the Hash" [https://www.sans.org/reading-room/whitepapers/testing/crack-pass-hash-33219].
Na Defcon 2012, Moxie Marlinspike e David Hulton apresentaram um ataque "Dividir e Conquistar" contra o NetNTLMv1 [https://www.youtube.com/watch?v=sIidzPntdCM]. No NetNTLMv1, o cliente recebe o desafio de 8 bytes e calcula a resposta criptografando-o três vezes usando DES com diferentes partes do hash NTLM como chave. O comprimento da chave para DES é efetivamente de 56 bits, ou seja, 7 bytes, enquanto o hash NTLM tem 16 bytes. O NetNTLMv1 primeiro criptografa o desafio usando os primeiros 7 bytes do hash NTLM como chave, depois criptografa o desafio usando os próximos 7 bytes do hash NTLM como chave e, finalmente, criptografa o desafio usando os últimos 2 bytes do hash NTLM preenchidos com bytes nulos como chave. Efetivamente, isso significa que, para recuperar o hash NTLM dado um desafio e resposta NetNTLMv1, um adversário deve quebrar duas chaves DES de 56 bits, o que é exponencialmente mais fácil do que quebrar uma única chave de 128 bits. Moxie e Hulton desenvolveram hardware personalizado para essa tarefa e conseguiram forçar bruto todo o espaço de chaves DES em menos de 24 horas, o que garante a recuperação bem-sucedida do hash NTLM em um tempo razoável. Observe que, diferentemente de ataques de dicionário ou força bruta contra a senha, que podem não ser frutíferos, este ataque garante a recuperação bem-sucedida do hash NTLM.
Conforme demonstrado pelo ToorCon em https://crack.sh, é viável criar uma tabela arco-íris completa para todas as respostas possíveis do NetNTLMv1 para um desafio escolhido, como 0x1122334455667788, o que permite quebrar o hash NTLM para uma determinada resposta em minutos. A implicação é que capturar uma resposta NetNTLMv1 para o desafio escolhido pode ser traduzida para o hash NTLM correspondente quase instantaneamente, o que é quase equivalente a obter a senha devido ao Pass the Hash.
O Mimikatz é comumente executado após o adversário obter acesso elevado ao host alvo. Neste ponto, o adversário também pode alterar chaves de registro, como o LMCompatibilityLevel, que especifica se o host deve negociar NetNTLMv1 ou NetNTLMv2. O adversário pode alterar o valor para 0, 1 ou 2, o que habilita o NetNTLMv1 como cliente, e então tentar autenticar em um servidor SMB malicioso que capturará a resposta do cliente, conforme descrito no post do blog da Optiv [https://www.optiv.com/blog/post-exploitation-using-netntlm-downgrade-attacks].
Mais duas configurações podem impedir que a vítima negocie uma resposta NetNTLMv1:
Em ambientes seguros, onde o Mimikatz não deve ser executado, um adversário pode realizar um Ataque Monólogo Interno, no qual invoca uma chamada de procedimento local para o pacote de autenticação NTLM (MSV1_0) a partir de uma aplicação em modo de usuário através do SSPI para calcular uma resposta NetNTLM no contexto do usuário logado, após realizar um rebaixamento NetNTLM estendido.
O fluxo do Ataque Monólogo Interno é descrito abaixo:
Testei recentemente o Monólogo Interno em ambientes com Credential Guard ativado e obtive resultados negativos. Não tenho certeza se o Credential Guard não estava funcionando corretamente no meu ambiente de teste durante os testes iniciais, ou se algo mudou desde então. Atualizei a implementação para adquirir um token de servidor do AcceptSecurityContext dinamicamente e adulterá-lo para evitar a armadilha de autenticação local, de modo que, se o NetNTLMv1 sem Segurança de Sessão Estendida falhar, pelo menos um desafio-resposta NetNTLMv2 possa ser capturado.
O Ataque Monólogo Interno é indiscutivelmente mais furtivo do que executar o Mimikatz, pois não há necessidade de injetar código ou despejar memória de/para um processo protegido. Como a resposta NetNTLMv1 é obtida interagindo com o NTLM SSP localmente, nenhum tráfego de rede é gerado, e o desafio escolhido não é facilmente visível. Nenhum evento de autenticação NTLM bem-sucedido é registrado nos logs. As alterações no registro para o rebaixamento NetNTLM e roubo de tokens/personificação de outros usuários podem acionar indicadores.
Esta ferramenta é uma prova de conceito que implementa o Ataque Monólogo Interno em C#. Portar o código para o PowerShell pode substituir certos logs de eventos na trilha de auditoria por outros. O código PoC está longe de ser perfeito. Contribuições e melhorias positivas são bem-vindas.
Elad Shamir da The Missing Link Security
