EtcSecBeta
🏢Active DirectoryAttack PathsPasswordMonitoring

Pass-the-Hash: como hashes NTLM roubados ainda permitem movimento lateral

Pass-the-Hash permite que um atacante se autentique com material NTLM roubado sem conhecer a senha em texto claro. Veja como a técnica funciona, como detectá-la e como reduzir a exposição no AD.

ES
EtcSec Security Team
14 min read
Pass-the-Hash: como hashes NTLM roubados ainda permitem movimento lateral

O que é Pass-the-Hash?

Pass-the-Hash é uma técnica de autenticação que reutiliza material de autenticação derivado de NTLM roubado no lugar da senha em texto claro do usuário. Na prática, o atacante rouba material reutilizável de um sistema Windows comprometido e o utiliza para acessar outro host ou serviço como aquele 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 mantém o Pass-the-Hash relevante em ambientes AD corporativos: uma workstation ou servidor comprometido, material de autenticação reutilizável presente nesse sistema e um segundo host que ainda aceita autenticação baseada em NTLM.

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

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

Pass-the-Hash, portanto, é 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 avançando.


Como o Pass-the-Hash funciona

A MITRE classifica Pass-the-Hash como T1550.002, uma sub-técnica de Use Alternate Authentication Material. A ideia central é simples: após um logon, o Windows e alguns fluxos de autenticação mantêm material de autenticação que, em determinadas condições, pode ser reutilizado se um atacante conseguir roubá-lo.

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

Na prática, o material reutilizável costuma vir de um destes caminhos:

  • Memória LSASS em um endpoint ou servidor comprometido, depois que a vítima fez logon
  • Hives SAM / SECURITY para material associado a contas locais da máquina
  • Contas 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 Credential Guard é particularmente útil aqui, porque explica com precisão o que o recurso realmente protege: segredos de NTLM, Kerberos e Credential Manager isolados com virtualização, em vez de permanecerem apenas no espaço normal do LSASS. Isso não elimina todo risco de roubo de credenciais, mas altera de forma relevante a superfície de ataque das cadeias clássicas de PtH.


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

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

1. O atacante já comprometeu um host Windows

Pass-the-Hash raramente é o primeiro movimento. Em geral, o atacante começa com phishing, malware, acesso remoto exposto, baixa higiene de privilégios locais ou outro vetor inicial. O PtH entra em seguida como técnica de movimento lateral.

2. Material de autenticação reutilizável está presente no sistema comprometido

Esse é o requisito central. Se contas privilegiadas fazem logon em sistemas menos confiáveis, se administradores usam RDP sem proteções mais fortes ou se servidores acumulam segredos administrativos reutilizáveis no LSASS, o atacante tem algo para roubar.

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

A técnica se torna muito mais difícil quando o ambiente reduz sua dependência de NTLM, endurece os fluxos de administração remota ou remove caminhos críticos que dependem de autenticação reutilizável baseada em NTLM.

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

Um hash roubado de uma conta de baixo valor tem utilidade limitada. O material realmente perigoso é o de um administrador local reutilizado em vários endpoints, de uma conta helpdesk com grande alcance ou de uma conta AD privilegiada que faz logon em servidores membros.

5. A higiene administrativa é fraca o suficiente para permitir uma cadeia de saltos

É por isso que o Pass-the-Hash está tão ligado a movimento lateral, e não apenas a roubo de credenciais. Se as senhas de administrador local são únicas, se administradores usam workstations dedicadas e se credenciais privilegiadas não pousam em sistemas de tier inferior, o atacante perde o caminho que dá valor operacional 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 em um primeiro host

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 para extrair material reutilizável. A MITRE associa explicitamente ferramentas como Mimikatz ao uso de Pass-the-Hash, incluindo o módulo SEKURLSA::Pth.

Etapa 3 - Identificar a melhor conta para reutilizar

O atacante não precisa de todas as contas. Ele precisa da conta que abre o próximo salto. Em ambientes reais, isso geralmente significa:

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

Etapa 4 - Autenticar em outro host por um caminho que ainda aceita NTLM

A partir daí, o atacante se move lateralmente por meio de protocolos administrativos, criação remota de serviços, acesso SMB administrativo, WMI, tarefas agendadas ou outros caminhos de gerenciamento Windows que ainda aceitam esse material reutilizado.

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

O perigo do Pass-the-Hash não é 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 sistema onde existem credenciais de maior valor e, por fim, ao controle de domínio ou floresta. Essa é a mesma lógica operacional descrita mais amplamente em caminhos de ataque AD: 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 ainda aceitam NTLM.

