Servidores de Exchange hackeados a través de aplicaciones OAuth para phishing

Los investigadores de Microsoft investigaron recientemente un ataque en el que se implementaron aplicaciones OAuth maliciosas en inquilinos de la nube comprometidos y luego se usaron para controlar la configuración de Exchange Online y distribuir spam. La investigación reveló que el actor de amenazas lanzó ataques de relleno de credenciales contra cuentas de alto riesgo que no tenían habilitada la autenticación multifactor (MFA) y aprovechó las cuentas de administrador no seguras para obtener acceso inicial. El acceso no autorizado al inquilino de la nube permitió al actor crear una aplicación OAuth maliciosa que agregó un conector entrante malicioso en el servidor de correo electrónico. Luego, el actor usó el conector de entrada malicioso para enviar correos electrónicos no deseados que parecían haberse originado en el dominio de los objetivos.

Microsoft ha estado monitoreando la creciente popularidad del abuso de aplicaciones OAuth. Uno de los primeros usos maliciosos observados de aplicaciones OAuth en la naturaleza es el phishing de consentimiento . Los ataques de phishing de consentimiento tienen como objetivo engañar a los usuarios para que otorguen permisos a aplicaciones OAuth maliciosas para obtener acceso a los servicios en la nube legítimos del usuario (servidores de correo, almacenamiento de archivos, API de administración, etc.). En los últimos años, Microsoft ha observado que cada vez más actores de amenazas, incluidos actores de estados nacionales , han estado utilizando aplicaciones OAuth para diferentes propósitos maliciosos: comunicación de comando y control (C2), puertas traseras, phishing, redirecciones, etc. en.

Este ataque reciente involucró una red de aplicaciones de inquilino único instaladas en organizaciones comprometidas que se usaban como la plataforma de identidad del actor para realizar el ataque. Tan pronto como se reveló la red, se eliminaron todas las aplicaciones relacionadas y se enviaron notificaciones a los clientes, incluidos los pasos de remediación recomendados.

Este blog presenta el análisis técnico de este vector de ataque y la siguiente campaña de spam intentada por el actor de amenazas. También brinda orientación para los defensores sobre cómo proteger a las organizaciones de esta amenaza y cómo las tecnologías de seguridad de Microsoft la detectan.

Acceso inicial

Para que el ataque tuviera éxito, el actor de amenazas necesitaba comprometer a los usuarios de la nube con suficientes permisos que le permitieran crear una aplicación en el entorno de la nube y darle el consentimiento del administrador. El actor realizó ataques de relleno de credenciales contra sus objetivos, intentando acceder a los usuarios con la función de administrador global. Los intentos de autenticación, que se originaron en una sola dirección IP, se iniciaron en la aplicación PowerShell de Azure Active Directory (ID de la aplicación: 1b730954-1685-4b74-9bfd-dac224a7b894). La misma aplicación se usó más tarde para implementar el resto del ataque.

Según la tasa de éxito de los intentos de autenticación, se infiere que el atacante usó un volcado de credenciales comprometidas. La investigación también reveló que el 86 % de los inquilinos comprometidos tenían al menos un administrador con una puntuación de alto riesgo en tiempo real , lo que significa que Azure AD Identity Protection los marcó como muy probablemente comprometidos. También es importante tener en cuenta que todos los administradores comprometidos no tenían MFA habilitado, lo que podría haber detenido el ataque. Estas observaciones amplifican la importancia de asegurar las cuentas y monitorear a los usuarios de alto riesgo, especialmente aquellos con altos privilegios.

Implementación de una aplicación OAuth maliciosa

Una vez que el actor de amenazas obtuvo acceso a los usuarios privilegiados, su siguiente paso fue configurar la aplicación maliciosa. Según el análisis del agente de usuario del evento (Swagger-Codegen/1.4.0.0/csharp) y la rapidez con la que se realizó la implementación de la aplicación, es probable que el actor haya ejecutado un script de PowerShell para realizar lo siguiente en Azure Active Directory (AAD) actividades de gestión en todos los inquilinos objetivo:

• Registre una nueva aplicación de inquilino único con la convención de nomenclatura de [nombre de dominio]_([a-zA-Z]){3} (por ejemplo: Contoso_GhY)
• Agregue el permiso heredado Exchange.ManageAsApp que se puede usar para la autenticación solo de la aplicación del módulo Exchange Online PowerShell
• Otorgar consentimiento de administrador al permiso anterior
• Otorgue roles de administrador global y administrador de Exchange Online a la aplicación previamente registrada
• Agregue las credenciales de la aplicación (clave/certificado/ambos)  

