La estrategia de Shelby

Conclusiones clave

• La familia de malware SHELBY abusa de GitHub para comando y control, robando datos y recuperando comandos.
• El diseño C2 del atacante tiene una falla crítica: cualquiera con el token PAT puede controlar las máquinas infectadas, lo que expone una vulnerabilidad de seguridad significativa.
• El código no empleado y la carga útil dinámica sugieren que el malware está en desarrollo activo, lo que indica que futuras actualizaciones pueden solucionar cualquier problema con las versiones contemporáneas.

Resumen

Como parte de nuestra investigación en curso sobre amenazas emergentes, analizamos un posible email de phishing enviado desde una dirección de email perteneciente a una compañía de telecomunicaciones iraquí y enviado a otros empleados de esa misma compañía.

El email de phishing se basa en que la víctima abra el archivo adjunto Details.zip y ejecute el binario contenido, JPerf-3.0.0.exe. Este binario emplea el sistema de instalación controlado por script, Inno setup, que contiene la aplicación maliciosa:

• %AppData%\Local\Microsoft\HTTPApi:
  • HTTPApi.dll (SHELBYC2)
  • HTTPService.dll (SHELBYLOADER)
  • Microsoft.Http.Api.exe
  • Microsoft.Http.Api.exe.config

El Microsoft.Http.Api.exe instalado es un ejecutable .NET benigno. Su propósito principal es cargar lateralmente el HTTPService.dll malicioso. Una vez cargado, HTTPService.dll actúa como cargador, iniciando la comunicación con GitHub para su comando y control (C2).

El cargador recupera un valor específico del C2, que se emplea para descifrar la carga útil de la puerta trasera, HTTPApi.dll. Luego del descifrado, la puerta trasera se carga en la memoria como un ensamblaje gestionado mediante reflexión, lo que le permite ejecutar sin escribir en el disco y evadir los mecanismos de detección tradicionales.

Al momento de escribir este artículo, tanto la puerta trasera como el cargador tienen una tasa de detección baja en VirusTotal.

Análisis del código SHELBYLOADER

Ofuscación

Tanto el cargador como la puerta trasera están ofuscados con la herramienta de código abierto Obfuscar, que emplea el cifrado de cadenas como una de sus características. Para evitar esta ofuscación, podemos aprovechar de4dot con parámetros personalizados. Obfuscar reemplaza cadenas con llamadas a una función de descifrado de cadenas, pero al proporcionar el token de esta función a de4dot, podemos desofuscar el código de manera efectiva. Usando los parámetros --strtyp (el tipo de descifrador de cadenas, en nuestro caso delegate) y --strtok (el token del método de descifrado de cadenas), podemos reemplazar estas llamadas de función con sus valores de texto simple correspondientes, revelando las cadenas originales en el código.

Detección de sandbox

SHELBYLOADER emplea técnicas de detección de sandbox para identificar entornos virtualizados o monitoreados. Una vez ejecutado, envía los resultados a C2. Estos resultados se empaquetan como archivos de registro que detallan si cada método de detección identificó con éxito un entorno sandbox, por ejemplo:

Técnica 1: Consulta WMI para obtener información del sistema

El malware ejecuta una consulta WMI (Select * from Win32_ComputerSystem) para recuperar detalles del sistema. Luego verifica los campos Fabricante y Modelo en busca de indicadores de una máquina virtual, como "VMware" o "VirtualBox".

Técnica 2: Enumeración de procesos

El malware escanea los procesos en ejecución en busca de servicios conocidos relacionados con la virtualización, incluidos:

• vmsrvc
• vmtools
• xenservice
• vboxservice
• vboxtray

La presencia de estos procesos le indica al malware que puede estar ejecutar en un entorno virtualizado.

Técnica 3: Comprobaciones del sistema de archivos

El malware busca la existencia de archivos de controladores específicos comúnmente asociados con el software de virtualización, como:

• C:\Windows\System32\drivers\VBoxMouse.sys
• C:\Windows\System32\drivers\VBoxGuest.sys
• C:\Windows\System32\drivers\vmhgfs.sys
• C:\Windows\System32\drivers\vmci.sys

Técnica 4: Análisis del tamaño del disco

