Ingeniería social al helpdesk y restablecimiento MFA en Okta

TL;DR. El atacante llama al servicio de ayuda haciéndose pasar por la víctima y pide que le restablezcan la contraseña o el MFA. En el System Log eso es un user.mfa.factor.reset_all, user.mfa.factor.deactivate o user.account.reset_password cuyo actor no es el objetivo, seguido en pocas horas de un user.mfa.factor.activate del objetivo, normalmente desde una red que ese usuario no ha usado nunca. Restablecimiento más factor nuevo merece una revisión; restablecimiento más factor nuevo desde un ASN nuevo, un proveedor de hosting o un proxy es un incidente. Si la víctima es administradora, da por hecho que el siguiente paso será el abuso de privilegios y un proveedor de identidad malicioso.

Por qué funciona tan bien

Un MFA fuerte protege el inicio de sesión, no el proceso de recuperación que lo rodea. Cuando alguien se hace pasar de forma convincente por un empleado que ha perdido el móvil, un agente bienintencionado hace lo que el procedimiento permite: restablece los factores para que el «empleado» registre un dispositivo nuevo. El atacante registra entonces su dispositivo y se queda con la cuenta, MFA incluido.

No es hipotético. En 2023, Okta Security informó de atacantes que llamaban a servicios de ayuda de TI para que restablecieran todos los factores MFA de usuarios con muchos privilegios, y usaban después esas cuentas para hacerse con el acceso de Super Administrator (Okta Security: cross-tenant impersonation). El aviso de CISA y el FBI sobre Scattered Spider describe al grupo suplantando a empleados y personal de TI en llamadas a los servicios de ayuda (CISA AA23-320A). MITRE ATT&CK cubre las piezas como T1656 Impersonation, T1098.005 Device Registration y T1556.006 Multi-Factor Authentication.

La secuencia en el System Log

Por separado, los pasos 2 y 3 son indistinguibles del soporte legítimo: los restablecimientos de factores son rutinarios. Son los pasos 4 y 5 los que delatan el ataque y, en concreto, de dónde vienen.

Otra pista: el usuario real suele enterarse más tarde, cuando su contraseña deja de funcionar. Unos cuantos user.session.start fallidos con INVALID_CREDENTIALS desde la red habitual del usuario, horas después del restablecimiento, son la víctima intentando entrar.

Cómo lo detecta el analizador

El analizador Okta Forensics tiene dos reglas para este patrón:

La regla baja existe para que la cronología muestre siempre quién restableció a quién; por sí sola no cambia el veredicto. Lo que lo eleva es la regla de secuencia. «Nunca usada antes» se calcula a partir de la propia exportación, por eso una exportación más larga (semanas antes del restablecimiento) hace más fiable el agravamiento. Consulta límites y ajuste.

Distinguir el ataque del trabajo del soporte

Para cada alerta, responde a estas cuatro preguntas:

1. ¿Hay un ticket? Un restablecimiento real tiene ticket, identificador de llamada y un agente que recuerda la llamada. Pregúntale cómo verificó la identidad.
2. ¿De dónde vino el registro del factor? Mira client.ipAddress, securityContext.asOrg y client.userAgent.rawUserAgent en el user.mfa.factor.activate. Compáralos con los inicios de sesión del usuario en las semanas anteriores. Un proveedor de VPS, un país desde el que el usuario nunca ha trabajado o un escritorio Linux para alguien que siempre usa un portátil Windows gestionado son decisivos.
3. ¿Qué hizo la cuenta después? Destinos de SSO, acceso a la Admin Console, acciones de administración. Un usuario normal que abre su correo y su aplicación de RR. HH. tranquiliza. Un administrador que concede roles de inmediato, no.
4. ¿Lo confirma el usuario? Llámale a un número del sistema de RR. HH., no al que dio quien llamó.

Si la víctima es administradora

Trátalo como un compromiso del tenant mientras no se demuestre lo contrario. Pivota sobre la víctima como actor desde el registro del factor y busca:

• user.account.privilege.grant / group.privilege.grant, sobre todo Super Administrator (Super Administrator);
• system.api_token.create;
• system.idp.lifecycle.create y cambios en las reglas de enrutamiento;
• cambios de políticas, autenticadores y zonas de red.

El recorrido por el incidente ficticio es exactamente esta cadena: un restablecimiento del helpdesk para una administradora de TI, un registro de factor desde un VPS, y después una concesión de Super Administrator y un nuevo proveedor de identidad.

Contención

1. Elimina las sesiones de la víctima; revoca los tokens.
2. Quita el factor del atacante; restablece contraseña y factores; vuelve a registrar al usuario real en persona o por un canal fuertemente verificado.
3. Revisa cada asignación de administración, token y proveedor de identidad creados después del restablecimiento.
4. Investiga las aplicaciones abiertas en la sesión del atacante.

Reforzar el helpdesk

Las recomendaciones de Okta tras la campaña de 2023 incluyen restringir lo que puede hacer el personal del helpdesk y reforzar la verificación de identidad antes de los restablecimientos (Okta Security). En la práctica:

• Una verificación que quien llama no pueda investigar: devolución de la llamada a un número del sistema de RR. HH., aprobación del responsable, o comprobación en persona o por vídeo con documento de identidad. Los datos personales sacados de redes sociales no son verificación.
• Un proceso más estricto para administradores: nunca un restablecimiento solo por teléfono en cuentas de administración.
• Alertas sobre la secuencia, no sobre los restablecimientos aislados: restablecimiento por otra persona más registro de factor desde una red nueva, enviado a alguien que pueda llamar al usuario.
• Autenticadores resistentes al phishing para los administradores, vinculados a dispositivos gestionados, para que un restablecimiento por sí solo no permita al atacante registrar cualquier cosa.

Lecturas recomendadas

• Okta Security: Cross-Tenant Impersonation, prevención y detección
• CISA: Scattered Spider (AA23-320A)
• Detección de la fatiga MFA, la otra forma de saltarse un push