Por Henrique Pina

Vulnerability Management, (ou gerenciamento de vulnerabilidades) consiste na “prática cíclica de identificar, classificar, priorizar, remediar e mitigar vulnerabilidades de software” (Wikipedia). O time de Vulnerability Management da Tempest é responsável por atividades que vão desde responder aos nossos clientes dúvidas quanto ao procedimento de correção de vulnerabilidades, até a realização de troubleshooting no ambiente ao serem aplicadas recomendações de segurança ou procedimentos de correção de vulnerabilidades. Sendo assim, em alguns casos, a equipe também recebe questionamentos acerca procedimentos para mitigar a execução de ataques específicos. Dentre estes ataques, por várias vezes, fomos questionados sobre como realizar o bloqueio do Mimikatz, o que inspirou a produção deste blog post.

Mimikatz é uma ferramenta que foi publicamente disponibilizada pelo pesquisador Benjamin Delpy e, deste então, tornou-se indispensável no arsenal utilizado tanto por pentesters como, também, por atacantes e malwares em cenários reais de comprometimento. O Mimikatz é amplamente conhecido por suas capacidades de extração de credenciais em sistemas operacionais Windows. Entre as opções disponíveis na ferramenta, destacam-se: extração de senhas em texto plano armazenadas na memória; hashes de senhas armazenadas na SAM; senhas armazenadas em navegadores como o Google Chrome e Microsoft Edge; e criação de tickets falsos para autenticação via Kerberos.

É compreensível que esse tipo de solicitação, feita pelos clientes, seja realizada com a intenção de bloquear a execução do Mimikatz e, consequentemente, impedir que atacantes obtenham êxito na extração de credenciais valiosas, levando muitas vezes ao comprometimento total de ambientes Active Directory. Contudo, considerar de forma isolada o bloqueio de execução do Mimikatz como uma medida efetiva para o problema de roubo de credenciais pode gerar uma falsa sensação de segurança. Devido às suas capacidades, todos os grandes fabricantes de antivírus já possuem assinatura (ou deveriam possuir) para o seu bloqueio. Porém, conforme já amplamente divulgado, simples modificações no código do software podem inviabilizar esse bloqueio realizado pelos antivírus. Além disso, o PowerShell possibilita que o Mimikatz seja executado de diversas formas diferentes, aumentando as chances de evasão de detecção.

É importante mencionar que as ações maliciosas que podem ser realizadas com o Mimikatz necessitam de um nível de permissão elevado. Ou seja, para realizar um ataque com o Mimikatz, é necessário que o atacante já possua permissão elevada no sistema operacional. Desta forma, consideramos que as medidas para prevenção de uso do Mimikatz no ambiente não se restringem apenas ao bloqueio do software em si, mas a um conjunto de medidas com a finalidade de evitar que usuários não autorizados obtenham êxito na execução de comandos de forma administrativa em qualquer ativo Windows do ambiente. Muito além do bloqueio de um binário, estas medidas envolvem:

  1. Configuração de parâmetros nos sistemas operacionais;
  2. Mudanças de comportamento interno dos administradores do ambiente;
  3. Ajuste constante dos processos de proteção e monitoramento.

Alertamos que neste blog post, trataremos apenas de parâmetros de configuração dos sistemas operacionais. Além disso, vale salientar, que cada um dos pontos listados a seguir possui procedimentos de configuração específicos, além de diferentes níveis de complexidade para sua devida configuração. Sendo assim importante salientar que mudanças podem, e provavelmente irão, gerar incompatibilidade de comunicação e funcionamento entre computadores e algumas aplicações e sistemas; por isso, é extremamente recomendável que qualquer alteração no ambiente seja testada e homologada antes da sua aplicação no ambiente em produção.

No momento do lançamento do Mimikatz, em 2011, a versão desktop do Windows mais utilizada era o Windows XP. Somente no final de 2011, o Windows 7 ultrapassou o Windows XP, tornando-se a versão mais utilizada até janeiro de 2018, quando perdeu a liderança para o Windows 10. Do Windows XP ao Windows 10, muita coisa mudou. O Windows 10 trouxe inúmeras inovações nos mecanismos de proteção de credenciais valiosas.

Abaixo, listamos alguns parâmetros de configuração disponíveis para dificultar o uso do Mimikatz com sucesso por parte de um atacante:

  • Impedir o uso do protocolo de autenticação WDigest