El malware comprueba el tamaño del volumen C: . Si el tamaño es menor a 50 GB, se puede inferir que el entorno es parte de un espacio aislado, ya que muchas máquinas virtuales están configuradas con tamaños de disco más pequeños para fines de prueba.

Técnica 5: Verificación del proceso principal

El malware examina su proceso padre. Si el proceso principal no es explorer.exe, puede indicar que se ejecuta dentro de un entorno de análisis automatizado en lugar de un escenario típico controlado por el usuario.

Técnica 6: Detección de la desviación del tiempo de sueño

El malware emplea controles de tiempo para detectar si sus funciones de suspensión o retraso se están acelerando, una técnica común empleada por los entornos sandbox para acelerar el análisis. Desviaciones significativas en los tiempos de sueño esperados pueden revelar un entorno aislado.

Técnica 7: Consulta WMI para el controlador de video

El malware ejecuta una consulta WMI (SELECT * FROM Win32_VideoController) para recuperar información sobre el controlador de video del sistema. Luego compara el nombre del controlador de video con los valores conocidos asociados con las máquinas virtuales: virtual , vmware o vbox.

Funcionalidad principal

El código del cargador del malware comienza inicializando varias variables dentro de su constructor de clase principal. Estas variables incluyen:

• Un nombre de cuenta de GitHub
• Un nombre de repositorio privado
• Un token de acceso personal (PAT) para autenticar y acceder al repositorio

Además, el malware configura dos temporizadores, que se emplean para activar acciones específicas a intervalos predefinidos.

Uno de los temporizadores está configurado para activar un método específico 125 segundos luego de la ejecución. Cuando se invoca, este método establece persistencia en el sistema infectado agregando una nueva entrada a la clave del Registro de Windows SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Una vez que se activa el método y se ejecuta correctamente el mecanismo de persistencia, se detiene el temporizador y no se activa más.

Este método emplea una variable entera para indicar el resultado de su operación. La siguiente tabla describe cada valor posible y su significado:

Este valor entero se informa a C2 durante su primer registro, lo que permite a los atacantes monitorear el éxito o el fracaso del mecanismo de persistencia en el sistema infectado.

El segundo temporizador está configurado para activar un método responsable de cargar la puerta trasera, que se ejecuta 65 segundos después de que se inicia el malware. En primer lugar, el malware genera un hash MD5 basado en una combinación de información específica del sistema. Los datos empleados para crear el hash tienen el siguiente formato, con cada componente separado por una barra ( / ):

• El número de procesadores disponibles en el sistema.
• El nombre de la máquina (nombre de host).
• El nombre de dominio asociado con la cuenta de usuario.
• El nombre de usuario del usuario actualmente conectado.
• El número total de unidades lógicas presentes en el sistema.

Luego se extrae un subconjunto de este hash y se emplea como identificador único para la máquina infectada. Este identificador sirve a los atacantes para rastrear y gestionar los sistemas comprometidos dentro de su infraestructura.

Luego de generar el identificador único, el malware envía una nueva confirmación al repositorio myToken mediante una solicitud HTTPS. La confirmación incluye un directorio llamado según el identificador único, que contiene un archivo llamado Info.txt. Este archivo almacena la siguiente información sobre el sistema infectado:

• El nombre de dominio asociado con la cuenta de usuario.
• El nombre de usuario del usuario actualmente conectado.
• El registro de los resultados de la detección de sandbox que detalla qué técnicas tuvieron éxito o fallaron.
• La bandera de persistencia (como se describe en la tabla anterior) indica el resultado del mecanismo de persistencia.
• La fecha y hora actuales del evento de balizamiento

El malware primero intenta enviar una confirmación al repositorio sin usar un proxy. Si este intento inicial falla, vuelve a emplear el proxy configurado por el sistema para su comunicación.

Luego de la primera señalización y el registro exitoso de la víctima, el malware intenta acceder al mismo directorio del repositorio de GitHub que creó anteriormente y descargar un archivo llamado License.txt (no observamos ninguna fluctuación en el intervalo de verificación, pero el servidor pudo manejarlo). Si está presente, este archivo contiene un valor de 48 bytes, que se emplea para generar una clave de descifrado AES. El backend del atacante carga este archivo solo luego de validar que el malware no se esté ejecutando en un entorno sandbox. Esto garantiza que solo las infecciones validadas reciban la clave y escalen la cadena de ejecución a la puerta trasera.

