Nueva estafa de phishing: el robo silencioso de Microsoft 365

Phishing con código de dispositivo explota OAuth en Microsoft 365: así toman cuentas con un token y qué ajustes cortan ese acceso silencioso.

La nueva ola de intrusiones aprovecha OAuth 2.0 —un sistema legítimo de autorización— para secuestrar cuentas de Microsoft 365 sin necesidad de robar contraseñas ni clonar páginas de inicio de sesión. El truco está en el llamado “device code flow”: el atacante empuja a la víctima a introducir un código en una página auténtica de Microsoft, obtiene un token de acceso emitido por la propia plataforma y, con él, entra en Outlook, OneDrive, SharePoint o Teams como si nada. A simple vista todo parece normal; por debajo, la sesión queda bajo control del intruso.

La mejor manera de defenderte es seguir reglas básicas de higiene y configurar todo de manera estricta. Esto se puede hacer limitando el acceso a ciertas partes del sistema, como el flujo de código de dispositivo en Entra ID, que es el directorio en la nube de Microsoft. También es importante restringir el consentimiento de aplicaciones solo a editores verificados o a aquellos que han sido aprobados por TI.

Además, es recomendable revisar con frecuencia los permisos ya otorgados para asegurarse de que siguen siendo necesarios. Mientras tanto, conviene ser cauteloso con mensajes que te piden que “verifiques” tu cuenta con un código o un código QR. Si ves permisos que no reconoces en el panel de usuario, lo mejor es retirarlos. Cambiar la contraseña es útil, pero lo que realmente corta el acceso es revocar el consentimiento.

El método: un código legítimo que abre la puerta

El correo o mensaje llega con la forma y el tono adecuados. Firma corporativa limpia, ortografía impecable, urgencia bien calibrada: “hay que actualizar la firma digital”, “se ha modificado la política de acceso”, “quedan documentos por validar”. La diferencia con el phishing clásico está en el destino. En lugar de enviar a una web falsa, conduce a una página real de Microsoft donde se solicita un código de seis u ocho dígitos. Ese portal es real. La gente lo utiliza para iniciar sesión en dispositivos que tienen pantallas pequeñas o que no tienen navegador. El usuario escribe el código y confirma. Sin saberlo, está dando permiso a una aplicación que el atacante controla. Al final, obtiene un token que le da permisos específicos para hacer cosas dentro de su cuenta.

El gancho funciona porque desplaza la frontera del engaño. Ya no se trata de capturar la contraseña sino de aprovechar un proceso oficial para lograr el consentimiento. Si el señuelo llega por correo, por chat interno o incluso impreso con un QR en un documento, la secuencia encaja con hábitos reales de oficina. En algunos casos, los delincuentes hacen algo más. Crean una aplicación que parece completamente normal. Le dan un nombre común, un icono gris y pocos permisos. Esta aplicación se queda en el teléfono de la víctima durante semanas sin hacer nada sospechoso. Mientras tanto, el delincuente puede acceder a la información sin que la víctima se dé cuenta. La víctima puede seguir usando su teléfono como siempre, sin notar nada extraño. El doble factor de autenticación no se dispara porque el delincuente ya tiene el token necesario. Así, el delincuente puede actuar sin que nadie sepa lo que está pasando.

Normalmente, hay un patrón que se sigue con el tiempo. Primero, se hace el reconocimiento. Esto implica leer el correo electrónico para encontrar información importante como la ubicación de proveedores, facturas, declaraciones fiscales y conversaciones con personas muy importantes. Después, el atacante hace un movimiento lateral en la nube. Esto significa que el atacante descarga selectivamente carpetas de OneDrive o bibliotecas de SharePoint. El atacante también crea reglas en Outlook para ocultar las huellas. Esto implica mover a carpetas poco visibles los mensajes que el atacante envía o recibe en nombre del usuario.

