Un ataque de ingeniería social nunca antes visto permite hackear la cuenta de administrador de Okta

Okta, un destacado proveedor de soluciones para la gestión de identidades y accesos, ha revelado que durante las últimas semanas sus clientes han sido víctimas de una serie de sofisticados ataques de ingeniería social.
El equipo de seguridad de Okta realizó un estudio y descubrió que los actores de amenazas están utilizando técnicas de ingeniería social para obtener acceso a cuentas privilegiadas, en particular cuentas con capacidades de superadministrador. Los atacantes logran convencer a los empleados de la mesa de ayuda de TI para que restablezcan todos los factores de autenticación multifactor (MFA) que han sido registrados por usuarios altamente privilegiados.

Una vez que un atacante ha obtenido acceso a una cuenta privilegiada, el siguiente paso para él es hacer un mal uso de las capacidades legales de federación de identidades aprovechando su penetración en cuentas de superadministrador de Okta altamente privilegiadas. Esto le da al atacante la capacidad de hacerse pasar por personas dentro de la empresa comprometida.

El acceso de inicio de sesión único se puede obtener de un proveedor de identidad “fuente” confiable utilizando la federación entrante de Okta, que se conecta a un proveedor de identidad “destino”. Los atacantes primero crean su propio proveedor de identidad falso para hacerse pasar por la fuente y luego alteran el parámetro de nombre de usuario para que coincida con un usuario genuino de la empresa que es el objetivo del ataque. Pueden hacerse pasar por usuarios legítimos y acceder a aplicaciones dentro de la empresa objetivo debido a esta vulnerabilidad.

Tácticas, Técnicas y Procedimientos


Okta Security ha encontrado un patrón de comportamiento sospechoso que incluye lo siguiente:

Antes de llamar al servicio de atención de TI de una organización objetivo y exigir un restablecimiento de todos los factores MFA en la cuenta objetivo, los actores de amenazas parecían a) tener credenciales para cuentas de usuarios privilegiados o b) poder influir en el flujo de autenticación delegado a través de Active. Directorio (AD). De cualquier manera, pudieron acceder a la cuenta objetivo. En el caso de los clientes de Okta, el actor de amenazas se dirigió específicamente a personas a las que se les dio acceso equivalente a superadministrador.

Para acceder a la cuenta de usuario que había sido pirateada, el actor de amenazas emplearía servicios de proxy anónimos, así como una IP y un dispositivo que no estaban previamente vinculados con la cuenta de usuario.

Las cuentas de superadministrador comprometidas se utilizaron para proporcionar mayores derechos a otras cuentas y/o restablecer los autenticadores inscritos en cuentas de administrador existentes. Esto se hizo asignando mayores privilegios a otras cuentas. El actor malicioso fue responsable de eliminar algunas reglas de la política de autenticación que requerían un segundo factor en ciertos casos.

Se descubrió que el actor de la amenaza estaba configurando un segundo proveedor de identidad para que funcionara como una “aplicación de suplantación” para poder acceder a las aplicaciones incluidas dentro de la organización comprometida en nombre de otros usuarios. Este segundo proveedor de identidad, que también controla el atacante, funcionaría como un IdP de “origen” en una relación de federación entrante (también conocida como “Org2Org”) con la organización objetivo.

El actor de amenazas cambió el parámetro de nombre de usuario para los usuarios objetivo en el segundo proveedor de identidad “de origen”, de modo que coincidiera con un usuario genuino en el proveedor de identidad “de destino” comprometido. Esta manipulación se llevó a cabo desde este proveedor de identidad “fuente”. Esto hizo posible emplear el inicio de sesión único, o SSO, al iniciar sesión en aplicaciones dentro del IdP objetivo en el contexto del usuario objetivo.

Según Okta, este tipo particular de ataque exhibe “métodos novedosos de movimiento lateral y evasión de defensa” que no se habían observado antes.

La organización ha ofrecido a sus clientes una serie de consejos para protegerse contra este tipo de ataques. Estas incluyen imponer autenticación multifactor (MFA) resistente al phishing, prohibir cuentas privilegiadas, exigir reautenticación para consolas administrativas y monitorear actividades administrativas inusuales.

como proteger

Proteja los procesos de inicio de sesión exigiendo una autenticación resistente al phishing mediante Okta FastPass y FIDO2 WebAuthn. 

Es necesario configurar Políticas de autenticación, también conocidas como Políticas de inicio de sesión de aplicaciones, para exigir una nueva autenticación “en cada inicio de sesión” para obtener acceso a aplicaciones privilegiadas, como la Consola de administración.

Si va a utilizar la recuperación de autoservicio, asegúrese de iniciar el proceso de recuperación utilizando el autenticador más seguro disponible actualmente (Okta Verify o Google Authenticator) y restrinja los flujos de recuperación solo a redes confiables (por IP, ASN, o geolocalización).

Se debe revisar y consolidar el uso de las herramientas de monitoreo y administración remota (RMM) por parte de los empleados de la mesa de ayuda, y se debe bloquear la ejecución de cualquier otra herramienta RMM.

Los procedimientos de verificación de identidad de la mesa de ayuda deben fortalecerse mediante el uso de una combinación de verificación visual, flujos de trabajo delegados en los que los trabajadores de la mesa de ayuda emiten desafíos de MFA para autenticar la identidad de un usuario y/o solicitudes de acceso que necesitan permiso del gerente de línea de un usuario antes de que se puedan restablecer los factores. Todos estos métodos deben usarse junto con otros.

Las alertas de usuario final para dispositivos nuevos y actividades sospechosas deben habilitarse y probarse en este momento.

Es importante revisar y restringir el uso de las funciones de superadministrador. Se debe implementar la gestión de acceso privilegiado (PAM) para el acceso de superadministrador. Se deben utilizar funciones de administrador personalizadas para las tareas de mantenimiento y se deben delegar los trabajos de alto riesgo.

Se deben aplicar políticas administrativas específicas. – Es necesario exigir que los administradores inicien sesión utilizando dispositivos controlados y autenticación multifactor resistente al phishing (Okta FastPass, FIDO2 WebAuthn). La restricción solo debe permitirse en zonas de red confiables y se debe negar el acceso a servidores proxy anónimos.

Aunque la ingeniería social sigue siendo uno de los vectores de ataque más comunes, el daño que pueden causar las credenciales comprometidas puede mitigarse si se siguen las mejores prácticas de seguridad, como privilegios mínimos y autenticación multifactor. Este incidente subraya la necesidad de proteger y monitorear cuentas altamente privilegiadas que actúan como puertas de entrada a los sistemas y datos más sensibles de una organización para evitar el acceso no autorizado a esos sistemas y datos.