MFA.

Durante años, una de las recomendaciones más importantes en ciberseguridad ha sido clara: utiliza autenticación multifactor.

Y sigue siendo un consejo fundamental.

Pero los atacantes están aprendiendo que, en lugar de intentar romper directamente los controles de seguridad, pueden buscar algo mucho más interesante: aprovechar la confianza que existe entre esos controles.

Ese es el concepto detrás de TrustSink, una técnica que pone el foco en Microsoft Entra ID y en los entornos de identidad federada.

En lugar de llevar a la víctima a una página de phishing evidentemente falsa, TrustSink busca insertarse en un flujo de autenticación legítimo mediante un proveedor de autenticación multifactor (MFA) malicioso.

El usuario cree que está iniciando sesión normalmente.

El sistema cree que está trabajando con un proveedor de confianza.

Mientras tanto, el atacante puede estar capturando las credenciales.

TrustSink cambia la pregunta: ¿en quién confías para autenticar a tus usuarios?

La fortaleza de un sistema de identidad federada depende, en gran medida, de las relaciones de confianza que existen dentro de él.

Las organizaciones utilizan proveedores de identidad, mecanismos de autenticación y servicios externos para facilitar el acceso seguro a aplicaciones y recursos corporativos.

TrustSink intenta convertir esa confianza en una oportunidad de ataque.

La técnica introduce un proveedor MFA malicioso dentro del proceso de autenticación. Cuando un usuario inicia sesión a través de un portal legítimo, sus credenciales pueden pasar por ese componente antes de completar el proceso de autenticación.

Esto abre la puerta a la captura de las contraseñas en tiempo real.

Y aquí está la diferencia fundamental frente al phishing tradicional:

el usuario no necesariamente está interactuando con una página falsa.

Está utilizando un flujo de autenticación que parece legítimo.

El problema no es solamente robar una contraseña

Una contraseña comprometida ya representa un riesgo.

Pero cuando esa contraseña pertenece a una identidad corporativa con acceso a Microsoft Entra ID, Microsoft 365, aplicaciones empresariales y recursos en la nube, el impacto potencial puede ser mucho mayor.

Una credencial válida puede convertirse en el punto de partida para:

• Acceder a aplicaciones y servicios corporativos.

• Consultar información confidencial.

• Comprometer otras cuentas.

• Intentar elevar privilegios.

• Realizar movimiento lateral.

• Mantener acceso persistente.

• Preparar ataques posteriores, incluido ransomware.

Por eso, la identidad se ha convertido en uno de los activos más importantes que una organización debe proteger.

Si un atacante controla una identidad legítima, puede intentar comportarse como un usuario legítimo.

Y eso hace que la detección sea mucho más complicada.

Cuando el ataque utiliza la infraestructura legítima

Esta es probablemente la característica más preocupante de TrustSink.

El phishing tradicional intenta engañar al usuario para que abandone el entorno legítimo y entre en una página controlada por el atacante.

TrustSink plantea otro escenario.

El atacante busca aprovechar el propio ecosistema de autenticación y las relaciones de confianza existentes.

Esto puede reducir algunas de las señales que normalmente ayudan a detectar un ataque de phishing.

No necesariamente hay una página con una URL extraña.

No necesariamente existe un correo lleno de errores.

No necesariamente el usuario recibe una alerta evidente.

En cambio, el ataque intenta integrarse en un proceso que la víctima ya reconoce como normal.

La confianza deja de ser únicamente una defensa y se convierte en parte de la superficie de ataque.

MFA sigue siendo importante. Pero MFA no puede tratarse como una solución aislada

TrustSink también deja una lección importante sobre la autenticación multifactor.

MFA continúa siendo uno de los controles más importantes para reducir el riesgo asociado con credenciales robadas. Sin embargo, ningún mecanismo de seguridad debería considerarse una barrera absoluta.

Los atacantes están evolucionando.

Ya no se limitan a intentar obtener una contraseña mediante phishing. También buscan manipular sesiones, robar tokens, explotar procesos de autenticación y abusar de relaciones de confianza.

