Greatness: el kit de phishing como servicio que roba tokens con device code phishing y redefine la seguridad corporativa

El ecosistema del crimen cibernético avanza con rapidez y un nuevo capítulo lo escribe la comercialización de técnicas sofisticadas para eludir controles de seguridad: el kit de phishing-as-a-service (PhaaS) conocido como Greatness ha añadido soporte para el llamado "device code phishing", una variante que abusa del flujo legítimo OAuth 2.0 Device Authorization Grant para capturar tokens y sortear factores de autenticación tradicionales. La novedad no es solo técnica, sino comercial: servicios como éste empaquetan complejidad y la venden por suscripción, reduciendo drásticamente la barrera para que atacantes poco expertos alcancen impactos empresariales graves.

En términos prácticos, device code phishing aprovecha un mecanismo pensado para dispositivos con entrada limitada: el servicio presenta al usuario una página legítima del proveedor de identidad y le pide que introduzca un código corto en otro dispositivo. El engaño funciona porque la página de autenticación es auténtica, pero el atacante controla el flujo que asocia ese código a la sesión del victimario. El resultado es que el atacante obtiene tokens válidos sin que la víctima esté ante una web de login falsa, lo que dificulta la detección por los usuarios y por controles superficiales de correo y navegación. Microsoft mantiene documentación técnica del flujo de dispositivo que explica cómo funciona el grant y por qué puede ser aprovechado de este modo: OAuth 2.0 Device Authorization Grant (Microsoft).

La convergencia de herramientas —AiTM (adversary‑in‑the‑middle), proxies para robo de cookies, plantillas preconstruidas para correos y cadenas de redirección con protecciones anti‑análisis— convierte a plataformas como Greatness en ecosistemas de ataque. Esa profesionalización se traduce en campañas más eficientes: desde la entrega inicial mediante lures que se aprovechan de listas de remitentes seguros hasta la explotación de tokens para explorar y exfiltrar datos vía Microsoft Graph API. Además, la validez prolongada de algunos tokens y la capacidad de generar Primary Refresh Tokens (PRT) para persistencia elevan el riesgo de compromiso sostenido.

Un vector preocupante detectado en campañas recientes es la explotación de configuraciones de confianza existentes con proveedores legítimos (por ejemplo, RingCentral). Si una organización tiene un dominio en su lista de remitentes seguros por ser cliente de un servicio, una filtración del proveedor puede convertirse en una guía para atacantes que saben exactamente qué dominios evitarán los filtros. Eso obliga a repensar la práctica de listas blancas automáticas: tras una brecha de terceros, las configuraciones de exclusión deben revisarse y endurecerse de inmediato.

Las implicaciones operativas son claras: el phishing sigue siendo la puerta de entrada principal y, gracias a PhaaS, los ataques escalan en volumen y en sofisticación sin que aumente necesariamente la pericia del atacante. Esto exige un cambio de estrategia que combine prevención técnica, detección afinada y control del riesgo humano. A nivel de identidad, una palanca crítica es la política de acceso: bloquear globalmente el uso del grant de dispositivo o restringir su aplicación mediante políticas de Conditional Access reduce la superficie de abuso. Microsoft ofrece guías para diseñar políticas de acceso condicional que permitan controlar este tipo de flujos: Overview of Conditional Access (Microsoft).

Además de ajustar políticas, es imprescindible migrar a métodos de autenticación resistentes al phishing, como claves FIDO2 o certificados basados en hardware, y eliminar en lo posible los MFA que dependen de códigos de un solo uso introducidos manualmente o solicitudes de aprobación en aplicaciones que pueden ser simuladas o interceptadas. La formación del personal debe centrarse en un punto concreto: desconfíen de códigos inesperados y de solicitudes de reautenticación sin contexto. La combinación de controles técnicos y concienciación reduce drásticamente la efectividad de campañas basadas en ingeniería social.

En detección y respuesta conviene prestar atención a señales tempranas: autenticaciones por flujos de dispositivo en cuentas que no deberían usarlos, aparición de nuevos dispositivos registrados (posible generación de PRT), uso anómalo de la Microsoft Graph API, creación tardía de reglas de bandeja de entrada y accesos desde infraestructuras proxy que repiten inicios de sesión minutos u horas después de una campaña. Instrumentar alertas y playbooks para rotación de credenciales, revocación de tokens y bloqueo de sesiones sospechosas acorta la ventana de ataque y limita el daño.

La amenaza tiene además una dimensión de higiene organizativa: imponer políticas de DMARC, SPF y DKIM estrictas no es suficiente cuando las listas de remitentes seguros se mantienen sin revisión. Después de cada notificación de compromiso de un proveedor, las organizaciones deben auditar las exclusiones de gateway y validar que no existan rutas alternativas que permitan la entrega de phishing. Las guías prácticas de agencias como CISA sobre cómo protegerse contra phishing siguen siendo un punto de partida útil para equipos de seguridad y responsables de TI: Consejos para protegerse contra phishing (CISA).

Finalmente, no hay que perder de vista la economía del crimen: el acceso a paneles preconfigurados, soporte por Telegram y plantillas listas para usar convierte a la seguridad en una carrera continua. Las infraestructuras internas deben asumir que la próxima campaña llegará y preparar controles que no dependan únicamente de que los usuarios "no caigan" en el engaño. Auditorías periódicas de permisos, reducción de privilegios, segmentación de accesos y políticas de revocación automática al detectar comportamiento anómalo son medidas que, combinadas con autenticación resistente al phishing y una postura de respuesta activa, pueden restar eficacia a los servicios como Greatness.

En resumen, la evolución de los kits de phishing hacia plataformas integradas de token theft exige una respuesta coordinada: limitar y auditar el uso del device code grant, adoptar MFA a prueba de phishing, endurecer exclusiones de correo tras brechas de terceros, y mejorar la detección de uso anómalo de tokens. La defensa eficaz ya no es opcional: es la condición para que las organizaciones mantengan el control de sus identidades y activos en la nube.