Device code phishing en Microsoft 365: el ataque que abusa de flujos legítimos de autenticación

El device code phishing en Microsoft 365 demuestra que no todos los ataques de phishing buscan que un usuario escriba su contraseña en una página falsa.

En algunos escenarios, el objetivo es distinto: lograr que el propio usuario autorice una sesión legítima iniciada por el atacante.
Sin robar la contraseña.

Sin usar necesariamente un sitio falso.

Y, muchas veces, aprovechando una página real de Microsoft.

El problema no está en una falla puntual de Microsoft 365. Está en el abuso de un flujo legítimo de autenticación, pensado para dispositivos donde ingresar credenciales puede ser difícil.

Por eso, la pregunta ya no es solo si una organización tiene MFA activada. La pregunta es más amplia: qué tan controlados están sus flujos de autenticación, sus tokens y sus sesiones activas.

Qué es el device code phishing

El device code flow es un mecanismo legítimo de autenticación basado en OAuth.

Se utiliza en dispositivos con entrada limitada, como pantallas compartidas, dispositivos IoT, impresoras, salas de reunión, ciertos equipos Teams o herramientas de línea de comandos. En estos casos, el dispositivo muestra un código y el usuario completa la autenticación desde otro navegador.

En un uso legítimo, el flujo tiene sentido.

El riesgo aparece cuando un atacante lo inicia desde su propio entorno y luego engaña al usuario para que ingrese el código en una página real de Microsoft.

Si el usuario completa la autenticación, el atacante puede recibir tokens válidos asociados a esa sesión.

La idea central es simple, pero crítica: el usuario puede estar autenticándose en una página legítima, pero autorizando una sesión que no inició.

Por eso este tipo de ataque puede ser difícil de identificar para usuarios finales. La señal de alerta no siempre está en el dominio. Muchas veces está en el contexto.

Por qué este ataque es relevante para Microsoft 365

Microsoft 365 concentra correo, archivos, conversaciones, documentos compartidos, reuniones, permisos y aplicaciones críticas.

Por eso, una cuenta comprometida puede abrir la puerta a mucho más que una casilla de email.

Un atacante con tokens válidos podría intentar acceder a Outlook, Teams, SharePoint, OneDrive u otros recursos corporativos, según los permisos disponibles. También podría revisar conversaciones, descargar archivos, crear reglas maliciosas de correo o buscar oportunidades de movimiento lateral.

El riesgo principal no es solo la credencial.

Es la sesión autorizada.

En este escenario, la MFA tradicional puede no ofrecer la protección esperada si el usuario aprueba una autenticación que no inició. Esto no significa que la MFA no sirva. Significa que tener MFA no equivale automáticamente a tener una estrategia de identidad madura.

Los ataques modernos no buscan únicamente contraseñas. También buscan sesiones, tokens, permisos y flujos legítimos que puedan ser utilizados de forma maliciosa.

Cómo suele desarrollarse un ataque de device code phishing

Un ataque de device code phishing en Microsoft 365 suele combinar ingeniería social con abuso de un flujo válido.

La fortaleza del ataque está en que no necesita parecer completamente falso.

Puede apoyarse en mensajes de soporte, supuestas validaciones de cuenta, documentos compartidos, facturas, procesos internos, RFPs o comunicaciones que aparentan urgencia.

Por eso, una frase debería quedar clara en toda organización:

Una página legítima no siempre significa que la solicitud sea legítima.

Si el usuario no inició la autenticación, no debería ingresar un código ni aprobar un acceso.

Señales que deberían activar alerta

El device code phishing puede ser complejo por detrás, pero sus señales pueden explicarse de forma clara.

Un usuario debería sospechar si recibe:

• Un pedido para ingresar un código que no solicitó.
• Instrucciones para “validar” o “recuperar” una cuenta.
• Mensajes de urgencia vinculados a accesos, documentos o facturas.
• Supuestas solicitudes del área de soporte.
• Enlaces a páginas reales de Microsoft, pero con un contexto extraño.
• Pedidos para aprobar una autenticación no iniciada.
• Comunicaciones por Microsoft Teams, email, SMS o plataformas externas que empujan a actuar rápido.

La capacitación no debería limitarse a detectar sitios falsos.

También debe enseñar a reconocer acciones no iniciadas por el usuario.

En seguridad de identidad, el contexto importa tanto como la pantalla que el usuario está viendo.

Qué debería revisar un equipo de IT en Microsoft 365

Antes de aplicar controles, conviene responder una pregunta de arquitectura:

¿La organización realmente necesita device code flow?

No todos los tenants lo requieren. Y cuando existe una necesidad legítima, debería estar documentada, limitada y monitoreada.