El actor de amenazas agregó sus propias credenciales a la aplicación OAuth, lo que les permitió acceder a la aplicación incluso si el administrador global comprometido inicialmente cambió su contraseña.

Las actividades mencionadas le dieron al actor de amenazas el control de una aplicación altamente privilegiada. Se observó que el actor de amenazas no siempre usaba la aplicación justo después de implementarla. En algunos casos, tomó semanas o meses antes de que se utilizara la aplicación. Además, en las organizaciones que no monitorearon las aplicaciones sospechosas, las aplicaciones se implementaron durante meses y el actor de amenazas las usó varias veces.

Modificación de la configuración de Exchange Online

El actor de amenazas usó la aplicación privilegiada para autenticar el módulo Exchange Online PowerShell y modificar la configuración de Exchange Online. Hubo dos modificaciones que les permitieron realizar el siguiente paso en la cadena de ataque:

Crear un nuevo conector de entrada

Los conectores son una colección de instrucciones que personalizan la forma en que fluye el correo electrónico hacia y desde las organizaciones que utilizanmicrosoft 365oOficina 365. La mayoría de las organizaciones que utilizanmicrosoft 365yOficina 365no necesitan conectores personalizados para el flujo de correo regular, pero algunos los usan cuando necesitan procesar mensajes de otro sistema de mensajería que no ejecuta Exchange Online, o si tienen un dispositivo de red que realiza verificaciones de políticas y luego enruta mensajes a su Exchange Online Servicio.

El actor de amenazas estableció un nuevo conector de entrada con la convención de nomenclatura Ran_([a-zA-Z]){5} (por ejemplo , Ran_xAFzd ). El propósito del conector de entrada era permitir que los correos de ciertas direcciones IP (que están relacionadas con la infraestructura del atacante) fluyan a través del servicio Exchange Online de la víctima. Esto permitió que el actor de amenazas enviara correos electrónicos que parecían haberse originado en el dominio de Exchange comprometido. La información de configuración para los conectores recién creados se vio en el evento de auditoría de Exchange Online New-InboundConnector . La siguiente tabla muestra los parámetros de configuración en el evento de auditoría relacionado con este cambio:

Crear reglas de transporte

Las reglas de transporte (también conocidas como reglas de flujo de correo) son conjuntos de acciones que se pueden realizar en cualquier correo que fluya en la organización. El actor de amenazas utilizó esta característica para establecer 12 nuevas reglas de transporte con la convención de nomenclatura de Test01 a Test012 . Cada una de estas reglas de transporte era responsable de eliminar los siguientes encabezados específicos de cada correo que fluía en la organización:

• X-MS-Exchange-ExternalOriginalInternetSender
• X-MS-Exchange-SkipListedInternetSender
• Recibido-SPF
• Recibió
• ARC-autenticación-resultados
• ARC-Mensaje-Firma
• Firma DKIM
• Sello ARC
• X-MS-Exchange-SenderADCheck
• Resultados de autenticación de X-MS-Exchange
• Autenticación-Resultados
• X-MS-Exchange-AntiSpam-MessageData-ChunkCount

Al eliminar estos encabezados, el atacante intentó evadir la defensa para evitar que los productos de seguridad o los proveedores de correo electrónico detectaran o bloquearan sus correos electrónicos y aumentar la tasa de éxito de la campaña de spam. La información de configuración para las reglas de transporte recién creadas se vio en el evento de auditoría New-TransportRule de Exchange Online . La siguiente tabla muestra los parámetros de configuración en el evento de auditoría relacionado con este cambio:

Estas modificaciones a la configuración de Exchange Online permitieron que el actor de amenazas realizara su objetivo principal en el ataque: enviar correos electrónicos no deseados. Después de cada campaña de spam, el actor eliminó el conector de entrada malicioso y las reglas de transporte para evitar la detección, mientras que la aplicación permaneció implementada en el arrendatario hasta la siguiente ola del ataque (en algunos casos, la aplicación estuvo inactiva durante meses antes de que la reutilizaran). el actor de la amenaza).

Campaña de correo electrónico no deseado enviada a través del conector de Exchange Online

El actor detrás de este ataque ha estado ejecutando activamente campañas de correo electrónico no deseado durante muchos años. Según nuestra investigación, este actor ha enviado grandes volúmenes de correos electrónicos no deseados en períodos cortos a través de otros métodos, como conectarse a servidores de correo desde direcciones IP no autorizadas o enviar directamente desde una infraestructura legítima de envío masivo de correo electrónico basada en la nube.

