La mayoría de las veces que escuchas sobre un compromiso de correo comercial (BEC), escuchas que se comprometió la cuenta de un solo usuario, lo que llevó a grandes pérdidas financieras. Pero en este caso, descubrimos que un atacante tenía acceso a varias cuentas. 👀
Para continuar nuestra serie que expone las tácticas detrás del BEC, este blog analizará cómo Huntress encontró y ayudó a detener un ataque masivo dirigido a múltiples cuentas de usuario dentro de una sola organización. Esto se hizo a través de una cuenta de administrador comprometida de Azure Active Directory (pronto conocido como Microsoft Entra ID), y todo se descubrió durante la fase beta de nuestro producto más reciente, Managed Detection and Response (MDR) para Microsoft 365.
Cómo se desarrolló el ataque
Una de nuestras analistas del SOC estaba revisando la actividad reciente de Microsoft 365 cuando encontró varias reglas de bandeja de entrada sospechosas que se agregaron en múltiples cuentas de usuario dentro del mismo dominio de Azure en rápida sucesión. Al profundizar más en los datos, se dio cuenta de que todas las reglas de bandeja de entrada habían sido agregadas en nombre de los usuarios por uno de los administradores de Azure, quien estaba iniciando sesión desde una ubicación inesperada: Lagos, Nigeria.
Nuestro equipo del SOC reportó de inmediato la actividad a nuestro socio, quien procedió a asegurarse de que a la cuenta afectada se le restableciera la contraseña, se agregara la autenticación multifactor (MFA) como requisito y se eliminaran las reglas de bandeja de entrada. Pero, por supuesto, nuestra investigación no se detuvo ahí…
Debido a la naturaleza del compromiso, queríamos responder:
- ¿Qué más hizo el actor de amenazas mientras tenía las llaves del reino de Azure? Esto significó que debíamos retroceder hasta las primeras señales potenciales de compromiso.
- ¿Había otras acciones que nuestro socio necesitara tomar para garantizar que su entorno estuviera protegido? Esto significó que debíamos auditar cada acción de usuario realizada mientras el actor de amenazas tenía sesión iniciada.
Lo que encontramos durante esta investigación rozaba lo increíble, ya que culminó en una batalla épica entre el administrador legítimo de Azure y el actor de amenazas por quién tenía las credenciales de varias cuentas. 🔥
Acciones iniciales del ataque
Poco después del inicio de sesión inicial desde Lagos, el actor de amenazas tomó medidas inmediatas para mantener el acceso al entorno comprometido de Azure.
¿Cómo lo hizo? Fue bastante sencillo: eligió otra cuenta de usuario que no se usaba con frecuencia, restableció las credenciales y luego también le otorgó a esa cuenta privilegios de administrador completos en Azure. En otras palabras, el atacante ahora tenía dos cuentas con privilegios administrativos completos que podía usar para causar estragos.
Sin embargo, como el atacante descubrió al probarlo, solo otorgar privilegios de administrador no le dio a su cuenta de administrador alterna los permisos que quería. Entonces, asignó licencias reales a esta cuenta secundaria usando la cuenta original comprometida. Si no quedaba claro antes, esperamos que ahora sí: un atacante que puede iniciar sesión en una cuenta con permisos de administrador global de Azure realmente puede realizar cualquier acción dentro del entorno.
Dame todos los correos
Seguro de contar con un método de respaldo por si perdía el acceso, el atacante entró en modo de robo total, otorgándose permiso para ver las bandejas de entrada de los usuarios y enviar correos en su nombre. En lugar de seguir apuntando a usuarios específicos, comenzó a hacerlo con usuarios en grandes lotes.
Luego el atacante inició una serie de agregados de reglas de correo en nombre de dichos usuarios a través de la primera cuenta de administrador, lo que movería los correos de un dominio específico con apariencia legítima a la carpeta de Historial de conversaciones y los marcaría como leídos. Esto le permitiría al atacante revisar el contenido de estos correos sin ser detectado mientras mantenía acceso persistente.
Luego las cosas se pusieron aún más interesantes. El atacante modificó las reglas varias veces, agregando primero un correo de Gmail y luego una dirección de correo de AOL a las reglas.
Al estilo del topo de Azure
Todo debe llegar a su fin, y en el caso de nuestro atacante, Huntress notificó al administrador legítimo sobre estas actividades maliciosas. El administrador entonces inició sesión para comenzar la remediación completa. Recomendamos deshabilitar temporalmente la cuenta de administrador y cambiar las credenciales, como parte de las remediaciones, además de auditar los permisos de cualquier otra cuenta que tuviera privilegios de administrador.
Al principio, vimos que el administrador real intervino y restableció las credenciales, además de renovar el token de autenticación de la cuenta comprometida (Cuenta 1). Incluso resultó exitoso: poco después apareció un intento fallido de inicio de sesión, donde el atacante intentó volver a entrar desde la IP de Nigeria.
Pero nuestro atacante fue bastante persistente y siguió intentando mantener y recuperar el acceso.
¿Recuerdas esa segunda cuenta que habían comprometido y convertido en administradora? En cuestión de minutos, volvieron a aparecer a través de la segunda cuenta comprometida (Cuenta 2) usando el acceso persistente que habían configurado al inicio del ataque.
El atacante, por supuesto, está preocupado por perder el acceso. Así que configuró el acceso a una tercera cuenta (Cuenta 3) usando el mismo método que antes: restableció la contraseña de una cuenta de usuario poco usada y luego le otorgó permisos.
Lo que pasó después fue que el atacante empezó a usar la Cuenta 3 para seguir agregando reglas maliciosas, hasta que el administrador entró y deshabilitó la cuenta. Sin darse por vencido, el atacante volvió a entrar a la Cuenta 2, restableció la contraseña de la Cuenta 3, la volvió a habilitar y luego inició sesión de nuevo en la Cuenta 3.
En aproximadamente 15 minutos, el administrador verdadero logró recuperar el control de todas las cuentas comprometidas. Pero fue toda una travesía llegar hasta ahí.
Reflexiones finales
Entonces, ¿cómo se podría haber evitado todo esto? ¿Y cuál es la mejor manera de detener un ataque como este, donde el atacante tiene acceso a varias cuentas?
- A cualquier usuario con algún tipo de privilegio administrativo se le debería exigir usar autenticación multifactor (MFA). No exigir MFA es como cerrar una puerta con llave y luego pegar las llaves afuera para que cualquiera las tome. Idealmente, todo usuario debería tener MFA activado, pero esto no es negociable para ningún usuario con poder administrativo.
- Considera usar políticas de acceso condicional en Azure cuando sea posible, para evitar que los usuarios inicien sesión desde países en los que no se espera que estén. Durante un compromiso en curso, puede ser prudente agregar rápidamente una política de acceso condicional que impida inicios de sesión desde el mismo país que el actor de amenazas, mientras se investiga el alcance del compromiso y se hacen mejoras de seguridad a más largo plazo.
- Audita regularmente a los usuarios en Azure que tienen permisos administrativos. Si están de licencia prolongada, considera revocar los permisos temporalmente o configurar alertas para actividad inesperada. Si ya no necesitan los permisos, quítaselos.
Como siempre, esperamos que esto ayude a quienes combaten a los actores de amenazas en el salvaje oeste de Microsoft 365. Si alguna vez decides que necesitas a alguien que te dé Detección y Respuesta Administrada para Microsoft 365, ya sabes a quién llamar. 😉
Continúa con la quinta parte: Legitimate Apps as Traitorware for Persistent Microsoft 365 Compromise
Agradecimiento especial a @f0xtrot_sierra y Sharon Martin por sus contribuciones a esta publicación del blog.
