Mesmo com MFA e soluções modernas de identidade, protocolos legados como NTLM continuam oferecendo oportunidades para ataques. Uma vulnerabilidade no Microsoft Outlook reforça a necessidade de revisar a segurança das autenticações corporativas.
Uma vulnerabilidade no Outlook reacende o alerta sobre credenciais corporativas
A Microsoft divulgou uma correção para a vulnerabilidade CVE-2026-124194, associada ao Microsoft Outlook e reportada como explorada ativamente.
Segundo as informações divulgadas, a falha permite que um arquivo de mensagem especialmente preparado provoque uma conexão do Outlook com um recurso de rede controlado por um atacante quando a vítima abre o conteúdo malicioso.
Dependendo da configuração do ambiente, essa conexão pode desencadear uma tentativa de autenticação NTLM, expondo material de autenticação NTLMv2 ao servidor controlado pelo invasor.
Embora a exploração dependa da interação do usuário e de conectividade de rede, o impacto potencial ultrapassa o próprio cliente de e-mail.
O episódio chama atenção para um problema recorrente na segurança corporativa: mecanismos antigos de autenticação continuam ativos mesmo em organizações que investiram significativamente na modernização de suas plataformas de Identity and Access Management (IAM).
Como um arquivo do Outlook pode expor material de autenticação?
O mecanismo explorado envolve o comportamento de autenticação do Windows diante de recursos de rede.
Em determinados cenários, quando uma aplicação tenta acessar um recurso remoto, o sistema operacional pode negociar automaticamente a autenticação usando NTLM.
O fluxo de ataque pode ocorrer da seguinte maneira:
- O atacante prepara um arquivo de mensagem malicioso contendo uma referência a um recurso de rede sob seu controle.
- A vítima abre o arquivo utilizando uma versão vulnerável do Outlook.
- O Outlook tenta acessar o recurso remoto.
- O Windows pode iniciar uma negociação de autenticação NTLM.
- O servidor controlado pelo atacante recebe material de autenticação NTLMv2, que poderá ser utilizado em tentativas posteriores de comprometimento.
É importante distinguir a exposição de uma resposta de autenticação NTLMv2 do roubo direto da senha ou do hash NT armazenado no sistema.
O material capturado não representa, por si só, acesso garantido à conta. Entretanto, dependendo das proteções existentes, pode viabilizar ataques de relay ou tentativas de recuperação offline da senha.
O risco efetivo depende de fatores como configuração dos serviços de destino, proteções contra relay, qualidade das senhas e restrições de autenticação.
O problema não é apenas o Outlook. É a dependência de NTLM.
A vulnerabilidade evidencia uma fragilidade arquitetural que pode permanecer invisível durante projetos de transformação digital.
Muitas organizações já implementaram:
- Autenticação multifator (MFA).
- Single Sign-On (SSO).
- Microsoft Entra ID e outros provedores modernos de identidade.
- Políticas de Conditional Access.
- Soluções de Privileged Access Management (PAM).
- Estratégias de Zero Trust.
Ainda assim, sistemas internos, aplicações antigas, compartilhamentos de arquivos e integrações podem continuar dependendo de NTLM.
Essa coexistência cria uma superfície de ataque que nem sempre é adequadamente coberta pelos mecanismos modernos de proteção de identidade.
Uma empresa pode exigir MFA para acessar o Microsoft 365 e, simultaneamente, permitir autenticações NTLM em determinados serviços internos.
Nesse cenário, o MFA aplicado ao login moderno não necessariamente protege uma autenticação legada realizada por outro protocolo.
Isso não significa que MFA seja ineficaz. Significa que sua proteção depende do caminho de autenticação utilizado.
NTLM Relay: quando a autenticação é reutilizada contra outro serviço
Um dos riscos associados à captura de autenticações NTLM é a possibilidade de ataques conhecidos como NTLM Relay.
Nessa modalidade, o atacante tenta encaminhar uma negociação de autenticação para outro serviço que aceite NTLM, aproveitando a autenticação da vítima sem necessariamente conhecer sua senha.
A viabilidade depende de diversas condições técnicas, incluindo a ausência ou insuficiência de mecanismos como SMB Signing, LDAP Signing, Channel Binding e outras proteções específicas.
Outro cenário envolve ataques offline contra respostas NTLMv2 capturadas, especialmente quando as contas utilizam senhas fracas ou previsíveis.
Contas privilegiadas e contas de serviço merecem atenção especial, pois uma autenticação comprometida pode proporcionar acesso a recursos sensíveis ou ampliar as possibilidades de movimentação lateral.
Por isso, a análise de risco não deve considerar apenas a vulnerabilidade original, mas também os serviços que poderiam aceitar uma autenticação potencialmente comprometida.
O desafio para IAM: autenticações que escapam da governança moderna
Projetos de Identity Governance and Administration (IGA) tradicionalmente concentram esforços no ciclo de vida das identidades, provisionamento, certificações de acesso e segregação de funções.
Essas capacidades continuam fundamentais.
Entretanto, conhecer quem possui acesso a uma aplicação não significa necessariamente conhecer todos os mecanismos utilizados para autenticar esse acesso.
Uma organização pode ter processos maduros de Joiner, Mover and Leaver (JML), revisões periódicas de permissões e controle de contas privilegiadas, mas ainda manter dependências de autenticação legada pouco documentadas.
A questão passa a ser mais abrangente:
Sua plataforma de IAM governa apenas as permissões ou também oferece visibilidade sobre os caminhos reais de autenticação?
Esse questionamento aproxima IAM de outras disciplinas essenciais, como Identity Threat Detection and Response (ITDR), gestão de exposição de identidades e segurança de protocolos.
Cinco prioridades para reduzir a exposição
A correção da vulnerabilidade deve ser tratada como uma ação imediata, mas a resposta de segurança não deveria terminar na instalação do patch.
1. Atualizar o Outlook e validar a correção
Identificar instalações afetadas, aplicar as atualizações de segurança disponibilizadas pela Microsoft e confirmar a implantação nos endpoints corporativos.
2. Mapear o uso de NTLM no ambiente
Identificar servidores, aplicações, dispositivos e integrações que ainda dependem de NTLM. Utilizar mecanismos de auditoria do Windows e ferramentas de monitoramento para compreender onde o protocolo continua necessário.
3. Restringir autenticações NTLM desnecessárias
Planejar a redução ou eliminação progressiva de NTLM, priorizando alternativas modernas, como Kerberos, quando tecnicamente aplicáveis. Avaliar controles para impedir autenticações de saída para destinos não confiáveis.
4. Fortalecer as proteções contra relay
Revisar SMB Signing, LDAP Signing, LDAP Channel Binding e demais controles relevantes. Avaliar também regras de firewall e restrições de conectividade que possam impedir a comunicação com servidores controlados por atacantes.
5. Integrar IAM, PAM e ITDR
Correlacionar eventos de autenticação, privilégios e comportamento das identidades para identificar tentativas de uso indevido de credenciais, acessos anômalos e movimentação lateral.
A eliminação de NTLM exige planejamento, testes de compatibilidade e conhecimento das dependências existentes. Bloqueios indiscriminados podem interromper aplicações críticas.
Zero Trust exige olhar além do login
A adoção de Zero Trust não se resume à implementação de MFA ou à migração das identidades para a nuvem.
Uma arquitetura de confiança zero precisa considerar continuamente como uma identidade se autentica, quais recursos acessa, em que contexto opera e quais mecanismos podem ser explorados para contornar controles modernos.
Quando protocolos legados permanecem ativos sem monitoramento e restrições adequadas, surgem caminhos de autenticação que podem enfraquecer a estratégia de segurança.
A vulnerabilidade no Outlook é mais um exemplo de como uma interação aparentemente simples pode explorar dependências históricas da infraestrutura corporativa.
Conclusão: modernizar IAM também significa eliminar dependências invisíveis
A CVE-2026-124194 reforça uma lição importante: a segurança das identidades não depende exclusivamente da qualidade das soluções modernas implementadas.
Ela também depende da capacidade de identificar, controlar e reduzir mecanismos antigos que continuam operando em segundo plano.
MFA, SSO, IGA e PAM são componentes essenciais de uma arquitetura de segurança de identidades. Entretanto, sua efetividade pode ser limitada quando caminhos alternativos de autenticação permanecem expostos.
O maior risco pode não estar no mecanismo de autenticação que sua empresa acabou de modernizar, mas naquele que ninguém percebeu que ainda estava ativo.
Na OWLK Cybersecurity, entendemos que a evolução da segurança de identidades exige uma visão integrada entre governança, autenticação, proteção de privilégios e detecção de ameaças.
Mais do que administrar acessos, é necessário compreender como as identidades são utilizadas e quais oportunidades de exploração permanecem no ambiente.
Sua organização sabe onde NTLM ainda está sendo utilizado?
Essa pode ser uma das perguntas mais importantes da próxima avaliação de segurança de identidades.