El motivo del actor era propagar correos electrónicos no deseados de sorteos engañosos diseñados para engañar a los destinatarios para que proporcionen los detalles de la tarjeta de crédito y se registren en suscripciones recurrentes con el pretexto de ganar un premio valioso. Si bien el esquema posiblemente condujo a cargos no deseados para los objetivos, no hubo evidencia de amenazas de seguridad manifiestas, como la suplantación de identidad de credenciales o la distribución de malware.

La campaña de spam llevaba las características de este actor: mensajes generados mediante programación que contenían dos imágenes con hipervínculos visibles en el cuerpo del correo electrónico, así como contenido dinámico y aleatorio inyectado dentro del cuerpo HTML de cada mensaje de correo para evadir los filtros de spam.

Las imágenes con hipervínculos dentro de los mensajes de spam insinuaban a los destinatarios que eran elegibles para un premio. Una vez que se hacía clic, el hipervínculo dirigía a los destinatarios a un sitio web donde se les pedía que completaran una encuesta y proporcionaran los detalles de la tarjeta de crédito para pagar el envío de su premio. Se utilizaron logotipos, nombres y sitios web de marcas familiares en todo el correo electrónico no deseado, probablemente para dar una ilusión de legitimidad.

La letra pequeña, visible solo al desplazarse hasta el final de una página posterior, reveló que al proporcionar la información de su tarjeta de crédito, los destinatarios no pagaban una tarifa de envío por su premio, sino que de hecho aceptaban que se les cobraran tarifas por varias suscripciones pagadas. servicios para participar en un sorteo del premio. Es probable que el motivo principal del actor de la amenaza fuera la posible ganancia financiera de las personas que fueron víctimas de esta engañosa campaña de spam con sorteos.

Probablemente para lograr escalar y maximizar aún más las posibilidades de una entrega de correo electrónico exitosa, el actor desencadenó esta campaña de spam desde la infraestructura de correo electrónico saliente basada en la nube fuera de Microsoft, principalmente Amazon SES y Mail Chimp. Estas plataformas de correo electrónico permiten el envío masivo de correos electrónicos masivos, normalmente con fines de marketing y otros fines legítimos.

La campaña también utilizó técnicas para generar direcciones URL dinámicas únicas que respaldan las imágenes con hipervínculos dentro de cada mensaje de correo electrónico no deseado, como se muestra en los ejemplos a continuación.

Esta campaña de spam se dirigía exclusivamente a las cuentas de correo electrónico de los consumidores. En el caso de los mensajes de spam enviados a cuentas de correo electrónico de consumidores alojadas en Microsoft (outlook.com), los correos electrónicos de spam se movían a las carpetas de correo no deseado de los clientes antes de que pudieran verse y hacer clic en ellos.

Mitigaciones

Si bien la campaña de spam de seguimiento se dirige a las cuentas de correo electrónico de los consumidores, este ataque se dirige a los inquilinos empresariales para utilizarlos como infraestructura para esta campaña. Por lo tanto, este ataque expone las debilidades de seguridad que podrían ser utilizadas por otros actores de amenazas en ataques que podrían afectar directamente a las empresas afectadas.

Dado que el principal vector de acceso inicial del ataque era obtener las credenciales del administrador, recomendamos que las organizaciones sigan los siguientes pasos para reducir su superficie de ataque:

Mitigar los riesgos de los ataques de adivinación de credenciales

Un paso clave para reducir la superficie de ataque es asegurar la infraestructura de identidad. El vector de acceso inicial más común observado en este ataque fue el compromiso de la cuenta a través del relleno de credenciales, y todas las cuentas de administrador comprometidas no tenían MFA habilitado. La implementación de prácticas de seguridad que fortalecen las credenciales de la cuenta , como habilitar MFA, aumenta el costo de un ataque.   

Habilitar políticas de acceso condicional

Las políticas de acceso condicional  se evalúan y aplican cada vez que el usuario intenta iniciar sesión. Las organizaciones pueden protegerse de los ataques que aprovechan las credenciales robadas al habilitar políticas como el cumplimiento de dispositivos o los requisitos de direcciones IP confiables.

Habilitar la evaluación de acceso continuo

La evaluación de acceso continuo  (CAE) revoca el acceso en tiempo real cuando los cambios en las condiciones del usuario desencadenan riesgos, como cuando un usuario es despedido o se muda a una ubicación que no es de confianza.

Habilitar valores predeterminados de seguridad

Si bien algunas de las características mencionadas anteriormente requieren suscripciones pagas, los valores predeterminados de seguridad en Azure AD , que son principalmente para organizaciones que usan el nivel gratuito de licencias de Azure Active Directory, son suficientes para proteger mejor la plataforma de identidad organizacional, ya que brindan configuraciones de seguridad preconfiguradas como como MFA, protección a actividades privilegiadas, y otros.