Un equipo de IT debería revisar:

• Si hay inicios de sesión recientes mediante device code flow.
• Qué usuarios, aplicaciones o dispositivos lo utilizan.
• Si existen Teams Rooms, dispositivos compartidos o herramientas técnicas que dependan de este flujo.
• Qué cuentas privilegiadas podrían estar expuestas.
• Qué excepciones existen y quién las aprobó.
• Si las políticas de Conditional Access están en modo reporte o activas.
• Si hay alertas ante usos inesperados.
• Si se revisan tokens, sesiones y aplicaciones consentidas ante incidentes.

Este análisis permite tomar una decisión más segura: bloquear el flujo, limitarlo o permitirlo solo en escenarios controlados.

Controles técnicos para reducir el riesgo

La protección contra device code phishing Microsoft 365 debe abordarse por capas.

1. Decisión de arquitectura

El primer paso es definir si el device code flow es necesario.

Si no existe una necesidad clara, conviene bloquearlo por defecto. Si existen usos legítimos, deben quedar identificados y vinculados a un responsable.

Mantener flujos habilitados “por si acaso” puede ampliar la exposición sin aportar valor operativo. Cada flujo permitido sin monitoreo, justificación o control de excepciones amplía la superficie de ataque.

2. Conditional Access: bloquear por defecto, probar antes y controlar excepciones

Conditional Access es una pieza clave para reducir el riesgo de device code phishing en Microsoft 365. Sin embargo, la aplicación de este control debe hacerse con criterio.

Antes de bloquear device code flow, el equipo de IT debería revisar los registros de inicio de sesión en Microsoft Entra ID para identificar si existen usos legítimos en la organización. Algunos dispositivos compartidos, salas de reunión, equipos Teams o herramientas técnicas pueden depender de este flujo. Por eso, el primer paso no es bloquear a ciegas, sino entender el uso real.

Luego, la política debería aplicarse inicialmente en modo reporte. Esto permite validar el impacto, detectar dependencias operativas y ajustar el alcance antes de activar el bloqueo efectivo. Una vez completada esta revisión, la recomendación es bloquear device code flow por defecto y permitir únicamente excepciones controladas.

Estas excepciones deben ser puntuales, justificadas y revisadas periódicamente. Cada una debería tener un responsable, una razón documentada, un alcance limitado y monitoreo asociado. Una excepción amplia o permanente, sin revisión, puede transformarse en una nueva superficie de ataque.

En resumen: bloquear cuando no sea necesario, permitir solo cuando esté justificado y monitorear siempre. Ese es el equilibrio entre seguridad y continuidad operativa.

3. Gobierno de excepciones

Las excepciones pueden ser necesarias en algunos entornos. Pero no deberían ser amplias, permanentes ni difíciles de auditar.

Una excepción saludable tiene justificación técnica o de negocio, responsable asignado, alcance definido, fecha de revisión y monitoreo específico.

En términos prácticos, una excepción no debería convertirse en una puerta permanente sin control.

4. Protección de identidades críticas

Las cuentas privilegiadas, administradores, directivos, áreas financieras y perfiles con acceso a datos sensibles requieren controles más fuertes.

Para estos usuarios, conviene exigir MFA resistente a phishing, como FIDO2, passkeys, certificados o métodos equivalentes soportados por la arquitectura de identidad.

La MFA tradicional sigue siendo valiosa, pero algunos métodos pueden ser más vulnerables a ingeniería social, fatiga MFA o ataques que apuntan a tokens.

5. Detección y monitoreo

La prevención no alcanza si no hay visibilidad.

El equipo de seguridad debería monitorear inicios de sesión asociados a device code flow, sesiones derivadas de este tipo de autenticación, ubicaciones inusuales, aplicaciones inesperadas y accesos desde dispositivos no gestionados.

También es importante revisar actividad anómala en Outlook, Teams, SharePoint y OneDrive, especialmente cuando aparecen cambios en reglas de correo, descargas masivas o consentimientos OAuth sospechosos.

La detección temprana reduce el tiempo de exposición.

6. Respuesta ante sospecha

Si se sospecha compromiso, la respuesta debe enfocarse en identidad, tokens, sesiones y datos.

Las acciones prioritarias incluyen:

• Revocar sesiones activas.
• Invalidar refresh tokens.
• Cambiar credenciales si corresponde.
• Revisar inicios de sesión recientes.
• Analizar actividad en Outlook, Teams, SharePoint y OneDrive.
• Verificar reglas sospechosas de correo.
• Revisar aplicaciones consentidas.
• Identificar descargas o accesos masivos.
• Monitorear movimientos posteriores.
• Documentar el incidente y ajustar políticas.

