El device code phishing funciona porque la víctima inicia sesión en una página legítima de Microsoft, de modo que no hay ningún login falso que detectar ni ningún dominio parecido que bloquear. La defensa práctica consiste en desactivar el flujo para todos los que no lo necesiten. La propia guía de Microsoft recomienda acercarse lo máximo posible a un bloqueo unilateral del device code flow, y una sola política de Conditional Access lo consigue.
Para qué sirve el device code flow
El flujo existe para dispositivos que no tienen navegador o en los que resulta demasiado incómodo teclear. El RFC 8628 menciona televisores inteligentes, consolas multimedia, marcos de fotos e impresoras. El dispositivo no muestra ninguna página de inicio de sesión. Indica al usuario que visite una URL desde otro dispositivo, como un teléfono, e introduzca un código corto.
El cliente envía su identificador de cliente al servidor de autorización y recibe a cambio un device_code, un user_code, un verification_uri y un valor expires_in. Mientras el usuario inicia sesión en el segundo dispositivo, el cliente consulta periódicamente (polling) el endpoint de tokens con el device_code hasta que recibe un access token, un error o la instrucción de seguir esperando.
En la plataforma de identidad de Microsoft los endpoints son /devicecode y /token. La documentación de Microsoft concede al usuario 15 minutos por defecto para iniciar sesión, y se emite un refresh token si el scope solicitado incluía offline_access.
Por qué funciona como phishing
Quien solicita el código es el cliente. Quien inicia sesión es quien tiene el código en su poder. El protocolo no exige que sean la misma persona, y el RFC 8628 recoge el "Remote Phishing" entre sus consideraciones de seguridad (sección 5.4).
Un atacante puede, por tanto, hacerse pasar por el dispositivo. Solicita un código con un client_id (y un scope, que el endpoint de Microsoft exige) y envía el user_code a su objetivo con algún pretexto. El objetivo abre la página de verificación real, inicia sesión e introduce el código. El cliente del atacante, que ha estado haciendo polling todo el tiempo, recibe los tokens.
La contraseña nunca pasa por una página controlada por el atacante. Por eso las comprobaciones basadas en dominios y URL, como nuestro verificador de enlaces, no tienen nada que marcar aquí.
Aun así, el atacante depende de la víctima. El objetivo debe iniciar sesión e introducir el código antes de que transcurra expires_in (15 minutos por defecto), o el polling fallará con expired_token. A los usuarios de cuentas personales, además, se les pide que vuelvan a iniciar sesión y que den su consentimiento a los permisos solicitados.
Hay una pista útil para la formación. Microsoft no admite verification_uri_complete, el campo opcional que incluye el código dentro de la URL. "Alguien me ha enviado un código para introducirlo en una página de inicio de sesión de Microsoft" es el patrón que conviene enseñar.
Detectar los inicios de sesión con device code
Microsoft recomienda una política que audite el uso actual del flujo, y el modo report-only ofrece justo eso. Cree la política que se describe más abajo en Report-only y consulte los resultados de impacto de la política para ver a quién y qué se habría bloqueado.
Para la búsqueda continua, filtre los sign-in logs de Entra por inicios de sesión con device code y agrúpelos por usuario y aplicación. Se trata de una recomendación de la práctica profesional; las páginas de Microsoft citadas aquí no la documentan. Un inicio de sesión de un usuario que no tiene ningún dispositivo ni herramienta que use el flujo, o de una aplicación que nadie sabe nombrar, merece una conversación. Pregunte al usuario qué mensaje recibió.
Bloquear el flujo con Conditional Access
El recorrido paso a paso está en la guía de Conditional Access de Microsoft. Inicie sesión como mínimo con el rol de Conditional Access Administrator, vaya a Entra ID > Conditional Access > Policies y cree una política nueva. Incluya a todos los usuarios y All resources. En Conditions > Authentication Flows establezca Configure en Yes y seleccione Device code flow. En Grant seleccione Block access y fije Enable policy en Report-only. Pásela a On cuando haya revisado los resultados.
La misma página trata el bloqueo de la authentication transfer, que permite a los usuarios trasladar un inicio de sesión de un PC a un dispositivo móvil. Usa la misma condición de Authentication Flows, así que conviene decidir sobre ella en la misma sesión.
El consejo de Microsoft es permitir el flujo únicamente en casos de uso bien documentados y protegidos, como herramientas heredadas que no se pueden actualizar.
Para lo que deba mantenerse, cree un grupo de exclusión específico con un nombre que indique su finalidad. Registre un responsable y un motivo para cada miembro, y audite la lista con regularidad, tal como aconseja Microsoft. Mantenga también excluidas sus cuentas de acceso de emergencia (break-glass) para evitar un bloqueo total si la política se configura mal.
Por otra parte, Microsoft señala que las llamadas realizadas por service principals no quedan bloqueadas por políticas dirigidas a usuarios, y sugiere sustituir las cuentas de servicio empleadas en scripts o código por managed identities.
Si un phishing con código ya ha tenido éxito
Dé por hecho que el atacante tiene tokens, no solo una contraseña. Un refresh token permite obtener nuevos access tokens, así que revoque primero las sesiones del usuario y restablezca después la contraseña. Es una recomendación de la práctica profesional, no procede de las fuentes anteriores.
A continuación, revise las aplicaciones empresariales y los consentimientos concedidos asociados a la cuenta, y elimine los que no reconozca. Compruebe en el buzón si hay reglas que usted no creó, sobre todo de reenvío o de eliminación.
Amplíe la búsqueda más allá de un solo usuario aplicando el filtro de device code descrito antes al resto de cuentas y buscando la misma aplicación. Si puede haber más de una cuenta afectada, siga un proceso de respuesta adecuado; nuestro equipo de respuesta a incidentes puede acompañarle en él, y nuestro blog ofrece guías sobre respuesta a incidentes y phishing para la parte de formación.
Por dónde empezar
- Haga una lista de todos los dispositivos, scripts y herramientas que puedan iniciar sesión con un código: impresoras, televisores, dispositivos IoT, herramientas de línea de comandos. Pregunte a cada responsable si lo hace.
- Cree la política de Conditional Access con Device code flow seleccionado, todos los usuarios incluidos y las cuentas break-glass excluidas, en modo Report-only. Decida al mismo tiempo sobre la condición de authentication transfer.
- Lea los resultados de report-only y los inicios de sesión con device code en los logs. Corrija o retire cada uso legítimo, y ponga lo que quede en un grupo de exclusión con nombre y con un responsable.
- Pase la política a On y programe en el calendario la auditoría del grupo de exclusión.
- Documente los pasos de respuesta (revocar sesiones, revisar aplicaciones empresariales y consentimientos concedidos, comprobar las reglas del buzón). Explique a la plantilla que un código que no han solicitado ellos mismos, desde un dispositivo que no tienen en la mano, es un intento de phishing.
