Gestionado para el mal: cómo los atacantes convierten el MDM en acceso remoto

Agradecimientos: Un agradecimiento especial a Lindsey Welch, Anton Ovrutsky y Harlan Carvey por sus contribuciones a esta investigación y este informe.

Contexto

Huntress ha observado varios incidentes recientes en los que actores de amenazas aprovecharon aplicaciones de gestión de dispositivos móviles (MDM) para llevar a cabo ataques. En estos casos, se utilizan herramientas de gestión legítimas con fines maliciosos, en lugar de que los actores de amenazas aprovechen debilidades inherentes de las propias aplicaciones, como vulnerabilidades.

Las plataformas MDM son herramientas legítimas que las organizaciones usan para gestionar laptops, teléfonos y otros dispositivos de los empleados. Estas herramientas ayudan a los equipos de TI a inscribir y configurar dispositivos de la empresa de forma remota, aplicar políticas de seguridad e implementar aplicaciones aprobadas. Sin embargo, el control centralizado y el nivel de acceso confiable de estas aplicaciones pueden crear un punto de entrada para los actores de amenazas si se abusa de las herramientas.

Estos incidentes suelen comenzar con ingeniería social: usuarios que caen ante señuelos con temática empresarial que llegan a través de aplicaciones de mensajería y correo electrónico. Si bien no es una lista definitiva de los MDM que podrían usarse en este tipo de ataques, hemos visto a actores de amenazas usar recientemente aplicaciones conocidas de Hexnode y Rippling.

Una vez registrado con la aplicación MDM, el atacante obtiene una vía de gestión confiable y privilegiada en el sistema. En ambos casos descritos aquí, Huntress observó que los actores de amenazas instalaron herramientas RMM (monitoreo y gestión remotos) no autorizadas para avanzar en sus ataques.

El misterio del ScreenConnect que reaparece

Imagina recibir una alerta por una instalación no autorizada de ScreenConnect. Como es natural, dada la gravedad de esta alerta, la priorizas y eliminas el agente de ScreenConnect de inmediato. Sin embargo, varias horas después, recibes otra alerta: la misma instalación no autorizada. Claramente, algo está pasando detrás de escena. 

Una instalación recurrente de ScreenConnect es la primera pista de que esto es más que una implementación aislada y maliciosa de RMM. Si ambas instalaciones se conectaron al mismo relé de destino, esto sugeriría que el mismo actor de amenazas estuvo involucrado en las dos ocasiones. 

Entonces, ¿cómo logran volver a entrar después de haber sido eliminados una vez?

Observamos esta actividad en un incidente reciente, donde dos alertas de Huntress por actividad no autorizada de ScreenConnect en el mismo dispositivo, separadas por varias horas, se conectaron al mismo relé. 

Resultó que un actor de amenazas había logrado previamente instalar un cliente MDM de Hexnode en el sistema en el que ScreenConnect seguía apareciendo. Eliminar el RMM apenas los disuadió. Simplemente prepararon e instalaron el software RMM de nuevo. 

El ataque comenzó con un correo de phishing. El objetivo recibió varios correos con asuntos relacionados con propuestas, como "ATTN: Official Invitation to Submit Proposal" y "Review Required", que mencionaban una organización con la que el objetivo probablemente tenía una relación comercial. 

Al hacer clic en un enlace dentro del correo, se descargó un archivo desde https://webdocusign.viewportal[.]es/Windows/download/index.php

 que se guardó en la carpeta de descargas temporales de Microsoft Edge como eD0cuSign_Installer.msi.

Aunque el archivo se nombró para imitar un instalador de DocuSign, en realidad contenía un paquete de instalación para un MDM de Hexnode, una aplicación legítima de gestión de dispositivos. El paquete incluía Hexnode Gateway, el agente de Hexnode y componentes de soporte de PostgreSQL, todos los cuales se instalaron en el sistema.

Figura 1: Ejecución del MSI de Hexnode, diseñado para parecer un instalador (falso) de DocuSign.

El actor de amenazas continuó instalando ScreenConnect poco después y conectándose al relé controlado por el atacante, relay.bobdthjau[.]com:8041. Esto generó una alerta de Huntress por una instalación no autorizada de ScreenConnect, y el MSP eliminó el RMM del equipo comprometido poco después. 

Sin embargo, varias horas después se instaló otra instancia de ScreenConnect y se reconectó al relé. Esto activó otra alerta, lo que llevó a Huntress a aislar el endpoint, y comenzó una remediación exhaustiva.