O WDigest é um protocolo de autenticação do tipo challenge/response. Ele é utilizado em muitos casos na autenticação a serviços Web. Como podemos ver na imagem abaixo, seu protocolo mantém uma cópia em texto-plano da senha na memória, para facilitar no processo de Single Sign-On (SSO):

O processo para desativar o WDigest depende da versão do Windows que está sendo configurada. Isto porque, para as versões Windows 7, Windows 8, Windows Server 2008R2 e Windows Server 2012, primeiro é necessário aplicar o pacote de atualização KB2871997. Este KB adiciona ao sistema operacional diversas funcionalidades relacionadas à proteção de credenciais. Após a aplicação do KB, é recomendado validar se o WDigest está desabilitado no registro, observando a chave de registro abaixo:

Chave de registro: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest\]

Entrada de registro: UseLogonCredential

Tipo da entrada: DWORD

Valor: 0

Apenas após a desativação do WDigest, a senha em texto plano não é mais armazenada na memória do sistema.

As versões mais recentes do Windows (Windows 8.1 e Server 2012 R2 em diante) não necessitam da instalação do patch e configuração da chave de registro; pois, por padrão, o uso do WDigest nestas versões já é desabilitado. Porém, é importante monitorar as modificações na chave de registro, já que a sua modificação manual para o valor ‘1’ irá habilitar novamente o protocolo.

  • Habilitar o modo de proteção do LSASS

O Local Security Authority Subsystem Service — LSASS é o processo do Windows responsável por realizar as validações durante a autenticação local ou remota. A partir do Windows 8.1 / 2012 R2, a proteção do LSASS foi adicionada como uma medida de segurança, visando prevenir que processos não confiáveis sejam capazes de ler sua memória ou injetar código no processo. O pacote KB2871997 adiciona essa funcionalidade às versões 7, 8, 2008R2 e 2012 do Windows.

Por se tratar de uma configuração que pode gerar muitos impactos no funcionamento de aplicações do ambiente, é extremamente recomendável que seja realizado um processo de homologação prévio, utilizando o modo de auditoria para identificar plug-ins e drivers que precisam ser carregados pelo processo lsass.exe.

Para habilitar o modo de auditoria para o processo lsass.exe, deve-se configurar a chave de registro abaixo:

Chave de registro: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe]

Entrada de registro: AuditLevel

Tipo da entrada: DWORD

Valor: 8

Após a configuração do modo de auditoria, deve-se analisar a ocorrência dos eventos 3065 e 3066 dentro do log de eventos ‘Microsoft-Windows-Codeintegrity/Operational’.

Evento 3065: Este evento é registrado quando um processo (geralmente lsass.exe) tentou carregar um driver que não atende aos requisitos de segurança para Shared Sections. Entretanto, como o modo de operação é de auditoria, o carregamento da imagem é realizado sem nenhum bloqueio.

Evento 3066: Este evento é registrado quando um processo (geralmente lsass.exe) tentou carregar um driver que não atende aos requisitos de assinatura de drivers. Entretanto, como o modo de operação é de auditoria, o carregamento da imagem é realizado sem nenhum bloqueio.

Se, após um determinado período de uso dos sistemas no modo de auditoria, nenhum driver essencial para o funcionamento do sistema operacional — e das aplicações utilizadas no ambiente — for registrado nos logs, é provável que habilitar o modo de proteção do lsass.exe não cause nenhum problema ao ambiente. Para habilitar o modo de proteção do lsass.exe, deve-se configurar a chave de registro abaixo:

Chave de registro: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA]

Entrada de registro: RunAsPPL

Tipo da entrada: DWORD

Valor: 1

Assim, após adicionar a proteção ao processo lsass.exe, conforme pode ser observado na imagem a seguir, não será possível utilizar o Mimikatz para obter as informações de credenciais em memória:

  • Habilitar o “Restricted Admin Mode”

A partir do Windows Server 2012 R2, a Microsoft disponibilizou um método de autenticação para sessões RDP, de modo a impedir que as credenciais de administradores locais sejam mantidas em texto-plano pelo processo LSASS do computador remoto que está sendo acessado. Trata-se do Restricted Admin Mode.

