A mediados de junio, Huntress presenció un incidente en el que un actor de amenazas comprometió la herramienta de Gestión y Monitoreo Remoto (RMM) de un MSP en un intento de atacar a tres de sus clientes. Si bien el Centro de Operaciones de Seguridad de Huntress (SOC) pudo aislar los endpoints de los clientes afectados y trabajar con el socio, explicamos cómo este ataque es indicativo de actores de amenazas que atacan RMM de MSP para acceder de forma remota y silenciosa a los endpoints de los clientes.
Después de que ocurriera este incidente inicial, vimos surgir más incidentes que mostraban similitudes notables con este. En uno de los incidentes más recientes, se instaló un agente de Huntress para un MSP distinto en medio de un compromiso. En este ataque, que se desarrolló entre el 23 y el 25 de junio, los actores de amenazas también atacaron la instancia de Atera RMM del MSP y desplegaron túneles de Cloudflare, tal como habíamos visto en el incidente anterior. Los actores de amenazas usaron el mismo ID de cuenta en sus tokens de túnel.
Una diferencia notable aquí es que los actores de amenazas en este incidente lograron avanzar más en su ataque: tuvieron éxito al desplegar ransomware Akira en algunos endpoints. El agente de Huntress se instaló después del compromiso inicial y del despliegue del ransomware, por lo que no hubo informes de canary de ransomware, y la telemetría de Detección y respuesta para endpoints (EDR) no estuvo disponible hasta después de la instalación del agente de Huntress.
Como resultado, correlacionar de forma definitiva la actividad observada con el uso que el actor de amenazas hizo de la instancia de Atera RMM del socio recayó en el análisis de registros. Ambos incidentes muestran cómo las instancias de RMM de un MSP pueden permitir que los actores de amenazas afecten a varias empresas en un solo ataque al atacar a los clientes posteriores de los MSP; en este caso, con ransomware Akira.
De Atera RMM a ransomware Akira
El agente de Huntress se instaló en medio de un compromiso después de que una serie de incidentes el 23 y 24 de junio activaran alertas de antivirus administrado (MAV) para el ransomware Akira. Durante las etapas iniciales del despliegue del agente, se vieron afectados cuatro endpoints del MSP: uno del propio MSP y tres de los clientes del MSP.
Como se observa en la Figura 1 a continuación, los endpoints presentaron distintos tipos de actividad: algunos tenían túneles de Cloudflare instalados, mientras que en otros se desplegó ransomware (con éxito), según lo indicado por la detección de MAV. En otros, el actor de amenazas había deshabilitado Windows Defender después de que este detectara y pusiera en cuarentena su intento inicial de desplegar el ransomware.
Figura 1: Variación de acciones maliciosas en cuatro endpoints
Esta disparidad de actividad entre los endpoints afectados refuerza que el agente de Huntress se desplegó en medio de un compromiso, mientras el actor de amenazas estaba en proceso de expandirse por la base de clientes del MSP. Gracias a la respuesta ultrarrápida del SOC, el equipo de Respuesta Táctica y el equipo de Soporte, Huntress pudo evitar que el actor de amenazas avanzara más en la base de clientes del MSP, limitando severamente su impacto.
Endpoint 1
Como se vio anteriormente, en el “Endpoint 1”, los actores de amenazas no pudieron desplegar el ransomware Akira con éxito: MAV detectó y puso en cuarentena el intento de ransomware. Una inspección más detallada de los registros de eventos de Windows mostró la creación y ejecución de un túnel de Cloudflare el 23 de junio, como se ve en el siguiente registro del registro de eventos del sistema:
Service Control Manager/7045C:\Windows\system32\cloudflared.exe tunnel run --token [REDACTED]
El servicio de Windows o “autorun” detectado por la plataforma de Huntress se ilustra en la Figura 2.
Figura 2: Los actores de amenazas configuraron un túnel de Cloudflare antes de intentar desplegar el ransomware
Poco después se creó una cuenta llamada bck; luego, el 24 de junio a las 08:06 UTC, la cuenta bck accedió al endpoint, aparentemente mediante el Protocolo de Escritorio Remoto (RDP), como se ve en la siguiente secuencia de entradas del registro de eventos de Windows:
Microsoft-Windows-Security-Auditing/4624
Microsoft-Windows-TerminalServices-RemoteConnectionManager/1149
Microsoft-Windows-TerminalServices-LocalSessionManager/40
Microsoft-Windows-TerminalServices-LocalSessionManager/25
Es notable que todas estas entradas de registro incluían la dirección IP de origen 127.0.0.1 (localhost), lo cual es una señal reveladora de que se usó una RMM u otro medio de acceso remoto (además del RDP en específico). El nombre de la estación de trabajo desde la que se originó la autenticación también se había observado durante el incidente anterior destacado en nuestro blog anterior.
A las 08:23 UTC, Windows Defender detectó y bloqueó un intento de desplegar Akira. A las 08:24 UTC, un mensaje de Microsoft-Windows-Windows Defender/5001 indicó que la Protección en Tiempo Real (RTP) de Windows Defender había sido deshabilitada. Luego, unos 35 minutos después, la cuenta bck comenzó a ejecutar advanced_port_scanner.exe para mapear la red.
Endpoint 2
Para este endpoint, los registros de actividad de Atera proporcionados por el cliente mostraron una conexión al endpoint, y el registro de eventos de seguridad obtenido del endpoint demostró que se creó la cuenta adm1. Los registros también mostraron que al día siguiente, la cuenta adm1 se usó para acceder al endpoint mediante RDP desde otro endpoint de cliente, uno en el que no se había desplegado el agente de Huntress. Poco después del inicio de sesión, los mensajes del registro de eventos de Windows Defender indicaron que el ejecutable de ransomware, C:\ProgramData\akira.ex_, fue detectado y puesto en cuarentena con éxito.
Figura 3: Detección de MAV del ejecutable del ransomware Akira
Seis segundos después, se deshabilitó la RTP de Windows Defender, y el siguiente código de PowerShell se visualizó en los registros de eventos de Windows, lo que indica el lanzamiento exitoso del ejecutable del ransomware Akira:
powershell.exe -Command Get-WmiObject Win32_Shadowcopy , Remove-WmiObject
A esto le siguieron inmediatamente numerosos registros de eventos de Microsoft-Windows-RestartManager, que se han asociado con el lanzamiento exitoso del ejecutable del ransomware Akira.
Endpoint 3
La actividad en este endpoint comenzó el 23 de junio con una conexión mediante la RMM de Atera, ilustrada en los registros de actividad de Atera proporcionados por el cliente. A esto le siguió el cambio de la contraseña de una cuenta de usuario. Menos de un minuto después, se instaló Cloudflare, y dos horas y media después de completarse la instalación, la cuenta de usuario modificada se usó para iniciar sesión brevemente en el endpoint mediante RDP a través del túnel de Cloudflare, aparentemente para probar la conexión. No se observó ninguna otra actividad en este endpoint.
Endpoint 4
Al igual que con el tercer endpoint, la actividad en este endpoint comenzó con una conexión a través de Atera; en este caso, se instaló Cloudflare y luego se cambió la contraseña de una cuenta de usuario. Luego, unas dos horas y 10 minutos después, hubo una breve conexión a través del túnel de Cloudflare, nuevamente, al parecer para verificar la conexión. No se observó ninguna otra actividad en este endpoint.
Similitudes con el incidente anterior de RMM de MSP
Como vimos con el incidente abordado en la primera parte de esta serie de blogs, se determinó que el vector de acceso inicial para este incidente más reciente fueron las instancias de Atera RMM del MSP.
Sin embargo, hubo algunas diferencias. Para el incidente anterior descrito en nuestra primera parte, pudimos confiar en la telemetría de EDR para ilustrar claramente el acceso del actor de amenazas a los endpoints a través del RMM (como se ve en la Figura 4 a continuación).
Para el ataque abordado en esta publicación de blog, el agente de Huntress se implementó a mitad del incidente; como resultado, no se contó con artefactos como archivos señuelo cifrados o telemetría de EDR. En cambio, al reconstruir el incidente, dependimos únicamente de los archivos de registro obtenidos de los endpoints. En este incidente, el MSP también pudo proporcionar datos de registro que demostraban el acceso a su instancia de Atera RMM, y los analistas de Huntress pudieron correlacionar estos datos con los datos de registro recopilados de los endpoints.
Figura 4: Un árbol de procesos del incidente descrito en nuestro blog anterior que muestra la ejecución de net.exe a través de Atera RMM
En el incidente más reciente, las "marcas de herramientas" dejadas en los registros de eventos de Windows en los endpoints afectados dieron una visión clara de las actividades del actor de amenazas. Estas incluyeron eventos de instalación de servicios para túneles de Cloudflare, artefactos de PowerShell, detecciones de Windows Defender y evidencia de que la aplicación fue deshabilitada, así como "marcas de herramientas" asociadas con el lanzamiento exitoso del ejecutable de ransomware Akira.
Las etiquetas de cuenta de token del túnel de Cloudflare y los nombres de estación de trabajo del actor de amenazas fueron factores comunes en ambos incidentes, lo que demuestra conjuntos extremadamente similares de tácticas, técnicas y procedimientos (TTPs) junto con indicadores de compromiso (IOCs) idénticos.
Se identifica un tercer ataque
Durante la primera semana de julio, el Huntress SOC comenzó a informar un tercer ataque donde, nuevamente, se identificó la instancia de Atera RMM del socio como la fuente de la actividad detectada en múltiples endpoints de clientes. Este tercer ataque fue idéntico a los incidentes anteriores en los siguientes aspectos:
- Linaje de proceso (es decir, Atera utilizado para acceder a los endpoints, instalar túneles de Cloudflare, etc.)
- El ID de cuenta del token del túnel de Cloudflare
- Nombres de estación de trabajo
- La contraseña utilizada al modificar cuentas de usuario
En un endpoint, Windows Defender se deshabilitó después de detectar y poner en cuarentena inicialmente el ejecutable de Akira, el cual se lanzó exitosamente poco tiempo después. Luego, un análisis rápido programado regularmente de Windows Defender detectó y puso en cuarentena el ejecutable por segunda vez.
La Figura 5 ilustra el linaje de proceso observado durante este incidente, que es idéntico a lo observado durante el primer incidente (destacado en la Figura 4).
Figura 5: Linaje de proceso para el tercer ataque
El Huntress SOC respondió de inmediato tras la instalación de los túneles de Cloudflare y la detección por parte de Windows Defender de los intentos iniciales de implementar el ransomware Akira. El SOC aisló los endpoints y notificó al MSP sobre el punto de partida en Atera RMM, interrumpiendo los esfuerzos del actor de amenazas y evitando el resto del ataque.
Los ataques a RMM de MSP continúan
Debido al impacto generalizado que este tipo de incidentes puede generar, los actores de amenazas seguirán atacando a los MSP para afectar a sus clientes. Como describimos en nuestra publicación anterior, los MSP pueden tomar varias medidas para proteger sus herramientas de RMM y las instancias de RMM instaladas en los entornos de los clientes. Estos pasos incluyen crear controles de aplicaciones que cubran los RMM, revisar registros en busca de instancias donde se ejecutaron los RMM, y auditar las herramientas de acceso remoto para vigilar instancias potencialmente no autorizadas.
¿Quieres aprender más sobre las tácticas de los actores de amenazas, como el abuso de RMM? Únete a nuestro equipo cada mes para Tradecraft Tuesday, donde analizamos técnicas de hackers, hablamos de tecnología y mucho más.