Inscripción desde un enlace 

No todos los incidentes involucran técnicas de phishing que engañan a un usuario para que ejecute un instalador MSI. En otro caso, una recepcionista abrió un correo titulado "Re: Tax Planning and Preparation Inquiry". El correo incluía un enlace a lo que parecía ser una invitación a una reunión de Microsoft Teams. 

Al hacer clic en el enlace, el objetivo llegaba a una página titulada "Calendar". Aunque el sitio se dio de baja poco después del intento, probablemente suplantaba un calendario de programación de Teams. Esta página redirigía a un archivo .php que parece haber facilitado la inscripción en un inquilino de Rippling MDM controlado por el atacante. Los tres enlaces residían en el siguiente dominio (consulta la sección de IoC para ver las URL completas):

https://teams-microsoftcom5d41402abc4b2a76b9719d911017c592.kiratham[.]com

Aproximadamente un minuto después de hacer clic en el enlace, apareció una clave de registro de inscripción de Rippling en el sistema comprometido, lo cual es consistente con el registro en la plataforma MDM. Posteriormente se descargó un MSI de instalación para el agente de Rippling en C:\Windows\System32\config\systemprofile\AppData\Local\mdm\{GUID}.msi. Luego se instaló el agente con permisos de nivel SYSTEM como C:\Rippling\daemon.exe.

Una investigación más detallada de Huntress determinó que esta actividad se originó desde el agente de administración en línea de Rippling, lo que sugiere que el actor de amenazas había creado previamente una cuenta para llevar a cabo el ataque.

Aproximadamente 35 minutos después de la instalación, los atacantes usaron el MDM para preparar y ejecutar un instalador de ScreenConnect como SYSTEM, conectándose de vuelta a un dominio controlado por el atacante, relay.pronconetydesire[.]online:8041, lo que activó una alerta de Huntress por una instancia maliciosa de ScreenConnect.

Patrones de Tradecraft y motivaciones

Estos casos, y el abuso de las aplicaciones MDM en general, ponen de relieve una situación frustrante para los profesionales de seguridad. El desafío es que cada vez más herramientas diseñadas para ayudar a las organizaciones a administrar endpoints se están convirtiendo en mecanismos para comprometerlos. De forma similar al uso ilegítimo de los RMM, esto complica aún más lo que podemos considerar con seguridad software confiable, porque la reputación por sí sola no basta para determinar la intención. Ni Hexnode ni Rippling tienen la culpa en esto: a los usuarios simplemente se los engaña mediante ingeniería social para que instalen su software.

Entonces, ¿qué nos queda? La inscripción en MDM debería tratarse como una actividad sensible para la seguridad y no como una tarea administrativa rutinaria. Una inscripción inesperada puede establecer persistencia, dar una vía de implementación privilegiada y permitir que un atacante introduzca herramientas adicionales sin depender de cargas útiles llamativas como malware conocido.

Estos incidentes también demuestran que la detección no puede tratar la instalación de un RMM como un evento aislado. Aunque el cliente RMM, y su actividad posterior, puede haber sido la parte más visible de la intrusión, eliminarlo no elimina la arquitectura de administración no autorizada que lo entregó. 

La secuencia de eventos observada constituye una señal más fuerte: ingeniería social -> nueva inscripción en MDM -> instalación de RMM -> comunicación saliente con un relé desconocido. Como la cadena puede variar, la correlación entre identidad, MDM, endpoint y telemetría de red es nuestra mejor esperanza para brindar la resiliencia necesaria para defendernos de estos ataques. 

Guía de mitigación

Las organizaciones pueden reducir el riesgo de estas técnicas controlando tanto la ruta de inscripción como las aplicaciones que las plataformas MDM tienen permitido implementar. 

• Mantén un inventario de productos MDM, inquilinos, agentes y instancias de RMM autorizados. Trata cualquier inscripción inesperada, agente de administración o instancia de RMM como un incidente de seguridad.

• Capacita a los usuarios para que verifiquen solicitudes inesperadas de reuniones, firma de documentos y revisión de propuestas. Los controles de correo electrónico y web también deben examinar con cuidado los señuelos con temática empresarial.

• Si se sospecha un compromiso, aísla el endpoint, elimina el endpoint del inquilino MDM no autorizado, deshabilita las cuentas creadas por el atacante, revoca las sesiones o tokens activos, restablece las credenciales afectadas y reinstala la imagen del endpoint si no se puede confirmar su integridad.

Indicadores de compromiso (IOC)