Los hackers se han vuelto perezosos: ahora te piden que les abras tu cuenta — y tú accedes

Proofpoint advierte sobre un aumento de ataques de phishing, en los que los atacantes secuestran cuentas corporativas Microsoft 365 no mediante un inicio de sesión falso, sino mediante un mecanismo legítimo de OAuth —la autorización por código de dispositivo. A la víctima la persuaden para que introduzca «un código de un solo uso» en el sitio real de Microsoft, y como resultado los atacantes obtienen un token de acceso, que abre el camino para el secuestro de la cuenta, la extracción de datos y acciones posteriores dentro de la organización.

Los especialistas siguen varios clústeres —desde motivados financieramente hasta vinculados a estados— que usan distintas variantes de ingeniería social para obligar al usuario a «confirmar» el acceso para aplicaciones mediante el flujo de autorización por código de dispositivo de OAuth 2.0. El esquema suele comenzar con un correo donde el enlace está oculto tras un botón, un hipervínculo o un código QR. El acceso desencadena la cadena con el proceso oficial de Microsoft: al usuario se le muestra el código de dispositivo —directamente en la página o en un segundo correo de los atacantes— y se le explica que supuestamente es un código de un solo uso (OTP) para «verificación reforzada» o «reautorización del token». A continuación la víctima es dirigida al portal de verificación de Microsoft y se le pide introducir el código, tras lo cual el token original se confirma y el acceso pasa a los atacantes.

Proofpoint señala que la técnica no es nueva y antes se había observado en ataques puntuales y en equipos rojos, pero que para septiembre de 2025 vieron campañas inusualmente masivas con este enfoque. Un factor adicional es la aparición de herramientas y componentes listos para usar que ayudan a los atacantes a escalar los envíos, pese a que los códigos de dispositivo duran poco. Entre esas herramientas los investigadores describen SquarePhish2 —evolución de SquarePhish, publicado por primera vez en 2022, y luego una versión actualizada que en 2024 apareció en GitHub por un investigador independiente.

SquarePhish2 hace que el ataque se parezca al procedimiento habitual para que el usuario configure la autenticación multifactor: un correo con un código QR conduce al servidor del atacante, luego la víctima es redirigida a la página legítima de inicio de sesión de Microsoft, mientras el servidor inicia el proceso OAuth con un ID de cliente preconfigurado, y el código de dispositivo puede llegar en un segundo correo desde el tenant de Microsoft o el usuario será redirigido automáticamente a la página de entrada de código.

Otro kit mencionado es Graphish, que se distribuía en foros criminales cerrados y se entregaba gratis a participantes «de confianza». Está diseñado para ataques masivos a cuentas de Microsoft, incluyendo la creación de páginas de phishing verosímiles y escenarios de intermediario a través de un proxy inverso: el usuario introduce el inicio de sesión y la contraseña, completa el MFA y el atacante intercepta la sesión. Para aumentar la credibilidad, el atacante necesita un dominio y certificado SSL, además de registrar una aplicación en Azure y usar el ID de cliente para empujar a la víctima a conceder permisos OAuth. En Proofpoint subrayan que esos kits «facilitan la vida» incluso a delincuentes de baja cualificación, reduciendo la barrera de entrada a ataques bastante complejos.

Como ejemplo Proofpoint cita una campaña descubierta el 8 de diciembre: la víctima recibía un correo «recordatorio» sobre un supuesto documento compartido "Salary Bonus + Employer Benefit Reports 25", donde el enlace llevaba al sitio del atacante con localización por IP y branding de la empresa objetivo. Tras introducir la dirección de correo aparecía una ventana de «autenticación segura» con un código y la instrucción de introducirlo en la página de Microsoft para la autorización del dispositivo —y precisamente esa acción daba en la práctica al atacante acceso a Microsoft 365.

Por separado los investigadores describen a TA2723 —un atacante de phishing de alto volumen motivado financieramente, conocido por suplantar OneDrive, LinkedIn y DocuSign: desde octubre de 2025 también empezó a usar el código de dispositivo. En una de las oleadas del 9 al 10 de octubre, los correos se disfrazaban de archivo compartido con personalización para el destinatario, y el enlace llevaba primero a una página de «generación de OTP», tras lo cual un botón cambiaba de función y dirigía al portal legítimo de Microsoft, donde la víctima autorizaba de hecho una aplicación controlada por el atacante. Proofpoint supone que en las campañas de TA2723 pudieron haberse usado SquarePhish2 y Graphish, según las fechas, cambios de tácticas y la aparición de Graphish en un foro cerrado poco antes de la segunda oleada.

Según Proofpoint, desde enero de 2025 actores «estatales» también han recurrido al phishing por código de dispositivo, lo que encaja en la tendencia general hacia el phishing sin contraseñas. Por observaciones de los investigadores, la técnica se usa de forma más amplia por grupos con orientación rusa; también se registró actividad presuntamente vinculada a China y otras campañas de espionaje no atribuidas. Como ejemplo destacado figura UNK_AcademicFlare, que Proofpoint monitoriza al menos desde septiembre de 2025: los atacantes usaron buzones comprometidos de organizaciones gubernamentales y militares para, mediante una «correspondencia inocua» y la construcción de confianza, llevar a la víctima a una reunión ficticia o entrevista y luego enviar un enlace a un «documento con preguntas». El enlace apuntaba a una URL de Cloudflare Worker que imitaba OneDrive e iniciaba el escenario de código de dispositivo, en el que se pedía a la víctima copiar el código y continuar en la página de inicio de Microsoft.

En sus recomendaciones Proofpoint indica que la medida más fiable es bloquear el flujo de código de dispositivo mediante Acceso Condicional con la condición Flujos de autenticación —al menos inicialmente en modo de informe o mediante evaluación del impacto en los registros históricos de inicio de sesión. Si el bloqueo total no es posible, se propone un modelo de lista de permitidos con restricciones por usuarios, sistemas operativos o rangos de IP y «ubicaciones con nombre».

Además aconsejan exigir el inicio de sesión solo desde dispositivos gestionados o que cumplan los requisitos (si se utiliza el registro de dispositivos o Intune) y revisar la formación de los usuarios: comprobar la URL en este tipo de ataques casi no ayuda, porque la introducción del código ocurre en el dominio real de Microsoft, y el indicio clave es la propia petición de introducir un código de dispositivo procedente de una fuente no confiable. En Proofpoint consideran que el abuso de OAuth aumentará a medida que se generalicen los enfoques MFA compatibles con FIDO.