El malware genera una clave AES y un vector de inicialización (IV) a partir del contenido de License.txt. Primero, convierte el valor de 48 bytes en hash SHA256, luego emplea el hash resultante como clave y los primeros 16 bytes como IV.

Procede a descifrar el archivo HTTPApi.dll, que contiene la carga útil de la puerta trasera. Luego del descifrado, el malware emplea el método Assembly.Load para cargar de forma reflexiva la puerta trasera en la memoria. Esta técnica permite que el malware ejecute la puerta trasera descifrada directamente sin escribirla en el disco.

Mecanismo de claves basado en DNS

Otra variante de SHELBYLOADER emplea un enfoque diferente para el registro y la recuperación de la secuencia de bytes empleada para generar la clave AES y el IV.

En primer lugar, el malware ejecuta los mismos métodos anti-sandbox, creando una cadena de 1 o 0 dependiendo de si se detecta un sandbox para cada técnica.

Para su registro C2, el malware construye un subdominio bajo arthurshelby.click con tres partes: el primer subdominio es una cadena estática (s), el segundo subdominio es el identificador único codificado en Base32 y el tercer subdominio es una cadena concatenada en el formato DomainName\HostName >> Anti-Sandboxing Results >> Persistence Flag codificado en base32.

Por ejemplo, un dominio completo podría ver así s.grldiyrsmvsggojzmi4wmyi.inevyrcfknfvit2qfvcvinjriffe6ib6hyqdambqgaydambahy7cama.arthurshelby.click

Luego de eso, el malware ejecuta múltiples consultas DNS a los subdominios de arthurshelby.click. Las direcciones IP devueltas por estas consultas se concatenan en una secuencia de bytes, que luego se emplea para generar la clave AES para descifrar la puerta trasera, siguiendo el mismo proceso descrito anteriormente.

Los subdominios siguen este formato:

• El primer subdominio es l<index>, donde el índice corresponde al orden de las llamadas DNS (por ejemplo, l1, l2, etc.), lo que garantiza que la secuencia de bytes se ensamble correctamente.
• El segundo subdominio es el identificador único codificado en Base32.

Análisis del código SHELBYC2

La puerta trasera comienza regenerando el mismo identificador único creado por el cargador. Esto se hace calculando un hash MD5 de la cadena exacta específica del sistema empleada anteriormente. La puerta trasera luego crea un Mutex para garantizar que solo una instancia del malware se ejecute en la máquina infectada. El nombre del Mutex se obtiene anteponiendo la cadena Global\GHS al identificador único.

Luego de 65 segundos, la puerta trasera ejecuta un método que recopila la siguiente información del sistema:

• identidad del usuario actual
• versión del sistema operativo
• el ID del proceso del malware
• nombre de la máquina
• directorio de trabajo actual

Curiosamente, esta información recopilada no se emplea localmente ni se filtra al servidor C2. Esto sugiere que el código podría ser código muerto, dejado atrás durante el desarrollo, o que el malware aún está bajo desarrollo activo, con posibles planes de emplear estos datos en versiones futuras.

Luego, el malware carga la marca de tiempo actual en un archivo llamado Vivante.txt en el repositorio myGit dentro de su directorio único (nombrado empleando el identificador único del sistema). Esta marca de tiempo sirve como la última hora de señalización, lo que permite a los atacantes monitorear la actividad del malware y confirmar que el sistema infectado aún está activo. La palabra "Vivante" se traduce como "vivo" en francés, lo que refleja el papel del archivo como indicador de latidos de la máquina comprometida.

A continuación, el malware intenta descargar el archivo Command.txt, que contiene una lista de comandos emitidos por el operador para su ejecución en el sistema infectado.

Si Command.txt no contiene comandos, el malware busca comandos en otro archivo llamado Broadcast.txt. A diferencia de Command.txt, este archivo se encuentra fuera del directorio del malware y se emplea para transmitir comandos a todos los sistemas infectados simultáneamente. Este enfoque permite al atacante ejecutar operaciones simultáneamente en múltiples máquinas comprometidas, agilizando el control a gran escala.

