CrowdStrike: el día que una actualización causó 8,5 millones de BSOD

Eran las 04:09 del 19 de julio de 2024 cuando un archivo de 40 KB salió de los servidores de CrowdStrike rumbo a millones de ordenadores en todo el mundo. Setenta y ocho minutos después, los hospitales se bloqueaban, los aviones no despegaban y las terminales de los aeropuertos mostraban la pantalla azul más famosa de la informática. Sin hacker. Sin ransomware. Sin intrusión. Un único campo mal definido en un archivo de configuración bastó para producir el mayor apagón cibernético jamás registrado.

Dos años después, el incidente todavía genera procesos judiciales, debates sobre el acceso a nivel de kernel y cambios en las prácticas de actualización de software de seguridad en toda la industria.

Qué pasó

CrowdStrike es una de las principales empresas de ciberseguridad corporativa del mundo. Su producto Falcon Sensor funciona como un agente instalado en profundidad en Windows, con permisos de kernel, es decir, acceso al núcleo del sistema operativo. Esto permite una detección temprana de amenazas, pero también significa que cualquier fallo en el agente puede tumbar el sistema entero.

A las 04:09 UTC del 19 de julio de 2024, la empresa publicó una actualización de contenido llamada Channel File 291. Era una actualización de rutina, del tipo que se lanza varias veces por semana para enseñar al sensor a reconocer nuevas amenazas. A las 05:27 UTC, 78 minutos después, el equipo identificó el problema y retiró el archivo de los servidores.

El daño ya estaba hecho.

La causa técnica: un campo de menos

¿Qué hizo mal el Channel File 291?

El archivo se publicó con 20 campos de entrada, pero el driver esperaba 21. Cuando el intérprete de contenido de Falcon intentó procesar el campo 21, que era un criterio de coincidencia no comodín nuevo en esa versión, leyó una posición de memoria fuera de los límites del array. Windows detectó el acceso inválido al kernel e hizo lo único que podía hacer: pantalla azul de la muerte (BSOD) y reinicio.

El problema estaba en el driver CSagent.sys, que se ejecuta en el kernel de Windows como filtro del sistema de archivos. Al intentar interpretar el Channel File 291, realizaba una lectura fuera de límites (out-of-bounds read), fuera del espacio de memoria asignado, y causaba un fallo de página inválido. El resultado es el clásico BSOD, seguido de un reinicio automático.

Solo que, al reiniciar, el sistema volvía a cargar el archivo corrupto. Y se bloqueaba de nuevo. Bucle infinito de pantalla azul.

El propio análisis de causa raíz publicado por CrowdStrike en agosto de 2024 lo confirmó: el IPC Template Type usado por el Channel File 291 definía 21 campos de entrada, pero el código del sensor solo aportaba 20 durante la validación previa.

El impacto: 8,5 millones de PC, 5.000 vuelos, 5.400 millones de dólares

Microsoft estimó que aproximadamente 8,5 millones de dispositivos Windows se vieron afectados, menos del 1% del total de Windows en el mundo, pero concentrados justo en las empresas que usan seguridad corporativa de punta: hospitales, bancos, aerolíneas, cadenas de televisión, gobiernos.

El impacto fue inmediato y quedó documentado:

• 5.078 vuelos cancelados: el 4,6% de todos los vuelos programados ese día en el mundo
• Delta Air Lines: más de 7.000 vuelos cancelados en los días siguientes, pérdidas declaradas de 500 millones de dólares
• Bancos y bolsas de valores con sistemas fuera de línea en múltiples países
• Hospitales volviendo a papel y bolígrafo en triajes de emergencia
• Cadenas como Sky News con la pantalla azul visible en directo durante la transmisión

En Brasil, según reportaron Gazeta do Povo y CNN Brasil, el impacto fue más contenido pero real: los bancos Bradesco, Banco do Brasil, Neon, Next y Banco Pan registraron inestabilidad. Los aeropuertos reportaron retrasos en los sistemas de check-in. La Anac y sistemas gubernamentales operaron en modo de contingencia.

