Site icon Sophos News

Robo de credenciales de usuario con Evilginx

phishing

phishing

Evilginx, una herramienta basada en el legítimo servidor web (y ampliamente utilizado) de código abierto nginx, puede utilizarse para robar nombres de usuario, contraseñas y tokens de sesión, lo que permite a un atacante eludir potencialmente la autenticación multifactor (MFA). En esta entrada, demostraremos cómo funciona Evilginx y qué información es capaz de conseguir; también ofreceremos consejos para detectar esta herramienta, así como posibles mitigaciones.

Cómo funciona

Evilginx utiliza el popular y legítimo servidor web nginx para redirigir el tráfico web a través de sitios maliciosos, creados por el actor de la amenaza para imitar servicios reales como Microsoft 365, un ataque adversario en el medio (AitM). Para demostrarlo, configuramos un dominio malicioso; como se muestra en la Figura 1, tenemos un phishlet de Microsoft con su propio subdominio de ese dominio. Todas las direcciones IP, nombres de usuario, contraseñas y dominios relevantes utilizados en esta publicación fueron desactivados antes de su publicación. El phishlet incluye un señuelo y ese señuelo es lo que el usuario objetivo ve cuando el atacante intenta hacerse con su nombre de usuario y contraseña.

Figura 1: Evilginx en acción, mostrando el dominio malicioso, el phishlet y el señuelo que se utilizará contra el objetivo

Es útil señalar que los formularios y las imágenes que ve el usuario realmente provienen de la propia Microsoft; se transmiten desde la empresa legítima a través del servidor evilginx y de ahí al usuario. En el back-end, evilginx ofrece al atacante opciones para configurar la experiencia. En nuestras pruebas, imitamos una cuenta de usuario protegida por MFA… y rápidamente la sorteamos. Al usuario se le presenta una experiencia de inicio de sesión «normal»; solo cuando hace clic en una de las aplicaciones de la parte izquierda de la pantalla, un usuario experimentado puede notar que algo es extraño, ya que se le pedirá que inicie sesión de nuevo.

Un vistazo a nuestro servidor evilginx muestra lo que está sucediendo.

Figura 2: un servidor evilginx muestra la información capturada y la añade a su base de datos para su posterior abuso

Además de interceptar el nombre de usuario y la contraseña del usuario, también se recopiló el token de sesión, ya que fue pasado por la funcionalidad Keep Me Signed In (Mantenerme conectado) seleccionada por el atacante cuando apareció el mensaje de Microsoft. Evilginx almacena estos datos en una base de datos que recoge la información de cada sesión, incluyendo también la dirección IP pública utilizada para acceder al servidor, el agente de usuario en juego y, lo que es más importante, la cookie. Con esto en la mano, el atacante solo necesita abrir una ventana a la página de inicio de sesión legítima e importar la cookie para iniciar sesión como usuario legítimo.

A partir de aquí, el actor de la amenaza tiene acceso completo a la cuenta de correo del usuario. Las acciones típicas pueden incluir la adición de reglas de buzón. Si el acceso está disponible, el actor de la amenaza también puede restablecer los dispositivos MFA, cambiar contraseñas y realizar otras acciones para obtener persistencia adicional en la cuenta.

Vías de detección

Hay varias formas en que los defensores pueden descubrir actividades de este tipo. En primer lugar, en Azure y Microsoft 365, hay dos ubicaciones principales que realizan un seguimiento de los registros y eventos que pueden revisarse en busca de actividades inusuales. La primera son los registros de inicio de sesión y de auditoría de Entra ID (anteriormente conocido como Azure AD). Los dos ejemplos de la Figura 3 muestran las autenticaciones de nuestros usuarios que se originan en nuestro servidor Evilginx (54.225.206.84) y, a continuación, en el nodo de salida de Tor que utilizamos para nuestra demostración (45.80.158.27). Los registros de auditoría muestran que, después de este inicio de sesión, nuestro atacante añadió una nueva aplicación de autenticación a «su» cuenta.

Figura 3: definitivamente no hay nada sospechoso en una regla de bandeja de entrada llamada Completely Legit Forwarder

En segundo lugar, los registros de Microsoft 365, también llamados registro de auditoría unificado o UAL, muestran que durante la sesión nuestro usuario ilegítimo añadió una nueva regla de bandeja de entrada llamada Completely Legit Forwarder. Para ayudar a revisar estos registros, Microsoft 365 también ofrece un área de búsqueda avanzada dentro del centro de seguridad que te permite utilizar el lenguaje de consulta Kusto para filtrar y encontrar actividades sospechosas utilizando diferentes criterios.

