En julio de 2026, Arctic Wolf contabilizó cientos de organizaciones que recibieron el mismo correo dirigido contra Microsoft 365: el aviso de un buzón de voz que no existía. El objetivo era localizar a las personas que gestionan las nóminas y cambiar la cuenta bancaria en la que cobra un empleado. Fraude salarial puro, sin ransomware de por medio, cobrado en la siguiente nómina.
El clúster de actividad se conoce como Payroll Pirates. Microsoft rastrea como Storm-2755 al grupo al que atribuye buena parte de estas operaciones, con un clúster emparentado, Storm-2657, documentado contra universidades estadounidenses en 2025. Las intrusiones confirmadas este verano abarcan sanidad, educación, industria, sector público y servicios profesionales en Estados Unidos, Canadá y Europa, según Arctic Wolf.
Todo ocurre en la nube de identidad, sin tocar un solo equipo. Las sesiones robadas constan en los registros como autenticadas con MFA, y en la mayor parte de la intrusión no hay malware que un EDR pueda señalar. Este análisis reconstruye la campaña con las investigaciones públicas disponibles y detalla qué señales deja en la telemetría de Entra ID y de Microsoft Graph.
La vía de entrada: un buzón de voz que nunca existió
El correo imita una notificación automática de llamada perdida, con logotipo de Microsoft y datos fabricados de remitente, fecha, duración y número de referencia. El botón invita a abrir el «portal de buzón de voz» de la organización. Según Arctic Wolf, el asunto sigue un formato reconocible: [Organización] :ATTN: Review messages. Ref id: [cadena].
El enlace no lleva directamente a la página falsa. La cadena pasa por redirecciones de servicios legítimos: la infraestructura de enlaces salientes de Google, un rastreador de clics de Campaign Manager y un objeto HTML alojado en un bucket de Amazon S3. Cada salto presenta reputación limpia ante los filtros de correo, y el dominio final de phishing suele tener menos de diez días de vida, con subdominios del estilo mslogin, msonline o msauth.
Antes de mostrar el falso inicio de sesión, un script de reconocimiento examina el navegador para descartar sandboxes e investigadores, y guarda durante siete días una cookie llamada rcfh_country con el país de la víctima. Arctic Wolf plantea que ese valor serviría para elegir después proxies residenciales del mismo país, aunque reconoce que no pudo observar la lógica del servidor que consume la cookie.
Un apunte sobre la atribución: Arctic Wolf encontró URLs de entrega muy similares en sandboxes públicas que acababan sirviendo otros kits AiTM, como EvilTokens. La infraestructura de entrega podría ser compartida o reutilizada entre grupos, y eso no prueba un operador común.
Por qué el MFA activado no basta
La página final no es una imitación estática: es un proxy de atacante interpuesto (AiTM, adversary-in-the-middle) que retransmite en tiempo real el flujo de autenticación legítimo de Microsoft. La víctima introduce su contraseña real, aprueba su MFA real y termina en su buzón real. Lo que no ve es que la cookie de sesión y los tokens OAuth quedan también en manos del atacante. Cualquier segundo factor que no sea resistente al phishing, como la aprobación push o el código por SMS, queda anulado en este esquema.
El proxy deja una huella técnica aprovechable: a veces inicia el flujo OAuth sin el parámetro nonce que liga el token de identidad a una sesión concreta, lo que produce autenticaciones fallidas con el código 90014 sobre la aplicación OfficeHome. Arctic Wolf lo describe como un error rarísimo en su telemetría global y fuertemente asociado a esta campaña, aunque advierte de que no aparece en todas las intrusiones confirmadas.
Consumada la captura, entra la automatización: inicios de sesión no interactivos que refrescan cada sesión robada aproximadamente cada ocho horas desde proxies residenciales rotatorios. El SessionID se mantiene constante mientras cambian la IP, el operador y hasta el país de origen, y el cliente dice ser Microsoft Outlook pero se presenta con agentes de usuario de Firefox 131.0, Firefox 151.0 o Python Requests.
Dentro del tenant: la caza de quien paga la nómina
Con un token de Microsoft Graph en la mano, el reconocimiento empieza por un volcado masivo del directorio (/v1.0/users con $top=999) y sigue con búsquedas encadenadas sobre nombre, puesto y correo con palabras clave como payroll, hr, finance, account o admin, paginadas con $skiptoken. Security Risk Advisors reconstruyó consultas casi idénticas en varios clientes distintos durante sus respuestas a incidentes. Arctic Wolf añade que, en entornos con Defender XDR, estas peticiones dispararon la alerta «Suspicious Exchange Online Graph Reconnaissance Activity», habitualmente con el agente de usuario axios/1.18.1, una versión publicada en junio de 2026.
Los tokens observados por SRA llevaban permisos delegados amplios: Directory.Read.All, Files.ReadWrite.All, Group.ReadWrite.All, Chat.ReadWrite o User.ReadWrite. Es margen de sobra para leer directorio, ficheros y conversaciones de la cuenta comprometida, y deja abierta la vía de persistencia mediante aplicaciones OAuth con consentimiento concedido, que sobrevive al cambio de contraseña y al reinicio del MFA.
La lectura de buzones tampoco es manual. Arctic Wolf observó eventos MailItemsAccessed de tenants distintos agrupados en ventanas de segundos: 18 eventos de tres organizaciones en 26 segundos, 11 de dos organizaciones en 43. El patrón apunta a una infraestructura central que recolecta a la vez el correo de finanzas, pagos y banca de varias víctimas.
El final del recorrido es conocido por los casos que documentó Microsoft: convencer al personal de RR. HH. mediante ingeniería social para que cambie la domiciliación del salario, o hacer el cambio directamente como la víctima en la plataforma de nóminas, por ejemplo Workday.
Tres equipos de investigación, el mismo manual
Storm-2657: universidades de EE. UU. (octubre de 2025)
Microsoft documentó phishing como acceso inicial y una persistencia característica: el alta de dispositivos MFA controlados por el atacante en la cuenta de la víctima. Es la misma familia de abuso del registro de autenticadores que analizamos a propósito del secuestro del alta de llaves de acceso (passkeys) en Microsoft 365.
Storm-2755: Canadá y el envenenamiento SEO (abril de 2026)
La vía de entrada fue otra: Microsoft describió envenenamiento SEO y publicidad maliciosa para colocar un dominio fraudulento en lo alto de los resultados de búsquedas genéricas como «Office 365». La víctima llegaba por su propio pie a un proxy AiTM que capturaba la sesión completa. El vector de entrada rota; el manual, no.
Security Risk Advisors: la misma coreografía en varios clientes (junio de 2026)
SRA reconstruyó la cadena en múltiples respuestas a incidentes: tomas de cuenta con una secuencia reconocible de códigos de error, tokens de Graph reutilizados desde sesiones sin dispositivo gestionado y, en cuentas aún sin remediar, accesos no interactivos a Exchange Online repetidos aproximadamente cada tres horas. SRA no atribuye la actividad por su cuenta a un actor concreto; señala el solapamiento con lo que Microsoft rastrea como Storm-2755 y Storm-2657.
Arctic Wolf: la campaña sigue viva (agosto de 2026)
El informe de agosto confirma que la operación continúa: cientos de organizaciones atacadas por correo solo en julio, intrusiones en varios sectores y regiones, y una red de proxies residenciales, con el proveedor anyIP como el más recurrente, que disfraza cada inicio de sesión de tráfico doméstico normal. La cobertura de The Hacker News recoge el alcance sectorial y geográfico de la campaña.
Por qué los controles habituales no lo ven
Toda la intrusión vive en sesiones web válidas y en llamadas legítimas a las API de Microsoft, de modo que el puesto de trabajo queda al margen. Y los delatores clásicos del fraude por correo corporativo tardan en aparecer: a diferencia del BEC tradicional, los operadores evitan crear reglas de buzón en la fase temprana; cuando lo hacen, es tarde, desde sesiones interactivas originadas en proveedores de hosting y con el fraude ya en marcha.
Y la fase de reconocimiento resulta directamente invisible para la mayoría: los registros de actividad de Microsoft Graph no vienen habilitados por defecto, así que las consultas al directorio en busca del equipo de nómina no constan en ningún sitio si nadie los activó antes. SRA lo resume sin rodeos: sin esos registros, esta etapa no se puede ver.
Detección por comportamiento: señales que sobreviven a la rotación de dominios
Los dominios de phishing caducan en días; estas señales de conducta duran meses. Todas aparecieron de forma consistente en la telemetría publicada por los tres equipos:
- Autenticaciones fallidas con código 90014 sobre OfficeHome desde IP de operadores móviles: la huella del nonce ausente en el proxy AiTM.
- Combinaciones imposibles de navegador y sistema operativo, como Mobile Safari o Chrome Mobile declarados sobre Windows 10.
- Inicios de sesión no interactivos con cadencia regular de unas ocho horas, mismo SessionID e IP, operador y país cambiantes.
- Peticiones a /v1.0/users que combinan $search con palabras clave de nómina y finanzas, $top=999 y paginación con $skiptoken.
- Ráfagas de MailItemsAccessed sincronizadas en segundos entre cuentas o tenants, incompatibles con una lectura humana del correo.
- Reglas de buzón nuevas que ocultan o borran mensajes con términos como direct deposit, bank o payroll.
Ninguna de estas señales depende de indicadores de compromiso frescos: son patrones de conducta. Un SOC gestionado con acceso a los registros de inicio de sesión de Entra ID, a la auditoría de Exchange Online y a los registros de actividad de Graph puede convertirlas en detecciones duraderas; sin esa telemetría centralizada en un SIEM, casi toda la campaña transcurre por debajo del umbral de alerta.
Las mismas señales valen hacia atrás: una revisión retrospectiva de los últimos meses de registros, al estilo de un ejercicio de caza de amenazas, permite descubrir sesiones robadas que siguen refrescándose sin haber generado una sola alerta.
Defensa y gobierno: tratar la nómina como un proceso crítico
La medida que corta el vector de raíz es el MFA resistente al phishing (FIDO2, llaves de acceso) impuesto mediante políticas de intensidad de autenticación en el acceso condicional. Habilitar las llaves sin forzar su uso no basta: el atacante puede degradar a la víctima al método débil durante el propio flujo de phishing.
La sesión también se puede acotar: la evaluación continua de acceso, los límites de frecuencia de inicio de sesión y la exigencia de dispositivo conforme reducen la vida útil de un token robado. Y al remediar, la limpieza tiene que ser completa: revocar sesiones y tokens de actualización, reiniciar el registro de MFA, revisar reglas de buzón y auditar los consentimientos de aplicaciones OAuth concedidos durante la ventana de compromiso. Los pasos coinciden con los que describimos al analizar el secuestro de cuentas en Microsoft 365 mediante AiTM.
Activar los registros de actividad de Microsoft Graph y llevarlos al SIEM cubre justo la fase que hoy casi nadie ve: el reconocimiento del directorio. Estos registros han mejorado desde sus primeras versiones y hoy capturan la URI completa de cada llamada, que es justo lo que delata la forma de trabajar de este actor.
Queda un control que no es tecnológico: la propia plataforma de RR. HH. Debe alertar de cada cambio en la cuenta de abono de la nómina, de cada alta de dispositivo MFA y de los accesos inusuales; y ningún cambio de domiciliación debería ejecutarse sin verificarlo fuera de banda con la persona real. En Hard2bit lo planteamos así de simple: el proceso que mueve los salarios merece los mismos controles que una transferencia internacional.
Para el correo y la identidad corporativa, el punto de partida es revisar la configuración real del tenant: acceso condicional, métodos de autenticación, registros habilitados y aplicaciones con consentimiento. Es el alcance de una auditoría de seguridad de Microsoft 365.
Lo que este caso deja al descubierto
El fraude al correo corporativo ya no necesita el correo más que como llave. La diana es la identidad y, detrás de ella, los procesos de pago que dependen de una sesión web. La clonación de voz del fraude del CEO apunta al mismo sitio por otra vía: al dinero en tránsito entre la empresa y las personas.
En Hard2bit trabajamos para que ese cambio de cuenta sea, como mínimo, una conversación entre dos personas. La incógnita que ninguna fuente resuelve sigue abierta: cuánto dinero se ha desviado ya. Ni Microsoft, ni Arctic Wolf, ni SRA publican importes, y preferimos no estimarlos. Mientras para cambiar la cuenta de cobro de un empleado baste una sesión robada, sin más verificación, habrá quien pague la infraestructura de proxies con nóminas ajenas.
Este artículo describe señales de detección y medidas de defensa con carácter general, a partir de investigaciones públicas de Microsoft, Arctic Wolf y Security Risk Advisors disponibles en agosto de 2026. Verifica cualquier detección o cambio de configuración en un entorno controlado y adáptalos a tu organización antes de llevarlos a producción.
