Descobrindo a senha do Windows (Live-System)

Descobrindo a senha do Windows (Live-System)

DISCLAIMER

Primeiramente, é importante destacar que o conteúdo deste artigo é para fins educativos. Sua reprodução em ambiente produtivo pode trazer riscos de segurança.

INTRODUÇÃO

Apesar de ser uma ferramenta antiga, ainda há muitos sistemas operacionais Microsoft Windows em produção que estão sujeito a esta Vulnerabilidade. Eu particularmente consegui simular em:

  • Windows 7;
  • Windows 2008;
  • Windows 2012;
  • Windows 10 (Até Versão: 18362)

Muitos antí-virus acusam ele como malware. Windows Defender acusa ele “sem pestanhar os olhos”, mas permite colocar como confíavel.

O bacana que é possível fazer a mesma análise como POST-MORTEM ou LIVE-SYSTEM. No caso do POST-MORTEM que será abordado no futuro, é possível por exemplo análisar o hiberfile.sys e dumps de aplicativos e até mesmo memória RAM. O Volatility, inclusive tem uma opção não explorada de forma común a conversão para formato DMP para análise com o Windows Debug Tools, de qualquer jeito, isso é assunto para outra postagem.

ATENÇÃO
Esta vulnerabilidade foi corrigida no patch: KB2871997 apesar de ser de 2014, muitas empresas mantem seu parque desatualizado. E mesmo com patch, é possível elevar o privilegio sem saber a senha.

MIMIKATZ

Fonte: http://blog.gentilkiwi.com/ (em frânces)

No Windows, a técnica “Pass-the-Hash” consiste em autenticar em um servidor usando o hash da senha de um usuário, em vez da própria senha.

O BÁSICO

Basicamente, a autenticação de um usuário consiste em lançar um desáfio, normalmente, perguntando a senha. Ao digitar a senha o servidor calcula o hash da senha, se for a mesma já armazenada ele autentica o usuário.

As senhas estão nos controladores de domínio de um domínio, caso contrário, eles devem estar  na SAM local de cada servidor.

SENHAS

Ao contrário do que se poderia imaginar o Windows não usa a senha do usuário como senha compartilhada, e sim hashs não reversíveis.

Dependendo do protocolo usado, o segredo e os algoritmos usados são diferentes:

PROTOCOLOALGORITIMOSEGREDO
LMDES-ECBHash LM
NTLMv1DES-ECBHash NT
NTLMv2HMAC-MD5Hash NT

No caso do protocolo NTLM, o hash NT derivado da senha do usuário é suficiente para atender ao desafio de autenticação.

Overpass-the-hash (passe a chave)
A autenticação via Kerberos é um pouco diferente. O cliente criptografa um registro de data e hora de seu segredo do usuário, possivelmente com parâmetros de região e um número de iteração enviado do servidor.

Se a senha estiver certa, o servidor poderá descriptografar o registro de data e hora (e, no processo, verificar se os relógios não estão muito atrasados).

Protocolo de segredo usado:

PROTOCOLOSEGREDO (CHAVE)

KERBEROS
DES
RC4 = Hash NT!
AES128
AES256

Como comentado na introdução, os sistema testado, a chave tipo RC4 é disponível desde o XP ao 8.1 e continua sendo nosso hash NT!

VAMOS COLOCAR MÃO NA MASSA...

Primeiramente, compile ou baixe a versão compilada em: https://github.com/gentilkiwi/mimikatz

Para exemplificação utilizarei a versão “2.2.0 20200519” já previamente marcado como confíavel pelo antivírus.

IMPORTANTE: Estou omitindo propositalmente concéitos básicos como elevação de privilégio, modo debug, etc. como também os dados sensíveis serão sanitizados.

Para lista de comandos disponíveis, consulta tópico “COMANDOS MIMIKATZ”

As chaves listas abaixo estão na memória do Kerberos, ou seja, as senhas do usuários estão presentes.

