El device code phishing se ha convertido en uno de los fenómenos más preocupantes de 2026. En menos de seis meses, esta técnica pasó de ser una curiosidad usada por equipos de red al nivel de “industrial” que hoy aparece en campañas y kits listos para operar. ¿Qué lo hace tan atractivo para atacantes y tan difícil de frenar para los equipos de seguridad?
A continuación, repasamos seis claves, basadas en análisis y observaciones de investigadores, para entender el ritmo de crecimiento, el impacto real y los puntos ciegos de defensa.
1) Supera la MFA atacando la autorización
Lo primero que conviene aclarar es que el device code phishing no se centra en el momento típico del “inicio de sesión”. En su lugar, el abuso ocurre después de que la identidad ya quedó verificada para el usuario. Dicho de forma simple: el ataque aprovecha la capa de autorización y no la validación inicial.
En muchos casos, la víctima ya tiene sesión iniciada en su cuenta del proveedor (por ejemplo, una cuenta corporativa). Luego, se enfrenta a una página maliciosa, copia un código corto, lo introduce en una pantalla legítima del proveedor y aprueba la solicitud desde opciones que parecen normales, como seleccionar una cuenta en un menú y pulsar “permitir”. Esa cadena, completa y breve, es suficiente para que el atacante obtenga el resultado que busca.
Por eso, controles como passkeys, llaves de seguridad o MFA resistente al phishing pueden no detener el problema. La razón estructural es directa: probar identidad y conceder acceso a una aplicación son dos acciones distintas, y muchos mecanismos protegen mejor la primera que la segunda.
2) Se “industrializa” dentro de plataformas de phishing como servicio
Durante años, el phishing sofisticado requería más experiencia y un proceso de desarrollo más complejo. Hoy, el device code phishing se ha vuelto una característica estándar dentro del catálogo de herramientas de phishing como servicio (PhaaS). En otras palabras: ya no hace falta que el atacante “invente” el método; lo consume.
De acuerdo con el seguimiento de proveedores de seguridad, distintos kits incorporaron esta capacidad, incluso en marcos que antes estaban más asociados a otras variantes de robo de identidad. El patrón de comercialización recuerda a lo ocurrido con técnicas de tipo “AiTM”: primero aparecen en entornos de investigación, luego saltan al espionaje patrocinado por Estados y, finalmente, pasan a ser un producto accesible para delincuencia.
La diferencia clave aquí es el ritmo. La transición completa hacia adopción criminal se habría acelerado en cuestión de meses. Esa compresión se explica por la madurez del ecosistema PhaaS y por el impulso que da el desarrollo asistido por IA para construir y distribuir nuevas capacidades.
3) Los atacantes crean kits más rápido de lo que se documenta
Uno de los motivos por los que el device code phishing preocupa tanto es su velocidad de diversificación. Los equipos que monitorean el fenómeno reportan que ya rastrean más de 25 kits distintos en circulación.
Para contextualizarlo, se describe que, antes, la aparición de un kit completamente nuevo de ciertas familias de phishing era un evento relativamente poco frecuente (aproximadamente cada pocos meses). Tener decenas de familias en el mismo año indica un cambio estructural en cómo se fabrican estas herramientas.
La clave operativa es el desarrollo asistido por IA. Muchos kits comparten patrones de diseño y una arquitectura de código similar, porque se generan a partir de instrucciones equivalentes. Incluso se ha demostrado que crear un kit no requiere el mismo nivel de esfuerzo manual que antes.
4) Ya no es solo un problema de Microsoft
En el corto plazo, la mayor parte de la actividad observada se orienta hacia proveedores como Microsoft. Sin embargo, la advertencia es clara: el device code phishing no se limita a un ecosistema. El motivo es que se apoya en el OAuth 2.0 device authorization grant, un estándar con implementación en múltiples plataformas.
Según se documenta, actores vinculados a Estados ya lo han usado contra Salesforce en campañas específicas. En ese escenario, se habría abusado del flujo de device code mediante una aplicación maliciosa diseñada para escalar el impacto y comprometer un gran número de organizaciones, con un volumen enorme de datos expuestos.
También se menciona que plataformas como GitHub y AWS soportan flujos device code, y que en GitHub forman parte de autenticaciones para herramientas de desarrollo y túneles de VS Code. A medida que los desarrolladores de kits se mueven más allá de Microsoft, estos entornos se vuelven objetivos naturales.
5) Forma parte de un cambio más amplio: ataques a la autorización
El device code phishing no es un caso aislado. El foco de los atacantes está migrando desde el “momento de autenticación” hacia el “momento de autorización”. Si los defensores invirtieron principalmente en proteger el inicio de sesión, entonces las capas posteriores quedan con menor cobertura comparativa.
En esa línea, se cita un ejemplo de técnica asociada a phishing de consentimiento en el navegador, aparecida en 2025 y luego incorporada en kits criminales. Al igual que device code phishing, la lógica es que el abuso ocurre tras la autenticación: el usuario termina otorgando permisos bajo una apariencia confiable, y ese acto es el verdadero punto de explotación.
Mientras los atacantes sigan extendiendo ideas sobre consentimiento, registro de dispositivos y mecanismos de intercambio de tokens, el “hueco” defensivo tenderá a ampliarse a menos que los equipos actualicen su enfoque.
6) La detección debe ocurrir donde sucede el abuso
Otro motivo por el que el device code phishing es tan difícil de contener es que el engaño puede llegar por múltiples canales: correo, mensajería, redes sociales, resultados de búsqueda, sitios comprometidos y más. Sin embargo, el paso crítico para entender el problema es que el usuario termina introduciendo un código en una URL legítima del proveedor.
Eso significa que muchas barreras tradicionales no aplican bien: un bloqueo por reputación de URLs, un filtro de gateway de correo o un proxy de red pueden no frenar la aprobación, porque la interacción final transita por infraestructura aparentemente confiable.
En entornos donde se logra, la recomendación típica para Microsoft suele ser restringir flujos device code mediante políticas de acceso condicional. Pero el freno no siempre es viable. Algunos flujos existen por razones legítimas: no desactivarlos podría romper herramientas de desarrollo, flujos de CLI o escenarios con dispositivos restringidos.
Además, incluso si se endurece un proveedor, el riesgo persiste si el kit apunta a otras plataformas equivalentes donde quizá no existan controles comparables o donde no se apliquen las mismas políticas.
Por ello, la postura que se propone es enfocarse en la visibilidad desde el punto donde el usuario ve el engaño y aprueba la solicitud. En el caso descrito, la detección se apoya en un enfoque que analiza firmas de comportamiento del kit y el flujo de aprobación, más que en huellas de dominio o indicadores estáticos. Esa diferencia importa especialmente cuando aparecen familias nuevas con frecuencia y cuando los IOC tradicionales se quedan atrás con rapidez.
Qué puedes hacer hoy
Si tu objetivo es reducir el riesgo de device code phishing, conviene combinar controles y monitoreo con una lectura realista de cómo funciona el ataque:
- Revisa autorizaciones y consentimientos, no solo el inicio de sesión. El foco debe estar en lo que el usuario permite después de autenticarse.
- Evalúa políticas de acceso condicional para device code donde sea posible, pero valida el impacto en flujos legítimos de desarrollo y operaciones.
- Amplía la cobertura a otras plataformas (por ejemplo, servicios que implementan OAuth device flow), no solo al proveedor principal de tu empresa.
- Busca señales de comportamiento asociadas al flujo de aprobación y a la interacción con códigos, evitando depender únicamente de IOCs.
Conclusión
El device code phishing está creciendo con rapidez porque explota una separación estructural: la identidad y la autorización pueden caer bajo controles distintos. Al mismo tiempo, el ecosistema PhaaS lo ha “empaquetado” para operar a escala, mientras que el desarrollo asistido por IA acelera la creación de nuevas variantes.
La defensa efectiva requiere mirar más allá de la MFA y enfocarse en dónde ocurre la aprobación y el otorgamiento de permisos. Si consigues ajustar políticas y monitoreo a esa capa, mejoras tus probabilidades de detectar y frenar el ataque antes de que el token robado se convierta en acceso real.
Fuente: https://thehackernews.com/2026/07/6-reasons-why-device-code-phishing-is.html
