MFA não basta no Windows: descubra os caminhos de autenticação que ainda permitem mover-se pela rede

Muitas organizações celebraram a chegada da autenticação multifator (MFA) como a panaceia que encerraria de golpe o problema das credenciais roubadas. No entanto, em ambientes Windows essa confiança às vezes é prematura: os atacantes continuam a aceder a redes com contas válidas porque grande parte da autenticação no Windows não passa pelo provedor de identidade na nuvem e, portanto, não obriga um segundo fator.

Não é que MFA falle; o problema é que não cobre todos os caminhos pelos quais o Windows valida identidades. Quando as sessões são verificadas contra controladores de domínio locais por Kerberos ou NTLM, as políticas aplicadas no Azure AD, Okta ou outros IdP não são ativadas. A Microsoft descreve estes protocolos e suas implicações em sua documentação sobre Kerberos e NTLM, que serve como referência para entender por que certos logins ficam fora do alcance das soluções na nuvem: Kerberos e NTLM.

Assinar diretamente em um computador Windows unido ao domínio - seja um laptop do usuário ou um servidor - é geralmente um processo gerido pelo Active Directory. Se a organização não tiver integrado mecanismos de segundo fator para o início de sessão local (por exemplo, Windows Hello for Business ou cartões inteligentes), esse acesso é validado com a senha ou com o hash armazenado em memória. Consequentemente, um atacante que obtenha essa senha ou sua representação criptográfica pode mover-se pela rede sem ativar as políticas de acesso condicional impostas no IdP. A Microsoft explica as opções para modernizar o início de sessão e reduzir este risco na documentação Windows Hello for Business e em guias de proteção de credenciais como Credential Guard.

Outro vetor habitual são as sessões de Escritor Remoto (RDP). Embora não se exponha RDP à Internet, os atacantes costumam usá-los para se deslocar lateralmente após um acesso inicial. Uma conexão RDP a um servidor não garante que a camada de controle de acesso do IDP seja ultrapassada; muitas vezes a autenticação é resolvida localmente com AD, deixando o acesso exposto a credenciais roubadas. Por isso é fundamental aplicar controles de acesso no perímetro e na teleadministração, bem como soluções que integrem MFA nesses fluxos.

NTLM, legado, mas ainda presente por compatibilidade, continua sendo um alvo atrativo. Técnicas como o “pass-the-hash” aproveitam o fato de que o NTLM permite autenticar com o hash em vez da senha em texto claro, pelo que um atacante não precisa conhecer a senha para validar. MITRE documenta estas técnicas e suas variantes, o que ajuda a entender a mecânica de abuso em ambientes Windows: Pass-the-Hash e Pass-the-Ticket.

Kerberos também não é imune. Em vez de roubar senhas, os intrusos podem extrair tickets de autenticação da memória ou forjar tickets a partir de credenciais privilegiadas, criando cenários conhecidos como Golden Ticket ou Silver Ticket. Esses ataques permitem acesso persistente e lateralidade com um menor número de autenticações visíveis, e podem sobreviver a mudanças de senha se a causa raiz não for remediada. As implicações operacionais e de detecção são bem recolhidas pelo MITRE e na literatura especializada sobre abusos de Kerberos.

Um fator recorrente nas invasões são as contas locais com privilégios administrativos e a reutilização de senhas. Muitas organizações mantêm contas locais para suporte ou recuperação, e quando essas credenciais se repetem em vários equipamentos, uma única filtração pode abrir muitas portas. A Microsoft oferece ferramentas para mitigar este problema, entre elas o Local Administrator Password Solution (LAPS), que automatiza a rotação de senhas locais e reduz o risco derivado de senhas estáticas: LAPS.

O protocolo SMB, usado para compartilhar arquivos e gerenciar recursos remotos, é outro vetor de movimento lateral muito utilizado. Com credenciais válidas, um atacante pode aceder a recursos administrativos e mover-se rapidamente pela rede. É por isso que os controlos de autenticação sobre serviços como o SMB e as auditorias de tráfego interno são fundamentais; o catálogo de técnicas do MITRE inclui as vias de serviços remotos e como são utilizados para a lateralidade: SMB / Windows Admin Shares.