Se entender um pouco de como funciona a autenticação Kerberos (poderá ler aqui: https://www.ietf.org/rfc/rfc4120.txt) saberá que todas as chaves devem desaparecer após a obtenção de um TGT e que um TGT já é auto-suficiente para se renovar ao longo da sua vida útil.

Dessa forma, eu posso injetar no provedor msv1_0 e no Kerberos, para responder ao desafio de autenticação NTLM e obter um Kerberos TGT. Veja na imagem abaixo, que após injetar e aceitar a autenticação NTLM (marcado no box azul) a execução do CMD foi bem sucedida.

O mesmo feito com Hash NT, podemos fazer com AES256 marcado com o box azul na imagem abaixo:

Os exemplos citados acima foram de escalonamento de privilegio, ou seja, executar um aplicativo usando a tecnica “Pass-the-Hash”, já que no computador de laboratório possui o FIX instalado.

Em maquinas que não possui o fix instalado, podemos obter informações tanto do SAM como de um DC em texto puro, a exemplo:

COMANDOS MIMIKATZ

Relação de comandos disponíveis para uso no MIMIKATZ (em ingles):

  • CRYPTO::Certificates – list/export certificates
  • KERBEROS::Golden – create golden/silver/trust tickets
  • KERBEROS::List – List all user tickets (TGT and TGS) in user memory. No special privileges required since it only displays the current user’s tickets.Similar to functionality of “klist”.
  • KERBEROS::PTT – pass the ticket. Typically used to inject a stolen or forged Kerberos ticket (golden/silver/trust).
  • LSADUMP::DCSync – ask a DC to synchronize an object (get password data for account). No need to run code on DC.
  • LSADUMP::LSA – Ask LSA Server to retrieve SAM/AD enterprise (normal, patch on the fly or inject). Use to dump all Active Directory domain credentials from a Domain Controller or lsass.dmp dump file. Also used to get specific account credential such as krbtgt with the parameter /name: “/name:krbtgt”
  • LSADUMP::SAM – get the SysKey to decrypt SAM entries (from registry or hive). The SAM option connects to the local Security Account Manager (SAM) database and dumps credentials for local accounts. This is used to dump all local credentials on a Windows computer.
  • LSADUMP::Trust – Ask LSA Server to retrieve Trust Auth Information (normal or patch on the fly). Dumps trust keys (passwords) for all associated trusts (domain/forest).
  • MISC::AddSid – Add to SIDHistory to user account. The first value is the target account and the second value is the account/group name(s) (or SID). Moved to SID:modify as of May 6th, 2016.
  • MISC::MemSSP – Inject a malicious Windows SSP to log locally authenticated credentials.
  • MISC::Skeleton – Inject Skeleton Key into LSASS process on Domain Controller. This enables all user authentication to the Skeleton Key patched DC to use a “master password” (aka Skeleton Keys) as well as their usual password.
  • PRIVILEGE::Debug – get debug rights (this or Local System rights is required for many Mimikatz commands).
  • SEKURLSA::Ekeys – list Kerberos encryption keys
  • SEKURLSA::Kerberos – List Kerberos credentials for all authenticated users (including services and computer account)
  • SEKURLSA::Krbtgt – get Domain Kerberos service account (KRBTGT)password data
  • SEKURLSA::LogonPasswords – lists all available provider credentials. This usually shows recently logged on user and computer credentials.
  • SEKURLSA::Pth – Pass- theHash and Over-Pass-the-Hash
  • SEKURLSA::Tickets – Lists all available Kerberos tickets for all recently authenticated users, including services running under the context of a user account and the local computer’s AD computer account. Unlike kerberos::list, sekurlsa uses memory reading and is not subject to key export restrictions. sekurlsa can access tickets of others sessions (users).
  • TOKEN::List – list all tokens of the system
  • TOKEN::Elevate – impersonate a token. Used to elevate permissions to SYSTEM (default) or find a domain admin token on the box
  • TOKEN::Elevate /domainadmin – impersonate a token with Domain Admin credentials.

COMO SE PROTEGER

A proteção pode ser feita de duas formas,

A primeira, a básica, é manter seu sistema operacional atualizado. 

A segunda, é fazer um workaround, incluindo o seguinte registro:

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 0

MIMIKATZ POST-MORTEM

Como mencionado, é possível fazer a extração de senhas ou até mesmo obter credenciais em uma maquina em modo POST-MORTEM mas esse assunto é para outra oportunidade.

About The Author

Related posts

Leave a Reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *