Este no fue el silencio de una caída de red o un fallo de servidor que sorprendió al equipo de seguridad. En cambio, fue el silencio de casi 200,000 dispositivos borrados. Todo, desde computadoras portátiles, teléfonos y servidores en 79 países se apagaron simultáneamente, incluso antes de que la mayoría de la fuerza laboral tuviera su sorbo matutino de café. Lo que le ocurrió a Stryker el 11 de marzo es diferente a tus ataques habituales, no solo por su escala (aunque la escala es preocupante), sino porque revela un punto ciego que está escondido a simple vista dentro de prácticamente todas las empresas del planeta. Es hora de que nos despertemos a esta amenaza. 

Para empezar, permíteme guiarte a través de este incidente y luego discutamos algunas medidas de remedio. 

Antes de continuar, no olvides revisar nuestra publicación anterior en el blog sobre  Cómo los actores de amenazas iraníes operan sin conectividad aquí. 

Puedes descargar el Informe Completo del Incidente sobre este incidente aquí.

Lo que realmente sucedió. La versión con la que nadie está liderando

Stryker Corporation es un fabricante de dispositivos médicos. Produce robots quirúrgicos, implantes ortopédicos, camas de hospital, y el sistema de transmisión de electrocardiograma Lifenet utilizado por los servicios de emergencia. Fue golpeado por un ciberataque destructivo reclamado por Handala, un grupo vinculado a Irán conectado al Ministerio de Inteligencia y Seguridad de Irán (MOIS) que informa al Presidente de Irán (a diferencia del IRGC que informa al Líder Supremo). Handala ha estado mostrando niveles extraordinarios de actividad en un entorno de conectividad escasa durante las últimas dos semanas.

La historia superficial es esencialmente esta. Handala borró más de 200,000 dispositivos, afirmó haber exfiltrado 50 terabytes de datos, desfiguró pantallas de inicio de sesión con su logo e inactivó a 56,000 empleados a nivel mundial. También hizo que las acciones de Stryker bajaran casi un 4 por ciento en una sola sesión de negociación. El ataque se enmarcó como represalia por un ataque de misiles en una escuela en Minab, Irán.

Has escuchado y leído todo esto gracias a la atención mediática generalizada que recibió este evento. Ahora, aquí está la historia que no te están contando.

El vector de ataque real: Tu herramienta de seguridad fue el arma

Una mayoría de la cobertura posterior al incidente ha descrito esto como un simple "ataque de borrado" y pasó al siguiente tema. Ese encuadre, aunque técnicamente preciso, oculta el detalle más importante de todo este incidente: Handala probablemente no desplegó ningún malware nuevo para borrar esos 200,000 dispositivos. Simplemente usaron Microsoft Intune. 

Intune es la plataforma de administración de dispositivos móviles basada en la nube que las empresas usan para aplicar políticas de seguridad, enviar actualizaciones de software y borrar dispositivos de manera remota que se han perdido o robado para prevenir el robo de datos. Está diseñado específicamente para dar a los administradores de TI una consola única desde la cual pueden restablecer de fábrica cualquier dispositivo registrado en el planeta con unos pocos clics. Se puede equiparar a un botón nuclear administrativo. 

Handala obtuvo acceso administrativo al entorno Intune de Stryker y usó la capacidad incorporada de borrado remoto de Intune para emitir un comando de borrado masivo a todos los dispositivos registrados de una sola vez. Eso no es un exploit de día cero. Eso no es malware de última generación. Eso es ingresar en una plataforma empresarial legítima con credenciales de administrador robadas y presionar un botón que ya estaba allí.

Este es el detalle que debería mantener despierto a cada CISO en este momento: los atacantes ya no necesitan ninguna herramienta personalizada o desplegar un borrador. Solo necesitaron llegar a la capa administrativa de una plataforma que la posible víctima ya está pagando y confiando implícitamente. Una vez que tuvieron ese acceso, la detección tradicional de endpoints estaba ciega ante ello. Un comando de borrado remoto emitido a través de Intune parece idéntico a un movimiento legítimo de administración de TI. Sin firma de malware, sin proceso anómalo, y sin alerta.

El riesgo desde dentro

BYOD se convirtió en un multiplicador de responsabilidades de maneras que los empleados nunca entendieron completamente. Stryker, como la mayoría de las empresas, operaba una política de Trae tu propio dispositivo y los empleados registraban sus iPhones y Androids personales en Intune para acceso laboral. Cuando se ejecutó el comando de borrado, no discriminó entre datos corporativos y datos personales. Fotos personales, aplicaciones bancarias y aplicaciones autenticadoras usadas para la autenticación de dos factores fueron todas borradas. En otro giro (de la fortuna), los empleados que perdieron sus aplicaciones de autenticación personal luego se encontraron bloqueados de sus propias cuentas bancarias porque el segundo factor se había ido. Este es un fracaso catastrófico de BYOD que los equipos de cumplimiento deben tomar nota de. 

