Pass-the-Hash no Active Directory: detecção e mitigação

O que é Pass-the-Hash?

Pass-the-Hash é um método de autenticação que usa material de credencial derivado de NTLM roubado em vez da senha em texto claro do usuário. Na prática, o atacante rouba material de autenticação reutilizável de um sistema Windows comprometido e o usa para acessar outro host ou serviço como esse usuário.

Neste artigo, o escopo é deliberadamente restrito: Windows, Active Directory, NTLM e movimento lateral. Não se trata de um artigo genérico sobre roubo de credenciais. O foco é o modelo operacional específico que torna o Pass-the-Hash relevante em ambientes AD corporativos: uma workstation ou servidor comprometido, material de credencial reutilizável presente nesse sistema e um segundo host que ainda aceita autenticação baseada em NTLM.

Essa distinção importa porque o Pass-the-Hash costuma ser confundido com várias técnicas próximas:

Password spraying testa senhas comuns em muitas contas e não exige hashes roubados.
Pass-the-Ticket usa tickets Kerberos roubados, não material derivado de NTLM.
Overpass-the-Hash usa material derivado de NTLM para obter material de autenticação Kerberos e então pivota para acesso baseado em Kerberos.
Kerberoasting solicita service tickets e os quebra offline para recuperar senhas de contas de serviço.

O Pass-the-Hash é um problema próprio: o atacante já possui material de autenticação reutilizável e não precisa conhecer a senha em texto claro para continuar se movendo.

Como o Pass-the-Hash funciona

A MITRE classifica o Pass-the-Hash como T1550.002, uma sub-técnica de Use Alternate Authentication Material. A ideia central é simples: o Windows e fluxos de autenticação relacionados geram e retêm material de autenticação depois que um usuário faz logon, e esse material às vezes pode ser reutilizado se um atacante conseguir roubá-lo.

Em ambientes Windows, o NTLM continua sendo o principal motivo pelo qual o Pass-the-Hash permanece operacionalmente relevante. Se um alvo remoto aceita NTLM, o atacante pode conseguir apresentar material derivado de NTLM roubado e se autenticar sem nunca conhecer a senha em texto claro. É por isso que reduzir o uso de NTLM e reduzir os lugares onde credenciais reutilizáveis pousam são defesas centrais.

Na prática, a origem do material reutilizável costuma ser um destes caminhos:

Memória LSASS em um endpoint ou servidor comprometido, depois que a vítima fez logon
Hives SAM / SECURITY para material de contas locais da máquina
Credenciais de administrador local compartilhadas reutilizadas em vários sistemas
Credential dumping depois que o atacante já obteve privilégios de administrador local ou execução equivalente em um host

A documentação da Microsoft sobre o Credential Guard é útil aqui porque explica o que o recurso realmente protege: segredos de NTLM, Kerberos e Credential Manager são isolados com segurança baseada em virtualização, em vez de permanecerem apenas no espaço normal do processo LSASS. Isso não elimina todo o risco de roubo de credenciais, mas altera de forma relevante a superfície de ataque dos workflows clássicos de PtH.

Pré-requisitos para um ataque Pass-the-Hash bem-sucedido

O Pass-the-Hash normalmente só é bem-sucedido quando várias condições se alinham.

1. O atacante já comprometeu um host Windows

O Pass-the-Hash raramente é o primeiro movimento. Em geral, o atacante começa com phishing, malware, acesso remoto explorado, baixa higiene de administração local ou outro ponto de apoio inicial. O PtH se torna então uma técnica de movimento lateral.

2. Material de credencial reutilizável está presente no sistema comprometido

Este é o requisito central. Se usuários privilegiados fazem logon em sistemas de menor confiança, se administradores usam RDP sem proteções mais fortes, ou se servidores acumulam credenciais administrativas reutilizáveis no LSASS, o atacante tem algo para roubar.

3. O próximo alvo ainda aceita autenticação NTLM

A técnica fica muito mais difícil de usar se o ambiente reduziu sua dependência de NTLM, endureceu os padrões de administração remota ou moveu workflows críticos para longe de caminhos de autenticação reutilizáveis baseados em NTLM.

