Pass-the-Hash e Pass-the-Ticket: mecânica e detecção para equipes azuis

O roubo de credenciais continua sendo um dos caminhos mais confiáveis para um invasor se mover por um domínio Windows, e duas técnicas estão no centro disso: Pass-the-Hash (PtH) e Pass-the-Ticket (PtT). Ambas abusam do próprio funcionamento dos protocolos de autenticação, e não de uma única falha corrigível, e é justamente por isso que os defensores precisam entendê-las a fundo. Este artigo adota a abordagem entender para defender: explicamos o que são essas técnicas, como operam em nível conceitual, onde reside o material de credenciais e — acima de tudo — os sinais de detecção concretos e as medidas de fortalecimento que permitem a uma equipe azul flagrar e conter o movimento lateral. Aqui não há receitas de ataque, apenas o conhecimento de que um defensor precisa para construir um monitoramento resiliente e reduzir o raio de impacto de um host comprometido.

O que Pass-the-Hash e Pass-the-Ticket realmente são

Em um ambiente Windows, os usuários raramente redigitam a senha para cada recurso. Em vez disso, o sistema operacional mantém artefatos de autenticação na memória para provar a identidade em nome do usuário. Na autenticação NTLM, esse artefato é um hash equivalente à senha; no Kerberos, é um ticket, seja um Ticket-Granting Ticket (TGT) ou um ticket de serviço. Pass-the-Hash é a reutilização de um hash NTLM roubado para se autenticar como um usuário sem nunca conhecer a senha em texto claro. Pass-the-Ticket é a ideia equivalente para o Kerberos: um ticket roubado ou forjado é apresentado para obter acesso. O ponto estratégico para os defensores é que ambas as técnicas transformam um único endpoint comprometido em uma plataforma de lançamento, porque os artefatos colhidos ali são válidos em outros pontos do domínio.

Como as técnicas funcionam em alto nível

As duas técnicas compartilham uma condição prévia: um atacante que já obteve execução de código privilegiada em um host e consegue ler a memória protegida do processo LSASS, o subsistema do Windows que mantém em cache o material de credenciais para o logon único. Uma vez extraído esse material, o PtH reproduz o hash contra serviços que aceitam NTLM, e o PtT injeta um ticket válido em uma sessão de logon para que os serviços baseados em Kerberos confiem nele. Variantes como Overpass-the-Hash fazem a ponte entre os dois mundos usando um hash NTLM para solicitar um TGT do Kerberos. O fio condutor é que o atacante nunca precisa da senha: o segredo de que precisa é o artefato derivado, e esse artefato foi projetado para ser reproduzível por software legítimo. Por isso a resposta defensiva é em camadas — não se pode simplesmente corrigir um protocolo que se comporta conforme a especificação.

Superfície de ataque: onde reside o material de credenciais

Entender a superfície indica o que proteger. O reservatório principal é a memória do LSASS em qualquer host onde uma conta privilegiada tenha feito logon recentemente de forma interativa, via Área de Trabalho Remota ou por meio de um serviço que armazena credenciais em cache. Reservatórios secundários incluem o banco de dados local SAM, os verificadores de logon de domínio em cache, o banco de dados NTDS.dit nos controladores de domínio e backups ou snapshots de máquinas virtuais que contenham qualquer um deles. Contas altamente privilegiadas — administradores de domínio, contas de serviço com amplos direitos e operadores de backup — são as joias da coroa, pois um único hash ou ticket colhido de uma delas pode abrir todo o diretório. O corolário defensivo é um princípio de higiene de credenciais: nunca deixar uma conta de Nível 0 se autenticar em uma estação de trabalho de menor confiança, porque isso semeia na memória daquela máquina um segredo que domina o domínio.

Sinais de detecção: logs, Event IDs e telemetria

A detecção é onde as equipes azuis vencem. Como essas técnicas reutilizam protocolos legítimos, nenhum evento isolado é uma prova cabal; em vez disso, correlacionam-se vários sinais fracos em um forte. Observe os logs de segurança do Windows em busca do Event ID 4624 (logon bem-sucedido) com Logon Type 3 (rede) ou Type 9 (NewCredentials), sobretudo quando o pacote de autenticação for NTLM em contas que deveriam usar Kerberos. Combine o 4624 com o 4776 (validação de credencial NTLM) e o 4672 (privilégios especiais atribuídos) para flagrar logons de rede privilegiados que não correspondam aos padrões normais. Para abuso de Kerberos, monitore o 4768 (TGT solicitado) e o 4769 (ticket de serviço solicitado); tickets com tipos de criptografia incomuns, tempos de vida incompatíveis ou solicitações para contas que nunca fazem logon interativo merecem escrutínio. Tickets forjados costumam produzir um tempo de vida que excede a política do domínio, uma anomalia forte.

A telemetria de endpoint fecha a lacuna. Um bom EDR sinaliza solicitações de handle suspeitas ao LSASS — o acesso ao processo com direitos como PROCESS_VM_READ a partir de um processo que não é do sistema é um alerta de alto valor — bem como o carregamento de drivers incomuns e a injeção de material de ticket em sessões de logon. O Sysmon acrescenta precisão: Event ID 10 (ProcessAccess) mirando lsass.exe, Event ID 1 (criação de processo) para padrões conhecidos de ferramentas de credenciais e Event ID 3 (conexão de rede) para conexões laterais de estação a estação. O sinal comportamental mais duradouro é o próprio movimento lateral: uma conta que se autentica a partir de uma máquina que nunca usou, em um horário em que nunca trabalha, para hosts que nunca toca. Estabelecer uma linha de base dos caminhos de autenticação normais e alertar sobre desvios detecta PtH e PtT mesmo quando a ferramenta é inédita.