Si el objetivo lo permite, el atacante intenta cometer fraude de pago. El atacante puede cambiar una cuenta bancaria en una orden de compra o introducir una factura falsa en un hilo auténtico. El atacante hace todo esto con el mínimo de permisos para no levantar alertas.

Qué hay detrás: cómo funciona OAuth con Microsoft 365

OAuth es una forma de dar permiso a alguien más. En lugar de darle tu contraseña a cada servicio, das a una aplicación un permiso especial que dice exactamente lo que puede hacer. Por ejemplo, puede decir “puedes leer mi correo”, “puedes acceder a mis archivos” o “puedes ver mi calendario”. Este permiso especial se llama token.

Lo interesante, y también un poco peligroso, es que estos permisos son muy específicos. Se expresan de manera muy clara, como por ejemplo: Mail.Read, que significa que la aplicación puede leer tu correo; Files.ReadWrite, que significa que puede leer y escribir en tus archivos; o Calendars.Read, que significa que puede ver tu calendario. También hay permisos como User.Read, offline_access… Cuantos más y más sensibles, mayor el radio de acción.

El device code flow —el flujo por código de dispositivo— nació para casos legítimos: una consola sin navegador, un televisor, un script puntual que necesita autorización. El proceso separa el dispositivo donde se ejecuta la aplicación de la pantalla donde el usuario confirma la identidad. Así, al teclear el código en login.microsoftonline.com (u otra URL de Microsoft), el usuario confirma en un entorno de confianza. El atacante sabe muy bien lo que hace y se aprovecha de ese mismo proceso. Primero, prepara el código, luego lo envía a la víctima, espera a que lo introduzca y después recoge el token que se expide para su aplicación. Lo que es importante destacar es que no hay falsificación de la página de inicio de sesión. Por eso mismo, este tipo de ataque puede pasar los filtros que normalmente buscan dominios raros o errores ortográficos.

Cuando Microsoft 365 entra en juego, el ecosistema hace que las posibilidades sean mucho mayores. Un token que tiene el permiso Mail.Read puede abrir el correo en Exchange Online. Si tiene el permiso Files.ReadWrite, puede leer y escribir en OneDrive y SharePoint. Con el permiso Sites.Read.All, se puede acceder a estructuras compartidas del inquilino.

Si además se concede el permiso offline_access, el servicio obtiene un token de actualización que mantiene la sesión activa sin necesidad de intervención humana. Sin embargo, cambiar la contraseña después no siempre invalida el acceso. Lo que sí puede cortar el acceso es revocar la concesión OAuth de Microsoft 365.

Tokens y permisos que prolongan el acceso

En la práctica, hay tres partes importantes. El access token es el que dura poco tiempo y nos permite hacer cosas. El refresh token es el que nos da acceso de nuevo sin tener que iniciar sesión otra vez. Y luego está la concesión, que es como un permiso que guarda qué puede hacer la aplicación en nombre del usuario.

La persistencia silenciosa sucede cuando la aplicación obtiene offline_access junto con permisos para leer o escribir. Esto es un problema porque un atacante puede usar esto para volver una y otra vez sin que nos demos cuenta.

La estrategia defensiva se enfoca en limitar esa tríada. Si se sospecha que hay alguien que no debería estar dentro, hay que actuar en orden. Primero, es importante quitarle a la aplicación sospechosa el acceso desde el portal donde se gestionan las aplicaciones. Después, hay que anular los tokens de acceso que ya se han emitido. Y como último paso, pero igual de importante, revisar las credenciales y los factores de autenticación para asegurarse de que todo esté en orden.

En empresas de tamaño mediano o grande, este proceso se gestiona a través de Entra ID. Para hacerlo, hay que localizar la aplicación de la empresa o el service principal que se está utilizando, quitarle los permisos que tiene, y si es necesario, eliminar completamente el objeto. También es importante vigilar si la aplicación intenta generar nuevas solicitudes de consentimiento para acceder a los sistemas de la empresa. En incidentes complejos, Defender for Office 365 y la API de Microsoft Graph permiten hacerlo con precisión y registrar cada paso.

