Para muchos de nosotros en el mercado de los proveedores de servicios administrados, la noticia de una vulnerabilidad en el producto VSA de Kaseya nos tomó por sorpresa. El propósito de este blog es aportar claridad técnica sobre lo que el equipo del SOC de Huntress observó y analizó hasta el momento. Para obtener la guía oficial de Kaseya, asegúrate de consultar su Aviso de actualización de seguridad y sus Procedimientos de eliminación (felicitaciones al equipo de seguridad de Kaseya por el descubrimiento y la rápida respuesta).
Información de contexto
Durante las últimas semanas, nuestro equipo descubrió docenas de tareas programadas sospechosas usadas para ejecutar un payload persistente con privilegios de Local System. Al ejecutarse, los puntos de persistencia iniciaban PowerShell para ejecutar archivos codificados en Base64 almacenados dentro del Registro de Windows y en dominios alojados en Dropbox. El script original usado para infectar los endpoints se veía así:
Monitoreo de la ejecución de PowerShell
Como se ilustra arriba, se establece un punto de persistencia con un único comando de PowerShell que descarga y ejecuta el script de PowerShell en:
- hxxps://dl[.]dropboxusercontent[.]com/s/namkbc37wtx2mdq/reg_load_subsequent.ps1
Al ejecutarse, el script primero valida si su payload ya está en ejecución. Para hacer esto, reúne la lista de procesos en ejecución y no continúa si ya hay más de un proceso de PowerShell en ejecución.
Por más tonto que suene, esta amenaza en particular podría "inmunizarse" temporalmente al ejecutar dos o más procesos de PowerShell de larga duración :)
Selección y almacenamiento de payloads de 32 y 64 bits
Al entregar malware a las víctimas, algunos atacantes se toman el tiempo de asegurarse de que sus payloads coincidan con la arquitectura de los sistemas comprometidos. En este caso, el siguiente código realiza esa verificación:
Para quienes no lo sepan, el atacante eligió medir el tamaño de una estructura de puntero entero. Si el tamaño es de 4 bytes (32 bits), el malware descarga el contenido de los payloads x86 desde las URL correspondientes (nota que terminan en _32.txt). Si la estructura tiene cualquier otro tamaño, el script asume que el endpoint es un sistema de 64 bits.
Con estos datos de payload, el malware almacena el contenido en varios valores de clave del registro junto con otro script de PowerShell fuertemente ofuscado. Los datos se almacenaron en las siguientes rutas:
- Clave: HKLM\SOFTWARE\Microsoft\Powershell\Scripts | Valor: a
- Clave: HKLM\SOFTWARE\Microsoft\Powershell\Scripts | Valor: b
- Clave: HKLM\SOFTWARE\Microsoft\Powershell\Scripts | Valor: c
- Clave: HKLM\SOFTWARE\Microsoft\Powershell\Scripts | Valor: d
- Clave: HKLM\SOFTWARE\Microsoft\Powershell | Valor: ScriptInit
Configuraciones de tareas programadas
Como se mencionó antes, el script de infección aprovechó tareas programadas para su punto de persistencia. Muchos atacantes usan schtasks.exe y sus abundantes parámetros para crear o configurar tareas que ejecuten:
- los payloads deseados
- en los intervalos esperados
- con los privilegios especificados
Sin embargo, este actor decidió crear las tareas programadas a partir de una plantilla XML que también se descarga de Dropbox.
Ocultar tareas programadas a plena vista
En lugar de simplemente crear una tarea programada con un nombre fijo, el script de infección genera de manera astuta un nombre "aleatorio". Lo hace combinando la ruta y el nombre de tarea de dos tareas programadas legítimas, seleccionadas al azar, con el siguiente código:
Para ilustrar mejor cómo funciona esto, usemos estos ejemplos como las tareas programadas seleccionadas al azar:
- \Microsoft\Windows\UPnP\UPnPHostConfig
- \Microsoft\Windows\SettingSync\BackupTask
El código anterior divide cada una de ellas en una "ruta de tarea" y un "nombre de tarea":
- Ruta de tarea #1: \Microsoft\Windows\UPnP
- Nombre de tarea #1: UPnPHostConfig
- Ruta de tarea #2: \Microsoft\Windows\SettingSync
- Nombre de tarea #2: BackupTask
Ahora el script une la segunda ruta de tarea con el primer nombre de tarea para crear un nombre de tarea programada que se oculta fácilmente a plena vista del análisis humano:
- \Microsoft\Windows\SettingSync\UPnPHostConfig
Con este nombre de tarea personalizado y la plantilla XML descargada, el script de infección ejecuta schtasks.exe para crear la tarea programada maliciosa.
schtasks /CREATE /XML $file /TN "$fullTaskName" /F
Código actualizado de PowerShell
En la tarde del 29 de enero de 2018, los atacantes actualizaron el comando de PowerShell descrito en este blog para evadir el Procedimiento de Eliminación Automatizada de Kaseya.
Lo más notable es que la ruta de la clave del registro y el nombre del valor se actualizaron de:
- Clave: HKLM\SOFTWARE\Microsoft\Powershell\Scripts | Valor: *
- Clave: HKLM\SOFTWARE\Microsoft\Powershell | Valor: ScriptInit
a:
- Clave: HKLM\SOFTWARE\Microsoft\Policies\System| Valor: *
- Clave: HKLM\SOFTWARE\Microsoft\Policies| Valor: Start
Esto hizo que el Script de Eliminación Automatizada inicial de Kaseya (XMR.xml) ya no eliminara todos los valores de clave del registro maliciosos.
Lamentablemente, el atacante diseñó este cambio para evitar que se eliminaran nuevos puntos de persistencia basados en tareas programadas, ya que la "firma" original coincidía con la presencia de "ScriptInit" dentro de los argumentos del comando (que ahora es "Start").
Por último, el atacante se puso aún más astuto y decidió poner una puerta trasera en una de las tareas programadas legítimas de Microsoft: "sihboot".
Usando la plantilla XML de tarea programada de la URL anterior, el atacante agregó una Acción de ejecución adicional que una vez más ejecuta el payload malicioso de PowerShell:
Douglas Sanchez de Kaseya ya actualizó los Procedimientos de Eliminación Automatizada oficiales y las Instrucciones de Eliminación Manual.
Eliminación de archivos y scripts
Para ayudar a mitigar el impacto de estos payloads, el equipo del SOC de Huntress coordinó con Dropbox para eliminar las siguientes URL maliciosas
En la tarde del 30 de enero de 2018, el equipo de Dropbox eliminó estos archivos :)
Si te gustaría analizar estos archivos y scripts por tu cuenta, escríbenos a support[at]huntresslabs.com y con gusto te los enviaremos.
¿Tienes curiosidad por saber si sigues comprometido?
Ofrecemos una prueba de 21 días de Huntress para un número ilimitado de computadoras. Simplemente despliega nuestro agente, configura una integración de reportes en tu sistema de tickets, y te daremos procedimientos de remediación paso a paso para cada endpoint comprometido que descubramos. Cuando termine la prueba, nuestro equipo puede desinstalar remotamente nuestros agentes con un solo clic (sin limpieza adicional). Contacta a sales[at]huntresslabs.com para demos y más detalles :)
