Por dentro de Greatness: la plataforma PhaaS que burla la MFA

Una plataforma de phishing como servicio (PhaaS) llamada Greatness depende de la evasión de la autenticación multifactor (MFA) para comprometer cuentas de Microsoft 365.

Investigadores de ZeroBEC identificaron la actividad al investigar cuatro correos enviados a una organización protegida, según informó Cyber Security News. Los correos fallaron todas las verificaciones de autenticación. Aun así, llegaron a la bandeja de entrada.

La causa estaba dentro del propio entorno de la víctima. Una exclusión en la lista de remitentes seguros anuló el fallo de autenticación, y es un patrón que los equipos de seguridad empresarial probablemente volverán a ver.

¿Qué es la plataforma PhaaS Greatness?

Greatness comenzó como un kit de phishing y se ha convertido en una plataforma completa. Ofrece a los operadores señuelos listos para usar, dominios configurables y herramientas para atacar cuentas de Microsoft 365, iCloud, Yahoo y Google Workspace. Una campaña reciente usó mensajes falsos de correo de voz de RingCentral y de evaluación de desempeño.

Esta campaña también dependió de un servicio de operador gestionado de forma centralizada y entregado a través de Telegram. El backend compartido de la plataforma permite que los dominios y la infraestructura detrás de una campaña cambien rápidamente, mientras que los patrones de phishing Adversary in the Middle (AiTM) se mantienen iguales.

Cómo ocurre la evasión de MFA

Los correos suplantando a RingCentral fallaron SPF, DKIM y DMARC, tal como se esperaba. Ninguno de los mensajes se envió desde un dominio legítimo de RingCentral, por lo que la autenticación los marcó correctamente como no verificados. La propia lista de remitentes seguros de la empresa anuló ese fallo. Una exclusión basada en el dominio, probablemente configurada por conveniencia, indicó al sistema de correo que entregara los mensajes sin importar lo que reportara la autenticación.

A partir de ahí, Greatness ejecuta una secuencia de phishing AiTM. La víctima ve la marca auténtica de su empresa, introduce una contraseña y completa una verificación de MFA normal. El relé recibe entonces un token. El atacante nunca tiene que adivinar una contraseña ni vencer un segundo factor. Simplemente espera a que la víctima complete un inicio de sesión que, de otro modo, sería rutinario.

El respaldo del phishing por código de dispositivo

Greatness también ofrece una vía de phishing por código de dispositivo para las situaciones en las que el phishing AiTM no resulta práctico. Páginas con apariencia de documentos convencen a la víctima de introducir un código de dispositivo y aprobar un inicio de sesión que, de nuevo, ocurre realmente.

Por qué las exclusiones en la lista de remitentes seguros son peligrosas

Un token de sesión capturado no se limita al correo. Puede exponer Outlook, Teams, SharePoint, OneDrive, calendarios, contactos y aplicaciones registradas, dando al atacante una base de operaciones que va mucho más allá de la bandeja de entrada original.

Pocas organizaciones mantienen un inventario actualizado de cada entrada de su lista de remitentes seguros. Las exclusiones se acumulan con el tiempo y rara vez se revisan. Sin visibilidad continua sobre qué proveedores son de confianza y por qué, una exclusión obsoleta se vuelve indistinguible de una necesaria, hasta que una campaña como esta la encuentra.

Qué deben hacer los equipos de seguridad empresarial

Empiece por la propia lista de remitentes seguros. Audite cada entrada y exclusión de regla de transporte, especialmente para los proveedores de software más comunes. Un dominio solo debería recibir trato especial cuando su correo también pase SPF, DKIM y DMARC. Un aviso de vulneración de un proveedor debería activar la misma revisión de inmediato, ya que una lista de clientes puede revelar qué empresas son más propensas a confiar en el dominio de ese proveedor.

Mejorar la visibilidad en toda la empresa importa tanto como revisar cada exclusión por separado. Los equipos de seguridad necesitan una imagen actualizada de cada remitente y configuración.

Ante una posible vulneración, los responsables deben revocar el acceso y renovar los tokens, rotar las credenciales, inspeccionar las reglas de buzón y los consentimientos de aplicaciones OAuth, y revisar la actividad de Microsoft Graph en busca de algo inusual. Bloquear la infraestructura conocida ayuda, pero monitorear el comportamiento importa más, ya que los operadores de PhaaS pueden reemplazar dominios e infraestructura proxy rápidamente.

Cómo proteger su propio dominio

Esta campaña suplantó el dominio de RingCentral para sortear una excepción en una lista de remitentes seguros. La próxima campaña podría usar su dominio de la misma manera.

Aplicar DMARC en p=reject en sus propios dominios le indica a los servidores receptores qué hacer cuando un mensaje que dice ser suyo falla la autenticación: rechazarlo. Esa instrucción solo funciona si la organización receptora la sigue.

Los mensajes de RingCentral fallaron SPF, DKIM y DMARC porque en realidad no se enviaron desde RingCentral. Una política de p=reject le indica entonces al servidor receptor que rechace un mensaje fallido, pero la exclusión en la lista de remitentes seguros de la empresa receptora anuló esa instrucción y dejó pasar el mensaje de todos modos.

No puede controlar si una empresa receptora sigue esa instrucción, pero sí puede controlar si las configuraciones de DMARC, SPF y DKIM de su propio dominio son precisas y están actualizadas.

La plataforma de Sendmarc brinda a los equipos de seguridad e IT visibilidad centralizada de las configuraciones de SPF, DKIM y DMARC en todos los dominios que poseen, reduciendo la investigación manual para la que los equipos con poco tiempo no disponen.

La mayoría de los equipos de seguridad descubren que su configuración de DMARC, SPF o DKIM se ha desviado solo después de que algo los obliga a preguntarse. Hable con nuestro equipo antes de que eso le ocurra a usted.