4. A credencial comprometida ainda tem direitos relevantes em outros lugares

O hash de uma conta de baixo valor roubada é muito menos útil do que o material de um administrador local reutilizado entre endpoints, de uma conta de helpdesk com amplo alcance administrativo, ou de uma conta AD privilegiada que faz logon em servidores membros.

5. A higiene administrativa é fraca o suficiente para permitir encadear hosts

É por isso que o Pass-the-Hash está tão ligado ao movimento lateral, e não apenas ao roubo de credenciais. Se as senhas de administrador local são únicas, se administradores privilegiados usam workstations dedicadas e se credenciais privilegiadas não pousam em sistemas de tier inferior, o atacante perde o caminho que dá valor ao PtH.

A cadeia de ataque

Uma sequência típica de Pass-the-Hash em um ambiente AD se parece com isto.

Etapa 1 - Obter execução de código em um host inicial

O atacante compromete uma workstation ou servidor por phishing, malware, software vulnerável ou um caminho de acesso já existente.

Etapa 2 - Extrair material reutilizável

Assim que obtém os privilégios necessários nesse host, o atacante mira o LSASS ou repositórios locais de credenciais e extrai material reutilizável. A MITRE associa explicitamente ferramentas como Mimikatz ao uso de Pass-the-Hash: seu módulo SEKURLSA::Pth "pode se passar por um usuário, apenas com um hash de senha, para executar comandos arbitrários".

Etapa 3 - Identificar a melhor conta para reutilizar

O atacante não precisa de todas as contas. Ele precisa da conta que consegue alcançar o próximo sistema. Em ambientes reais, isso costuma significar:

uma conta de administrador local reutilizada
uma identidade de helpdesk ou de administração de endpoints
uma conta de administração de servidores que passou por muitos hosts
uma conta AD privilegiada que nunca deveria ter pousado naquele endpoint

Etapa 4 - Autenticar em outro host usando acesso baseado em NTLM

Nesse ponto, o atacante se move lateralmente por meio de protocolos administrativos, criação remota de serviços, acesso administrativo via SMB, WMI, tarefas agendadas ou outros caminhos de gerenciamento do Windows que ainda aceitam o material reutilizado.

Etapa 5 - Repetir até alcançar um tier privilegiado

O perigo do Pass-the-Hash não está em um único salto. O perigo é a cadeia. Uma workstation comprometida leva a outro contexto administrativo, depois a um servidor de gestão, depois a um servidor onde existem credenciais de maior valor e, por fim, ao controle de domínio ou da floresta. É a mesma lógica operacional descrita de forma mais ampla em Caminhos de Ataque no Active Directory até o Domain Admin: cada fronteira fraca de credenciais facilita o próximo salto.

Pass-the-Hash vs. Overpass-the-Hash vs. Pass-the-Ticket

Essas técnicas são relacionadas, mas não são intercambiáveis.

Pass-the-Hash permanece centrado em material de autenticação derivado de NTLM e em caminhos de acesso que aceitam NTLM.

Overpass-the-Hash começa a partir de material derivado de NTLM, mas o usa para obter material de autenticação Kerberos, pivotando efetivamente de segredos derivados de NTLM para acesso baseado em Kerberos.

Pass-the-Ticket dispensa material derivado de NTLM e reutiliza diretamente tickets Kerberos roubados.

Essa distinção importa tanto para detecção quanto para remediação. Quando os defensores colapsam tudo em um único conceito, costumam construir uma estratégia de detecção fraca e aplicar as mitigações erradas ao caminho errado.

Detecção

Não existe um único evento do Windows que diga "isto foi Pass-the-Hash". Uma estratégia de detecção utilizável é uma estratégia de correlação.

A estratégia de detecção do Windows da MITRE para T1550.002 está no caminho certo: ela sinaliza autenticações anômalas de NTLM LogonType 3 que ocorrem sem eventos de logon de domínio correspondentes, correlacionadas com contexto de processo, sessão e rede, em vez de depender de um único indicador isolado.

O que observar

Padrões do 4624

4624 (An account was successfully logged on) é útil quando importa saber onde a sessão apareceu, qual tipo de logon foi usado e qual contexto de conta é inesperado naquele sistema.