Uma sessão RDP é um logon do tipo interativo. Este tipo de logon mantém as credenciais em memória para uso posterior, evitando que a senha seja seguidamente solicitada para os usuários, enquanto os mesmos acessem recursos do ambiente. Autenticações realizadas a partir do console local do computador, área de trabalho remota via RDP, VNC, Citrix e até o RunAs, são métodos de autenticação do tipo interativo.

O Restricted Admin Mode é um novo tipo de logon interativo que, diferentemente do convencional, não envia as credenciais do usuário durante o processo de logon interativo.

No exemplo abaixo, o usuário ‘user1’ está conectado via RDP ao servidor DC02:

Enquanto o usuário está com sessão ativa, é possível obter, através do Mimikatz, acesso ao hash da senha do usuário:

Para forçar os computadores clientes a fazerem uso do Restricted Admin Mode quando estabelecerem conexões RDP com os servidores do ambiente, é possível configurar a seguinte diretiva:

Caminho da diretiva: Computer Configuration → Administrative Templates → System → Credential Delegation

Nome da diretiva: Restrict delegation of credentials to remote servers

Vale também destacar atenção para o parâmetro /RestrictedAdmin. Pois, ao estabelecer uma nova sessão RDP, desta vez utilizando esse parâmetro — /RestrictedAdmin — do cliente mstsc.exe, o resultado obtido com a execução do Mimikatz não é o mesmo, como veremos nas duas imagens seguintes:

Conectando-se ao servidor utilizando o parâmetro ‘RestrictedAdmin’:

Resultado da execução do Mimikatz no servidor onde o ‘user1’ se conectou:

Pode-se verificar que as informações sensíveis relacionadas ao ‘user1’ não aparecem mais. Apesar de ‘user1’ ser o usuário associado ao logon interativo remoto, as credenciais que o Mimikatz extraiu são as da conta de computador DC02$, e não as credenciais do usuário.

É importante saber que existe um trade-off entre expor o hash de senha de uma conta de administrador ou o hash de senha da conta de computador ao qual o usuário administrador está estabelecendo a conexão RDP. Como resultado da exposição do hash de senha da conta de computador, o computador em questão passa a estar suscetível a ataques do tipo pass-the-hash para conexões RDP. Ou seja, um atacante com esse hash em mãos poderá se conectar ao computador via RDP. Acontece que, como já frisamos no início desse blog post, a utilização do Mimikatz para extração de credenciais requer um nível de acesso privilegiado ao sistema; ou seja, o atacante já precisaria estar com acesso privilegiado no servidor para obter esse hash da conta do computador. Hash que, independentemente da existência ou não de uma conexão RDP através do Restricted Admin Mode, estaria disponível para o atacante com acesso privilegiado.

O intuito da funcionalidade é proteger e minimizar a exposição das credenciais de usuários com perfil administrativo. Além disso, permissões, direitos e privilégios normalmente não são concedidos a contas de computador e, sim, a contas de usuários. Entretanto, cada ambiente possui particularidades específicas que irão demandar configurações específicas. Desta forma, é importante que a funcionalidade seja estudada e avaliada internamente, a fim de que seja definida a viabilidade ou não de implementação.

  • Evitar o reuso de senhas de administrador nas estações e servidores do ambiente

É comum, em ambientes corporativos, que os administradores automatizem o processo de deploy de estações de trabalho e servidores, a partir do uso de imagens. O uso de uma única imagem resulta, normalmente, em uma mesma credencial de administrador local para todas as estações de trabalho e/ou servidores do ambiente. Uma vez que um atacante obtenha acesso privilegiado a uma estação ou servidor, e realize a extração dessa credencial local, rapidamente ele pode conseguir acessar um ativo em que um administrador do ambiente esteja com sessão ativa, alcançando, assim, permissões administrativas de domínio.

A Microsoft disponibiliza uma ferramenta que realiza o gerenciamento da credencial de administrador local do sistema operacional, o Local Administrator Password Solution — LAPS. A partir de um client, o LAPS realiza a troca de senha da conta local ‘Administrador’ e armazena em um atributo do objeto ‘conta de computador’, no Active Directory. A permissão de leitura neste atributo poderá ser delegada aos analistas de help desk, administradores do ambiente ou demais usuários e grupos necessários.

  • Utilizar o grupo de segurança “Protected Users”

