Segredos nos logs: falha no Windows expõe arquivos sensíveis

Imagine o seguinte: você tem um diário trancado numa gaveta, mas, toda vez que você escreve algo lá, uma cópia aparece colada na porta da geladeira da casa. Bizarro, né? Pois é mais ou menos isso que aconteceu com o sistema de arquivos NTFS do Windows nessa vulnerabilidade que foi catalogada como CVE-2025-24984.

Essa CVE é um caso de “inserção indevida de informações sensíveis em arquivos de log” – uma falha na qual o sistema, sem querer querendo, escreve dados delicados em lugares onde eles não deveriam aparecer. E o pior: não é um ataque remoto. Isso quer dizer que qualquer um com acesso físico ao computador pode explorar. Um risco real em ambientes corporativos ou qualquer lugar onde computadores sejam compartilhados ou possam ser acessados por terceiros.

Vamos destrinchar isso tudo agora.

O que é o NTFS e por que ele é importante?

Antes de falar da falha, vamos entender o NTFS (New Technology File System). Ele é o sistema de arquivos padrão do Windows desde os tempos gloriosos do Windows NT. Seu papel? Organizar, armazenar, indexar, e proteger os dados no disco. Ele é tipo aquele bibliotecário supercontrolador que sabe onde cada livro está, quem pegou, e quando deve voltar.

O NTFS é repleto de recursos avançados como:

• Permissões por arquivo e pasta (ACLs)

• Journaling (registro de alterações para evitar corrupção de dados)

• Compressão e criptografia nativas

• Cotas de disco por usuário

• Links simbólicos, hardlinks e transações de arquivos

Mas com grandes poderes vêm grandes responsabilidades… e grandes chances de alguém deixar escapar informação onde não devia.

Arquivos de Log no NTFS

O NTFS mantém um componente chamado NTFS Log File (ou $LogFile). Ele é utilizado para registrar transações e mudanças no sistema de arquivos. Esse registro é essencial para recuperar dados em caso de falha repentina – tipo quando a luz acaba e seu PC desliga.

Esse log funciona como um diário das operações:

• Criação de arquivos e pastas

• Modificações de metadados

• Renomeações, deleções, mudanças de permissão

Agora, aqui está o problema: o Windows deveria registrar apenas o necessário nesses logs, como metadados e identificadores. Mas no caso da CVE-2025-24984, informações sensíveis estão indo parar ali sem filtro.

CWE-532 – A categoria da falha

A vulnerabilidade foi classificada como um caso de CWE-532 – Insertion of Sensitive Information into Log File.

Isso significa que:

Um software registra dados sensíveis, como senhas, tokens de autenticação, ou nomes de arquivos confidenciais em arquivos de log que podem ser acessíveis por outras partes do sistema.

Traduzindo: o sistema está “falando demais” nos bastidores e deixando rastros que um atacante pode seguir.

Como a falha acontece: Passo a Passo técnico

Agora vamos para o backstage real da falha. O NTFS, durante certas operações como:

• Criação de arquivos temporários (ex: .tmp, .log)

• Movimentação de arquivos protegidos

• Copiando arquivos com atributos de segurança (como ACLs específicas ou criptografados via EFS)

...acaba logando mais do que devia. Em vez de registrar só o caminho genérico do arquivo, ele acaba incluindo:

• O nome real do arquivo

• Trechos de conteúdo

• Dados de ACL

• Às vezes até identificadores de usuário ou sessões criptográficas

Tudo isso vai parar no $LogFile, no $UsnJrnl (Change Journal) ou em arquivos temporários utilizados no processo.

Por que isso é perigoso mesmo não sendo remoto?

Aí você pode pensar: “Ué, mas precisa de acesso físico, então não é tão grave, né?”.

Depende. Em ambientes como:

• Universidades

• Escritórios com computadores compartilhados

• Postos de trabalho sem controle de acesso

• Máquinas usadas em atendimento público

...o acesso físico não é nada difícil. Um pendrive com um Linux live boot + ferramenta de forense pode tirar essas informações em minutos.

Pior ainda: esse tipo de vazamento pode ser usado como etapa auxiliar em ataques maiores, como:

• Descobrir o nome de arquivos e onde estão

• Identificar usuários com privilégios

• Mapear comportamento da máquina

• Obter arquivos deletados sensíveis

Esses arquivos podem ser acessíveis via:

• Ferramentas como o Sysinternals, que analisam logs

• Comandos de linha como fsutil usn readjournal

• Programas forenses que varrem setores não alocados

Um atacante com uma simples conta de usuário, se conseguir ler essas estruturas, pode vasculhar informações privadas, como arquivos recém-apagados, nomes de documentos sigilosos, ou até mesmo caminhos internos de arquivos que deveriam estar criptografados ou restritos.