Exemplos de alto valor incluem:

um logon de rede que coloca uma identidade administrativa em um host que ela raramente acessa
movimento lateral repetido a partir de uma workstation comprometida para vários pares ou servidores
uma identidade de administrador local reutilizada aparecendo em vários endpoints

4672 no destino

4672 (Special privileges assigned to new logon) ajuda quando um novo logon recebe privilégios especiais no sistema de destino. Não é um detector de PtH por si só, mas ajuda a identificar quais logons remotos realmente importam.

Contexto NTLM quando disponível

Onde sua telemetria captura contexto de autenticação NTLM, isso é valioso porque o PtH depende dos caminhos de acesso que ainda aceitam NTLM. O objetivo não é alertar para todo evento NTLM. O objetivo é identificar atividade administrativa baseada em NTLM inesperada, envolvendo contas, sistemas ou caminhos que normalmente não se combinam.

Movimento privilegiado incomum entre hosts

Os sinais mais fortes costumam vir do comportamento, não de um único event ID:

a mesma identidade administrativa aparecendo em vários hosts em uma janela de tempo curta
contexto de administrador local reutilizado em hosts que deveriam ter senhas de administrador únicas
atividade administrativa que começa a partir de uma workstation que não faz parte do workflow normal de administração

Sinais de EDR para credential dumping e acesso ao LSASS

O Pass-the-Hash normalmente depende primeiro de roubo de credenciais. Se o seu EDR mostra acesso suspeito ao LSASS, comportamento de credential dumping, ou atividade administrativa remota subsequente a partir do mesmo host, essa correlação costuma ser mais valiosa do que uma regra baseada em um único evento.

Exemplo de enquadramento de detecção

Não trate detecções como "4624 significa Pass-the-Hash". Um enquadramento melhor é:

comportamento suspeito de acesso a credenciais no host A
seguido de logon remoto ou atividade administrativa baseada em NTLM no host B
usando um contexto de conta que não corresponde ao sistema de origem habitual nem ao workflow administrativo normal

É nesse nível que os defensores realmente capturam o PtH.

Dependência de monitoramento

Se o seu monitoramento de AD e Windows é fraco, esta técnica será fácil de perder. É por isso que Monitoramento de Segurança do Active Directory: Event IDs que Importam pertence à mesma família de controles da detecção de PtH.

Remediation

A remediação de Pass-the-Hash não é uma única configuração. É uma estratégia para reduzir onde existe material de credencial reutilizável, reduzir onde o NTLM ainda é aceito e reduzir até onde um contexto administrativo roubado pode viajar.

1. Habilitar o Credential Guard onde houver suporte

A Microsoft afirma que o Credential Guard protege hashes de senha NTLM, Ticket Granting Tickets (TGTs) do Kerberos e credenciais armazenadas por aplicativos como credenciais de domínio, isolando-as com segurança baseada em virtualização. Essa é uma das mitigações mais diretas contra os workflows clássicos de roubo de credenciais que viabilizam o PtH.

Antes de planejar um rollout, verifique o que já está ativado. Desde o Windows 11, versão 22H2 e o Windows Server 2025, o Credential Guard vem habilitado por padrão em sistemas ingressados no domínio que atendem aos requisitos de hardware e licenciamento e que não são controladores de domínio. Em muitos ambientes atuais, o trabalho é confirmar que ele continua habilitado, não ativá-lo do zero.

Ressalvas importantes, dos limites de proteção do Credential Guard documentados pela Microsoft:

algumas capacidades de autenticação são bloqueadas, portanto os aplicativos precisam ser testados antes do rollout
contas locais e contas Microsoft não são protegidas. O Credential Guard cobre segredos derivados do domínio, então o material de conta local por trás de um administrador local reutilizado permanece exposto
credenciais fornecidas para autenticação NTLM não são protegidas: a Microsoft afirma que, se um usuário é solicitado a inserir e insere credenciais para autenticação NTLM, essas credenciais ficam vulneráveis a serem lidas da memória do LSASS
os service tickets Kerberos também não são protegidos; apenas o TGT Kerberos é
a Microsoft afirma explicitamente que habilitar o Credential Guard em controladores de domínio não é recomendado — não agrega segurança ali e pode causar problemas de compatibilidade de aplicativos