Overpass-the-Hash começa com material derivado de NTLM, mas o utiliza para obter material de autenticação Kerberos e então pivotar para acesso baseado em Kerberos.

Pass-the-Ticket não usa material derivado de NTLM; 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 controles errados ao caminho errado.


Detecção

Não existe um único evento do Windows que diga “isso foi Pass-the-Hash”. Uma estratégia útil de detecção é uma estratégia de correlação.

A estratégia de detecção da MITRE para T1550.002 aponta na direção certa: é preciso correlacionar atividade anômala de NTLM LogonType 3 com contexto de processo, sessão e rede, em vez de depender de um único indicador isolado.

O que observar

Padrões em torno do 4624

4624 é ú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:

  • 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
  • o mesmo contexto de administrador local aparecendo em vários endpoints

4672 no destino

4672 é útil quando um novo logon recebe privilégios especiais no sistema de destino. Não é um detector de PtH por si só, mas ajuda a distinguir quais logons remotos realmente importam.

Contexto NTLM quando disponível

Se sua telemetria captura contexto de autenticação NTLM, esse dado é valioso porque o PtH depende dos caminhos que ainda aceitam NTLM. O objetivo não é alertar para todo evento NTLM. O objetivo é identificar atividade administrativa baseada em NTLM que seja inesperada para as contas, os sistemas ou os caminhos observados.

Movimento privilegiado incomum entre hosts

Os sinais mais fortes muitas vezes vêm do comportamento, não de um único event ID:

  • a mesma identidade administrativa aparecendo em vários hosts em pouco tempo
  • contexto de administrador local reutilizado em hosts que deveriam ter senhas locais únicas
  • atividade administrativa iniciada a partir de uma workstation fora do fluxo normal de administração

Sinais EDR de credential dumping e acesso ao LSASS

Pass-the-Hash geralmente depende antes de roubo de credenciais. Se o EDR mostra acesso suspeito ao LSASS, comportamento de credential dumping e depois atividade administrativa remota a partir do mesmo host, essa correlação costuma valer mais do que uma regra baseada em um único evento.

Exemplo de framing de detecção

Não enquadre a detecção como “4624 significa Pass-the-Hash”. Um enquadramento melhor é:

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

É nesse nível que PtH realmente é detectado na prática.

Dependência de monitoramento

Se o monitoramento de AD e Windows é fraco, essa técnica será fácil de perder. Por isso o monitoramento de segurança AD faz parte da mesma família de controles da detecção de Pass-the-Hash.


Remediação

A remediação de Pass-the-Hash não é uma única configuração. É uma estratégia para reduzir os lugares onde existem credenciais reutilizáveis, reduzir os caminhos que ainda aceitam NTLM e limitar até onde um contexto administrativo roubado pode viajar.

1. Habilitar Credential Guard onde houver suporte

A Microsoft explica que o Credential Guard protege hashes NTLM, TGTs Kerberos e outros segredos ao isolá-los com virtualização. Esse é um dos controles mais diretos contra cadeias clássicas de roubo de credenciais que tornam o PtH viável.

Ressalvas importantes documentadas pela Microsoft:

  • algumas capacidades de autenticação são bloqueadas, portanto as aplicações precisam ser testadas antes do rollout
  • o Credential Guard não protege contas locais e contas Microsoft exatamente da mesma forma que protege segredos derivados do domínio
  • credenciais fornecidas para autenticação NTLM não ficam totalmente protegidas em todos os cenários
  • a Microsoft afirma explicitamente que não recomenda habilitar Credential Guard em controladores de domínio

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

A Microsoft documenta duas proteções diferentes para fluxos administrativos baseados em RDP.

Remote Credential Guard evita que credenciais sejam enviadas ao dispositivo remoto e é a opção preferida quando o cenário a suporta.

Restricted Admin também continua valioso. A Microsoft o recomenda especialmente para cenários de suporte helpdesk, porque reduz a exposição de credenciais reutilizáveis e recursos do usuário a um host remoto comprometido.

Caveats importantes da documentação da Microsoft:

  • o Remote Credential Guard funciona apenas com RDP
  • exige Kerberos
  • é suportado apenas para conexões diretas ao host de destino, não por RD Gateway ou Connection Broker
  • não pode ser usado quando o host remoto está unido apenas ao Microsoft Entra
  • não cobre todos os cenários de autenticação, então testes de compatibilidade continuam necessários

3. Eliminar o reuso de senhas de administrador local com Windows LAPS