Mitigação e fortalecimento

O controle mais eficaz é a segmentação por níveis de credenciais: dividir contas e sistemas em níveis administrativos (Nível 0 para controladores de domínio e infraestrutura de identidade, Nível 1 para servidores, Nível 2 para estações de trabalho) e proibir que credenciais de nível alto façam logon em níveis inferiores. Só isso já nega ao atacante os artefatos joias da coroa em alvos frágeis. Habilite o Credential Guard, que usa segurança baseada em virtualização para isolar os segredos do LSASS do sistema operacional em execução, encarecendo drasticamente a extração. Implante a proteção do LSASS (RunAsPPL / Protected Process Light) para que o código comum não consiga abrir um handle de leitura ao processo. Use o grupo de segurança Usuários Protegidos para as contas sensíveis, que desativa NTLM, a criptografia Kerberos fraca e o cache de credenciais para seus membros.

Reduza a quantidade de lugares onde os segredos pousam. Aplique o princípio do menor privilégio para que o trabalho diário nunca use uma conta de administrador de domínio; forneça contas de administração separadas e sem e-mail, usadas apenas a partir de estações de trabalho de acesso privilegiado (PAWs) fortalecidas. Configure restrições de logon com Negar logon localmente e Negar logon por meio da Área de Trabalho Remota para manter as contas de Nível 0 longe de máquinas comuns. Rotacione a senha da conta krbtgt de forma programada — duas vezes, com atraso — para invalidar os Golden Tickets forjados. Desative o NTLM onde for possível e audite onde ele ainda é exigido. Segmente a rede para que uma estação comprometida não alcance os pares diretamente e exija assinatura SMB e vinculação de canal LDAP para atenuar o abuso do tipo relay. Por fim, encurte os tempos de vida dos tickets Kerberos dentro da tolerância operacional para que tickets roubados expirem rápido.

Erros comuns que enfraquecem as defesas

Até equipes maduras se sabotam. Um erro frequente é habilitar o Credential Guard nas estações de trabalho, mas deixar um administrador de domínio fazer logon em servidores onde ele não está habilitado, ressemeando segredos colhíveis. Outro é tratar as regras de detecção como algo que se configura e esquece: as linhas de base de autenticação derivam à medida que o parque muda, de modo que uma regra ajustada no ano passado hoje sepulta alertas reais em ruído. As equipes também confiam demais em um único Event ID; como o 4624 e o 4769 disparam o tempo todo, alertar sobre eles sem correlação produz fadiga de alertas e nada mais. Backups são um ponto cego — um backup NTDS.dit desprotegido entrega todos os hashes do domínio. Por fim, esquecer de rotacionar o krbtgt após um incidente deixa intacta a persistência de tickets forjados, mesmo quando se acredita ter expulsado o invasor.

Lista de verificação do defensor

Use isto como lista de trabalho. Identidade: implemente a hierarquização administrativa; coloque as contas sensíveis em Usuários Protegidos; use PAWs para todo trabalho privilegiado; rotacione o krbtgt duas vezes de forma programada e após qualquer suspeita de comprometimento. Fortalecimento de host: habilite o Credential Guard e o RunAsPPL; mantenha a proteção do LSASS verificada, não apenas configurada; restrinja os direitos de logon local e RDP por nível. Detecção: colete e centralize os Event IDs de segurança 4624, 4672, 4768, 4769, 4776; implante o Sysmon com monitoramento de ProcessAccess em lsass.exe; estabeleça linhas de base dos caminhos de autenticação normais e alerte sobre desvios; cace tickets com tempos de vida ou tipos de criptografia anômalos. Contenção: segmente a rede, exija assinatura SMB e vinculação de canal LDAP, desative o NTLM legado e ensaie um runbook de incidente que inclua a rotação do krbtgt e a redefinição de credenciais privilegiadas.

Perguntas frequentes

O Pass-the-Hash ainda é relevante se usamos Kerberos em todo lugar? Sim. Muitos ambientes recorrem ao NTLM em casos de borda — conexões diretas por IP, aplicações antigas ou serviços mal configurados — e qualquer superfície NTLM residual mantém o PtH viável. Além disso, o Pass-the-Ticket mira diretamente o Kerberos, de modo que migrar de protocolo não substitui o isolamento de credenciais nem o monitoramento.

A autenticação multifator interrompe essas técnicas? O MFA é essencial no ponto do logon interativo, mas o PtH e o PtT reutilizam artefatos criados depois de uma autenticação bem-sucedida. Uma vez que o hash ou o ticket existe na memória, o MFA já não está no circuito. Por isso os controles duradouros são o isolamento de artefatos (Credential Guard, proteção do LSASS), a segmentação por níveis e a detecção comportamental, e não apenas a força da autenticação.

Conclusão

Pass-the-Hash e Pass-the-Ticket perduram porque exploram os próprios mecanismos que tornam o logon único conveniente. Não existe um único patch que os elimine; em vez disso, os defensores vencem tornando os artefatos colhidos difíceis de obter, inúteis fora de um escopo estreito e barulhentos quando abusados. Concentre-se na segmentação por níveis de credenciais, em recursos de isolamento de memória como Credential Guard e RunAsPPL, em restrições de logon disciplinadas e em uma detecção correlacionada construída sobre Event IDs do Windows e telemetria de endpoint. Quando essas camadas atuam juntas, uma única estação comprometida continua sendo uma única estação comprometida — e a técnica mais confiável do invasor se torna o seu erro mais visível.