El coste total estimado para las empresas afectadas llegó a 5.400 millones de dólares (alrededor de 30.500 millones de reales en la época), según un estudio de la aseguradora Parametrix. Delta presentó una demanda contra CrowdStrike, proceso que todavía está en curso en EE. UU.

¿Por qué la recuperación tardó días?

¿Por qué no se podía resolver de forma remota?

Porque el ordenador no llegaba a arrancar el sistema operativo. Para aplicar la corrección, el técnico tenía que iniciar físicamente la máquina en Modo Seguro (Safe Mode) o en el Windows Recovery Environment, navegar hasta la carpeta C:\Windows\System32\drivers\CrowdStrike</code> y borrar manualmente el archivo C-00000291*.sys.

Simple en teoría. Inviable a escala cuando los centros de datos tienen miles de servidores y los portátiles de los empleados están repartidos por aeropuertos de todo el mundo.

La complicación extra: las empresas que usaban BitLocker para cifrar los discos necesitaban la clave de recuperación antes de entrar en modo seguro. Para quien no tenía esa clave documentada y accesible fuera del propio sistema, la recuperación empezaba desde cero. Delta estimó que retomó las operaciones normales casi una semana después del incidente.

Lo que enseñó el 19 de julio

El incidente de CrowdStrike no fue un ataque. No fue negligencia de los equipos de TI de las empresas afectadas. Fue un error de proceso dentro de una empresa de seguridad respetada, y eso es, en cierto modo, más revelador que la mayoría de los ataques reales.

Las lecciones que la industria empezó a debatir con más seriedad:

• Las actualizaciones de kernel necesitan un despliegue gradual, no una distribución global simultánea para todos los clientes
• El contenido de configuración no es menos crítico que el código ejecutable: el Channel File 291 no pasó por una validación adecuada antes de publicarse
• El plan de recuperación tiene que incluir acceso físico offline: depender exclusivamente de la gestión remota es una vulnerabilidad sistémica
• Las claves de BitLocker deben estar documentadas y accesibles fuera del sistema que protegen

Este tipo de dependencia de un único proveedor, lo que la industria llama single point of failure, ya había aparecido antes. En los ataques de WannaCry en 2017, el vector también fue una propagación a escala industrial por sistemas en los que las empresas confiaban plenamente. En NotPetya, el ransomware se propagó a través de una actualización legítima de un software contable ucraniano, un mecanismo estructuralmente idéntico al de CrowdStrike, pero con intención maliciosa.

La diferencia del 19 de julio: no había atacante. El daño fue accidental. Y aun así llegó a 5.400 millones de dólares.

Dos años después: qué cambió

CrowdStrike sobrevivió al incidente. Perdió contratos, cayó más de un 30% en bolsa en las semanas siguientes, pero sigue siendo una referencia en EDR corporativo. George Kurtz, su CEO, pidió disculpas públicamente y anunció una reestructuración en los procesos de QA, incluyendo despliegue por fases, validación adicional de archivos de configuración y sandbox interno antes de la distribución masiva.

El debate más amplio, sin embargo, es el que quedó como legado real: Microsoft anunció en los meses siguientes que trabajaría para ofrecer API de nivel más bajo para que las herramientas de seguridad operen fuera del kernel de Windows. Menos riesgo de que un único driver tumbe todo el sistema, pero también menos visibilidad para detectar amenazas sofisticadas. Una disyuntiva sin respuesta fácil.

El 19 de julio de 2024 garantizó que ese debate no se ignorara durante otra década.

Si quieres entender cómo prepararte para que un evento así, ataque real o fallo accidental, no paralice tu infraestructura, la guía de respuesta a incidentes trae los pasos prácticos de contención, copia de seguridad y recuperación que sirven tanto para ransomware como para un BSOD a escala global.