Tabla de manejo de comandos:

Los comandos en el archivo Command.txt pueden ser comandos manejados o comandos del sistema ejecutados con Powershell. A continuación se muestra una descripción de cada comando manejado.

/descargar

Este comando descarga un archivo de un repositorio de GitHub a la máquina infectada. Requiere dos parámetros:

• El nombre del archivo almacenado en el repositorio de GitHub.
• La ruta donde se almacenará el archivo en la máquina infectada.

/subir

Este comando carga un archivo desde la máquina infectada al repositorio de GitHub. Toma un parámetro: la ruta del archivo que se va a cargar.

/dextraer

Este comando descarga un archivo zip del repositorio de GitHub (similar a /download), extrae su contenido y lo almacena en un directorio específico en la máquina.

/evocar

Este comando se emplea para cargar un binario .NET de forma reflexiva; toma dos parámetros: el primer parámetro es la ruta de un binario .NET cifrado con AES previamente descargado a la máquina infectada, el segundo parámetro es un valor empleado para derivar AES y el IV, de forma similar a cómo el cargador carga la puerta trasera.

Este comando carga de forma reflexiva un binario .NET de manera similar a cómo SHELBYLOADER carga la puerta trasera. Requiere dos parámetros:

• La ruta a un binario .NET cifrado con AES previamente descargado en la máquina infectada.
• Un valor empleado para derivar la clave AES y el IV.

Comandos del sistema

Cualquier comando que no comience con uno de los anteriores se trata como un comando de PowerShell y se ejecuta en consecuencia.

Comunicación

El malware no emplea la herramienta Git en el backend para enviar confirmaciones. En su lugar, crea solicitudes HTTP para interactuar con GitHub. Envía una confirmación al repositorio empleando un objeto JSON con la siguiente estructura:

{
  "message": "Commit message",
  "content": "<base64 encoded content>",
  "sha": "<hash>"
}

El malware establece encabezados HTTP específicos para la solicitud, incluidos:

• Aceptar: application/vnd.github.v3+json
• Tipo de contenido: application/json
• Autorización: token <PAT_token>
• Agente de usuario: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

La solicitud se envía al punto final de la API de GitHub, construido de la siguiente manera:

https://api.github.com/repos/<owner>/<repo>/contents/<unique identifier>/<file>

El token de acceso personal (PAT) necesario para acceder al repositorio privado está integrado en el binario. Esto permite que el malware se autentique y realice acciones en el repositorio sin emplear la cadena de herramientas estándar de Git.

La forma en que está configurado el malware significa que cualquiera con el PAT (Token de acceso personal) teóricamente puede obtener comandos enviados por el atacante y acceder a las salidas de comandos de cualquier máquina víctima. Esto se debe a que el token PAT está integrado en el binario y puede ser empleado por cualquiera que lo obtenga.

Conclusión de la familia SHELBY

Si bien la infraestructura C2 está diseñada de manera exótica, el atacante pasó por alto los riesgos e participaciones importantes de este enfoque.

Creemos que el uso de este malware, ya sea por parte de un equipo rojo autorizado o de un actor malicioso, constituiría una mala práctica. Permite a cualquier víctima emplear el PAT incorporado como arma y tomar el control de todas las infecciones activas. Además, si una víctima carga muestras a plataformas como VirusTotal o MalwareBazaar, cualquier tercero podría acceder a datos relacionados con la infección o apoderar de la misma por completo.

Análisis de la campaña REF8685

Elastic Security Labs descubrió REF8685 mediante la recopilación y el análisis de rutina de fuentes de datos de terceros. Al estudiar la intrusión REF8685, identificamos un cargador y un implante C2 que determinamos que eran nuevos, lo que nos llevó a publicar este análisis detallado de malware e intrusión.

Las cargas maliciosas fueron enviadas a una compañía de telecomunicaciones con sede en Irak a través de un email de phishing altamente dirigido enviado desde dentro de la organización atacada. El texto del email es una discusión entre ingenieros sobre los detalles técnicos de la gestión de la red. Según el contenido y el contexto del email, no es probable que este señuelo fue elaborado externamente, lo que indica el compromiso de puntos finales de ingenieros, servidores de correo o ambos.

