Sin Malware. Solo una Cuenta de Administrador.

Miércoles, 11 de marzo de 2026. Los empleados de las oficinas de Stryker en 79 países encendieron sus ordenadores y los encontraron en blanco. Pantallas de inicio de sesión reemplazadas por un logotipo. Portátiles corporativos, teléfonos de empresa, dispositivos personales inscritos en el programa BYOD de la compañía. Todos borrados simultáneamente, de madrugada. Sin ransomware. Sin firmas de malware. Nada que una herramienta de detección de endpoints pudiera capturar.

El atacante, un grupo hacktivista pro-iraní llamado Handala, había convertido la propia infraestructura de gestión de TI de Stryker en el arma.

Lo que realmente ocurrió

El núcleo del ataque no fue un exploit sofisticado ni una vulnerabilidad de día cero. Fue algo mucho más simple y, francamente, mucho más común: una cuenta de administrador fue comprometida, y esa cuenta tenía acceso a Microsoft Intune.

Según los informes de BleepingComputer, aproximadamente 80.000 dispositivos fueron borrados entre las 5:00 y las 8:00 UTC. Handala afirmó que el número superó los 200.000, incluyendo servidores y dispositivos móviles en las operaciones globales de la empresa en 79 países.

Sin malware personalizado. Sin binarios maliciosos que detectar. Un ataque de tipo living-off-the-land, ejecutado íntegramente a través de una consola de gestión legítima.

Por qué tuvo éxito este ataque

Hay un problema estructural en la raíz de esto, y no es exclusivo de Stryker. Es endémico en las empresas.

La mayoría de las organizaciones tratan las tareas administrativas y el trabajo diario como actividades que pueden coexistir cómodamente en el mismo dispositivo, bajo la misma identidad de usuario. Un administrador de TI responde correos electrónicos, navega por la web, hace clic en algún enlace ocasional y — desde esa misma sesión, en esa misma máquina — gestiona infraestructura en la nube, aprueba cambios de acceso o, en este caso, accede a una consola de gestión de dispositivos con el poder de borrar toda la flota.

Esta es la superficie de ataque. Cuando el contexto de trabajo cotidiano y el contexto de administración privilegiada comparten un endpoint común y una identidad común, cualquier compromiso de ese endpoint es automáticamente un compromiso de todo lo que esa identidad puede alcanzar. Phishing, robo de credenciales mediante malware infostealer, robo de tokens de sesión adversary-in-the-middle (AiTM): todos se convierten en una ruta directa hacia los controles más poderosos de su entorno. No se necesita escalada de privilegios. El atacante simplemente usa lo que ya está ahí.

En el caso de Stryker, ese acceso incluía un tenant de Intune que gestionaba dispositivos en seis continentes.

CISA ha visto suficiente

La escala y la audacia del ataque provocaron una respuesta inusual: CISA, la Agencia de Ciberseguridad e Infraestructura de EE. UU., emitió orientaciones que abordan directamente el riesgo de las plataformas de gestión de dispositivos comprometidas. La agencia confirmó que conocía el vector de ataque e instó a las organizaciones a tomar medidas concretas, asegurando que las funciones de alto impacto de Intune, como el borrado de dispositivos, requieran la aprobación de un segundo administrador antes de ejecutarse.

Esta es una señal rara y significativa. Cuando una agencia federal de seguridad emite orientaciones específicas inmediatamente después de un incidente concreto, el mensaje es claro: esto no es un caso excepcional. Es un patrón, y otras organizaciones probablemente tienen la misma exposición.

La separación no es un lujo. Es el control.

El ataque Stryker es un caso de estudio útil precisamente porque ilustra el radio de explosión de un modelo de privilegios plano. El atacante no necesitó escalar privilegios a través de una cadena de vulnerabilidades. Obtuvo acceso a credenciales, o a un token de sesión, en un nivel y encontró que ese nivel ya era suficiente para causar un daño catastrófico, global e irreversible.

La respuesta arquitectónica a este problema tiene un nombre: el Microsoft Enterprise Access Model (EAM). Su principio central es la administración por niveles: las operaciones privilegiadas se realizan utilizando cuentas dedicadas y dispositivos dedicados, estrictamente separados del contexto de trabajo cotidiano. Este enfoque de mínimo privilegio significa que una cuenta de productividad comprometida no puede alcanzar el plano de gestión, y una cuenta de gestión comprometida no puede alcanzar las operaciones del plano de control. Esto se aplica igualmente a entornos exclusivamente en la nube y a configuraciones híbridas que incluyen conexión a Active Directory local a través de Entra ID, donde una única cuenta con exceso de privilegios puede seguir uniendo la nube y el dominio.

