Em outubro de 2023, a Microsoft fez um anúncio fundamental que sinalizou o início do fim para NTLM, incluindo todas as suas versões. Esta decisão, reiterada em junho de 2024, ressalta o compromisso da Microsoft em fazer a transição dos desenvolvedores para protocolos mais seguros, como Kerberos através do mecanismo de negociação. Com o processo de descontinuação previsto para começar no início de 2025 e ser concluído em 2027, o reinado de longa data do NTLM está terminando.
Apesar do seu significado histórico, o NTLM representa agora uma responsabilidade de segurança considerável. Este blog explora os pontos fracos críticos inerentes ao NTLM, as razões por trás de seu uso prolongado e a transição imperativa para um sistema mais seguro. autenticação protocolos. Compreender estes elementos é essencial para que as organizações protejam os seus sistemas e dados num cenário digital em evolução.
Anúncio da Microsoft
Microsoft anunciou em outubro de 2023 sua intenção de descontinuar todas as versões do NTLM, incluindo LANMAN, NTLMv1 e NTLMv2. Esta decisão foi reafirmada em junho de 2024, enfatizando que o NTLM não está mais em desenvolvimento ativo e instando os desenvolvedores a fazerem a transição para protocolos mais seguros como o Kerberos por meio do mecanismo de negociação.
O processo de descontinuação está definido para começar no início de 2025, com reduções graduais no apoio ao longo do ano. Em meados de 2026, o NTLM não estará mais disponível em novas instalações de sistemas operacionais da Microsoft (no entanto, a possibilidade de habilitá-lo em algumas configurações avançadas não foi verificada). Espera-se que a descontinuação total, incluindo a remoção do suporte legado, seja concluída até o final de 2027.
NTLM é um risco de segurança
Hoje, o NTLM apresenta riscos de segurança significativos devido a métodos criptográficos desatualizados e fraquezas bem documentadas. Além disso, o NTLM carece de recursos de segurança modernos, como Autenticação multifatorial (MFA) e validação de identidade do servidor. Devido a essas fraquezas, os invasores podem explorar o NTLM e obter acesso não autorizado a recursos confidenciais, como bancos de dados e aplicativos internos, tornando-o um grande risco.
Uma versão mais antiga do NTLM usava um segredo compartilhado (senha) para autenticação em um canal não criptografado. Para um novo usuário, não existe protocolo de inicialização; é tão simples como “faça login do usuário X com senha Y”.
Isso significa que o protocolo troca todas as informações necessárias para que um invasor possa quebrar a senha com um ataque de força bruta nas próprias mensagens.
Para melhorar as deficiências do NTLM, a salga foi incorporada ao mecanismo de desafio-resposta do NTLMv2. Como resultado, o NTLMv2 pode ser visto como “parcialmente salgado” ou “não aprimorado”, melhorando a segurança durante a autenticação, mas não abordando totalmente a segurança do armazenamento de hashes de senha ou a capacidade de reutilização de hashes, como em ataques de retransmissão. No geral, o NTLMv2 não oferece proteção contra ataques de retransmissão devido à sua capacidade de reutilizar senhas com hash.
A prevalência do NTLM: a última resistência de um legado
Apesar de suas muitas vulnerabilidades conhecidas, o NTLM manteve sua posição como um velho guerreiro que se recusa a se aposentar. A persistência NTLM não é aleatória. No final da década de 1990 e início da década de 2000, nasceu uma onda de aplicações legadas. Esses aplicativos eram frequentemente adaptados para atender às necessidades exclusivas de suas organizações. No entanto, com o passar do tempo, muitos desses aplicativos foram abandonados por seus criadores. Eles ficaram sem atualizações ou suporte, mas permaneceram essenciais para inúmeras empresas.
O NTLM, com seu mecanismo de autenticação simples, mas robusto, tornou-se a tábua de salvação para esses sistemas legados. Ele forneceu a compatibilidade necessária para funcionar em um mundo moderno que há muito migrou para protocolos mais novos e mais seguros, como o Kerberos.
Para muitas organizações, substituir esses sistemas críticos era algo assustador. A migração para protocolos de autenticação modernos não foi apenas um desafio técnico, mas também um empreendimento dispendioso e complexo. Isso exigiu um amplo retrabalho da infraestrutura e do código do aplicativo. À medida que o cenário empresarial evoluiu, também evoluiu a sua infraestrutura de TI.
Novos sistemas foram introduzidos e com eles surgiu a necessidade de manter relações de confiança num ambiente multidomínio. O NTLM, apesar da sua antiguidade, revelou-se uma ponte fiável, garantindo continuidade operacional e comodidade administrativa. Atualizações graduais tornaram-se a norma e O NTLM era frequentemente mantido como um substituto – uma rede de segurança para quando novos protocolos tropeçassem.
No entanto, os analistas de segurança sabiam que as fraquezas do NTLM faziam dele um alvo preferencial para os atacantes. Isso ocorreu porque ataques pass-the-hash, ataques de retransmissão e tentativas de força bruta são muito familiares no NTLM. Esta confiança no NTLM é uma história de sobrevivência num mundo digital em rápida mudança, uma dança delicada entre inovação e legado.
No entanto, vale ressaltar que NTLM não é estritamente um protocolo para autenticação, mas sim um modelo conceitual para projetar mecanismos de autenticação. A sua versatilidade permite a integração com vários protocolos complementares, como SMB ou CIFS para partilha de ficheiros e RPC para acesso RDP, tornando-o num modelo robusto e adaptável para autenticação.
Por que o NTLM ainda reina: compatibilidade herdada, necessidades operacionais e considerações de segurança
Existem altos custos e complexidades associados à atualização ou reescrita de sistemas legados, que são responsáveis pela persistência do NTLM. Além disso, o NTLM continua a ser usado apesar da disponibilidade de protocolos de autenticação mais modernos devido à natureza gradual das atualizações de infraestrutura e à dependência de sistemas não Windows e de terceiros.
A seguir está uma lista de alguns dos elementos principais:
Compatibilidade e sistemas legados:
- Sistemas e aplicativos legados foram projetados para funcionar com NTLM.
- Reescrever ou atualizar esses sistemas pode ser caro e complexo.
- Alguns sistemas e aplicativos não Windows ainda dependem do NTLM.
- As organizações frequentemente atualizam sua infraestrutura de TI de forma incremental.
Controles de segurança e suporte do fornecedor:
- Certos fornecedores terceirizados podem oferecer suporte apenas a NTLM.
- As organizações aprimoram o NTLM com controles de segurança como MFA e monitoramento.
- NTLM é usado em casos específicos, como acesso remoto.
- A manutenção da continuidade operacional muitas vezes prevalece sobre a adoção de novas tecnologias.
Noções básicas sobre desafios de sincronização de senha e riscos de SaaS
No lado do servidor, os hashes de senha são armazenados com segurança no arquivo NTDS.dit em cada controlador de domínio (DC). No entanto, esses hashes são suscetíveis a ataques DCSync, uma técnica sofisticada em que software malicioso se disfarça como um DC legítimo.
Ao explorar essa técnica, os invasores podem enganar o controlador de domínio para que sincronize seu banco de dados de hashes de senha com software nocivo, como o Mimikatz.
Isso permite que o invasor colete um conjunto completo de hashes de credenciais do controlador de domínio, que pode então ser usado para controle de domínio.
O comando lsadump é usado para extrair informações confidenciais, como senhas e hashes, dos segredos da Autoridade de Segurança Local (LSA).
Isto é particularmente perigoso para ambientes SaaS sincronizados com ambientes locais Active Directory (AD) por meio de provedores de identidade (IdPs) em nuvem, como azuread. Hashes roubados podem ser usados para autenticar aplicativos SaaS sem quebrar senhas, aproveitando a integração AD sincronizada. Isso concede acesso não autorizado a dados e serviços comerciais críticos na nuvem.
Os invasores podem se mover lateralmente no ambiente de nuvem, comprometendo contas adicionais e acessando informações confidenciais. Se forem obtidas credenciais administrativas, elas podem acionar a criação de backdoor, alterar as configurações de segurança e manter o acesso persistente. Isto realça a necessidade de AMF, de monitorização contínua e de adesão ao princípio da Ultimo privilégio.
Expondo vulnerabilidades NTLM: acesso inicial, movimento lateral e exposição a ameaças
Esta seção investiga as fases críticas de exposição, incluindo como os invasores muitas vezes aproveitam os pontos fracos do NTLM durante o acesso inicial e os estágios pós-exploração, permitindo-lhes estabelecer uma posição segura, escalar privilégios e mover-se lateralmente, ampliando assim o potencial de comprometimento generalizado da rede.
Acesso inicial: Os invasores geralmente obtêm acesso inicial por meio de métodos como phishing ou exploração de vulnerabilidades de software. Uma vez lá dentro, eles exploram as vulnerabilidades do NTLM para estabelecer uma posição segura na rede.
Exposição Pós-Exploração: As vulnerabilidades NTLM pós-exploração permitem que os invasores mantenham e expandam seu acesso. Isto poderia envolver uma escalada adicional de privilégios e movimentação lateral dentro da rede, aumentando os danos.
Acesso malicioso: movimento lateral
Movimento lateral: Com o NTLM, você pode reutilizar ou reproduzir o hash em outras máquinas mais privilegiadas até obter o domínio do domínio. Pronto para uso (hacker), Kali Linux, integrado com Metasploit exploits, podem ser usados para conseguir isso.
Por exemplo, no Violação de dados alvo de 2013, os invasores usaram credenciais roubadas para se moverem lateralmente na rede, acessando sistemas confidenciais e dados de clientes. Esta violação expôs milhões de registos de cartões de crédito e informações pessoais, destacando os perigos dos ataques pass-the-hash. Os invasores usaram hashes NTLM capturados para autenticar e mover-se pelos sistemas da rede, evitando a detecção e acessando recursos confidenciais. Outro exemplo é o famoso Ataque de ransomware WannaCry.
Os invasores usaram uma vulnerabilidade conhecida no protocolo SMB para espalhar o malware. Isso incluiu a exploração dos pontos fracos da autenticação NTLM para mover-se lateralmente pelas redes afetadas. Isto permitiu-lhes propagar rapidamente o ransomware, causando perturbações generalizadas.
Revelada a exposição a ameaças NTLM
A próxima seção investiga a exposição às ameaças representadas pelo NTLM, destacando como os invasores podem explorar hashes armazenados e transmitidos, levando a violações de segurança significativas nas redes.
Hashes NTLM armazenados na memória
As vulnerabilidades do NTLM são particularmente evidentes na forma como ele lida e transmite hashes, tornando-o um alvo principal para invasores que buscam comprometer a segurança da rede por meio de extração de memória, interceptação de rede e ataques de passagem de hash.
Os hashes NTLM são armazenados na memória das máquinas autenticadas. Os invasores podem usar ferramentas como o Mimikatz para extrair esses hashes da memória da máquina, permitindo-lhes se passar por usuários sem precisar de suas senhas reais. Depois que os invasores extraírem os hashes NTLM, eles poderão realizar um ataque pass-the-hash.
Isso envolve o uso do hash para autenticação em outros sistemas na rede, concedendo-lhes efetivamente o mesmo acesso que o usuário original. Isto pode levar a um comprometimento em grande escala da rede se contas com privilégios mais elevados forem visadas.
Hashes NTLM enviados pela rede
A autenticação NTLM envia hashes pela rede, tornando-os suscetíveis à interceptação. Ao usar ferramentas de detecção de rede, os invasores podem capturar esses hashes e realizar ataques man-in-the-middle para obter acesso a eles. Se os invasores interceptarem esses hashes com sucesso, eles poderão usá-los para aumentar seus privilégios, autenticando-se em máquinas adicionais e usando ferramentas como LSADUMP para extrair mais credenciais.
NTLS tem múltiplas autenticações em comparação com Kerberos
Autenticação NTLM: Cada vez que um usuário acessa um recurso diferente, o NTLM envia as credenciais com hash pela rede. Essa transmissão repetida de hashes oferece mais oportunidades para os invasores interceptá-los e utilizá-los indevidamente.
À medida que os hashes são armazenados em cada máquina, eles são dispersos por toda a rede por design.
Imagine uma usuária chamada Alice que precisa acessar vários recursos de rede, como um servidor de arquivos, um servidor de e-mail e uma impressora. Para cada solicitação de acesso, a estação de trabalho de Alice envia suas credenciais com hash pela rede para o respectivo servidor. Um invasor que use uma ferramenta de detecção de rede pode interceptar esses hashes durante a transmissão. Com hashes interceptados suficientes, o invasor pode realizar um ataque pass-the-hash para obter acesso não autorizado a outros sistemas, reproduzindo os hashes capturados.
Autenticação Kerberos: O Kerberos, por outro lado, usa um mecanismo de autenticação baseado em tickets que minimiza solicitações repetidas de autenticação e reduz significativamente o risco de interceptação de credenciais. No Kerberos, o usuário se autentica uma vez no Key Distribution Center (KDC) e recebe um Ticket Granting Ticket (TGT). Este TGT é então usado para solicitar tickets de serviço para acessar diferentes recursos sem reenviar as credenciais do usuário pela rede.
Combatendo ataques NTLM: estratégias comuns e medidas proativas
O objetivo da seção a seguir é examinar técnicas relacionadas a acesso credencial, começando com o despejo dos hashes armazenados na memória.
Quando um usuário faz login ou se autentica em um serviço, suas credenciais são criptografadas e esses hashes são armazenados na memória do sistema. Os invasores frequentemente usam ferramentas como o Mimikatz para extrair hashes NTLM da memória de uma máquina. Uma vez obtidos, esses hashes podem ser aproveitados em ataques pass-the-hash para obter acesso não autorizado a outros sistemas na rede.
Os invasores normalmente começam comprometendo um sistema com privilégios suficientes para acessar a memória LSASS (Local Security Authority Subsystem Service), onde os hashes NTLM são armazenados. Exemplo de hashes NTLM e SHA1 extraídos usando Mimikatz.
Do tráfego de rede: respondedor
Em uma rede onde a autenticação NTLM é usada, ferramentas como o Responder representam uma ameaça significativa porque podem capturar hashes NTLM do tráfego de rede por meio da falsificação de respostas de serviços de rede. Imagine um cenário em que um invasor, Bob, se infiltra no mesmo segmento de rede que Alice, uma administradora de rede. Bob configura o Responder em seu laptop para escutar na interface de rede e falsificar respostas a solicitações de serviço de nomes NetBIOS (NBT-NS), LLMNR e mDNS.
À medida que a estação de trabalho de Alice envia solicitações de rede para resolver nomes de host, O Respondente intercepta essas solicitações e finge ser o serviço de rede legítimo. Quando a máquina de Alice se autentica no serviço falsificado, ela envia seu hash NTLM, que o Respondente captura. Por exemplo, o Respondente pode exibir um hash NTLMv2 interceptado, como alice::CONTOSO:1122334455667788:9988776655443322:0101000000000000800000….
Armado com esse hash, Bob pode realizar um ataque de força bruta offline usando ferramentas como o Hashcat para quebrar a senha de Alice. No entanto, de forma mais eficiente, ele pode usar o hash capturado diretamente em um ataque pass-the-hash para obter acesso não autorizado a outros sistemas na rede, autenticando-se como Alice.
O objetivo da seção seguinte é examinar técnicas relacionadas ao movimento lateral:
Alavancagem de movimento lateral hashes capturados
Passe o hash: Os ataques PtH exploram fraquezas inerentes à autenticação NTLM. Os invasores usam hashes NTLM capturados para se autenticar em outras máquinas sem precisar da senha em texto simples.
No cenário anterior, executando um comando como pth-winexe -U 'CONTOSO\alice%1122334455667788:9988776655443322' //target-server cmd – usando o kit de ferramentas PTH, Bob pode abrir um prompt de comando em um servidor de destino como Alice, ignorando o necessidade da senha em texto simples. Isso pode ser feito usando várias ferramentas que suportam autenticação hash NTLM, como pth-winexe ou pth-smbclient.
Relé NTLM: Um ataque de retransmissão NTLM envolve a interceptação de uma solicitação de autenticação NTLM de um usuário e a retransmissão para um servidor de destino para obter acesso não autorizado. O invasor captura o hash NTLM e o utiliza para autenticar outro sistema como usuário legítimo, explorando relações de confiança dentro da rede.
Ele usa uma ferramenta como o ntlmrelayx para retransmitir o hash NTLM capturado para outro servidor na rede que confia na autenticação NTLM. Este servidor, desconhecendo a interceptação, processa a autenticação como se fosse genuinamente do usuário original.
Usando senha descriptografada
Login direto -> No local: As senhas NTLM descriptografadas permitem que invasores contornem as medidas de segurança e obtenham acesso direto aos sistemas locais. Os invasores podem extrair e descriptografar hashes NTLM de máquinas comprometidas usando ferramentas como o Mimikatz.
As senhas descriptografadas dessa forma podem ser usadas para logins diretos via protocolo de desktop remoto (RDP) ou shell seguro (SSH), permitindo movimento lateral pela rede com credenciais legítimas, contornando efetivamente o MFA – presumindo que ele seja habilitado apenas durante o login inicial.
Login direto -> SaaS: Em ambientes onde as senhas NTLM são sincronizadas entre sistemas locais e aplicativos SaaS, as senhas descriptografadas representam uma ameaça significativa. Serviços em nuvem como Office 365, Salesforce e Google Workspace podem ser acessados usando essas credenciais. Isto expande o superfície de ataque além da rede corporativa para incluir recursos de nuvem, aumentando o impacto potencial da violação. Por exemplo, descriptografar a senha NTLM de um administrador do ambiente local permite que invasores acessem os serviços em nuvem da organização com o mesmo nível de privilégio.
Isto enfatiza a necessidade de práticas robustas de criptografia, controles de acesso rigorosos e MFA em todos os serviços para proteção contra comprometimento de credenciais NTLM.
Devido à natureza unidirecional dos hashes NTLM, não é possível descriptografar diretamente senhas de texto simples de hashes NTLM. É possível explorar esses hashes usando técnicas como tabelas arco-íris ou ataques de força bruta usando ferramentas como o Hashcat.
Da captura de acesso de credenciais ao movimento lateral
Imagine o seguinte cenário: Bob, um invasor experiente, decide explorar a dependência de uma empresa do NTLM para autenticação de rede. Ele configura seu laptop no mesmo segmento de rede e configura o Respondente para capturar solicitações de autenticação NTLM ouvindo na interface de rede. À medida que funcionários como Alice tentam acessar os recursos da rede, o Responder intercepta essas solicitações e captura seus hashes NTLM.
Com esses hashes em mãos, Bob usa ntlmrelayx para retransmiti-los para um servidor de destino de alto valor no endereço IP 192.168.1.10. Ao executar ntlmrelayx.py -t smb://192.168.1.10, Bob encaminha efetivamente o hash capturado de Alice para o servidor, que ingenuamente aceita a autenticação e lhe concede acesso como se fosse Alice. Isso permite que Bob explore os compartilhamentos de arquivos do servidor e extraia potencialmente informações confidenciais, demonstrando o grave risco representado pelos ataques de retransmissão NTLM em um ambiente de rede desprotegido.
Obtendo visibilidade no uso do NTLM
Para se protegerem de todas as maneiras pelas quais os invasores podem aproveitar o NTLM, as organizações primeiro precisam obter visibilidade sobre onde e como o NTLM é usado em suas redes. Isso envolve a identificação de todos os sistemas e aplicativos que dependem do NTLM para autenticação. Auditorias regulares de rede e ferramentas de monitoramento podem ajudar a alcançar essa visibilidade.
Silverfort aumenta a visibilidade do NTLM integrando sua plataforma para monitorar e proteger todas as autenticações no ambiente de uma organização. Ao fazer isso, Silverfort fornece visibilidade em tempo real e análise de risco da autenticação NTLM, permitindo que as organizações detectem e mitiguem ameaças potenciais de forma eficaz. SilverfortO mecanismo de análise de risco baseado em IA da empresa monitora continuamente as tentativas de acesso, criando linhas de base comportamentais detalhadas para cada usuário. Isso ajuda a identificar atividades anômalas e riscos potenciais associados às autenticações NTLM.
Redução do NTLM Os esforços da Reliance devem ser feitos para reduzir o uso do NTLM ao mínimo. A transição para protocolos de autenticação mais seguros, como Kerberos ou mecanismos modernos de autenticação baseados em nuvem, pode mitigar os riscos relacionados ao NTLM. A Microsoft recomenda usar o protocolo Negotiate, que prioriza Kerberos e recorre ao NTLM somente quando necessário.
Melhore a segurança da sua organização obtendo visibilidade clara do uso do NTLM, identificando onde o NTLM está sendo usado e tomando medidas para minimizar sua dependência fazendo a transição para protocolos de autenticação mais seguros.
O NTLM é uma superfície de ataque que você deseja abordar? Agende uma reunião com um de nossos especialistas aqui.