El objetivo no es solo recuperar la cuenta. Es entender qué pudo hacer el atacante mientras tuvo acceso.

Por qué la MFA tradicional puede no ser suficiente

La MFA reduce muchos riesgos. Pero no elimina todos.

En un ataque de device code phishing, el usuario puede completar una autenticación real para una sesión que no inició. En ese caso, la MFA se cumple, pero el acceso puede beneficiar al atacante.

Por eso, las organizaciones deben dejar de evaluar la identidad solo desde la pregunta “¿tenemos MFA?”.

La evaluación debería ser más profunda:

• ¿Qué métodos MFA están permitidos?
• ¿Son resistentes a phishing?
• ¿Qué cuentas críticas siguen usando métodos más débiles?
• ¿Hay Conditional Access aplicado a flujos de autenticación?
• ¿Se monitorean tokens y sesiones?
• ¿Hay respuesta definida ante robo de tokens Microsoft 365?

La seguridad de identidad no depende de un único control. Depende de una arquitectura coherente.

Cómo puede ayudar Wezen a proteger identidades en Microsoft 365

En escenarios como el device code phishing, la pregunta no es solo qué política activar.

La pregunta es qué nivel de exposición tiene hoy la organización.

En identidad, el riesgo no siempre está en un único control mal configurado. Muchas veces aparece por la falta de visibilidad sobre cómo se autentican los usuarios, qué excepciones existen, qué aplicaciones tienen permisos, qué sesiones permanecen activas y qué eventos generan alertas.

Wezen puede acompañar a las empresas a revisar su postura de identidad y acceso en Microsoft 365 desde una mirada integral: Seguridad de la Información, Infraestructura, Networking, Monitoreo y operación confiable.

Ese acompañamiento puede incluir evaluación de políticas de Conditional Access, revisión del uso de device code flow, hardening de Microsoft Entra ID, fortalecimiento de MFA resistente a phishing, monitoreo de eventos de autenticación y respuesta ante cuentas comprometidas.

El objetivo no es sumar controles aislados. Es construir una arquitectura de identidad más segura, visible y preparada para responder ante amenazas reales.

Preguntas frecuentes sobre device code phishing en Microsoft 365

¿El device code phishing roba la contraseña?

No necesariamente. El ataque puede lograr que el usuario autorice una sesión iniciada por el atacante.

¿La MFA protege contra device code phishing?

Ayuda, pero puede no ser suficiente si el usuario aprueba una autenticación que no inició.

¿Conviene bloquear device code flow?

Si la organización no lo necesita, bloquearlo por defecto reduce superficie de ataque. Si lo necesita, conviene aplicar excepciones controladas.

¿Qué usuarios tienen mayor riesgo?

Cuentas privilegiadas, usuarios financieros, directivos, equipos de IT y perfiles con acceso a información sensible.

¿Qué debería revisar primero una empresa?

El uso real de device code flow, las políticas de Conditional Access, los métodos MFA permitidos y la actividad de tokens/sesiones.

Proteger Microsoft 365 exige mirar más allá de la contraseña

Las amenazas modernas ya no buscan solo contraseñas.

También buscan sesiones, tokens, permisos y accesos legítimos usados de forma maliciosa.

El device code phishing en Microsoft 365 demuestra por qué la seguridad de identidad debe evolucionar. No alcanza con activar MFA y asumir que el riesgo está resuelto. Es necesario revisar flujos de autenticación, limitar excepciones, fortalecer métodos resistentes a phishing, monitorear sesiones y responder rápido ante señales de compromiso.

Microsoft 365 puede ser una plataforma segura, pero su nivel real de protección depende de cómo se configure, gobierne y monitoree.

Evalúa la seguridad de identidad en tu entorno Microsoft 365 y revisa si tus políticas están preparadas para prevenir ataques que abusan de flujos legítimos de autenticación. Escríbenos.

Imagen: generada por IA (DALL·E 3 – GPT-4o), OpenAI, 2026.

Fuentes consultadas

• Microsoft Security Blog. “Inside an AI-enabled device code phishing campaign”. Publicado el 6 de abril de 2026. URL
• Microsoft Learn. “Conditional Access: Authentication flows”. Actualizado el 24 de marzo de 2026. URL
• Microsoft Learn. “Microsoft-managed Conditional Access policies”. Actualizado el 25 de marzo de 2026. URL
• Microsoft Learn. “Restrict device code flow for Microsoft Teams devices with Conditional Access”. Actualizado el 28 de mayo de 2026. URL
• Microsoft Learn. “Require phishing-resistant multifactor authentication for administrators”. Actualizado el 24 de marzo de 2026. URL
• FBI / IC3. “Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens”. Publicado el 21 de mayo de 2026. URL