2. Usar o Remote Credential Guard ou o Restricted Admin para workflows de RDP

A Microsoft documenta duas proteções diferentes para workflows administrativos baseados em RDP, e credita ambas por prevenir Pass-the-Hash. Qual delas usar depende do quanto você confia no host remoto.

O Remote Credential Guard redireciona as solicitações Kerberos de volta para o dispositivo que está se conectando, de modo que nem a credencial nem seus derivados são passados ao host remoto. Ele é adequado para conexões a um host que você considera confiável.

O Restricted Admin é o que a Microsoft recomenda para cenários de suporte de helpdesk, e essa é a parte mais frequentemente invertida. A Microsoft afirma que o Remote Credential Guard não é recomendado para trabalho de helpdesk: se a sessão é aberta para um cliente já comprometido, o atacante pode usar esse canal aberto para criar sessões em nome do usuário e alcançar os recursos do usuário por um período limitado após a desconexão da sessão. Para helpdesk, a Microsoft afirma que as conexões RDP devem ser iniciadas apenas com o parâmetro /RestrictedAdmin.

Ressalvas importantes da documentação da Microsoft:

o Remote Credential Guard só funciona com RDP
o servidor e o cliente devem se autenticar usando Kerberos, e o Remote Credential Guard não permite fallback para NTLM, porque isso exporia credenciais
é suportado apenas para conexões diretas às máquinas de destino, não por meio do Remote Desktop Connection Broker ou do Remote Desktop Gateway
o host remoto precisa estar ingressado em um domínio Active Directory; não pode ser usado para conectar a um dispositivo ingressado no Microsoft Entra ID (um cliente ingressado no Microsoft Entra ainda pode se conectar a um host ingressado no AD)
não suporta autenticação composta (compound authentication), então testes de compatibilidade são importantes
o Restricted Admin tem seu próprio custo: exige associação ao grupo Administrators no host remoto e não oferece single sign-on para outros sistemas

3. Eliminar a reutilização de senhas de administrador local com o Windows LAPS

Senhas de administrador local compartilhadas são uma das formas mais fáceis de escalar o Pass-the-Hash. A Microsoft lista "proteção contra ataques de pass-the-hash e de deslocamento lateral" como o primeiro benefício do Windows LAPS. Implante o Windows LAPS nativo em vez do MSI legado do Microsoft LAPS, que a Microsoft descontinuou a partir do Windows 11 23H2.

Se a mesma senha de administrador local existe em dezenas ou centenas de endpoints, a compromissão de um único host pode se tornar uma campanha ampla de movimento lateral. Windows LAPS Não Implantado: Por Que Senhas de Administrador Local Compartilhadas Ainda Importam deve, portanto, ser tratado como um artigo de exposição direta a PtH, não como um tema de higiene separado.

4. Manter credenciais privilegiadas fora de hosts de menor confiança

A própria orientação da Microsoft sobre o Credential Guard é direta aqui. O Credential Guard não impede que um atacante com malware no PC use os privilégios associados a qualquer credencial, por isso a Microsoft recomenda "usar PCs dedicados para contas de alto valor, como profissionais de TI e usuários com acesso a ativos de alto valor". Esse é um dos controles anti-PtH mais práticos, porque reduz a chance de que material de credencial privilegiado acabe pousando em workstations comuns.

Isso pode assumir várias formas:

workstations administrativas dedicadas
jump hosts administrativos com escopo de função rígido
administração em camadas (tiered administration), em que sistemas de tier inferior não conseguem coletar credenciais de tier superior
identidades administrativas separadas, em vez de uso administrativo no dia a dia

5. Reduzir o uso de NTLM sempre que possível

O Pass-the-Hash continua operacionalmente útil porque o NTLM continua operacionalmente útil. Se caminhos administrativos críticos ainda dependem de NTLM, o atacante tem mais espaço para se mover. Reduzir o uso de NTLM, remover dependências desnecessárias de NTLM e evitar fallback silencioso reduzem a exposição ao PtH.