Por eso, proteger la identidad requiere una estrategia más amplia.

No basta con preguntar “¿el usuario tiene MFA?”.

También debemos preguntar:

¿Quién puede modificar la configuración de autenticación?

¿Qué proveedores externos están autorizados?

¿Qué relaciones de federación existen?

¿Qué cambios se están realizando?

¿Desde dónde se están produciendo las autenticaciones?

¿El comportamiento coincide realmente con el usuario?

Estas preguntas forman parte de una estrategia de seguridad de identidad mucho más robusta.

¿Quién está más expuesto?

El riesgo es especialmente relevante para organizaciones que dependen de Microsoft Entra ID con configuraciones de identidad federada y mantienen relaciones con proveedores externos de identidad o autenticación.

Una gobernanza deficiente puede ampliar considerablemente la superficie de ataque.

Por ejemplo, una organización puede tener dificultades para detectar o controlar:

• Proveedores de identidad externos que ya no deberían tener acceso.

• Configuraciones de federación excesivamente permisivas.

• Usuarios con privilegios para modificar mecanismos de autenticación.

• Cambios inesperados en proveedores MFA.

• Actividad de autenticación anómala.

• Relaciones de confianza que no han sido revisadas recientemente.

El problema es que una configuración que alguna vez fue necesaria puede convertirse, con el tiempo, en una puerta que nadie recuerda que dejó abierta.

¿Cómo reducir el riesgo de TrustSink?

La defensa comienza por recuperar visibilidad sobre quién y qué tiene capacidad para intervenir en los procesos de autenticación.

Barracuda recomienda adoptar varias medidas:

1. Revisar las relaciones de confianza

Audite periódicamente los proveedores de identidad externos y las configuraciones de MFA asociadas a Microsoft Entra ID.

La pregunta no debería ser únicamente “¿funciona?”, sino también “¿sigue siendo necesario y confiable?”

2. Aplicar controles estrictos de acceso

Utilice políticas de acceso condicional para limitar la autenticación proveniente de proveedores no autorizados o que no cumplan los requisitos de seguridad establecidos.

3. Vigilar los cambios en la federación

Habilite registros y alertas avanzadas para detectar modificaciones inesperadas en la configuración de identidad, proveedores de autenticación y relaciones de federación.

Un cambio aparentemente pequeño puede tener consecuencias importantes.

4. Reducir los privilegios administrativos

Limite el número de usuarios capaces de modificar configuraciones de federación o agregar proveedores externos de autenticación.

Cuantas menos identidades puedan cambiar las reglas de confianza, menor será la superficie de ataque.

5. Adoptar un enfoque Zero Trust

No asuma que una identidad, dispositivo o proveedor es confiable simplemente porque ya se encuentra dentro del ecosistema.

La confianza debe evaluarse continuamente antes de conceder acceso a recursos sensibles.

6. Considerar métodos de autenticación resistentes al phishing

Siempre que sea posible, las organizaciones deberían evaluar mecanismos como claves de seguridad FIDO2 o autenticación basada en certificados, reduciendo la dependencia de métodos que puedan ser susceptibles a determinadas técnicas de robo de credenciales.

La nueva batalla por la identidad

TrustSink representa una evolución importante en la forma en que debemos pensar sobre la seguridad de las identidades.

Durante mucho tiempo, la estrategia consistía en proteger las credenciales.

Después, añadimos MFA para protegerlas mejor.

Ahora los atacantes están buscando algo más sofisticado:

atacar el sistema que determina en quién confiamos para autenticar esas identidades.

Ese cambio obliga a las organizaciones a ampliar su perspectiva.

La seguridad de identidad no consiste únicamente en proteger nombres de usuario y contraseñas. También implica proteger las relaciones, configuraciones, proveedores y privilegios que hacen posible la autenticación.

Porque si un atacante consigue robar una contraseña, tenemos un problema.

Pero si consigue que el sistema confíe en él para obtenerla, tenemos un problema mucho mayor.

La lección de TrustSink es clara: en un entorno donde la identidad se ha convertido en el nuevo perímetro, la confianza también debe ser protegida.