Las intrusiones en entornos de nube que Microsoft observa desde mayo de 2026 comparten un punto de partida incómodo: el permiso lo concede el propio empleado. Ninguna de las acciones que vienen después —registrar un método de autenticación, consultar el directorio, descargar archivos— es maliciosa en sí misma; lo irregular es quién las ejecuta. Microsoft describe el conjunto como una recolección automatizada de información desde identidades en la nube ya comprometidas.
El primer contacto ocurre fuera de los sistemas de la empresa
Nada de esto pasa por el correo institucional, así que ningún filtro corporativo llega a intervenir. La vía es el número particular del trabajador, por llamada o por mensaje, y quien está del otro lado se identifica como personal de soporte de la propia organización. El argumento siempre es de plazo: la clave de acceso, el segundo factor o el inicio de sesión único deben reconfigurarse ahora mismo o se interrumpirá el acceso.
Quien acepta recibe en ese mismo teléfono un enlace hacia un portal que reproduce la apariencia del inicio de sesión de Microsoft. De ahí salen dos caminos que terminan igual: en uno, el portal funciona como intermediario y se queda con las credenciales y la sesión mientras el usuario cree autenticarse con normalidad; en el otro, se le presenta una autorización por código de dispositivo y es él quien concede el permiso, sin contraseña robada porque nunca hizo falta.
Cuando el atacante ya controla alguna cuenta de la entidad, reutiliza ese acceso para repetir el pedido desde adentro por Teams, una variante que Microsoft ubica en una proporción menor de los casos. Es la misma mecánica telefónica que ya describimos en el robo de sesiones de Microsoft 365 mediante llamadas falsas de soporte, ahora con el pretexto de las claves de acceso.
Cada enlace lleva el nombre de la institución atacada
La dirección que recibe la víctima no es genérica. Los dominios se compran con nombres que giran en torno a trámites de identidad —claves de acceso, matrícula de inicio de sesión único, activación de cuenta, verificación— y el enlace se arma colocando el nombre de la entidad objetivo como subdominio, con la forma nombre-de-la-organización seguido del dominio malicioso.
Personalizar cada enlace obliga a saber a quién se ataca. Microsoft atribuye esa precisión a un trabajo de investigación previo considerable sobre el personal y la estructura de la organización, alimentado con lo que las propias personas publican en redes sociales y plataformas de perfil profesional. Ese reconocimiento previo, hoy cada vez más automatizado, es el mismo que sostiene a las campañas de phishing operadas con agentes de IA.
El atacante inscribe su propio método de verificación
Aquí está el giro que conviene subrayar en cualquier informe interno. Tras el acceso inicial, el primer objetivo no es robar datos sino convertir un compromiso temporal en un punto de apoyo permanente, y para eso el atacante registra un método de verificación bajo su control: un teléfono nuevo, una aplicación autenticadora o un token de un solo uso.
Ese segundo factor propio le permite iniciar sesión en la cuenta corporativa sin participación de la víctima y mantener el acceso de forma continua mientras existan sesiones sin revocar o credenciales válidas.
Días de descargas que no levantan alertas
Con la permanencia asegurada, la actividad sigue un patrón reconocible: recorrer el directorio de la organización, inventariar usuarios y permisos, buscar cuentas de alto privilegio, revisar mensajes y adjuntos, y descargar en volumen desde SharePoint Online, OneDrive y, en algunos casos, Exchange Online. La extracción dura de varias horas a varios días, rotando direcciones de conexión entre cada fase para evadir los indicadores de red.
El desafío de detección es explícito: ese abuso casi nunca parece sospechoso visto en una operación aislada. Reconocerlo exige correlacionar eventos, algo que solo ocurre cuando alguien mira los registros de forma continua y no únicamente después del incidente.
Por qué el señuelo funcionaría en una entidad peruana
Este ataque no necesita una versión local porque sus dos requisitos ya están dados en buena parte del sector público. El primero es que la entidad opere su correo y sus archivos sobre Microsoft 365, algo cierto en ministerios, municipalidades, hospitales y universidades migrados a la nube. El segundo es que sus trabajadores tengan perfiles laborales públicos con cargo, área e institución: sin eso el atacante no sabría a quién llamar ni cómo sonar creíble.
Un tercer factor agrava el escenario: en muchas entidades el soporte técnico está tercerizado o rota entre proveedores, así que el trabajador está habituado a recibir instrucciones de personas que no conoce. "¿Quién me está llamando?" no siempre tiene respuesta clara ni cuando la llamada es legítima.
El contexto general acompaña: según cifras de ESET publicadas por El Comercio, el Perú registró más de 350 mil detecciones de amenazas hasta mayo de 2026, y más del 45 % correspondió a ingeniería social, phishing, scripts maliciosos y programas descargadores.
No hay reportes públicos de que esta campaña haya alcanzado entidades peruanas; lo que existe son las condiciones para que funcione. Cerrar la vía del correo es el primer paso: SPF, DKIM y DMARC bien configurados mediante una solución de autenticación de dominio impiden que un tercero envíe mensajes en nombre de la institución.
Qué revisar esta semana
Las señales existen y son concretas: un método de verificación inscrito en una fecha que el usuario no reconoce, un acceso desde un dispositivo no administrado, descargas masivas fuera de horario. El problema es que alguien debe mirarlas, y en muchas entidades el área de TI son dos o tres personas cubriendo soporte, infraestructura y seguridad a la vez. Ahí una plataforma de gestión y monitoreo remoto centraliza la visibilidad y vuelve continua la revisión, mientras una protección de endpoint con contención limita lo que un acceso robado puede ejecutar.
Cuatro controles cierran la ruta sin inversión nueva: fijar un canal único de verificación y comunicar que el soporte nunca pide cambios de autenticación al teléfono personal; restringir el registro de nuevos métodos a dispositivos confiables y alertar cada vez que se inscriba uno; revocar las sesiones activas ante cualquier sospecha; y deshabilitar el inicio de sesión por código de dispositivo si no se usa. Ordenar esas reglas bajo un procedimiento escrito, con responsables y trazabilidad, es parte de un modelo de gestión de TI que no dependa de la memoria de cada técnico.
Conviene añadir un quinto: mantener una copia independiente de los buzones y repositorios. Si la extracción ya ocurrió, el respaldo de Microsoft 365 es lo que permite reconstruir qué había en cada carpeta el día del incidente y responder con datos ante una fiscalización.
El componente legal en el Perú
Cuando lo descargado son expedientes, historiales o padrones con datos personales de ciudadanos, el incidente deja de ser un problema técnico. La Ley 29733, de Protección de Datos Personales, obliga a adoptar medidas de seguridad sobre los bancos de datos, y su marco sancionador contempla infracciones muy graves de 50 a 100 UIT cuando se tratan datos sensibles sin las condiciones exigidas. Fiscaliza la Autoridad Nacional de Protección de Datos Personales, y la responsabilidad recae en la entidad que trata la información, no en el proveedor de la nube.
Conclusión
La passkey no se rompe en este ataque. Los atacantes solo usan el tema de las claves de acceso como pretexto, porque es un cambio que suena urgente, técnico y plausible. Falla el canal por el que se pide el cambio, no la tecnología que se dice estar actualizando.
Por eso la pregunta útil para cualquier organización no es qué producto falta comprar, sino qué ocurre hoy cuando alguien llama al celular de un trabajador diciendo que es de soporte y pide reconfigurar su autenticación. Si la respuesta depende del criterio de cada persona, la ruta está abierta. Y si además nadie revisa quién inscribió un método de verificación esta semana, el acceso puede durar días sin que aparezca una sola alerta.