É também por isso que o PtH e os Ataques de NTLM Relay: Sequestrando a Autenticação no AD pertencem ao mesmo ciclo de revisão. São técnicas diferentes, mas ambas sobrevivem sobre a mesma dívida do mesmo protocolo.

6. Proteger as contas que mais valem a pena roubar

Para identidades altamente privilegiadas, considere controles que tornem o uso de NTLM e o armazenamento de credenciais reutilizáveis menos aceitáveis operacionalmente:

evite fazer logon em sistemas de uso geral com identidades privilegiadas
use o grupo Protected Users onde o ambiente conseguir suportar suas restrições
revise Contas Privilegiadas Obsoletas: Risco Oculto no Active Directory e remova identidades antigas que mantêm alcance desnecessário em muitos sistemas
reforce Segurança de Senhas no Active Directory: Configurações Incorretas que Importam para que uma higiene de senhas fraca não amplifique o dano de um único contexto administrativo roubado

O Protected Users é poderoso, mas não é gratuito. A Microsoft documenta que os membros não podem se autenticar com NTLM, não podem usar criptografia DES ou RC4 na pré-autenticação Kerberos, não podem ser delegados por delegação irrestrita ou restrita, e não podem renovar TGTs Kerberos além de um tempo de vida inicial de quatro horas. No lado do dispositivo, o CredSSP e o Windows Digest deixam de armazenar credenciais em texto claro em cache, o NTLM deixa de armazenar em cache a função unidirecional NT, e o logon offline deixa de funcionar. A Microsoft também alerta contra adicionar membros de Domain Admins ou Enterprise Admins antes de testar, porque é possível bloquear o acesso dessas contas. Isso torna o recurso um controle forte para contas de alto valor, mas não uma mudança plug-and-play para todo ambiente.

Validação após o hardening

Não encerre a remediação de Pass-the-Hash porque uma única configuração foi habilitada. Valide o caminho de ponta a ponta.

confirme que contas privilegiadas não fazem mais logon em sistemas de tier inferior que exponham seu material de credencial
verifique que o Windows LAPS está de fato rotacionando senhas de administrador local únicas nos sistemas dentro do escopo
teste a compatibilidade do Credential Guard em sistemas representativos antes de um rollout amplo, e depois confirme que ele permaneceu habilitado após a implantação
valide que os workflows administrativos de RDP usam Remote Credential Guard ou Restricted Admin onde previsto
revise se os caminhos administrativos restantes ainda dependem de NTLM ou de fallback silencioso
teste se um endpoint comprometido ainda conseguiria alcançar outros endpoints usando um contexto de administrador local reutilizado

O critério de sucesso correto não é "habilitamos um controle". O critério de sucesso correto é "um contexto administrativo roubado não consegue mais mover o atacante pela mesma cadeia".

Como a EtcSec detecta exposição relacionada

A EtcSec não precisa de uma tag de taxonomia falsa para Pass-the-Hash para ser útil aqui. O valor está nas exposições relacionadas que tornam o PtH viável.

As famílias de controle mais relevantes em torno do PtH são:

Juntas, essas verificações mostram se o ambiente ainda tem os ingredientes que permitem que uma credencial Windows roubada se torne uma cadeia de movimento lateral.

Controles relacionados

O Pass-the-Hash raramente é o único problema de identidade no ambiente. Se o objetivo é reduzir o movimento real do atacante, e não apenas melhorar um item de checklist, revise o PtH junto com Windows LAPS Não Implantado: Por Que Senhas de Administrador Local Compartilhadas Ainda Importam, WDigest Habilitado: Por Que Credenciais em Texto Claro Reaparecem no LSASS, Ataques de NTLM Relay: Sequestrando a Autenticação no AD, Contas Privilegiadas Obsoletas: Risco Oculto no Active Directory, Monitoramento de Segurança do Active Directory: Event IDs que Importam e o Guia de Detecção e Prevenção de Kerberoasting: Como Encontrar e Proteger Contas de Serviço Crackeáveis. Esses são os controles vizinhos que decidem se o PtH continua sendo uma técnica prática de operador no seu ambiente AD.