Señales en la operativa: lo que suele ocurrir tras la intrusión

Cuando hay una intrusión, suelen aparecer algunas señales que indican que algo no está bien. Estas señales en la operativa pueden ser variadas, pero generalmente tienen un patrón.

Entre las señales más comunes se encuentran:

• Fallos en el sistema
• Accesos no autorizados
• Cambios en la configuración
• Actividad sospechosa

Después de una intrusión, es importante estar atento a estas señales para poder tomar medidas y evitar daños mayores. La operativa puede verse afectada de diferentes maneras, y es fundamental identificar los problemas lo antes posible.

Algunas de las cosas que pueden ocurrir tras una intrusión incluyen:

1. Pérdida de datos
2. Robo de información
3. Daños al sistema
4. Problemas de seguridad

Es importante tener un plan para hacer frente a estas situaciones y minimizar los daños. La operativa debe ser revisada y actualizada regularmente para prevenir futuras intrusiones y proteger la información.

La huella de abuso de OAuth no es fácil de detectar como un intento de inicio de sesión fallido, pero sí deja pistas. Por ejemplo, se pueden ver concesiones nuevas cerca de la fecha del correo sospechoso. A menudo, estas concesiones tienen nombres genéricos, como “Herramienta de ayuda para documentos”, “Herramienta de sincronización de SharePoint” o “Visor de correo seguro”. También pueden aparecer inicios de sesión relacionados con métodos de autenticación que no se utilizan con frecuencia en la empresa, como el flujo de código de dispositivo. Se hacen reglas para esconder correos electrónicos que tienen palabras como “transferencia”, “factura” o “confirmación de banco”. Se revisan conversaciones sobre facturas con proveedores o equipos financieros. Luego, se intenta cambiar el número de cuenta bancaria de un proveedor o agregar una cuenta diferente a una factura real.

No todas las intrusiones tienen como objetivo obtener dinero de manera rápida. En las empresas que manejan propiedad intelectual, lo que más busca el atacante es llevarse documentos. Esto incluye repositorios de proyectos, anexos de contratos y memorias técnicas.

En el caso de las administraciones públicas o de la sanidad, el interés se centra en obtener listados de contactos, agendas y organigramas. En los bufetes, la meta es conseguir los expedientes y sus anexos. El atacante se adapta al contexto en el que se encuentra y trata de minimizar sus movimientos. Lo que más quiere es poder leer la información de manera silenciosa, para no alertar a nadie. Esa moderación, unida a la validez del token, explica por qué algunos compromisos se descubren semanas después.

En diferentes partes del mundo, el idioma del señuelo cambia según la región. En España, se utiliza un lenguaje muy común: el castellano natural, con referencias a herramientas como Teams, SharePoint o la “firma digital” de manera corporativa. A veces, incluso aparece un código QR en la esquina de un supuesto memorando interno que dice “escanear para activar”. La mezcla de elementos como el QR, la página real y el código que funciona puede hacer que muchas personas no se den cuenta del peligro, porque desactiva sus reflejos de alerta en comparación con las campañas clásicas.

Medidas inmediatas: hábitos y controles que funcionan

La protección sólida es mezcla de criterio y configuración. La parte humana exige recelo ante solicitudes de introducir códigos cuando no se está iniciando sesión proactivamente en ningún servicio. El proceso correcto empieza por el propio usuario: si no se ha pedido nada, no se teclea nada. En entornos profesionales, cualquier “verificación” recibida por correo o chat debe validarse por un canal distinto con el equipo de TI. Es conveniente revisar periódicamente, desde el portal de “Mis aplicaciones” de Microsoft, las aplicaciones que tienen acceso a la cuenta. Es una buena idea retirar los permisos que son antiguos o que no se reconocen.

