Windows Mark of the Web Security Feature Bypass Vulnerability

Falha na Mark of the Web (MOTW), o mecanismo do Windows que marca arquivos baixados da internet como não confiáveis e aciona proteções como o Protected View do Office e avisos do SmartScreen. Um atacante consegue entregar um arquivo malicioso que não recebe a marcação MOTW, fazendo com que ele abra sem os avisos e restrições esperadas. Está no catálogo KEV da CISA com exploração confirmada, mas o impacto direto é baixo (perda limitada de integridade/disponibilidade) — o risco real é servir de porta de entrada silenciosa para outra carga.

MOTW é um atributo de zona (Alternate Data Stream 'Zone.Identifier') que o Windows grava em arquivos originados da internet, de e-mail ou de outra máquina, sinalizando à Explorer, ao Office e ao SmartScreen que o conteúdo merece cautela. A CVE-2024-38217 é classificada pela CISA como CWE-693 (Protection Mechanism Failure): existe uma condição em que o sistema deixa de propagar ou de honrar essa marcação, permitindo que um arquivo hostil seja tratado como local/confiável.

A pesquisa da Elastic Security Labs sobre bypasses de SmartScreen/Smart App Control documenta uma técnica chamada 'LNK Stomping', que envolve manipulação de arquivos de atalho (.lnk) para escapar da marcação MOTW ou da verificação de reputação associada a ela. O texto da Elastic descreve o problema no contexto mais amplo de fraquezas de design em sistemas baseados em reputação (SmartScreen e Smart App Control), mas o detalhe técnico completo do LNK Stomping não está disponível nas fontes consultadas aqui — o que se sabe com segurança é que a falha reside na cadeia de verificação de zona/reputação que depende do MOTW estar corretamente presente e íntegro no arquivo.

O vetor CVSS (AV:N/AC:L/PR:N/UI:R) indica exploração remota, sem privilégios, com complexidade de ataque baixa, mas exigindo interação do usuário — ou seja, a vítima precisa abrir o arquivo manipulado. Não há elevação de privilégio nem execução direta de código pela falha em si; ela remove uma camada de aviso/contenção que normalmente precederia a execução de outro artefato malicioso.

O vetor prático é entrega de arquivo: phishing com anexo, download via navegador, ou arquivo recebido por outro canal que normalmente receberia a marcação de zona de internet. O atacante monta o arquivo (segundo a pesquisa disponível, envolvendo arquivos .lnk) de forma que o Windows não aplique ou não reconheça a MOTW nele. A vítima precisa executar/abrir o arquivo — não há exploração sem interação do usuário.

O ganho para o atacante não é execução de código pela vulnerabilidade em si, mas a supressão de camadas defensivas que dependem de MOTW: o Protected View do Microsoft Office deixa de forçar modo restrito, e avisos do SmartScreen/Smart App Control podem não disparar. Isso reduz a vulnerabilidade a um passo intermediário numa cadeia de ataque — tipicamente o primeiro estágio de um documento ou executável malicioso que, sem essa barreira, executa macros, scripts ou binários sem o atrito e os avisos que normalmente alertariam o usuário ou dariam tempo para detecção.

A CISA confirma exploração ativa (presença no KEV, prazo de correção 2024-10-01), mas não há indicação nas fontes de uso em campanhas de ransomware ('Known To Be Used in Ransomware Campaigns: Unknown'). O CVSS reflete isso: impacto classificado como baixo em confidencialidade/integridade/disponibilidade, mesmo com exploração confirmada — a gravidade real depende do que vem depois na cadeia de ataque.

A correção é aplicar a atualização de segurança da Microsoft referente a esta CVE, distribuída no ciclo de setembro de 2024. As fontes consultadas não trazem os números de build/KB específicos por versão do Windows, portanto confirme a build corrigida diretamente no Update Guide da MSRC para cada versão do seu parque (Windows 10 1507/1607/1809/21H2/22H2, Windows 11 21H2/22H2/22H3).

Como controle compensatório quando a atualização não é imediata: reforçar políticas de bloqueio de macro e Protected View no Office via GPO independentemente do MOTW (não delegar a decisão só ao atributo de zona), restringir a execução de arquivos .lnk vindos de fontes não confiáveis, e usar controles de e-mail/gateway que removam ou neutralizem anexos de atalho e scripts antes de chegarem ao usuário. Soluções de EDR com detecção comportamental independente de MOTW (por exemplo, monitorando abertura de LNK seguida de execução de interpretadores incomuns) cobrem parte da lacuna.

Não funciona como mitigação confiar apenas em SmartScreen ou Smart App Control como camada única: a pesquisa da Elastic mostra que ambos têm fraquezas de design mais amplas (assinatura de malware, hijacking de reputação, seeding de reputação, tampering) que independem desta CVE específica — tratar MOTW/SmartScreen como controle definitivo é o erro mais comum observado.

Não há assinatura de rede confiável para detectar exploração, já que a falha ocorre localmente na verificação de atributo de zona do arquivo, não em tráfego. Em ambiente de SOC, monitore a ausência do stream Zone.Identifier em arquivos que deveriam tê-lo (recebidos por e-mail, download ou SMB de origem externa) e correlacione com abertura subsequente de arquivos .lnk seguida de execução de processos interpretadores (script hosts, PowerShell, mshta, etc.) sem o aviso esperado do SmartScreen ou do Protected View — a ausência desses avisos onde normalmente ocorreriam é o indício mais forte, mas exige telemetria de EDR e não apenas logs padrão do Windows.