Como descobriram

Toda falha tem sua origem — e geralmente vem acompanhada de alguém curioso, habilidoso e ligeiramente desconfiado.

Pesquisadores de segurança começaram a perceber um comportamento estranho em sistemas NTFS ao realizar análises forenses em arquivos de log ($LogFile) e do Change Journal ($UsnJrnl). Eles notaram que detalhes demais estavam sendo gravados, inclusive nomes de arquivos criptografados, dados de arquivos temporários e até identificadores internos.

Como qualquer bom profissional da segurança faria, eles começaram a fazer engenharia reversa no driver ntfs.sys, que é o coração do sistema de arquivos NTFS no Windows. Ao investigar como o driver lida com operações de I/O, notaram uma falta de sanitização nos buffers de escrita para o log.

Ou seja, na hora de registrar algo no log, o sistema apenas “despejava” os dados, sem filtrar campos sensíveis.

Descoberta prática: Criando arquivos criptografados com nomes específicos (como senhas ou tokens), deletando-os, e lendo o Change Journal logo depois, os pesquisadores conseguiam recuperar o nome original do arquivo — algo que não deveria acontecer.

Como a Microsoft corrigiu isso?

Com a divulgação da vulnerabilidade, a Microsoft entrou em ação (um pouco devagar, como sempre). A correção foi entregue através de um patch de segurança no Windows Update.

A correção teve três frentes:

1. Sanitização dos logs: O ntfs.sys foi atualizado para garantir que informações sensíveis (nomes, conteúdo, ACLs) sejam omitidas ou substituídas por identificadores genéricos antes de serem gravadas nos logs.

2. Permissões mais restritas: As permissões de leitura de logs como $LogFile e $UsnJrnl foram reforçadas para que apenas administradores ou processos de sistema possam acessá-los.

3. Correção retroativa parcial: O update também remove ou limpa entradas antigas de log após o patch, minimizando a exposição residual de informações já registradas antes da correção.

Como se proteger na prática?

Mesmo com a correção, boas práticas de segurança continuam sendo essenciais. Aqui vão algumas recomendações:

1.  Aplique o patch imediatamente

• Se ainda não fez isso, vá ao Windows Update e atualize seu sistema.

• Para sysadmins: use WSUS, Intune ou GPO para forçar o update em ambientes corporativos.

2. Criptografia de disco completa

• Use BitLocker para proteger todo o volume.

• Isso garante que mesmo com acesso físico, o atacante não consiga montar ou analisar a partição NTFS.

3.  Monitore acessos locais

• Instale ferramentas como Sysmon para registrar quem está acessando arquivos de log ou executando comandos suspeitos no terminal.

4. Apague artefatos sensíveis com cuidado

• Não apenas “delete” arquivos. Use ferramentas de wipe seguro (como sdelete) para garantir que o conteúdo e os metadados não fiquem no disco.

5. Controle rigoroso de acesso físico

• Use cadeados, biometria, salas separadas, proteção por BIOS/UEFI e boot via senha. Às vezes o básico salva o dia.

Cenário prático de ataque: "O estagiário curioso"

Vamos a um pequeno exemplo.

Cenário:

• Davi, estagiário de TI, tem acesso físico aos computadores da empresa para fazer manutenção.

• Um dia, ele leva um pendrive com um Linux live e faz boot numa máquina desligada, fora do horário.

• Ele usa ferramentas como ntfs-3g e logfile-parser para montar a partição e começar a fuçar.

Passos do ataque:

1. Monta a partição NTFS com permissões de leitura.

2. Acessa os logs brutos do $LogFile e $UsnJrnl.

3. Usa scripts para extrair strings legíveis e identificar nomes de arquivos.

4. Descobre:

   • “senha-admin-contas-financeiras.xlsx”

   • “login-nuvem-tokens.txt”

   • E outros nomes reveladores que nunca deveriam estar ali.

5. A partir disso, ele:

   • Sabe o que procurar na rede ou backups.

   • Pode escalar privilégios se descobrir nomes de usuários sensíveis.

   • Obtém vantagem para ataques internos, chantagens ou exfiltração de dados.

Tudo isso sem nem precisar logar no sistema operacional do Windows. Terrível? Bastante. Possível? Totalmente.

Conclusão

A CVE-2025-24984 é mais um lembrete de que logs são armas de dois gumes. Eles ajudam a depurar, analisar, recuperar... mas também podem ser grandes vazadores.

• Se você é desenvolvedor, nunca logue dados sensíveis.

• Se você é sysadmin, revise permissões e políticas de logging.

• E se você é um curioso como os pesquisadores que descobriram essa falha... continue assim. Bom trabalho!