CrowdStrike: o dia que uma atualização causou 8,5 mi de BSODs

Eram 04h09 do dia 19 de julho de 2024 quando um arquivo de 40 KB saiu dos servidores da CrowdStrike em direção a milhões de computadores ao redor do mundo. Setenta e oito minutos depois, hospitais travavam, aviões não decolavam e terminais de aeroporto exibiam a tela azul mais famosa da computação. Sem hacker. Sem ransomware. Sem invasão. Um único campo errado em um arquivo de configuração bastou para produzir o maior apagão cibernético já registrado.

Dois anos depois, o incidente ainda rende processos judiciais, debates sobre acesso de kernel e mudanças nas práticas de atualização de software de segurança em toda a indústria.

O que aconteceu

A CrowdStrike é uma das principais empresas de cibersegurança corporativa do mundo. Seu produto Falcon Sensor funciona como um agente instalado em profundidade no Windows — com permissão de kernel, ou seja, acesso ao núcleo do sistema operacional. Isso permite detecção precoce de ameaças, mas também significa que qualquer falha no agente pode derrubar o sistema inteiro.

Às 04h09 UTC de 19 de julho de 2024, a empresa publicou uma atualização de conteúdo chamada Channel File 291. Era uma atualização de rotina — o tipo lançado várias vezes por semana para ensinar o sensor a reconhecer novas ameaças. Às 05h27 UTC, 78 minutos depois, a equipe identificou o problema e retirou o arquivo dos servidores.

Os danos já estavam feitos.

A causa técnica: um campo a menos

O que o Channel File 291 fez de errado?

O arquivo foi publicado com 20 campos de entrada, mas o driver esperava 21. Quando o interpretador de conteúdo do Falcon tentou processar o 21º campo — que era um critério de correspondência não-curinga novo nessa versão — leu uma posição de memória fora dos limites do array. O Windows detectou o acesso inválido ao kernel e fez o único que podia: tela azul da morte (BSOD) e reinicialização.

O problema estava no driver CSagent.sys, que roda no kernel do Windows como filtro de sistema de arquivos. Ao tentar interpretar o Channel File 291, ele realizava um out-of-bounds read — leitura fora do espaço de memória alocado — e causava uma falha de página inválida. O resultado é o BSOD clássico, seguido de reinicialização automática.

Só que ao reiniciar, o sistema carregava o arquivo corrompido de novo. E travava de novo. Loop infinito de tela azul.

O próprio root cause analysis publicado pela CrowdStrike em agosto de 2024 confirmou: o IPC Template Type usado pelo Channel File 291 definia 21 campos de entrada, mas o código do sensor fornecia apenas 20 durante a validação prévia.

O impacto: 8,5 milhões de PCs, 5 mil voos, US$ 5,4 bilhões

A Microsoft estimou que aproximadamente 8,5 milhões de dispositivos Windows foram afetados — menos de 1% do total de Windows no mundo, mas concentrados exatamente nas empresas que usam segurança corporativa de ponta: hospitais, bancos, companhias aéreas, emissoras de TV, governos.

O impacto foi imediato e documentado:

• 5.078 voos cancelados — 4,6% de todos os voos programados para aquele dia no mundo
• Delta Air Lines: mais de 7.000 voos cancelados nos dias seguintes, prejuízo declarado de US$ 500 milhões
• Bancos e bolsas de valores com sistemas fora do ar em múltiplos países
• Hospitais revertendo para papel e caneta em triagens de emergência
• Emissoras como a Sky News com BSOD visível ao vivo na transmissão

No Brasil, conforme reportado pela Gazeta do Povo e CNN Brasil, o impacto foi mais contido mas real: os bancos Bradesco, Banco do Brasil, Neon, Next e Banco Pan registraram instabilidades. Aeroportos relataram atrasos em sistemas de check-in. A Anac e sistemas governamentais operaram em modo de contingência.

O custo total estimado para as empresas afetadas chegou a US$ 5,4 bilhões (cerca de R$ 30,5 bilhões na época), segundo levantamento da seguradora Parametrix. A Delta entrou com ação judicial contra a CrowdStrike — processo que ainda corre nos EUA.

Por que a recuperação levou dias?

Por que não dava para resolver remotamente?

Porque o computador não subia o sistema operacional. Para aplicar a correção, o técnico precisava fisicamente iniciar a máquina no Modo de Segurança (Safe Mode) ou no Windows Recovery Environment, navegar até a pasta C:\Windows\System32\drivers\CrowdStrike</code> e deletar manualmente o arquivo C-00000291*.sys.

Simples em teoria. Inviável em escala quando data centers têm milhares de servidores e laptops de funcionários estão espalhados por aeroportos do mundo inteiro.

A complicação extra: empresas que usavam BitLocker para criptografar os drives precisavam da chave de recuperação antes de entrar no modo seguro. Para quem não tinha essa chave documentada e acessível fora do próprio sistema, a recuperação começava do zero. A Delta estimou que retomou operações normais apenas quase uma semana depois do incidente.

O que o 19 de julho ensinou

O incidente CrowdStrike não foi um ataque. Não foi negligência das equipes de TI nas empresas afetadas. Foi um erro de processo dentro de uma empresa de segurança respeitada — e isso é, de certa forma, mais revelador do que a maioria dos ataques reais.

As lições que a indústria passou a debater com mais seriedade:

• Atualizações de kernel precisam de rollout gradual, não distribuição global simultânea para todos os clientes
• Conteúdo de configuração não é menos crítico que código executável — o Channel File 291 não passou por validação adequada antes da publicação
• Plano de recuperação precisa incluir acesso físico offline — depender exclusivamente de gerenciamento remoto é uma vulnerabilidade sistêmica
• Chaves de BitLocker devem estar documentadas e acessíveis fora do sistema que protegem

Esse tipo de dependência em um único fornecedor — o que a indústria chama de single point of failure — já tinha aparecido antes. Nos ataques do WannaCry em 2017, o vetor também foi uma propagação em escala industrial por sistemas que as empresas confiavam plenamente. No NotPetya, o ransomware se espalhou via atualização legítima de um software contábil ucraniano — um mecanismo estruturalmente idêntico ao da CrowdStrike, mas com intenção maliciosa.

A diferença do 19 de julho: não havia atacante. O dano foi acidental. E mesmo assim chegou a US$ 5,4 bilhões.

Dois anos depois: o que mudou

A CrowdStrike sobreviveu ao incidente. Perdeu contratos, caiu mais de 30% na bolsa nas semanas seguintes, mas continua como referência em EDR corporativo. George Kurtz, CEO, pediu desculpas publicamente e anunciou reestruturação nos processos de QA — incluindo rollout em fases, validação adicional de arquivos de configuração e sandbox interno antes de distribuição massiva.

O debate mais amplo, no entanto, é o que ficou de legado real: a Microsoft anunciou nos meses seguintes que trabalharia para disponibilizar APIs de nível mais baixo para que ferramentas de segurança operem fora do kernel do Windows. Menos risco de um único driver derrubar o sistema inteiro — mas também menos visibilidade para detectar ameaças sofisticadas. Um trade-off sem resposta fácil.

O 19 de julho de 2024 garantiu que esse debate não fosse ignorado por mais uma década.

Se quiser entender como se preparar para que um evento assim — ataque real ou falha acidental — não paralise sua infraestrutura, o guia de resposta a incidentes traz os passos práticos de contenção, backup e recuperação que valem tanto para ransomware quanto para um BSOD em escala global.