Volver al blog
Análisis de incidentes

No se robaron nada: el borrado de Stryker y la consola que lo hizo

Equipo de Plaza Cyber Security11 de marzo de 20267 min readIncidente: 11 de marzo de 2026
Unidades de servidor en fila dentro de un rack, iluminadas en azul y rojo

Casi todos los incidentes que analizamos terminan con datos en algún lugar donde no deberían estar. Este no. A Stryker no le robaron nada. Simplemente le borraron cosas, a gran escala, usando sus propias herramientas.

Qué pasó

El 11 de marzo de 2026, Stryker —fabricante de dispositivos médicos con sede en Michigan y personal en todo el mundo— sufrió un ataque destructivo. Los atacantes llegaron a una cuenta de administrador dentro del entorno de Microsoft de la compañía y la usaron para emitir comandos masivos de borrado. Decenas de miles de laptops y dispositivos móviles del personal quedaron borrados en cuestión de horas.

Stryker confirmó el ataque públicamente y dijo estar restaurando sus computadoras y su red interna. Señaló que el incidente quedó contenido en su entorno interno de Microsoft y que sus productos médicos conectados eran seguros de usar. Los investigadores no encontraron evidencia de ransomware ni de malware en los sistemas, porque no hizo falta ninguno. Días después, la compañía indicó que su capacidad de procesar pedidos, fabricar y enviar equipos seguía afectada. El incidente llegó a los resultados trimestrales.

Un grupo pro-Irán autodenominado Handala se atribuyó el ataque y lo planteó como represalia por hechos ajenos al negocio de Stryker.

El instrumento probable fue Microsoft Intune, la plataforma de gestión de dispositivos móviles. Los investigadores apuntan al phishing o a malware ladrón de credenciales como vía de acceso a la cuenta de administrador. Ese detalle es el que conviene masticar.

UNA CUENTA DE ADMINISTRADORpor phishingBORRAR TODOconsola MDMDECENAS DE MILES DE EQUIPOSSIN RESCATE · SIN DESCIFRADOR · SIN NEGOCIACIÓN
Una sola cuenta de administrador obtenida por phishing llega a la consola de gestión de dispositivos. La consola hace exactamente aquello para lo que fue diseñada, en todos los equipos a la vez.

La herramienta que hizo esto estaba funcionando bien

Intune existe para que un equipo pequeño aplique un cambio a todos los dispositivos de una organización a la vez. Empujar una política, desplegar una aplicación y, cuando una laptop se pierde o alguien se va, borrarla de forma remota. Esa última capacidad no es una falla: es el producto, y la mayoría de las organizaciones hace bien en tenerla activa.

Pero significa que la consola es un instrumento cargado apuntando a todo tu parque, y que una cuenta de administrador en ella vale más para un atacante que casi cualquier otra credencial del negocio. Aquí no hay exploit que parchar ni CVE que seguir. El atacante inició sesión y usó una función documentada.

Y esto va más allá de Intune. Toda organización de cierto tamaño opera hoy al menos una herramienta cuyo trabajo entero es hacer un cambio en todas partes a la vez: un MDM, un RMM, una plataforma de gestión de configuración, un pipeline de CI/CD con llaves de despliegue. Cada una está a una cuenta de distancia de convertirse en lo más destructivo del entorno.

Por qué un borrador es un problema distinto al ransomware

El ransomware moldeó la forma en que casi todas las organizaciones piensan la recuperación, y lo hizo de manera engañosa. Quien opera ransomware quiere cobrar, lo que significa que quiere que te recuperes, eventualmente y en sus términos. Hay una negociación, un descifrador y un camino malo pero transitable que no depende únicamente de tus respaldos.

Un borrador no ofrece nada de eso. No hay contacto, ni llave, ni palanca que mover. Los datos no están, y el único camino de vuelta es el que construiste antes de que pasara. Cada supuesto sin probar de tu plan de recuperación se vuelve crítico la misma mañana.

Esa es la prueba incómoda que plantea este incidente. Casi todas las organizaciones que evaluamos tienen respaldos de sus servidores y de sus carpetas compartidas. Muchas menos tienen una respuesta creíble para qué pasa cuando los equipos mismos —las laptops donde la gente trabaja, con lo que hubiera guardado en una carpeta local— se borran todos a la vez. Y menos todavía han cronometrado alguna vez esa reconstrucción.

"¿Por qué nos atacarían a nosotros?"

La razón que dio Handala para elegir a Stryker no tuvo nada que ver con su postura de seguridad, su sector ni su tamaño. Fue geopolítica, y tuvo que ver con asociaciones que la empresa había hecho en el curso normal de sus negocios.

Esa es la parte que vuelve poco confiable el razonamiento sobre selección de objetivos. A una organización pueden elegirla por quiénes son sus clientes, qué contratos de gobierno tiene, quién la adquirió, dónde está la casa matriz, o simplemente porque era alcanzable la semana en que alguien buscaba un objetivo. "No somos lo bastante interesantes" supone que el atacante comparte tu idea de qué hace interesante a una empresa. Cada vez menos la comparte.

Qué hacer en concreto

Trata las consolas de gestión como tus joyas de la corona. Inventaría cada herramienta capaz de hacer un cambio en todo tu entorno: MDM, RMM, gestión de endpoints, directorio, CI/CD. Para cada una, deja por escrito quién tiene acceso administrativo y cuándo se revisó esa lista por última vez. La mayoría descubre que la lista es más larga y más vieja de lo que esperaba.

MFA resistente al phishing en esas cuentas, sin excepciones. Llaves de hardware o passkeys, no notificaciones push ni códigos por SMS. Si la vía de entrada fue una credencial robada o pescada, este es el control que más habría importado.

Separa la administración del trabajo diario. Quien administra no debería leer correo con la cuenta capaz de borrar el parque. Identidades separadas, y acceso privilegiado solicitado y otorgado por ventanas de tiempo en lugar de permanente.

Ponle un límite de velocidad a las acciones masivas. Pregúntale a tu plataforma qué ocurre cuando alguien selecciona todos los dispositivos y elige borrar. Donde la herramienta admita flujos de aprobación, límites de tasa o alertas sobre operaciones masivas, actívalos. Un comando destructivo que exige dos personas y diez minutos es un riesgo muy distinto de uno que exige un clic.

Alerta sobre la consola misma. Los inicios de sesión administrativos desde ubicaciones nuevas, las asignaciones de roles de administrador y las acciones masivas sobre dispositivos deberían generar un aviso que alguien lea. Este incidente se desarrolló en horas, no en segundos.

Conoce tu tiempo de recuperación de endpoints, medido. No "tenemos Intune, los volvemos a inscribir", sino una cifra real salida de una reconstrucción real. ¿Cuánto toma dejar una laptop funcionando? ¿Cuántas puede hacer tu equipo por día? ¿Qué pierde una persona que solo tenía las cosas en su equipo? Si no puedes responder eso, un borrador es un día mucho peor para ti que para quien sí puede.

El resumen

A Stryker no la vulneraron con un exploit ingenioso. Alguien consiguió una cuenta de administrador y usó una función documentada exactamente como fue diseñada. La lección defensiva no es sobre un fabricante ni sobre un parche: es que las herramientas que compraste para gestionar miles de dispositivos con eficiencia son igual de eficientes en las manos equivocadas, y que la recuperación —la disciplina que todo el mundo financia al final— es el único control que sigue sirviendo cuando ya falló todo lo demás.

Fuentes

#wiper#mdm#intune#destructive attack#incident analysis