Borrado masivo en la nube y el riesgo de la gestión de endpoints

La mañana del 11 de marzo dejó a una de las grandes empresas del sector sanitario con importantes interrupciones: miles de equipos gestionados por la nube fueron borrados de forma remota y, según declaraciones del grupo que reivindicó el ataque, se sustrajeron terabytes de información. Lo que diferencia este incidente de otros ataques con malware es que los agresores no necesitaron desplegar un gusano o un ransomware en cada máquina; aprovecharon las capacidades administrativas de una herramienta de gestión de endpoints en la nube para ejecutar un borrado masivo.

La herramienta en cuestión es Microsoft Intune, un servicio que muchas organizaciones usan para controlar y proteger dispositivos corporativos. Intune incluye funciones legítimas y potentes, como la posibilidad de eliminar datos de un equipo de forma remota para proteger activos cuando un dispositivo se pierde o es robado. Pero esa misma capacidad puede convertirse en un vector de daño si un atacante logra privilegios administrativos. Sobre lo sucedido en Stryker han informado medios especializados; un análisis de la cronología y técnicas empleadas puede consultarse en BleepingComputer.

Tras el incidente, la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos publicó un aviso en el que insta a organizaciones de todo tipo a reforzar sus sistemas de gestión de endpoints. En ese comunicado la agencia recomienda medidas de endurecimiento que van más allá de un único producto: se trata de aplicar principios de seguridad administrativa para reducir la superficie de ataque y contener el impacto si una cuenta es comprometida. El texto de CISA está disponible en su alerta pública.

Microsoft, por su parte, publicó orientaciones específicas para proteger entornos Intune y controlar mejor quién puede realizar acciones críticas desde la nube. Sus recomendaciones subrayan la necesidad de pasar de confiar en administradores «confiables» a diseñar una administración segura desde el principio: minimizar privilegios, verificar la identidad con controles modernos y exigir aprobaciones para operaciones sensibles. Las pautas oficiales de Microsoft para reforzar Intune pueden consultarse en su blog técnico en Tech Community, y la documentación sobre la función de borrado remoto está en la documentación de Intune en Microsoft Learn.

¿Qué lecciones prácticas deja este incidente? En primer lugar, la gestión de roles y permisos debe obedecer al principio de menor privilegio: no todos los administradores necesitan acceso global. Implementar controles de acceso basados en roles y evitar cuentas con permisos excesivos reduce la capacidad de un atacante de provocar daños masivos solo con una cuenta comprometida. En segundo lugar, la protección de las cuentas con privilegios debe ser mucho más exigente: autenticación multifactor, políticas de acceso condicional que evalúen el contexto de inicio de sesión y mecanismos de acceso privilegiado temporal (just-in-time) son capas que complican el trabajo de quien intente elevar o usurpar privilegios.

También es crucial establecer barreras administrativas para las operaciones que puedan causar mayor impacto: las acciones de borrado, las modificaciones en las políticas de roles o las actualizaciones globales deberían someterse a mecanismos de doble aprobación o flujos de control donde intervengan varios responsables. Paralelamente, la telemetría, los registros de auditoría y las alertas en tiempo real permiten detectar movimientos laterales o creación de cuentas sospechosas de forma temprana; sin telemetría adecuada, un intruso puede crear un administrador y actuar sin ser visto.

El actor que reivindicó la intrusión, conocido como Handala o con otros alias, es descrito por analistas como un grupo hacktivista con vínculos que apuntan hacia estructuras estatales iraníes y con historial de usar malware borrador en campañas anteriores. Informes de investigación y contexto sobre esta agrupación y sus operaciones recientes pueden consultarse en el análisis de Palo Alto Networks Unit 42 en su informe sobre ataques iraníes en 2026. El patrón que muestra Handala —exfiltración seguida de desfiguración o borrado de datos— es especialmente peligroso para organizaciones críticas donde la disponibilidad y la integridad de la información son vitales.

Más allá de la técnica y la táctica del adversario, hay una dimensión organizativa que merece atención: las pruebas de recuperación y los planes de contingencia. Tener un sistema que permita borrar de forma remota no sustituye a políticas robustas de respaldo, segmentación de redes y procedimientos de recuperación verificables. Ensayar escenarios de compromiso, revisar permisos periódicamente y disponer de cuentas «break-glass» protegidas son prácticas que ayudan a recuperar operaciones con menor coste cuando algo falla.

El mensaje de las autoridades y de los fabricantes es claro y urgente: herramientas poderosas en manos legítimas facilitan la gestión, pero en manos de un atacante con privilegios pueden crear un cese de operaciones masivo. Por eso, además de aplicar las recomendaciones publicadas por Microsoft y CISA, conviene que los equipos de seguridad revisen sus configuraciones, auditen accesos recientes y planteen controles adicionales para las acciones críticas. La seguridad en la nube es tanto técnica como de procesos; la combinación de ambos es la que reduce realmente el riesgo.

Si tu organización utiliza Intune o cualquier plataforma de gestión de endpoints, es recomendable revisar las guías citadas, verificar roles y autenticaciones, y coordinar con el área de riesgos y continuidad para asegurar que existe capacidad de recuperación. Consultar las fuentes oficiales te dará una referencia sólida para priorizar medidas: la guía de Microsoft, la alerta de CISA y los reportes técnicos sobre el actor detrás del ataque como el de Unit 42 son buenos puntos de partida para entender el alcance y aplicar defensas eficaces.