O grupo Protected Users foi adicionado como um recurso de domínios Windows Server 2012 R2. Contas de usuários que fazem parte desse grupo receberão proteções adicionais, não-modificáveis, que em sua grande parte, são relativas ao não-armazenamento de credenciais em texto-plano. De forma resumida, contas de usuário que fazem parte desse grupo só podem realizar autenticação no domínio e serviços do ambiente através do Kerberos. Adicionalmente, a autenticação via Kerberos passa a restringir o uso de cifras consideradas fracas para os padrões atuais, dando preferência ao uso do AES.

  • Restringir a concessão do privilégio “Debug Privilege”

O direito de usuário “Debug Programs” é um direito muito poderoso pois permite que um usuário utilize um debugger em processos do sistema operacional ou no kernel. Este direito é utilizado pelo Mimikatz para realizar a extração de credenciais do processo LSASS.

A imagem a seguir exibe uma sessão iniciada pelo usuário ‘lambao’. Nela podemos observar os usuários pertencentes ao grupo local ‘Administrador’ da estação de trabalho; bem como, a quais grupos, o usuário ‘lambao’ pertence no domínio.

A partir da imagem acima, também é possível observar que a conta de usuário ‘lambao’ não pertence ao grupo local ‘Administradores’;14 e, no domínio, pertence apenas ao grupo padrão ‘Domain Users’. Ou seja, não é uma credencial com nível de privilégio administrativo.

Na mesma estação, a conta de usuário ‘lambao’ foi atribuída ao direito de usuário ‘Depurar programas’, conforme exibimos na imagem abaixo:

Ao executar o Mimikatz com a credencial ‘lambao’, foi possível acessar as credenciais armazenadas na estação de trabalho, conforme imagem a seguir:

  • Prevenir o armazenamento de credenciais em cache

O armazenamento de credenciais em cache também é um dos métodos verificados pelo Mimikatz para extração de credenciais. Credenciais em cache são normalmente armazenadas no intuito de viabilizar a autenticação dos usuários do domínio, durante o período em que não seja possível a comunicação com os controladores de domínio. Este parâmetro pode ser configurado e seu valor inicial é de 10 credenciais armazenadas.

Para configurar o sistema operacional de modo a não permitir o armazenamento de credenciais de usuários em cache, deve-se seguir a seguinte diretiva:

Caminho da diretiva: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options

Nome da diretiva: Interactive logon: Number of previous logons to cache (in case domain controller is not available)

Ao desativar o armazenamento de credenciais em cache, o Mimikatz não obterá nenhuma entrada.

  • Uso de políticas de restrição de software

O modelo normalmente utilizado para a realização de bloqueios de softwares indesejados, como malwares por exemplo, é baseado em assinaturas. Periodicamente, o software utilizado para efetuar os bloqueios realiza o download de uma base de assinaturas disponibilizada pelo fabricante. A partir dessa base, será tomada a decisão sobre quais aplicações não poderão ser executadas no sistema operacional. Esta abordagem é importante e realiza boa parte do trabalho de detecção e bloqueio de códigos maliciosos. Porém, para o nível das ameaças atualmente encontradas e, principalmente, para casos de ataques direcionados (onde os artefatos maliciosos são especificamente criados para o alvo escolhido) a estratégia não será suficiente para detectar e prevenir a execução de código malicioso no sistema operacional.

Uma forma diferente de abordar o problema é operando no modelo contrário, ou seja, informando ao sistema operacional o que pode ser executado (.EXE, .DLL, .PS1, .BAT, etc.), enquanto que todo o resto terá sua execução imediatamente negada. A partir dessa dinâmica, é possível garantir que um número muito maior de artefatos maliciosos sejam bloqueados.

Algumas soluções de mercado realizam esse tipo de restrição. A Microsoft também disponibiliza ferramentas para realização desse tipo de bloqueio como o AppLocker e, o mais recente, o Windows Defender Application Control.

Conclusão

Estas são algumas, mas não todas, opções de configuração que podem ser realizadas nos sistemas Windows visando dificultar o sucesso na execução do Mimikatz.

Conforme mencionamos no início do post, existem aspectos relacionados ao comportamento dos administradores que precisam ser modificados, evitando algumas situações consideradas como “normais” hoje em dia. Os sistemas de monitoramento também precisam de atenção especial, sendo devidamente municiados com os logs de eventos adequados e configurados com mecanismos de geração de alertas efetivos, para que as medidas de contenção sejam iniciadas o quanto antes, mesmo em eventos onde as medidas técnicas não sejam capazes de bloquear o avanço de um ataque eminente.