La idea es sencilla. El trabajo administrativo se realiza en dispositivos administrativos. La identidad utilizada para gestionar su tenant de Microsoft 365, su entorno de Intune o su infraestructura de Azure nunca es la misma identidad utilizada para leer correos electrónicos o asistir a llamadas de Teams. El dispositivo utilizado para esas sesiones administrativas está reforzado, restringido y aislado del contexto habitual de navegación por Internet y productividad que crea la exposición. El movimiento lateral se vuelve estructuralmente más difícil porque no existe ninguna ruta lateral.

Dos capas de defensa

Abordar correctamente este modelo de amenaza requiere trabajar simultáneamente en dos niveles: asegurar quién puede acceder al plano de gestión y a sus credenciales, y reforzar cómo ese plano de gestión mismo está configurado y operado. No son el mismo problema, y ambos importan.

Managed Red Tenant: proteger el contexto administrativo

La primera capa es aislar completamente el acceso privilegiado. Para eso está diseñado nuestro Managed Red Tenant.

El Managed Red Tenant proporciona un entorno administrativo completamente aislado y basado en la nube: un tenant dedicado de Microsoft Entra («el Red Tenant») utilizado exclusivamente para operaciones privilegiadas. Las identidades administrativas residen aquí. Los dispositivos administrativos se gestionan aquí. Nada del entorno de trabajo habitual se filtra.

Para los roles más críticos — aquellos con acceso al plano de control, como los administradores globales — implementamos el enfoque «Clean Keyboard»: una Privileged Admin Workstation (PAW) física con hardware dedicado, políticas reforzadas y sin ninguna exposición al contexto de trabajo cotidiano. Para roles administrativos más amplios, ofrecemos Virtual Access Workstations (VAW) escalables construidas sobre una infraestructura reforzada de Azure Virtual Desktop dentro del Red Tenant. La propia ruta de acceso está protegida a través de Microsoft Entra Private Access, aplicando Zero Trust Network Access y políticas de acceso condicional antes de que se pueda establecer cualquier sesión.

Microsoft Entra Internet Access bloquea el acceso a internet público desde las sesiones administrativas y restringe la conectividad estrictamente a interfaces privilegiadas y entornos de tenant autorizados. La revocación de sesiones en tiempo casi real es posible a través de Universal Conditional Access Evaluation, lo que significa que una credencial revocada no persiste como sesión válida.

El Managed Red Tenant está supervisado 24/7 por nuestro Cloud Security Operations Center (CSOC), con detecciones desarrolladas específicamente en torno a permisos administrativos y patrones de acceso. Un atacante que de alguna manera comprometiera una credencial en este entorno no tendría tres horas sin ser detectado para ejecutar comandos de borrado en una flota global de dispositivos.

Esto es especialmente relevante para roles como los administradores de Intune. Saben cómo proteger los clientes, pero proteger una estación de trabajo de administrador privilegiado requiere un conjunto de habilidades diferente — arquitectura de acceso empresarial, refuerzo de identidades, controles Zero Trust — que normalmente recae en el equipo de seguridad. Un Managed Red Tenant elimina esa carga por completo: los administradores de Intune obtienen una estación de trabajo gestionada profesionalmente y reforzada de forma consistente sin necesidad de convertirse en expertos en estaciones de trabajo seguras. Lo mismo se aplica a cualquier rol altamente privilegiado en la organización.

Managed Intune: reforzar el propio plano de gestión

La segunda capa es garantizar que Intune — la herramienta que fue utilizada como arma en el ataque Stryker — esté configurada, operada y mantenida continuamente según el estándar de seguridad más alto. Para eso está nuestro servicio Managed Intune.

Uno de los hallazgos centrales de incidentes como el de Stryker es que las organizaciones a menudo heredan entornos de Intune que han crecido de forma orgánica a lo largo del tiempo: políticas apiladas sobre políticas, cambios manuales realizados a través del portal que son difíciles de auditar, y baselines de seguridad que no han seguido el ritmo de las propias recomendaciones cambiantes de Microsoft. Ese tipo de entorno es exactamente donde la deriva de configuración crea brechas explotables.

