Windows Common Log File System Driver Elevation of Privilege Vulnerability

Falha de elevação de privilégio no driver CLFS (Common Log File System) do Windows, o componente do kernel responsável por gerenciar logs multiuso usados por diversos subsistemas do sistema operacional. Um processo local com credenciais de baixo privilégio pode corromper memória do kernel e escalar para SYSTEM, sem interação do usuário. Está no catálogo KEV da CISA com exploração confirmada e há PoC pública, mas por ser estritamente local (AV:L) ela não é um vetor de entrada — serve para transformar um acesso inicial limitado em controle total da máquina, o que a torna atraente em cadeias de ataque pós-exploração e ransomware.

O CLFS (clfs.sys) implementa um mecanismo de log genérico usado internamente pelo Windows (inclusive por componentes de transação de arquivos). A vulnerabilidade combina dois problemas classificados pela Microsoft/NVD: CWE-787 (Out-of-Bounds Write) e CWE-1285 (Improper Validation of Specified Index, Position, or Offset in Input). Na prática, isso indica que o driver, ao processar estruturas de um arquivo de log (blocos/metadados do formato BLF), não valida corretamente um índice ou offset fornecido, permitindo que uma escrita subsequente ocorra fora dos limites do buffer alocado no espaço de kernel.

O atacante controla o conteúdo do arquivo de log ou os parâmetros passados às APIs de CLFS que acabam alimentando esse índice/offset malformado. Como o processamento ocorre em contexto de kernel, uma escrita fora dos limites bem-sucedida corrompe estruturas internas do sistema e pode ser encadeada para executar código arbitrário com privilégios de SYSTEM — daí o Impact C:H/I:H/A:H completo no vetor CVSS.

O vetor exige PR:L (privilégio baixo já no sistema) e AC:L (baixa complexidade), sem UI. Isso é consistente com o padrão de várias CVEs de CLFS divulgadas na mesma leva de atualizações (abril de 2022): a superfície de ataque é o próprio driver exposto a qualquer usuário autenticado local, não um serviço de rede.

A exploração exige que o atacante já tenha uma sessão local no sistema — uma conta de usuário comum, sem privilégios administrativos, é suficiente como ponto de partida (PR:L). Não há vetor remoto: isso não é uma vulnerabilidade de rede e não pode ser disparada por um invasor sem acesso prévio à máquina. O uso típico é como segundo estágio: after phishing, exploração de outra falha de execução remota de código, ou uso de credenciais roubadas, o atacante executa um binário/PoC que manipula estruturas de log CLFS para disparar a escrita fora dos limites e escalar de usuário padrão para SYSTEM.

A CISA confirma exploração ativa (presença no catálogo KEV desde 13/04/2022, com prazo de correção fixado em 04/05/2022 para agências federais dos EUA), e existe PoC pública circulando, o que reduz a barreira de reprodução para qualquer grupo com capacidade de adaptar código de prova de conceito. O padrão de uso — elevação de privilégio local após acesso inicial — é exatamente o perfil que operadores de ransomware buscam para desativar defesas, acessar credenciais adicionais (LSASS) e se mover lateralmente com privilégios administrativos.

Não há indicação, nas fontes consultadas, de que esta CVE específica tenha sido atribuída a uma família de ransomware nomeada publicamente pela CISA; o catálogo KEV lista apenas a ação recomendada (aplicar a atualização) e o CWE, sem detalhar o ator ou campanha.

A correção veio na atualização de segurança de abril de 2022 (Patch Tuesday), que cobre todas as versões listadas pela Microsoft — Windows 10 (1507, 1607, 1809, 1909, 20H2, 21H1, 21H2) e Windows 11 21H2. O número de KB exato varia por versão/branch e deve ser conferido diretamente no Security Update Guide da Microsoft para a build específica em uso, já que a Microsoft publica atualizações cumulativas distintas por versão — não há um único KB universal a citar aqui sem risco de indicar o pacote errado.

Como mitigação real, não existe uma configuração ou flag documentada pela Microsoft que desative a falha sem aplicar o patch: CLFS é um componente central do kernel usado por outros subsistemas, e desabilitá-lo ou bloquear o driver não é uma opção suportada. O controle compensatório efetivo, quando a atualização não pode ser aplicada imediatamente, é reduzir a superfície de ataque local: restringir quem pode fazer logon interativo/RDP na máquina, aplicar princípio de menor privilégio nas contas de usuário, e monitorar/isolar hosts que não podem ser corrigidos dentro da janela de risco.

O mito a descartar: como o vetor é AV:L, algumas equipes assumem que a exposição é baixa e adiam o patch. Isso ignora que a vulnerabilidade é routineiramente usada como etapa de escalonamento após comprometimento inicial — sua presença no catálogo KEV da CISA, com prazo de correção obrigatório para agências federais, reflete exatamente esse risco de encadeamento, não um risco isolado de acesso físico.

Não há assinatura pública confiável e amplamente documentada para detectar tentativas de exploração desta CVE especificamente. Sinais indiretos a observar incluem: crashes ou eventos de erro relacionados ao driver clfs.sys no Event Log do Windows (System/Application), execução de processos incomuns por contas de usuário padrão imediatamente seguida por atividade em contexto SYSTEM, e criação/manipulação anômala de arquivos de log (.blf/.blg) por processos que normalmente não interagem com CLFS. Soluções de EDR com monitoramento de chamadas de kernel e comportamento pós-exploração (criação de processos privilegiados a partir de contexto de usuário limitado) têm mais chance de capturar a cadeia de ataque do que uma assinatura estática, dado que a PoC pública pode ser adaptada e variar em execução.