Plano em três fases aumenta auditoria, remove obstáculos de compatibilidade e prepara Windows Server e clientes Windows para bloquear autenticação NTLM de rede por padrão.
| Componente | Autenticação NTLM em ambientes Windows, com migração planejada para alternativas baseadas em Kerberos. |
| Vetor | Uso persistente de NTLM em redes corporativas por dependências legadas, limitações de rede ou lógica de aplicações que ainda não operam com Kerberos. |
| Impacto | Exposição a ataques de replay, relay, man-in-the-middle e pass-the-hash, com risco de acesso não autorizado a recursos de rede quando NTLM permanece aceito. |
| Prioridade | Auditar o uso real de NTLM, mapear dependências, testar configurações sem NTLM em ambientes não produtivos e planejar a migração para Kerberos. |
| Cronograma | Fase 1 disponível agora; Fase 2 esperada para o segundo semestre de 2026; Fase 3 prevista para a próxima versão do Windows Server e cliente Windows associado. |
| Mudança de padrão | A desativação por padrão não remove imediatamente o NTLM do Windows, mas bloqueia autenticação NTLM de rede e exige reativação explícita por política. |
A Microsoft iniciou uma transição em três fases para reduzir o uso do New Technology LAN Manager em ambientes Windows e deslocar a autenticação de rede para opções baseadas em Kerberos. A medida segue a depreciação formal do NTLM em junho de 2024, quando a tecnologia deixou de receber atualizações. O objetivo operacional não é remover o mecanismo de uma só vez, mas mudar o estado padrão do Windows para que a autenticação NTLM de rede deixe de ser usada automaticamente.
O risco central está na permanência de um protocolo legado em fluxos corporativos que ainda dependem de compatibilidade histórica. O NTLM foi projetado para autenticação, integridade e confidencialidade, mas seu modelo criptográfico e operacional é descrito como inadequado para ameaças modernas. A exposição citada envolve replay, relay, man-in-the-middle e pass-the-hash, cenários em que o atacante tenta reutilizar ou intermediar material de autenticação para alcançar recursos de rede sem autorização.
A primeira fase concentra-se em visibilidade e controle. A Microsoft disponibilizou auditoria aprimorada de NTLM para que administradores identifiquem onde o protocolo ainda aparece, por que ele é acionado e quais aplicações, serviços ou caminhos de autenticação dependem dele. Essa etapa é necessária porque a presença de NTLM em empresas costuma ser distribuída entre aplicações antigas, restrições de rede e lógica de autenticação incorporada a sistemas internos.
A segunda fase mira obstáculos conhecidos de migração. A empresa planeja recursos como IAKerb e Local KDC em estado de pré-lançamento, além de alterações em componentes centrais do Windows para priorizar autenticação Kerberos. Essa fase é esperada para o segundo semestre de 2026 e busca reduzir casos em que organizações mantêm NTLM porque determinadas condições de rede ou aplicações ainda não conseguem usar Kerberos de forma adequada.
A terceira fase muda o comportamento padrão na próxima versão do Windows Server e no cliente Windows associado. Nessa etapa, o NTLM será desativado por padrão para autenticação de rede, e a reativação dependerá de controles explícitos de política. A distinção técnica é importante: a medida não equivale à remoção completa do NTLM do sistema operacional, mas estabelece um padrão seguro em que o Windows prefere alternativas Kerberos e bloqueia o uso automático de NTLM.
A superfície exposta inclui ambientes Windows empresariais nos quais NTLM permanece ativo por compatibilidade. O contexto afetado não se limita a um único produto ou versão específica informada; a mudança abrange a direção de segurança para Windows Server e clientes Windows associados. O risco aparece principalmente quando recursos de rede continuam aceitando autenticação NTLM e quando aplicações internas não foram testadas com autenticação Kerberos.
Dependências legadas são o principal ponto de atenção. Aplicações que embutem lógica antiga de autenticação, redes com limitações que impedem Kerberos e serviços que ainda recorrem automaticamente ao NTLM podem falhar quando o bloqueio por padrão chegar. Por isso, a etapa de auditoria deve preceder qualquer desligamento amplo, evitando que a mitigação de segurança interrompa fluxos críticos sem inventário prévio.
- Ambientes Windows corporativos com autenticação NTLM ainda observada em tráfego ou logs de auditoria.
- Aplicações legadas que não foram migradas para Kerberos por dependências de lógica interna.
- Caminhos de rede em que limitações operacionais impedem ou dificultam o uso de Kerberos.
- Futuras implantações da próxima versão do Windows Server e do cliente Windows associado, nas quais a reativação de NTLM dependerá de política explícita.
A principal atividade defensiva é transformar a auditoria de NTLM em inventário acionável. Em vez de tratar a desativação como uma mudança binária, as equipes devem localizar origens, destinos e aplicações que ainda negociam NTLM, separando uso esperado, dependência legada e comportamento anômalo. O resultado deve indicar quais fluxos podem migrar diretamente para Kerberos e quais exigem correção de aplicação, ajuste de rede ou validação com recursos como IAKerb e Local KDC quando estiverem disponíveis.
A telemetria deve priorizar padrões compatíveis com abuso de autenticação, sem assumir comprometimento quando apenas houver uso legado. Sinais relevantes incluem NTLM em caminhos que deveriam aceitar Kerberos, autenticações repetidas entre sistemas intermediários, dependências descobertas durante testes de NTLM desativado e exceções solicitadas por aplicações que não foram modernizadas. Esses dados ajudam a reduzir a necessidade de reativação por política quando a Fase 3 chegar.
- Eventos de auditoria que mostrem quais sistemas ainda iniciam ou aceitam autenticação NTLM.
- Aplicações ou serviços que falham em ambiente não produtivo quando a autenticação NTLM de rede é bloqueada.
- Fluxos que recorrem a NTLM mesmo quando alternativas Kerberos deveriam ser preferidas.
- Solicitações de exceção para reativação de NTLM por política, associadas a dono técnico e prazo de migração.
A resposta deve começar por auditoria, não por bloqueio amplo imediato. O primeiro passo é mapear dependências de NTLM com a auditoria aprimorada disponível, classificar sistemas por criticidade e validar quais fluxos aceitam Kerberos. Depois, a organização deve executar testes de configuração sem NTLM em ambientes não produtivos, registrando falhas funcionais e distinguindo problemas de aplicação, rede e configuração.
A migração deve acompanhar o cronograma em fases. Antes da Fase 2, o foco é reduzir dependências conhecidas e preparar aplicações para autenticação Kerberos. Quando recursos como IAKerb e Local KDC estiverem disponíveis em pré-lançamento, eles devem ser avaliados para cenários comuns que hoje impedem a migração. Antes da Fase 3, qualquer reativação de NTLM por política precisa ser tratada como exceção documentada, com justificativa, escopo limitado e plano de remoção.
- Ativar e revisar auditoria aprimorada de NTLM para identificar origem, destino e aplicação responsável por cada uso relevante.
- Migrar fluxos compatíveis para Kerberos e testar configurações sem NTLM fora de produção antes de mudanças em sistemas críticos.
- Acompanhar recursos de pré-lançamento como IAKerb e Local KDC para reduzir dependências que hoje bloqueiam a migração.
- Preparar controles de política para que qualquer reativação futura de NTLM seja explícita, limitada e rastreável.
0 Comentários