Microsoft ha publicado recientemente mejores prácticas para proteger Microsoft Intune — una señal oportuna de que incluso Microsoft considera que el refuerzo de Intune es un tema que necesita atención explícita en toda la industria. Nuestro servicio Managed Intune está construido exactamente sobre estos principios, y hemos implementado las recomendaciones de Microsoft como parte de nuestra baseline.

Nuestro servicio Managed Intune se basa en la glueckkanja Intune Foundation: un conjunto probado y mantenido continuamente de mejores prácticas para la gestión de dispositivos, entregado íntegramente como código utilizando Terraform y nuestro propio TerraProvider. Cada cambio está automatizado, con control de versiones y es auditable. No existen configuraciones no documentadas de tipo «hacer clic en el portal» que un atacante pueda explotar al comprender la brecha entre lo que se pretendía y lo que se configuró.

Desde una perspectiva de seguridad, esto significa que las configuraciones de Zero Trust, las App Protection Policies y la seguridad de endpoints se aplican por diseño, de forma consistente, en Windows, macOS, iOS y Android: no como implementaciones únicas, sino como baselines evergreen aplicadas continuamente que siguen la evolución de las propias guías de seguridad de Microsoft.

Fundamentalmente, Managed Intune refleja la madurez operativa necesaria para proteger la gestión moderna de endpoints: monitorización continua del cumplimiento, gobierno estructurado de cambios y revisiones periódicas del servicio — no como extras opcionales, sino como operaciones de baseline. Pero proteger la configuración de Intune es solo la mitad del problema. Si el administrador que accede a la consola lo hace desde un dispositivo desprotegido, el plano de gestión sigue expuesto, independientemente — y es exactamente ahí donde el Managed Red Tenant completa el modelo.

Dado que todas las configuraciones se despliegan como código basado en la Intune Foundation, aplicamos un estricto principio de cuatro ojos con revisión por pares, validación automatizada adicional y pipelines de despliegue controlados. Esto elimina los cambios no gestionados en el portal dentro de la Intune Foundation y garantiza una baseline consistente, auditable y segura en todos los dispositivos.

El acceso administrativo se rige por un modelo de mínimo privilegio utilizando GDAP y Azure Lighthouse, con responsabilidades claramente definidas y acceso estrictamente delimitado al tenant del cliente. Esto reduce significativamente la superficie de ataque asociada con las operaciones privilegiadas.

Las acciones a nivel de dispositivo, incluidas las operaciones destructivas, siguen siendo responsabilidad del cliente, ya que su ejecución está estrechamente vinculada a los procesos específicos de la organización y a los marcos de gobernanza interna. Microsoft y CISA recomiendan proteger dichas acciones mediante salvaguardas adicionales, como los controles de aprobación de múltiples administradores dentro de Intune.

La pregunta incómoda

El ataque Stryker no es una acusación contra Microsoft Intune. Intune se comportó exactamente como fue diseñado. Ejecutó los comandos que recibió de un administrador autenticado. El fallo no estaba en la herramienta. Estaba en la ausencia de controles sobre quién podía acceder a esa herramienta, desde qué contexto y con qué nivel de autorización.

Es un problema de gobernanza y arquitectura. Y es el mismo problema que existe en la mayoría de las organizaciones que ejecutan Microsoft 365 hoy en día.

Si sus administradores acceden a Intune, Entra ID o Azure desde los mismos dispositivos e identidades que utilizan para el trabajo diario — y si su entorno de Intune ha crecido a través de años de cambios manuales en el portal en lugar de un modelo operativo estructurado y automatizado — está cargando con el mismo riesgo estructural que cargaba Stryker el 10 de marzo. La pregunta es si un adversario encontrará esa exposición antes de que usted la aborde.

Managed Red Tenant aborda la capa de privilegios e identidad. Managed Intune aborda la capa de configuración y operaciones. Juntos, cierran las dos brechas que hicieron posible el ataque Stryker.

Si quiere entender cómo cualquiera de los servicios se aplica a su entorno actual, o dónde están sus puntos de exposición específicos, estaremos encantados de analizarlo con usted.

También publicaremos en breve un artículo detallado que examina cómo fue posible que ocurriera el incidente Stryker en primer lugar.

Más información

• CISA: Securing Cloud Business Applications
• Microsoft: Mejores prácticas para proteger Microsoft Intune
• TechCrunch: CISA insta a las empresas a proteger los sistemas Microsoft Intune tras el borrado masivo de dispositivos Stryker por parte de hackers
• Managed Red Tenant en Azure Marketplace