La parte técnica es la que decide el partido. En Entra ID, la política adecuada es bloquear el device code flow, excepto en casos que estén documentados. Este bloqueo se aplica mediante el Acceso Condicional. Primero, se define un conjunto de usuarios y aplicaciones que estarán dentro del alcance. Luego, se activa la condición de flujos de autenticación. A continuación, se marca el flujo de código de dispositivo y se concede con bloqueo. Antes de aplicar en producción, el modo “Report-only” permite medir el impacto y ajustar exclusiones puntuales —por ejemplo, para un servicio que realmente dependa de ese flujo en un quiosco o un IoT industrial—. Las exclusiones se tratan como un activo crítico: se nombran, se documentan y se revisan con frecuencia.

El segundo pilar se basa en el consentimiento de aplicaciones. Es razonable no permitir que las aplicaciones tengan acceso libre o restringir este acceso solo a editores verificados por Microsoft y a permisos que no suponen un gran riesgo. En el caso de otros permisos, es necesario que pasen por una aprobación administrativa.

Entra ID tiene un proceso de “consentimiento de administrador” que funciona de la siguiente manera: el usuario hace una solicitud, el equipo de Seguridad la revisa, el departamento de TI la autoriza o la deniega, y todo el proceso queda registrado para poder ser auditado. Es una buena idea hacer una lista de las aplicaciones que utiliza la empresa de vez en cuando. Conviene verificar qué permisos tienen cada una y quién se los concedió. Luego, retirar las apps que no tengan un propósito claro. Si tomas algunas decisiones acertadas y las mantienes, controlas mejor quién entra y por dónde.

Para entornos personales y pequeñas empresas

En cuentas individuales o pymes sin equipo dedicado, el objetivo es reducir exposición sin complicaciones. Conviene mantener MFA robusto —aplicación de autenticación o llaves físicas FIDO2— y activar alertas de actividad inusual siempre que el proveedor las ofrezca. Si aparece un mensaje pidiendo introducir un código de verificación en una página oficial sin haber iniciado nada, lo prudente es ignorar y, en caso de duda, entrar manualmente en la cuenta por la ruta habitual para comprobar notificaciones. Es buena idea conocer bien el panel donde aparecen las aplicaciones con acceso y eliminar las que no se reconozcan. Si surge alguna duda, lo mejor es revocar el acceso primero, luego cambiar la contraseña y finalmente vigilar las reglas del correo para evitar sorpresas.

Para organizaciones con Entra ID

La pauta de referencia se centra en cuatro tareas importantes.

Primero, es necesario bloquear el device code flow con Acceso Condicional. Esto se hará con un conjunto limitado de exclusiones controladas y revisadas minuciosamente.

Segundo, se ajustará el consentimiento para que esté deshabilitado por defecto o solo permitido para editores verificados. Esto requerirá un workflow de aprobación para garantizar que se cumplan los requisitos necesarios.

Tercero, se implementará una revisión recurrente de las concesiones y las aplicaciones de la empresa. Esto implica examinar las altas recientes, identificar nombres sospechosos, detectar permisos excesivos y verificar a los propietarios para asegurarse de que todo esté en orden. Para proteger contra aplicaciones maliciosas, hay que hacer lo siguiente:

1. Revocar el acceso que se les concedió.
2. Eliminar los service principals.
3. Invalidar los tokens de acceso.
4. Revisar las reglas del correo del usuario afectado.

Y por último, monitorizar los accesos posteriores para detectar cualquier actividad sospechosa.

Herramientas como Defender for Office 365 y Microsoft Graph pueden ayudar mucho en este proceso. Permiten actuar rápido y documentar cada paso, algo clave cuando hay que reconstruir qué ocurrió y cuándo.

