Investigadores de Arctic Wolf están siguiendo una campaña de phishing extendida y basada en correo que comparte claras coincidencias tácticas con Storm-2755, el clúster que Microsoft nombró por primera vez “Payroll Pirate” en abril, después de que vaciara los sueldos con depósito directo de empleados canadienses. La nueva actividad se ha extendido por Estados Unidos, Canadá y Europa, golpeando organizaciones de salud, educación, manufactura, gobierno y servicios profesionales. Lo que hace que esta ola merezca una segunda mirada no es que robe credenciales. Es lo que hace el enlace de phishing en su camino hacia ese robo, y cuánto tiempo sobrevive el acceso resultante una vez que tiene éxito.
Un Buzón de Voz Que Pasa por Cuatro Dominios de Confianza
El correo señuelo parece una notificación automática de buzón de voz, un formato lo bastante familiar como para conseguir un clic sin mucho escrutinio. El enlace detrás de él no va directo a una página de inicio de sesión falsa. Pasa por el propio servicio de redirección de enlaces de Google Meet, luego por la infraestructura de enlaces salientes de Google, después por un rastreador dinámico de clics de Google Campaign Manager, antes de aterrizar finalmente en un archivo HTML alojado en un bucket de Amazon S3, que es donde realmente vive el proxy de adversario en el medio. Cada salto de esa cadena se apoya en un dominio que las herramientas de seguridad han aprendido a confiar: google.com, googleadservices.com, amazonaws.com. El filtrado de URL basado en reputación, el tipo que marca un enlace en el momento en que apunta a algo desconocido, no tiene nada que marcar hasta la última redirección, y para entonces la víctima ya está mirando una página de inicio de sesión de Microsoft 365 convincente.
Una vez que la víctima inicia sesión, el proxy AiTM captura la cookie de sesión y el token de acceso OAuth emitidos tras una autenticación exitosa, el mismo mecanismo que Microsoft documentó en los casos originales de Storm-2755. El MFA que no es resistente a phishing no detiene esto. La víctima completa su desafío multifactor de verdad, contra el proveedor de identidad real, y el proxy simplemente copia la sesión resultante en lugar de intentar adivinar un código.
Una Sesión Que se Mueve Más Rápido Que Tus Alertas
El detalle que separa esto de un reporte rutinario de robo de credenciales es lo que sucede después de que se establece el acceso. Arctic Wolf descubrió que, típicamente entre once y veinticuatro horas después del compromiso inicial, una actividad automatizada refresca cada sesión secuestrada a intervalos de aproximadamente ocho horas, y el SessionID se mantiene constante en cada refresco aunque la dirección IP de origen, el ASN y la ubicación geográfica cambien. Los operadores también enrutan los inicios de sesión a través de proxies residenciales, así que el patrón de tráfico que aparece en tus registros se ve como una conexión de internet residencial ordinaria en lugar de un pico proveniente de infraestructura de hosting desconocida. Un equipo de seguridad vigilando la señal de manual de una toma de cuenta, un inicio de sesión desde un nuevo país en un nuevo ASN, verá exactamente esa señal dispararse una y otra vez, ligada a una sesión a la que nunca se obligó a reautenticarse.
Desde dentro de esa sesión, el actor usa Microsoft Graph para enumerar qué empleados manejan nómina, RR. HH., finanzas y administración, y luego lee correos específicamente sobre facturas, datos bancarios y beneficios. Ese reconocimiento alimenta el mismo desenlace que Microsoft documentó en los casos de abril: reglas de bandeja de entrada que ocultan las palabras “depósito directo” y “banco” del empleado real, una solicitud suplantada para cambiar los datos bancarios, y un sueldo que termina en una cuenta que la víctima nunca eligió.
Por Qué Nada de Esto Toca lo Que DMARC Verifica
DMARC, SPF y DKIM responden exactamente una pregunta: si el dominio en el encabezado From de un mensaje está autorizado para enviar ese mensaje. Esa pregunta queda respondida y aprobada por completo en el momento en que llega el correo señuelo, porque nada en la notificación de buzón de voz necesita un dominio falsificado para funcionar. La cadena de redirecciones que sigue es un problema de reputación web, no un problema de autenticación, ya que Google Meet y Amazon S3 son servicios legítimos usados exactamente como están diseñados por cualquiera que tenga una cuenta, que es lo que tiene el atacante. Y el secuestro de sesión que viene después del clic se ubica una capa completa por encima de todo lo que DMARC evalúa. DMARC verifica el sobre en el que llega un mensaje. No tiene mecanismo para revocar un token de sesión, ni visibilidad sobre si un SessionID que ya ha pasado por seis ASN distintos en tres países en dos días sigue siendo el mismo usuario de confianza que escribió la contraseña.
Esto no es una crítica a DMARC. Es una descripción del límite en el que DMARC fue construido para operar, y esta campaña está diseñada específicamente para operar más allá de ese límite desde el primer clic en adelante.
Lo Que Esto Significa para tu Programa
Impulsa el MFA resistente a phishing donde tu proveedor de identidad lo soporte. Las passkeys y las llaves de hardware FIDO2 están vinculadas al origen contra el que fueron registradas, lo que derrota a un proxy situado entre la víctima y la página real de inicio de sesión de una forma que un código de un solo uso nunca puede.
Monitorea la continuidad del SessionID a través de cambios de IP y ASN, no solo los inicios de sesión desde ubicaciones nuevas. La señal que esta campaña explota es una en la que tus alertas se disparan correctamente pero tu respuesta trata cada alerta como un evento nuevo y aislado en lugar de reconocer una sola sesión que ha persistido silenciosamente durante días.
Audita las reglas de bandeja de entrada que ocultan palabras como “banco,” “nómina” o “depósito directo” como una detección permanente, no como un paso forense posterior al incidente. Esa regla es el mecanismo del que depende toda la etapa de daño financiero de esta campaña, y es visible antes de que se mueva cualquier dinero si alguien está mirando.
Mantén DMARC aplicado en modo reject de todos modos. Sigue cerrando la puerta a cualquiera que intente suplantar tu dominio directamente, y esa es una puerta que vale la pena mantener cerrada aunque esta campaña en particular entre por otra completamente distinta.
La Conclusión
Un dominio puede tener DMARC en aplicación total, con reportes agregados limpios y cada remitente legítimo alineado, y aun así ver cómo se redirige la nómina de un empleado por un atacante que nunca necesitó falsificar ese dominio. La campaña Payroll Pirate tiene éxito haciendo pasar su enlace de phishing por infraestructura en la que tus filtros ya confían, y manteniendo viva la sesión resultante mucho después del inicio de sesión que la creó. Cerrar esa brecha requiere monitoreo consciente de sesiones y autenticación resistente a phishing junto a DMARC, no una versión más fuerte del propio DMARC.
Excello Mail te da visibilidad continua sobre la aplicación de tu DMARC y sobre cada fuente autorizada para enviar correo bajo tu dominio, para que siempre sepas qué protege realmente tu autenticación y dónde están sus límites. Regístrate gratis en Excello Mail y mira exactamente quién envía correo como tú, en todo momento.