Cuando trabajas en ciberseguridad, que suene tu móvil un viernes suele significar malas noticias. Los cibercriminales conocen nuestros ritmos de trabajo y saben en qué días tienen más probabilidades de éxito. Por eso, muchos ciberincidentes ocurren en viernes. Y nos temimos lo peor cuando el 19 de julio el teléfono no dejaba de vibrar.

Aquí empiezan las buenas noticias. Primero, el teléfono no vibraba por una llamada del CERT de GMV, su servicio de monitorización de seguridad y respuesta a incidentes 7x24. Recibimos estas llamadas cuando hay un ciberincidente que está afectando al propio GMV o a alguno de sus clientes y nuestros compañeros del CERT deben avisar de que está ocurriendo. Así que probablemente no fuera un incidente grave, lo que nos daba tiempo a una respuesta más meditada y fácil de aplicar. 

La segunda buena noticia es que el origen del sonido del móvil correspondía a las comunicaciones internas propias de la actividad de un CERT. Es decir, que en el fondo sí que estaban pasando cosas pero que las estábamos detectando y que tendríamos capacidad de respuesta temprana si el asunto se ponía serio. No obstante, el volumen de estas comunicaciones era significativamente alto y merecía la pena investigarlo. Se trataba en todos los casos de datos muy distintos a los que habitualmente analiza el CERT. Algunos equipos y servicios que están siendo vigilados por el CERT estaban completamente parados. En realidad, bastantes. Ninguno de ellos era de GMV sino de algunos de sus clientes monitorizados. El equipo del CERT ya estaba investigando este punto para encontrar los patrones de potenciales ataques o fallos en los sistemas de transferencia de información. 

Mientras tanto, en paralelo, estaban llegando otras noticias. Los profesionales de la ciberseguridad siempre hablamos del valor de las redes de colaboración y cooperación. Algunos de los marcos de controles de seguridad más difundidos establecen requisitos específicos para crear, unirse y participar en estas redes de colaboración. El viernes 19 de julio estas redes demostraron su valor. Varios grupos de colaboración establecidos en redes sociales bullían de actividad. Se habían detectado problemas en servidores y puestos de usuario equipados con el software EDR del fabricante Crowdstrike. Estos equipos no respondían ni estaban activos. Algunos participantes compartían que los equipos estaban dando uno de los fallos más temibles en un equipo Windows, una pantalla azul. Estas pantallas azules ocurren cuando el estado de un equipo Windows es inestable y el sistema operativo no se puede ejecutar correctamente. Se para el equipo como medida de seguridad, mostrando en la pantalla completamente azul un mensaje de error con la causa detectada del problema. Lo que parecía raro era que estuviera ocurriendo simultáneamente en muchas organizaciones a nivel mundial y en todos los tipos de equipos. Aparentemente, todos estos equipos tenían instalado el mismo software EDR. Había una pista de investigación clara. 

Afortunadamente, la teoría se confirmó en poco tiempo. El fabricante Crowdstrike comunicaba oficialmente a las 07:30 hora española a través de su portal de soporte la existencia de una alerta técnica sobre su producto “Falcon Sensor”, que es el agente que se despliega en todos los equipos que está protegiendo. Esta alerta técnica señalaba la existencia de un error en el agente que causaba un fallo en el sistema Windows y provocaba la pantalla azul.

A través de estas redes también se empezaron a difundir algunas posibles soluciones, aplicando una solución temporal (un workaround). La solución pasaba por arrancar el equipo en modo “A prueba de fallos”, y luego eliminar manualmente un fichero llamado ““C-00000291-*.sys”. Crowdstrike reconocería que este fichero correspondía con una actualización que habían realizado a las 04:09 UTC (06:09 de España) que contenía este fichero erróneo que provocaba el fallo.

En este momento, el CERT ya estaba trabajando con los clientes afectados, validando potenciales soluciones y adaptando los sistemas de monitorización ante la avalancha de alertas. Eran más buenas noticias en mitad de un viernes con un inicio tan poco prometedor: 

• El posible ciberataque se debía a un fallo de operación y no a la acción de un ataque malicioso, por lo que la resolución del ciberincidente pasaría por resolver el error existente sin tener que preocuparse de la reacción del atacante antes nuestras acciones de contención, respuesta y recuperación.

