Windows LSA Spoofing Vulnerability
Prioritize patching. It under exploitation confirmed by CISA.
Apply remediation actions outlined in CISA guidance [https://www.cisa.gov/guidance-applying-june-microsoft-patch].
Summary
Falha de spoofing na Local Security Authority (LSA) do Windows que permite a um atacante não autenticado coagir um controlador de domínio (ou outro host Windows) a autenticar-se contra um servidor controlado pelo atacante usando NTLM. O impacto real não é o CVSS de 8.1 isolado, mas o que vem depois: a autenticação NTLM coagida pode ser retransmitida (relay) para outros serviços — em especial AD Certificate Services — resultando em emissão de certificado fraudulento e comprometimento total do domínio. Está no catálogo KEV da CISA com exploração confirmada.
Technical detail
A vulnerabilidade está classificada como CWE-306 (Missing Authentication for Critical Function) na LSA do Windows. O mecanismo é uma variante da família de ataques de coerção de autenticação NTLM — a mesma classe explorada por PetitPotam — em que uma interface RPC exposta pela LSA pode ser abusada para forçar a máquina alvo (tipicamente um domain controller) a iniciar uma autenticação NTLM contra um endereço arbitrário escolhido pelo atacante, sem que este precise de credenciais válidas na rede.
O atacante controla o destino da autenticação coagida: ele aponta o alvo para um listener sob seu controle e captura/retransmite a negociação NTLM. Como NTLM não amarra a autenticação a um canal específico por padrão (ausência de channel binding/signing obrigatório em muitos cenários), essa autenticação capturada pode ser repassada (relayed) a um segundo serviço, autenticando o atacante como a máquina coagida perante esse serviço.
A gravidade prática dessa CVE está amarrada ao contexto do AD CS: se houver um Enrollment endpoint HTTP de Certificate Authority acessível (o cenário conhecido como ESC8), o NTLM relay da autenticação da máquina/domain controller contra esse endpoint permite solicitar um certificado de autenticação em nome da conta coagida — inclusive contas com privilégios de domain controller — dando ao atacante um caminho para escalonamento total de privilégios no domínio.
O vetor de rede (AV:N) e a ausência de privilégios necessários (PR:N) explicam o CVSS alto, mas a complexidade de ataque é classificada como alta (AC:H) porque a exploração de impacto real depende de encadear a coerção com um segundo componente vulnerável a relay (como AD CS mal configurado) — a LSA spoofing isolada não entrega, por si só, execução de código ou domínio comprometido.
How it’s exploited
Pré-requisito de rede: o atacante precisa de acesso à rede (mesmo segmento ou rota) até a máquina que será coagida a autenticar — tipicamente um domain controller — e precisa controlar ou ter acesso a um endpoint que receberá/retransmitirá essa autenticação NTLM (por exemplo, um relay para o serviço web de enrollment do AD CS). Não são necessárias credenciais de domínio para iniciar a coerção, o que torna o vetor inicial acessível a um atacante já posicionado na rede interna, mesmo sem conta válida.
O encadeamento típico observado por pesquisadores é: coerção de autenticação NTLM do domain controller (explorando a falha de LSA) → captura/relay dessa autenticação para o endpoint HTTP de enrollment do AD CS → emissão de certificado de autenticação de cliente em nome da conta da máquina coagida → uso desse certificado para autenticar como a conta comprometida (que pode ter privilégios elevados) via Kerberos PKINIT. O impacto final documentado nesse encadeamento é comprometimento de domínio.
A CISA confirma exploração ativa (entrada no KEV), sem classificar a falha como associada a campanhas de ransomware conhecidas. O CVSS marca complexidade de ataque alta porque a exploração depende dessas condições de infraestrutura (AD CS presente e mal configurado, ou outro serviço vulnerável a relay) — em ambientes sem AD CS exposto via HTTP, o risco prático de escalonamento completo é bem menor, embora a coerção de autenticação em si já represente um problema de segurança.
Versions
How to protect
A correção do fornecedor foi distribuída nas atualizações cumulativas de maio de 2022 (Patch Tuesday, 10/05/2022) para todas as versões suportadas listadas — Windows 10 (1507, 1607, 1809, 1909, 20H2, 21H1, 21H2) e Windows 11 21H2. A CISA alerta explicitamente que essa atualização é obrigatória em todos os endpoints Windows, mas se aplicada a domain controllers sem ajustes de configuração adicionais ela quebra autenticação PIV/CAC — é essencial ler a orientação de implementação da CISA para maio de 2022 antes de aplicar em controladores de domínio.
Como paliativo além do patch, a mitigação estrutural real contra o encadeamento de maior impacto é endurecer o AD CS: desabilitar ou restringir o endpoint HTTP de enrollment de certificados (cenário ESC8), exigir extended protection for authentication (EPA)/channel binding nesse endpoint, e habilitar assinatura/vedação (signing) obrigatória de NTLM onde possível. Restringir NTLM na rede (via política de restrição de NTLM outbound) reduz a superfície de relay, embora tenha custo operacional em ambientes que dependem de NTLM para compatibilidade legada.
Aplicar apenas a atualização de maio sem revisar a configuração do AD CS não elimina o risco de escalonamento via relay se o Enrollment web endpoint continuar exposto sem EPA — o patch trata a coerção pela LSA, não necessariamente todos os vetores de relay subsequentes contra serviços de terceiros mal configurados.
How to detect
Não há assinatura de exploração publicamente confiável e específica para essa CVE isolada — a coerção de autenticação NTLM via LSA não deixa, por si, um artefato distintivo fácil de diferenciar de autenticação NTLM legítima. Sinais indiretos a monitorar: tentativas de autenticação NTLM outbound de contas de máquina/domain controller para destinos externos ou não usuais na rede, picos de requisições ao endpoint HTTP de enrollment do AD CS (Certificate Services Web Enrollment) vindos de origens atípicas, e emissão de certificados de autenticação para contas privilegiadas fora do padrão operacional — esse último é o indicador mais forte de exploração bem-sucedida do encadeamento completo com AD CS.