As contas de serviço constituem um risco discreto, mas grave. São projetadas para automatizar tarefas, integrações e serviços, pelo que costumam ter senhas longas vigentes durante anos e permissões amplas. Ao não poder incorporar MFA em processos automatizados com facilidade, essas contas tornam-se objetivos privilegiados para os atacantes. Auditar, rotar e minimizar privilégios em contas de serviço são medidas indispensáveis que muitas organizações pós-ponem e que, infelizmente, facilitam a escalada e a persistência de ameaças.

O que podem fazer as equipes de segurança para fechar esses buracos? A resposta passa por tratar a autenticação do Windows como uma superfície de risco com suas próprias regras e controles. Começando por endurecer as políticas de senhas no Active Directory, promovendo o uso de frases de passagem mais longas e evitando a reutilização, já reduz a probabilidade de compromisso por força bruta ou reutilização de credenciais. O NIST recomenda abordagens modernas na gestão de senhas e criação de credenciais comprometidas, cuja leitura esclarece por que palavras-passe longas e verificação frente a vazamentos são práticas recomendadas: NIST SP 800-63B.

Complementariamente, implementar controles que detectem e bloqueem senhas conhecidas por estarem expostas em lacunas reduz ainda mais a janela de vulnerabilidade. Serviços como Have I Been Pwned têm popularizado a verificação de senhas contra grandes repositórios de credenciais comprometidas, e muitas soluções comerciais incorporam essa função para prevenir que os usuários escolham chaves já filtradas: Have I Been Pwned – Passwords.

Avançar para a eliminação ou restrição de protocolos antigos — especialmente NTLM — e habilitar medidas que integrem MFA nos fluxos locais (por exemplo, Windows Hello for Business ou soluções de terceiros que acrescentam MFA ao RDP e ao início de sessão locais) é outra peça chave. A Microsoft e outros fornecedores explicam como combinar identidade híbrida e controles no perímetro para que os acessos remotos e administrativos também exijam verificação adicional: Acesso condicional no Azure AD.

Além disso, a higiene de identidades permanece imprescindível: inventariar e auditar contas de serviço, segregar contas com privilégios mínimos, rotar credenciais periodicamente e retirar acessos desnecessários são práticas que limitam a superfície de ataque. Ferramentas de gestão de senhas e de acesso privilegiado ajudam a automatizar muitas dessas tarefas e a reduzir a probabilidade de uma única conta comprometer todo o ambiente.

Finalmente, a detecção e resposta rápida são não transaccionáveis. Controles de telemetria que alertem sobre movimentos laterais, usos atípicos de tickets Kerberos, extração de hashes em memória ou acessos a recursos compartilhados desde hosts incomuns aumentam a probabilidade de interromper uma intrusão antes de explorar contas em múltiplos sistemas. Complementar políticas preventivas com tecnologias de proteção de endpoints e monitoramento do comportamento pode marcar a diferença entre um incidente isolado e uma brecha estendida.

Existem soluções comerciais que se concentram precisamente em estender MFA e controles de senha ao mundo Windows tradicional, bem como em bloquear senhas filtradas e fortalecer as políticas de senha no Active Directory. Se forem avaliados produtos, é conveniente compará-los com a documentação técnica e os guias de boas práticas aqui citados para entender como se encaixam na estratégia global de identidade e acesso. Entre as abordagens recomendadas estão a integração do MFA no início da sessão local, a eliminação da NTLM quando possível, a rotação automática de senhas locais e a monitorização contínua de anomalias nos fluxos de autenticação.

Em suma, adotar MFA é um avanço imprescindível, mas não basta por si mesmo. É preciso identificar e proteger os caminhos de autenticação que ficam fora do alcance do IDP, modernizar protocolos, gerir com rigor contas privilegiadas e dotar a equipe de segurança de detecção e remediação efetivas. Só assim se reduz de forma sustentada o risco derivado de credenciais comprometidas em ambientes Windows.

Fontes e leituras recomendadas: documentação da Microsoft sobre Kerberos e NTLM ( Kerberos, NTLM), guias de acesso condicional no Azure AD ( Conditional Access), NIST SP 800-63B sobre autenticação ( NIST SP 800-63B), repositórios de senhas filtradas como Have I Been Pwned e catálogo MITRE ATT&CK para técnicas de abuso de credenciais e movimento lateral ( MITRE ATT&CK).