Microsoft recua e diz que nao processara pesquisadores apos polemica com Nightmare Eclipse

A Microsoft recuou publicamente da postura adotada na semana passada e declarou não ter “intenção de tomar medidas legais” contra pesquisadores de segurança que descobrem e publicam vulnerabilidades. O recuo veio após uma forte reação da comunidade de segurança a um post oficial que classificou divulgações não coordenadas como “nunca justificáveis” e mencionava a possibilidade de ação da Digital Crimes Unit, em meio à polêmica gerada pelo pesquisador pseudônimo Nightmare Eclipse.

O que aconteceu

Na semana anterior, a Microsoft havia publicado um texto institucional condenando uma série recente de divulgações de zero-days no Windows feitas sem coordenação prévia com a empresa. O post afirmava que a Digital Crimes Unit (DCU) — braço jurídico-técnico da empresa historicamente usado para combate a operadores de botnets e atores de ameaça — “continuaria a abrir casos” contra indivíduos que estivessem habilitando atividade criminosa.

Embora o texto não citasse nomes, a leitura imediata da comunidade foi de que o alvo era Nightmare Eclipse, pseudônimo do pesquisador que publicou os exploits e que vinha denunciando publicamente o que descreve como abusos sofridos no relacionamento com o Microsoft Security Response Center (MSRC), incluindo a alegada exclusão de sua conta no programa e a retenção de pagamentos de bug bounty.

Após uma onda de críticas de pesquisadores influentes, a empresa publicou — desta vez em redes sociais, fora do blog oficial — uma declaração suavizando o tom: “Para deixar claro nossa abordagem em questões legais, não temos intenção de tomar medidas contra indivíduos que conduzem ou publicam pesquisa de segurança.”

Os detalhes do recuo

A nova declaração mantém uma ressalva relevante: “Quando um indivíduo viola a lei e se envolve em atividade maliciosa causando dano real aos nossos clientes, trabalharemos com as autoridades quando apropriado.” A Microsoft também reconheceu falhas internas, admitindo que “algumas interações ficaram aquém” e que a empresa estaria “trabalhando para aprender” com esses incidentes — sem, no entanto, endereçar diretamente as alegações específicas de Nightmare Eclipse.

Talvez o sinal semântico mais forte do recuo seja a substituição do termo “responsible disclosure” (divulgação responsável), que aparecia quatro vezes no post original, pelo termo “Coordinated Vulnerability Disclosure” (divulgação coordenada de vulnerabilidades). A própria Microsoft adotou em 2010 a expressão “coordinated” justamente para evitar a conotação de que pesquisadores que agem por conta própria seriam “irresponsáveis”.

“Nenhum fornecedor usa esse termo a menos que queira chamar alguém de irresponsável”, escreveu Katie Moussouris, que ajudou a aposentar a expressão “responsible disclosure” enquanto trabalhava na própria Microsoft.

O contexto técnico

Em paralelo ao recuo da Microsoft, Nightmare Eclipse anunciou em seu próprio blog que outros pesquisadores passaram a contatá-lo após o episódio, em alguns casos entregando vulnerabilidades diretamente. O pesquisador afirma que uma nova falha em Secure Boot será divulgada ainda em junho. Segundo ele, o bug “burla completamente o BitLocker” e pode ser usado para comprometer sistemas, o que, se confirmado, representaria um vetor sério para ataques de evil-maid e exfiltração de dados em dispositivos roubados.

Quem é afetado

• Pesquisadores independentes que dependem de previsibilidade jurídica para conduzir trabalho de hardening sobre produtos Microsoft.
• Programas de bug bounty e equipes de coordenação interna do MSRC, que terão de reconstruir confiança com a comunidade.
• Administradores de sistemas Windows, que podem ter de lidar com novos exploits de Secure Boot e bypass de BitLocker divulgados sem janela de patch.
• Organizações com requisitos de criptografia em disco para conformidade (saúde, governo, setor financeiro), que precisam acompanhar o ciclo de divulgações.

Análise

O episódio é um dos mais expressivos casos recentes de atrito público entre uma big tech e a comunidade de pesquisa em segurança ofensiva. A reação rápida da Microsoft mostra três coisas. Primeira, que o capital político de empresas com programas de bounty é frágil: uma única linha mal calibrada na comunicação pública é capaz de detonar dias de manchetes negativas e mobilizar contra a empresa pesquisadores que historicamente foram parceiros. Segunda, que a tensão entre divulgação coordenada e full disclosure não foi resolvida — apenas adormecida — e ressurge sempre que há percepção de tratamento abusivo de pesquisadores. Terceira, que o efeito prático tende a ser contraproducente para o vendor: o próprio Nightmare Eclipse afirma ter ganhado mais colaboradores após a polêmica, o que sugere uma aceleração — e não uma redução — do ritmo de divulgações.

Há ainda um elemento de continuidade histórica. A tensão entre vendors e pesquisadores remonta a episódios emblemáticos como o caso Mike Lynn vs. Cisco em 2005 e os litígios de DMCA contra pesquisadores de DRM nos anos 2000. A diferença é que, em 2026, com supply-chain attacks e zero-days em plataformas críticas como vetor preferencial de atores estatais, a relação custo-benefício de ameaçar publicamente um pesquisador é assimétrica: o vendor perde mais reputação do que ganha em controle de narrativa.

Recomendações práticas

• Equipes que mantêm parques Windows críticos devem acompanhar os boletins oficiais e canais não oficiais (incluindo o blog de Nightmare Eclipse) para se preparar para a possível divulgação do bypass de Secure Boot/BitLocker em junho.
• Reforçar políticas físicas: bloqueio automático de tela curto, criptografia de disco com PIN no boot do TPM, controle de portas USB e proibição de boot externo no setup.
• Para responsáveis por programas internos de bug bounty, revisar os SLAs de resposta, transparência sobre pagamentos e processo de escalonamento — a desconfiança no MSRC é um sinal de alerta para qualquer programa similar.
• Manter inventário atualizado de endpoints que dependem de BitLocker como única camada de proteção em caso de perda ou roubo do dispositivo.
• Documentar internamente a política de divulgação aceita pela organização e instruir profissionais de segurança sobre canais oficiais antes de pesquisas externas.

Fonte: The Record (Recorded Future News)