Que Lifenet se haya caído fue un evento de seguridad del paciente escondido dentro de una historia de TI corporativa. El sistema Lifenet de Stryker es utilizado por los servicios médicos de emergencia para transmitir datos de electrocardiograma a los hospitales antes de la llegada del paciente, segundos críticos en un evento cardíaco. El Instituto de Servicios Médicos de Emergencia de Maryland confirmó que Lifenet estaba no funcional en la mayor parte del estado tras el ataque, instruyendo a los técnicos de EMS a volver a la consulta por radio. Esta es la peor pesadilla del sector de la salud (y sigue ocurriendo): un ciberataque a un proveedor degradando silenciosamente la calidad de la atención de emergencia sin que un solo hospital sea violado. Esta dimensión ha recibido casi ningún análisis. 

La lógica de la selección del objetivo revela una lógica nueva y peligrosa. El manifiesto de Handala describió a Stryker como una "corporación enraizada", haciendo referencia a la adquisición de OrthoSpace por parte de la compañía en 2019. Stryker no tiene conexión con operaciones militares o contratos de defensa. Fue atacada debido a una adquisición comercial histórica que la vinculó, en el marco ideológico de los atacantes, a Israel. La implicación es significativa y no la reiteraré aquí. 

En el paisaje de amenazas moderno, compromisos corporativos pasados pueden ser auditados por adversarios para construir una justificación narrativa para la interrupción.  

El ataque comenzó justo después de la medianoche, hora del Este, calibrado precisamente para maximizar el alcance global durante la ventana fuera de horas cuando las operaciones de seguridad están típicamente al mínimo de personal y los dispositivos están inactivos pero conectados. El momento no fue incidental. Refleja una planificación operativa diseñada para maximizar el número de dispositivos registrados en línea cuando el comando de borrado se disparó, mientras se minimiza el tiempo que los defensores tienen para responder antes de que el daño se haya hecho a nivel mundial. 

¿Qué salió mal?

El punto de entrada fue casi seguramente un compromiso de credenciales (phishing es el método de acceso documentado de Handala). Alguien con privilegios administrativos al entorno Microsoft Entra ID (anteriormente Azure Active Directory) de Stryker fue comprometido, y ese compromiso otorgó a Handala acceso a la consola administrativa de Intune. Desde esa posición, el atacante tenía modo dios sobre cada dispositivo registrado en la organización.

Lo que falló no fue una falta de herramientas de seguridad. Stryker había implementado Intune a nivel global. Tenían políticas MDM. Lo que falló fue la ausencia de controles adecuados sobre el acceso privilegiado a la capa administrativa de MDM en sí. Específicamente: autenticación de múltiples factores usando credenciales resistentes al phishing para cuentas de administrador no fue aplicado o fue eludido; no había reglas de alerta para comandos de borrado masivo. Las acciones de borrado en más de un puñado de dispositivos en una ventana corta nunca activaron una investigación automática; los controles de Gestión de Identidad Privilegiada que habrían requerido una elevación just-in-time para realizar acciones destructivas como borrados masivos estaban ausentes o insuficientemente configurados; y nadie parece haber tratado la consola de administración de Intune con el mismo rigor de seguridad aplicado a un controlador de dominio, aunque en términos de radio de explosión, ahora es probablemente más peligroso que uno.

Las empresas despliegan MDM para asegurar sus dispositivos, luego fallan en asegurar el propio MDM. La herramienta diseñada para proteger se convierte en el mecanismo de destrucción. En seguridad, llamamos a esto un punto único de fallo catastrófico, y las empresas han estado incorporándolos en sus entornos de Microsoft durante años sin reconocerlo.

Asesoría

Las siguientes no son controles aspiracionales. Son acciones que, si hubieran estado en su lugar en Stryker, habrían prevenido este ataque o lo habrían contenido antes de que alcanzara 200,000 dispositivos.

Trata tu consola de administración de MDM como un controlador de dominio porque lo es. Audita cada cuenta con privilegios de Administrador de Intune, Administrador Global o Administrador de roles de Intune ahora mismo. Debería haber muy pocas de ellas, todas deberían ser individuos nombrados, y cada una de ellas debería requerir autenticación de múltiples factores resistente al phishing, claves de seguridad de hardware o autenticación basada en certificados, no SMS o aplicaciones de autenticación que pueden ser manipuladas socialmente.