Dears,

We would appreciate it if you would check the following alarms on Core Network many (ASSOCIATION) have been flapped.

Problem Text
*** ALARM 620 A1/APT "ARHLRF2SPX1.9IP"U 250213 1406
M3UA DESTINATION INACCESSIBLE
DEST            SPID
2-1936          ARSMSC1
END

Problem Text
*** ALARM 974 A1/APT "ARHLRF1SPX1.9IP"U 250213 1406
M3UA DESTINATION INACCESSIBLE
DEST            SPID
2-1936          ARSMSC1
END
…

Este email contiene un llamado a la acción para abordar las alarmas de la red y un archivo adjunto comprimido llamado details.zip. Dentro de ese archivo zip hay un archivo de texto que contiene los registros abordados en el email y un ejecutable de Windows (JPerf-3.0.0.exe), que inicia la cadena de ejecución, lo que da como resultado la entrega del implante SHELBYC2, que proporciona acceso remoto al entorno.

Aunque no se observó en la intrusión REF8685, debe tener que VirusTotal muestra que JPerf-3.0.0.exe (feb5d225fa38efe2a627ddfbe9654bf59c171ac0742cd565b7a5f22b45a4cc3a) se incluyó en un archivo comprimido separado (JPerf-3.0.0.zip) y también se envió desde Irak. No está claro si se trata de la misma víctima o de otra de esta campaña. Una búsqueda de similitud de archivos también identifica un segundo implante llamado Setup.exe con un archivo comprimido adicional (5c384109d3e578a0107e8518bcb91cd63f6926f0c0d0e01525d34a734445685c).

El análisis de estos archivos (JPerf-3.0.0.exe y Setup.exe) reveló el uso de GitHub para C2 y mecanismos de recuperación de claves AES (más sobre esto en las secciones de análisis de malware). Las cuentas de Github (arthurshellby y johnshelllby) empleadas para el malware REF8685 eran maliciosas y fueron cerradas por Github.

Cabe destacar que Arthur y John Shelby son personajes del serial de televisión británica de drama criminal Peaky Blinders. El programa estuvo en producción desde 2013 hasta 2022.

El dominio arthurshelby[.]click apuntaba a 2.56.126[.]151, un servidor alojado por Stark Industries (AS44477). Este proveedor de alojamiento VPS se empleó para servicios de proxy en otros ataques cibernéticos a gran escala. Este servidor tiene resoluciones superpuestas para:

• arthurshelby[.]click
• [REDACTED]telecom[.]digital
• speed-test[.]click
• [REDACTED]airport[.]cloud
• [REDACTED]airport[.]pro

El archivo comprimido y los dominios C2 de una de las muestras de SHELBYLOADER llevan el nombre de [REDACTED] Telecom, una compañía de telecomunicaciones con sede en Irak. El mapa de cobertura de [REDACTADO] se centra en la región del Kurdistán iraquí en el norte y este del país.

“Sharjaairport” indica una probable tercera víctima objetivo. El Aeropuerto Internacional [REDACTADO] ([REDACTADO]) es un aeropuerto internacional especializado en transporte aéreo de mercancías en los Emiratos Árabes Unidos. Se encuentra a 14,5 millas (23,3 kilómetros) del Aeropuerto Internacional de Dubái (DXB).

[REDACTED]airport[.]cloud resuelto a un nuevo servidor, 2.56.126[.]157, por un día el 21 enero de 2025. Después, apuntó a Google DNS, al servidor legítimo del aeropuerto [REDACTADO] y, finalmente, a una dirección de estacionamiento de Namecheap. El servidor 2.56.126[.]157 alojado por Stark Industries (AS44477) también aloja [REDACTED]-connect[.]online. [REDACTADO] es el código del aeropuerto internacional [REDACTADO].

El dominio [REDACTED]airport[.]cloud tiene un subdominio portal.[REDACTED]airport[.]cloud que apuntó brevemente a 2.56.126[.]188 del 23 de enero25 2025. Luego dirigió el tráfico a 172.86.68[.]55 hasta el momento de escribir este artículo.