Senhas locais compartilhadas são uma das formas mais simples de tornar o Pass-the-Hash escalável. A Microsoft posiciona explicitamente o Windows LAPS como proteção contra ataques que exploram contas locais para movimento lateral, incluindo progressão no estilo PtH.

Se a mesma senha de administrador local existe em dezenas ou centenas de endpoints, a compromissão de um único sistema pode virar uma campanha ampla de movimento lateral. Windows LAPS não implantado deve, portanto, ser tratado como uma exposição diretamente relacionada a PtH, e não como mero tema de higiene operacional.

4. Evitar que credenciais privilegiadas parem em hosts menos confiáveis

A própria documentação da Microsoft sobre Credential Guard é clara neste ponto: contas de alto valor devem usar PCs dedicados. Esse é um dos controles anti-PtH mais práticos, porque reduz a probabilidade de que material de autenticação privilegiado acabe em workstations generalistas.

Isso pode assumir várias formas:

  • workstations administrativas dedicadas
  • jump hosts administrativos com escopo de função rígido
  • administração em tiers impedindo que sistemas de nível inferior coletem credenciais de níveis superiores
  • identidades administrativas separadas em vez de uso diário privilegiado

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

Pass-the-Hash continua operacionalmente útil porque NTLM continua operacionalmente útil. Se caminhos críticos de administração ainda dependem de NTLM, o atacante mantém mais espaço para se mover. Reduzir NTLM, remover dependências desnecessárias e evitar fallbacks silenciosos reduz diretamente a exposição ao PtH.

Pelo mesmo motivo, PtH e ataques NTLM Relay devem ser avaliados juntos. São técnicas diferentes, mas ambas sobrevivem sobre a mesma dívida de protocolo.

6. Proteger as contas que mais valem a pena roubar

Para identidades altamente privilegiadas, vale considerar controles que tornem o uso de NTLM e o armazenamento de segredos reutilizáveis muito menos aceitáveis do ponto de vista operacional:

  • evitar logon de contas privilegiadas em sistemas de uso geral
  • usar o grupo Protected Users quando o ambiente suportar suas restrições
  • revisar contas obsoletas e superprivilegiadas e remover identidades antigas que mantêm alcance excessivo
  • endurecer a segurança de senhas no Active Directory para que práticas fracas de senha não ampliem o dano de um único contexto administrativo comprometido

Protected Users é poderoso, mas tem custo operacional. A Microsoft documenta que membros desse grupo não podem se autenticar usando NTLM, Digest ou delegação padrão do CredSSP, e que workflows legados podem falhar. Isso faz do grupo um controle forte para contas de alto valor, mas não uma mudança para aplicar sem validação.


Validação após o hardening

Não encerre a remediação de Pass-the-Hash só porque um único controle foi habilitado. É preciso validar o caminho de ponta a ponta.

  • confirmar que contas privilegiadas não fazem mais logon em sistemas de tier inferior que exponham seu material de autenticação
  • verificar que o Windows LAPS realmente rotaciona senhas únicas de administrador local nos sistemas dentro do escopo
  • testar compatibilidade do Credential Guard em sistemas representativos antes do rollout amplo e depois confirmar que ele permaneceu habilitado
  • validar que workflows administrativos via RDP usam Remote Credential Guard ou Restricted Admin onde previsto
  • revisar se os caminhos administrativos restantes ainda dependem de NTLM ou de fallbacks silenciosos
  • testar se um endpoint comprometido ainda pode alcançar outros sistemas usando um contexto de administrador local reutilizado

O critério correto de sucesso não é “habilitamos um controle”. O critério correto é: “um único contexto administrativo roubado não permite mais ao atacante percorrer a mesma cadeia”.


Como a EtcSec detecta exposição relacionada

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

As famílias de controle mais relevantes ao redor de PtH são:

Em conjunto, esses controles mostram se o ambiente ainda possui os ingredientes que permitem transformar uma credencial Windows roubada em uma cadeia de movimento lateral.


Controles relacionados

Pass-the-Hash raramente é o único problema de identidade no ambiente. Se o objetivo é reduzir movimento real de atacante e não apenas melhorar um item de checklist, convém revisar o PtH junto com Windows LAPS não implantado, WDigest habilitado, os ataques NTLM Relay, as contas obsoletas e superprivilegiadas, o monitoramento de segurança AD e o Kerberoasting. São esses controles vizinhos que determinam se o Pass-the-Hash continua sendo uma técnica praticável no seu ambiente AD.


Fontes primárias

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