En equipos que tienen sus propios desarrollos o automatizaciones, es una buena idea separar los entornos: desarrollo, pruebas y producción. También es importante registrar las aplicaciones con nombres claros y describir los permisos de manera precisa.

Asignar menos permisos por defecto es una buena práctica. Reduce el daño si una clave se expone o si hay abuso del flujo de autorización. Menos superficie, menos susto.

Variantes en campaña: códigos QR, aplicaciones creíbles y estafas de consentimiento

El código QR es la forma más fácil de hacer las cosas. No hace falta que la persona copie una dirección. Simplemente tiene que escanear el código para activar algo o para verificar una nueva medida de seguridad. Cuando se hace desde un móvil, todo funciona muy bien y el hecho de que lleve a la página oficial de Microsoft hace que parezca legítimo. Este método se ha visto en carteles en oficinas, documentos compartidos en Teams, correos que parecen anuncios internos y presentaciones de apariencia corporativa. El código muestra un portal conocido; el resto de la coreografía pasa ante los ojos sin ruido.

Otra vía consolidada es el “consent phishing” clásico: no hay código de dispositivo, sino una aplicación con nombre creíble —“SharePoint Sync”, “Document Viewer”, “Adobe Sign”— que solicita permisos amplios. El usuario acepta en la pantalla legítima y, a partir de ahí, la app obra su cometido. Estas campañas trabajan junto con kits de phishing que roban credenciales y tokens MFA en tiempo real. Algunos se especializan en Microsoft 365, combinan páginas espejo con proxies y, después de capturar la sesión, registran una aplicación para prolongar el acceso con OAuth. El resultado final es siempre el mismo: persistencia.

Un detalle importante es que a menudo los atacantes prefieren pedir permisos para leer en lugar de escribir. Leer es más silencioso y no genera tantos cambios que puedan activar alarmas. De esta manera, pueden espiar correos y archivos durante mucho tiempo sin ser detectados.

Si el objetivo es cometer fraude de pagos, el atacante observa conversaciones reales para intervenir en el momento adecuado. Pueden enviar instrucciones discretas, como un “nuevo número de cuenta” o una “actualización de proveedor”, y hacer que parezcan provenir del remitente legítimo. La cadena de confianza se rompe, pero el hilo parece auténtico porque lo es.

En empresas que usan Copilot y automatizaciones conectadas a Graph, conviene prestar atención a los permisos que se dan a agentes o conectores. Si un agente no está configurado correctamente, puede pedir permisos de más y dejar una puerta abierta. Revisar qué agentes hay, qué pueden leer y quién aprobó esos accesos evita sustos.

El permiso es la llave

El tablero ha cambiado: el token pesa más que la contraseña. El atacante busca consentimiento, no credenciales. Por eso el blindaje eficaz pasa por cerrar el grifo del device code flow salvo necesidad demostrada, limitar quién puede autorizar aplicaciones y qué permisos están permitidos, y mantener una higiene constante de concesiones. Cuando la intrusión ya ha ocurrido, lo decisivo no es únicamente el cambio de contraseña, sino retirar el permiso que sostiene la sesión y, en su caso, eliminar la aplicación que la perpetúa.

La historia reciente con Microsoft 365 deja una moraleja práctica: cuanto más granular es el control del consentimiento, menos margen tiene el adversario para moverse sin ruido. Con unas pocas decisiones bien aplicadas —bloqueo del device code flow, consentimiento restringido, revisión periódica de apps y una respuesta ordenada ante señales de abuso—, ese mensaje perfecto que llega a la bandeja pierde su poder. La trampa se queda sin llave. Y la cuenta, aunque cambie de manos durante unos minutos, recupera la cerradura.

🔎​ Contenido Verificado ✔️

Este artículo ha sido redactado basándose en información procedente de fuentes oficiales y confiables, garantizando su precisión y actualidad. Fuentes consultadas: MuyComputerPRO, CEPYMEnews, Proofpoint, Microsoft Learn.