Los pivotes hash del banner revelan una combinación de servidor-dominio adicional: 195.16.74[.]138, [REDACTED]-meeting[.]online.

El servidor 172.86.68[.].55 también aloja mail.[REDACTED]tell[.]com, un aparente dominio de phishing dirigido a nuestra víctima original.

Una página de inicio de sesión sitio web estaba alojada en hxxps://portal.[REDACTED]airport[.]cloud/Login (VirusTotal).

Evaluamos que los atacantes emplearon estos dos subdominios para obtener credenciales de inicio de sesión en la nube. Una vez obtenidas estas credenciales (en el caso de [REDACTADO] Telecom), los atacantes accedieron al email en la nube de la víctima y crearon un phishing muy específico empleando como arma los hilos de email internos en curso.

Este email interno armado se empleó para acceder mediante phishing a los puntos finales de las víctimas.

Todos los dominios asociados con esta campaña emplearon certificaciones ZeroSSL y estuvieron en la infraestructura de Stark Industries.

El modelo de diamante del análisis de intrusiones

Elastic Security Labs emplea el modelo de diamante para describir las relaciones de alto nivel entre los adversarios, las capacidades, la infraestructura y las víctimas de las intrusiones. Si bien el modelo de diamante se emplea más comúnmente con intrusiones individuales y aprovechando el subprocesamiento de actividades (sección 8) como una forma de crear relaciones entre incidentes, un modelo centrado en el adversario (sección 7.1.4) Este enfoque permite obtener un único diamante, aunque esté desordenado.

REF8685 y MITRE ATT&CK

Elastic usa el framework MITRE ATT&CK para documentar tácticas, técnicas y procedimientos comunes que las amenazas persistentes avanzadas emplean contra las redes empresariales.

Táctica

La táctica representa el porqué de una técnica o subtécnica. Es el objetivo táctico del adversario: la razón para realizar una acción.

• Comando y control
• Acceso inicial
• Evasión de defensa
• Descubrimiento
• Ejecución
• Exfiltración

Técnicas

Las técnicas representan cómo un adversario logra un objetivo táctico mediante la realización de una acción.

• Carga de código reflectante
• Phishing
• Información o archivos ofuscados
• Intérprete de comandos y secuencias de comandos
• Exfiltración a través del canal C2

Regla YARA

Elastic Security creó reglas YARA para identificar esta actividad. A continuación se muestran las reglas de YARA para identificar el malware SHELBYC2 y SHELBYLOADER:

rule Windows_Trojan_ShelbyLoader {
    meta:
        author = "Elastic Security"
        creation_date = "2025-03-11"
        last_modified = "2025-03-25"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "ShelbyLoader"
        threat_name = "Windows.Trojan.ShelbyLoader"
        license = "Elastic License v2"

    strings:
        $a0 = "[WARN] Unusual parent process detected: "
        $a1 = "[ERROR] Exception in CheckParentProcess:" fullword
        $a2 = "[INFO] Sandbox Not Detected by CheckParentProcess" fullword
        $b0 = { 22 63 6F 6E 74 65 6E 74 22 3A 20 22 2E 2B 3F 22 }
        $b1 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 }
        $b2 = "Persist ID: " fullword
        $b3 = "https://api.github.com/repos/" fullword
    condition:
        all of ($a*) or all of ($b*)
}

rule Windows_Trojan_ShelbyC2 {
    meta:
        author = "Elastic Security"
        creation_date = "2025-03-11"
        last_modified = "2025-03-25"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "ShelbyC2"
        threat_name = "Windows.Trojan.ShelbyC2"
        license = "Elastic License v2"

    strings:
        $a0 = "File Uploaded Successfully" fullword
        $a1 = "/dlextract" fullword
        $a2 = "/evoke" fullword
        $a4 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 }
        $a5 = { 22 2C 22 73 68 61 22 3A 22 }
    condition:
        all of them
}

Observaciones

Todos los observables también están disponibles para su descarga en formato ECS y STIX en un paquete zip combinado.

En esta investigación se discutieron los siguientes observables.