A exploração associada ao CVE-2017-0144 combina erros de conversão de atributos estendidos, parsing de transações SMB e controle de alocações no pool não paginado do núcleo.
| Componente | Implementação SMB do Windows no driver srv.sys, com exploração relacionada ao CVE-2017-0144 e ao boletim MS17-010. |
| Vetor | Conexões SMB contra sistemas Windows anteriores ao Windows 8, incluindo uso de sessão nula via IPC$ e sequências de transações SMB manipuladas. |
| Impacto | Escrita fora dos limites no pool não paginado do núcleo e execução remota de código quando a cadeia de exploração consegue controlar alocação, parsing e layout de memória. |
| Prioridade | Aplicar as correções do MS17-010, reduzir exposição de SMB e investigar tráfego com transações SMB inconsistentes, sessões anônimas e padrões de grooming no pool. |
| Artefatos | A exploração EternalBlue foi incluída no vazamento Lost in Translation, publicado pelo grupo The Shadow Brokers em 14 de abril de 2017, junto com outras ferramentas para SMB. |
| Mitigação | Corrigir sistemas vulneráveis, restringir acesso ao serviço SMB, revisar dependências legadas de sessão nula e correlacionar eventos de rede com estabilidade do serviço e falhas do núcleo. |
EternalBlue é uma cadeia de exploração voltada à implementação SMB do Windows e associada ao CVE-2017-0144, uma das vulnerabilidades tratadas no boletim MS17-010. O material técnico descreve uma exploração que não depende de uma única falha isolada: a execução remota de código surge da combinação de erros na conversão de estruturas de atributos estendidos, inconsistências no parsing de transações SMB e manipulação do layout de memória no pool não paginado do núcleo. O alvo central é o driver srv.sys, responsável por lidar com a parte de servidor do protocolo SMB em versões afetadas do Windows.
A exploração foi observada no conjunto vazado em 14 de abril de 2017 pelo grupo The Shadow Brokers, dentro do pacote Lost in Translation. O conjunto incluía o framework FuzzBunch, descrito como uma estrutura para configurar parâmetros de alvo e acionar ferramentas de exploração. O fato operacional mais relevante para defesa é que EternalBlue ficou associado a usos maliciosos posteriores, incluindo WannaCry, mas a análise técnica do mecanismo mostra que a superfície explorada está no tratamento de mensagens SMB e em pressupostos incorretos sobre tamanhos, formatos e continuidade de transações.
A primeira parte da cadeia está na conversão de FEA, ou File Extended Attributes, do formato OS/2 para o formato NT dentro da implementação SMB do Windows. Essas estruturas podem ser entendidas como pares de nome e valor que descrevem características de arquivo. Durante a conversão, funções do srv.sys calculam o tamanho necessário para uma lista NT e depois transformam registros OS/2 em registros NT. O problema descrito ocorre quando o campo SizeOfListInBytes, de tamanho DWORD, é tratado de forma incorreta em uma lógica de redução: apenas dois bytes são atualizados, deixando os bytes mais significativos intactos. Em vez de reduzir o tamanho usado pela conversão, a operação pode ampliá-lo em determinadas condições.
Esse erro cria uma divergência crítica entre o tamanho do buffer alocado e a quantidade de dados que o código passa a copiar. O tamanho de NtFeaList pode ser calculado para uma lista reduzida, enquanto o valor atualizado de SizeOfListInBytes indica que uma quantidade maior de registros deve ser convertida. A consequência é uma escrita fora dos limites no pool não paginado do núcleo. Como esse pool é usado por estruturas críticas do sistema, uma corrupção controlada nesse espaço pode permitir que a exploração influencie objetos adjacentes e avance para execução de código no contexto do núcleo.
A segunda parte envolve a forma como SMB divide dados grandes entre comandos primários e comandos secundários. O protocolo aceita operações como SMB_COM_TRANSACTION2 e SMB_COM_NT_TRANSACT, além de variantes secundárias usadas quando os dados excedem o que cabe em um único pacote ou quando o tamanho total declarado é maior que o conteúdo já transmitido. O ponto técnico decisivo é que SMB_COM_TRANSACTION2 representa determinados tamanhos em campos de palavra, enquanto SMB_COM_NT_TRANSACT usa campos de tamanho DWORD. A ausência de validação adequada sobre qual comando iniciou a transação permite uma sequência em que uma transação NT é seguida por uma secundária de Transaction2, levando o servidor a interpretar dados com a semântica errada.
Essa inconsistência de parsing ajuda a preparar a memória para a falha de conversão de FEA. A cadeia também usa um terceiro comportamento ligado a SMB_COM_SESSION_SETUP_ANDX, comando responsável por iniciar autenticação e estabelecer sessão SMB. Quando uma requisição é enviada como Extended Security com WordCount 12 e CAP_EXTENDED_SECURITY, mas sem FLAGS2_EXTENDED_SECURITY, a função BlockingSessionSetupAndX calcula ByteCount de modo incorreto e pode alocar uma área de tamanho controlado, maior que os dados reais do pacote. O resultado é uma primitiva útil para grooming do pool não paginado: a exploração cria buracos e posiciona estruturas para que a escrita fora dos limites alcance o objeto pretendido.
A superfície afetada é composta por sistemas Windows anteriores ao Windows 8 que executam o componente servidor SMB vulnerável. O contexto técnico destaca que essas versões aceitam uma área de comunicação interprocessos IPC$ com sessão nula, permitindo conexão anônima por padrão. Isso não significa que todo ambiente com SMB exposto terá exploração bem-sucedida em qualquer condição, mas estabelece uma pré-condição importante: o cliente consegue estabelecer uma sessão suficiente para enviar comandos SMB ao servidor e acionar caminhos de código complexos no srv.sys.
Do ponto de vista de inventário, a prioridade está em máquinas legadas que ainda aceitam SMB em redes internas, segmentos planos ou bordas mal filtradas. Servidores de arquivo, estáções antigas, appliances baseados em Windows legado e sistemas mantidos por compatibilidade operacional tendem a concentrar risco. A exploração não é descrita como roubo direto de dados no material recebido; o impacto técnico confirmado é corrupção de memória no núcleo e potencial execução remota de código. Qualquer consequência posterior, como instalação de malware ou propagação, depende da carga e do ambiente, não da vulnerabilidade isolada.
- Windows em versões anteriores ao Windows 8 com implementação SMB vulnerável no
srv.sys. - Serviços SMB que permitem conexão anônima ou sessão nula via
IPC$em ambientes legados. - Fluxos de rede que aceitam
SMB_COM_TRANSACTION2,SMB_COM_NT_TRANSACTe comandos secundários manipulados. - Hosts sem as correções do boletim
MS17-010aplicadas e validadas.
A investigação defensiva deve começar pela rede, porque a cadeia depende de tráfego SMB especialmente construído. O objetivo não é procurar um único pacote mágico, mas identificar combinações anômalas: sessões anônimas, uso de IPC$, transações grandes divididas em comandos secundários, alternância suspeita entre SMB_COM_NT_TRANSACT e SMB_COM_TRANSACTION2_SECONDARY, além de campos de tamanho que não fazem sentido quando comparados ao comando que iniciou a transação. Em sensores de rede, esses padrões são mais úteis quando correlacionados com o destino, a versão do sistema e a exposição do serviço.
No endpoint, a telemetria tende a aparecer de forma indireta. Como a corrupção ocorre no pool não paginado do núcleo, falhas do serviço, instabilidade do sistema, reinicializações inesperadas e eventos relacionados ao componente servidor SMB devem ser revisados quando coincidem com tráfego SMB incomum. Em ambientes com EDR ou coleta de eventos de sistema, vale correlacionar tentativas de conexão remota, autenticação anônima, criação de sessões SMB e alterações posteriores de processo ou serviço. O material recebido não fornece hashes, domínios, endereços IP ou nomes de cargas maliciosas específicos, portanto a caça deve se concentrar em comportamento de protocolo e exposição de hosts vulneráveis.
Para equipes de DFIR, a linha do tempo precisa separar tentativa de exploração, eventual execução remota e ação pós-exploração. EternalBlue descreve o caminho até execução no núcleo; persistência, movimentação, criptografia de arquivos ou comunicação de comando e controle só devem ser atribuídas quando houver evidência adicional. Essa separação evita conclusões incorretas e ajuda a priorizar contenção: primeiro confirmar se o host era vulnerável e recebeu tráfego compatível, depois verificar se houve execução anômala, criação de serviço, queda do sistema ou alteração persistente.
- Sessões SMB anônimas contra
IPC$em hosts legados ou não corrigidos. - Sequências em que
SMB_COM_NT_TRANSACTé seguido por comando secundário de Transaction2. - Campos de tamanho incompatíveis com o tipo de transação SMB observado.
- Falhas, reinicializações ou instabilidade próximas a tráfego SMB incomum.
- Atividade subsequente de processo ou serviço que indique execução remota após a tentativa de exploração.
A mitigação principal é aplicar e verificar as correções do MS17-010 nos sistemas afetados. Como a exploração depende de caminhos internos do srv.sys, controles compensatórios reduzem risco, mas não substituem correção quando o host permanece vulnerável. Em inventários antigos, a validação precisa incluir máquinas fora de domínio, imagens esquecidas, sistemas industriais ou servidores mantidos por dependência de aplicação. A presença de SMB em um host legado deve ser tratada como uma superfície crítica até que a versão, o nível de patch e a necessidade operacional estejam documentados.
A exposição de SMB deve ser reduzida ao mínimo necessário. Serviços que não precisam receber conexões SMB devem ser desativados ou filtrados; segmentos que precisam do protocolo devem limitar origem, destino e finalidade. Sessões nulas e dependências de IPC$ devem ser revisadas porque ampliam a capacidade de acionar caminhos de código antes de uma autenticação forte. Em redes internas, essa revisão é tão importante quanto na borda: o histórico de exploração de EternalBlue mostrou que a conectividade lateral via SMB aumenta rapidamente o alcance de uma falha remota quando existem muitos hosts antigos no mesmo domínio de broadcast ou em segmentos com filtragem permissiva.
Depois da correção, a validação deve combinar controle de configuração, telemetria e teste defensivo controlado. Não é necessário reproduzir payloads de exploração para confirmar redução de risco; basta verificar nível de atualização, exposição de portas SMB, políticas de sessão anônima, logs de acesso e alertas de transações anômalas. Caso haja suspeita de exploração anterior, a contenção deve preservar evidências de rede e endpoint, isolar sistemas vulneráveis, revisar alterações de serviço e processo, e reconstruir a linha do tempo sem assumir impacto além do que os artefatos sustentam.
- Aplicar as correções do
MS17-010e confirmar que o host não permanece em uma versão vulnerável. - Restringir SMB por segmentação, regras de firewall e necessidade operacional explícita.
- Eliminar ou limitar sessão nula e acesso anônimo a
IPC$quando não houver justificativa técnica. - Inventariar sistemas Windows anteriores ao Windows 8 e priorizar substituição ou isolamento.
- Correlacionar tráfego SMB suspeito com eventos de estabilidade, autenticação e execução no host.
0 Comentários