Implementa la Gestión de Identidad Privilegiada para roles administrativos de MDM. Usando Microsoft Entra PIM o equivalente, requiere elevación just-in-time para cualquier cuenta que necesite realizar acciones sensitivas de Intune. La capacidad de emitir un borrado remoto masivo nunca debe asignarse persistentemente a ninguna cuenta. Debe requerir aprobación, delimitación temporal y registro de auditoría cada vez que se use.

Crea una alerta de borrado masivo inmediatamente. Configura tu SIEM o Intune para activar una alerta de alta gravedad inmediata y un bloqueo automático cada vez que se emite un comando de borrado a más de cinco dispositivos en cualquier ventana de diez minutos. No hay escenario legítimo de TI que requiera el borrado de cincuenta dispositivos simultáneamente sin revisión humana. Este único control habría detenido el ataque a Stryker de inmediato.

Revisa tu política de BYOD con una divulgación de riesgo honesta. Si registras dispositivos personales en el MDM corporativo, los empleados necesitan entender en lenguaje simple que la empresa mantiene la capacidad técnica y legal de restablecer de fábrica su dispositivo personal, y que en un incidente de seguridad, esa eliminación puede ocurrir sin aviso. Más allá de la divulgación, evalúa si el registro de dispositivos personales en un MDM completo es necesario, o si un modelo de contenedor, donde solo se gestiona una partición de trabajo en espacio aislado, reduciría el radio de explosión sin sacrificar la productividad.

Segmenta tus sistemas de tecnología operativa (OT) y clínicos de tu entorno corporativo de Microsoft. La interrupción de Lifenet fue una consecuencia previsible de la tecnología operativa vinculada al mismo entorno de Microsoft que fue comprometido. Los sistemas clínicos, dispositivos médicos en uso activo y sistemas de datos de pacientes deben estar segmentados en la red con su propia infraestructura de autenticación, aislados de interrupciones de TI corporativa independientemente de la causa.

Trata la inteligencia de amenazas geopolíticas como inteligencia operativa. Los equipos de seguridad históricamente han tratado el análisis de riesgos geopolíticos como el problema de otra persona. El ataque a Stryker destruye esa postura. Si tu organización ha adquirido una compañía en un país que actualmente es un objetivo en un conflicto armado activo, o mantiene asociaciones estratégicas en ese país, eso es una entrada de inteligencia de amenazas que pertenece a tu evaluación de riesgo hoy. Revisa tu historial de fusiones y adquisiciones. Mapea tus relaciones con proveedores en zonas de conflicto geopolítico activo. Evalúa tu exposición a amenazas en consecuencia. 

Practica un escenario de recuperación de borrado masivo. ¿Cuándo probó tu organización por última vez restaurar 10,000 dispositivos desde cero? No un ejercicio teórico, sino una prueba real de tu canal de reconstrucción de dispositivos, tu proceso de recuperación de claves BitLocker, tus flujos de trabajo de reprovisión de aplicaciones? La mayoría de las organizaciones nunca han realizado este simulacro. Después de Stryker, ya no es opcional. La velocidad de recuperación de un evento de borrado catastrófico es una métrica de continuidad de negocio que necesita un dueño y un SLA probado.

Última palabra

Stryker se recuperará. Los dispositivos serán reconstruidos, los sistemas restaurados, la investigación concluida. Pero la lección enterrada dentro de este ataque es una que la industria ha sido lenta en asimilar: la mayor amenaza en tu entorno puede no ser el malware que el atacante trae. Puede ser el poder administrativo que ya has otorgado, sentado sin vigilancia en una consola en la nube, esperando que alguien con las credenciales correctas presione el botón equivocado. 

Hace veinticinco años, los atacantes tenían que estar físicamente dentro de tu edificio para hacer este tipo de daño. Hoy, necesitan una contraseña robada y acceso a una página de inicio de sesión. Este ataque no fue un fallo de tecnología de seguridad, fue un fallo del pensamiento de seguridad, específicamente, la suposición persistente de que las herramientas que desplegamos para protección están, en sí mismas, protegidas. 

No lo están. Y en una era de ciberseguridad geopolítica activa, esa suposición ya no es una que ninguna organización puede permitirse mantener. 

Lectura adicional

Lista de verificación de evaluación de riesgos para OT/ICS basada en IEC 62443 para el sector de fabricación de alimentos y bebidas
Proveedor de solución de escaneo de medios removibles, evaluación y selección lista de verificación

Una nota sobre el incidente publicada en el sitio web de Stryker