• Había un candidato claro a ser el origen del error: el autor del error lo había reconocido, había ofrecido una explicación que correspondía con lo que estábamos viendo en GMV y también otros actores, y teníamos una línea de actuación sólida para resolverlo.

• Todo ello había ocurrido en un periodo de minutos, por lo que el incidente tenía una solución rápida. De hecho, ya se estaba empezando a implantar.

• La comunicación estaba siendo clara y fluida, en todos los sentidos, compartiendo toda la información posible, cumpliendo los compromisos de confidencialidad a los que nos debemos.

Sin embargo, no todo eran buenas noticias. Otras organizaciones sí estaban sufriendo intensamente el problema, con la práctica de sus sistemas y servicios afectados, y con su actividad paralizada. Surgían algunos nombres de organizaciones señeras y de operadores de infraestructuras críticos afectados. Un compañero de GMV que estaba teletrabajando le comentó a su familia durante el desayuno que probablemente sería noticia de apertura en los telediarios del día. Claramente, el incidente iba a tener un impacto en la sociedad y no pequeño. Efectivamente, Microsoft declaró que 8,5 millones de computadoras fueron afectadas por el bug, con importantes consecuencias: se retrasaron vuelos internacionales y se interrumpieron conexiones de transporte público, algunos hospitales se vieron afectados teniendo que cancelar pruebas médicas, incluso algunas operaciones bancarias y de pago no pudieron realizarse…

Y mientras, el trabajo para solucionar el ciberincidente progresaba. El workaround se confirmaba como efectivo en la mayoría de los equipos. Los clientes de GMV estaban prácticamente recuperados. Se encontraban algunos casos en los que había que aplicar workarounds alternativos, para casos de equipos en los que había fallado el inicialmente prescrito. Se encontraban equipos que estaban fallando pero que no tenían exactamente el mismo fallo reportado. Las organizaciones analizaban la información que iban encontrado y la que íbamos compartiendo. Parecía claro que, aunque conocida, la solución en algunas empresas llevaría días o semanas. Había compañeros que estaban moviéndose físicamente a los equipos con USBs para aplicar el workaround manualmente. Esto funcionaba, pero necesitaba tiempo.

El resto ya es historia. No merece la pena que la repitamos de nuevo.

Sí que merece la pena dedicarle espacio al análisis que hemos realizado del incidente, cómo se actuó en él, cómo tendríamos que haber actuado, qué herramientas teníamos a nuestra disposición… Y, sobre todo, qué podríamos mejorar para próximas ocasiones.

La primera conclusión es la necesidad de tener monitorización de seguridad continua 7x24 a través de un servicio de CERT. Extensa, en tiempo real, efectiva y rápida. Con personas preparadas, formadas y capacitadas para desempeñar esta labor. Y con capacidad de detección de los eventos relevantes a varios niveles, para poder reaccionar cuando sea necesario, pero también para poder estar prevenidos si es posible antes de que sea necesario iniciar una respuesta. Sin un CERT o un SOC competente, nada de esto es posible. 

La segunda conclusión está en nuestros planes de respuesta a incidentes. En este caso, no tuvimos que ejecutarlo. Ni siquiera fue necesario iniciar los procedimientos de escalada. Pero el plan de respuesta funcionó con efectividad hasta donde fue necesario. Perfecto.

La tercera conclusión está en nuestros planes de continuidad de negocio. ¿Qué hubiera pasado si hubiéramos tenido un despliegue amplio del software Crowdstrike? Sabemos que lo hubiéramos detectado, pero ¿hubiera sabido responder el Plan de Continuidad a ese escenario? ¿Hubiera sido una respuesta efectiva? ¿Hay algo que podamos mejorar? Afortunadamente, no tuvimos que ejecutar el plan, pero sí pudimos revisarlo durante el incidente. Por si acaso. Y añadir al plan algún aspecto adicional que nos daba una respuesta más rápida, más efectiva y que hubiera reducido el impacto que hubiéramos sufrido.

Un viernes que pasará a la historia. Esperamos que sea por las lecciones que aprendimos y por el aumento de la concienciación de las empresas en sus necesidades de monitorización de seguridad y de respuesta a incidentes, que nos preparen mejor para la próxima crisis. 

Mariano J. Benito, Cibersecurity & Privacy AmbassadorGMV 

Óscar Riaño, responsable del CERT de GMV