Las alertas de seguridad y los incidentes también se generan cuando se detecta actividad sospechosa. Como ejemplo, podemos ver en la Figura 4 que la cuenta sophos_mfa intentó iniciar sesión desde una dirección IP sospechosa y que se utilizó un token anómalo durante una de esas sesiones.

Figura 4: el token anómalo, la dirección IP anónima y la regla de redireccionamiento sospechosa están marcados

Para los clientes de Sophos, existen integraciones para importar eventos y alertas de Azure y Microsoft 365 a Sophos Central. Dependiendo del paquete de integración XDR específico, las detecciones personalizadas relacionadas con la identidad forman parte del paquete; para los clientes de MDR, esas detecciones son clasificadas por el equipo de MDR como parte del servicio.

Posibles mitigaciones y problemas

Las posibles mitigaciones pueden clasificarse en dos categorías, preventivas y reactivas. Una lista completa de posibles mitigaciones está más allá del alcance de este artículo, pero como siempre, un enfoque bien pensado y por capas es lo mejor cuando se trata de defender cualquier tipo de aplicaciones o servicios que están disponibles públicamente y son de alto valor en tu entorno.

Aun así, es hora de que nosotros, como industria, busquemos medidas más fuertes, migrando de MFA basado en tokens o push hacia métodos de autenticación robustos, resistentes al phishing y basados en FIDO2.

La buena noticia es que hay buenas opciones disponibles en muchas formas: llaves de hardware tipo Yubikey, Apple Touch ID en hardware moderno, Windows Hello para empresas, incluso opciones que incorporan iPhone y Android. Para más ideas sobre formas de mejorar la MFA, consulta el reciente ensayo sobre claves de acceso de Chester Wisniewski.

Las políticas de acceso condicional son otro paso potencial para proteger los entornos de Azure y Microsoft 365. En teoría, por supuesto, se podría seguir la antigua ruta de la lista blanca hecha a mano, bloqueando cualquier dirección IP que no sea de confianza, pero en la práctica se tratarían de gestionar los dispositivos, permitiendo que solo los dispositivos de confianza de la empresa inicien sesión en los sistemas de la empresa. Por supuesto, Sophos y otros proveedores vigilan constantemente y bloquean los sitios maliciosos conocidos como parte de sus servicios, una tarea interminable, y se podría decir que la lista de bloqueo es más fácil de gestionar que la lista blanca.

Dicho esto, en última instancia no podemos confiar en la conciencia del usuario. Los seres humanos son susceptibles de cometer errores y, literalmente, todos serán víctimas del phishing tarde o temprano. El camino a seguir pasa por arquitecturas que sean resistentes cuando los humanos fallan.

Para las mitigaciones reactivas, el primer paso debe ser cerrar la puerta al actor de la amenaza. En este caso, hay una serie de pasos que deben tomarse para asegurarse de que la puerta esté completamente cerrada. Para empezar, revoca todas las sesiones y tokens a través de Entra ID y Microsoft 365, para eliminar el acceso que se ha obtenido. Estas acciones se pueden realizar en la cuenta del usuario tanto en Entra ID como en Microsoft 365 utilizando los botones «Revocar sesiones» y «Cerrar todas las sesiones».

A continuación, restablece las contraseñas y los dispositivos MFA del usuario. Como vimos en los registros, nuestro actor de amenazas añadió un nuevo dispositivo MFA a la cuenta del usuario. Dependiendo del tipo de dispositivo MFA añadido, este puede permitir el acceso sin contraseña a la cuenta, eliminando la eficacia de cambiar las contraseñas y eliminar las sesiones. Utiliza los registros de Microsoft 365 para examinar toda la actividad realizada por el atacante. Detectar cambios ocultos, como la adición de nuevas reglas de bandeja de entrada, es importante para asegurarse de que no pueda salir información adicional de la cuenta del usuario. Los administradores pueden encontrar útil consultar también la guía de investigación de Microsoft sobre el robo de tokens.

Conclusión

Evilginx es un método formidable para eludir la autenticación multifactorial en caso de vulneración de credenciales, y hace viable una técnica de ataque compleja, lo que a su vez puede conducir a un uso generalizado de la técnica. La buena noticia es que las medidas de mitigación y las prácticas que ya deberías estar siguiendo son poderosos elementos disuasorios para el éxito de los atacantes que intentan desplegar esta herramienta contra tu infraestructura.

Exit mobile version