Ahora es JA4+: localizamos servidores C2 ocultos mediante cookies y encabezados

El 18 de noviembre, Palo Alto Networks anunció el descubrimiento de dos vulnerabilidades críticas en el sistema operativo PAN-OS, utilizado en los NGFW de la compañía. Al día siguiente, la empresa watchTowr publicó un informe que describe cómo estas vulnerabilidades pueden combinarse para ejecutar código remoto.

Poco después de la publicación del informe de watchTowr, Arctic Wolf Labs registró una serie de intrusiones dirigidas a dispositivos de Palo Alto Networks. Los resultados de la investigación se publicaron el 22 de noviembre.

El 30 de noviembre, John Altaus de FoxIO informó que varios indicadores de compromiso (IoC), presentados por Arctic Wolf, pueden sustituirse por la siguiente huella JA4H: po11cn050000_bb52516416a2_eb49a3237520_*. A partir de esta huella, se logró confirmar varias víctimas de la actividad descrita, lo que corrobora la fiabilidad de los datos de Arctic Wolf.

En este artículo se presenta el análisis de la huella proporcionada por John Altaus, así como dos huellas JA4H adicionales descubiertas en la actividad descrita por Arctic Wolf. Además, se concluye que una huella más general, po11cn050000_bb52516416a2_*, permite identificar la misma actividad con un nivel aceptable de falsos positivos.

Entendiendo JA4H

El 26 de noviembre de 2024, John Altaus publicó un tuit compartiendo la huella JA4H: po11cn050000_bb52516416a2_eb49a3237520_*.

En la familia de huellas JA4+, la tecnología JA4H se encarga de identificar el cliente HTTP que realiza la solicitud. Para ello, analiza el método de la petición, los encabezados, las cookies, sus valores y otras variables de cada solicitud HTTP, creando una huella legible tanto por humanos como por máquinas.

La huella JA4H consta de cuatro partes: a, b, c y d:

• JA4H_a describe los aspectos principales: método HTTP, versión del protocolo, presencia de cookies, encabezado Referrer y número de encabezados.
• JA4H_b es el valor SHA256 truncado de los encabezados en el orden en que aparecen, excluyendo Cookie y Referer.
• JA4H_c crea la huella de los campos de la cookie, que serán iguales para un mismo sitio o aplicación.
• JA4H_d abarca tanto los campos de las cookies como sus valores, lo que hace que esta parte sea la más detallada.

Esta estructura permite que las huellas JA4H sean dinámicas para la detección y la búsqueda de amenazas. La especificidad de la huella aumenta desde la parte a hasta la d, manteniendo artefactos importantes de las solicitudes legibles en la parte a, lo que hace que la huella sea flexible y fácil de modificar.

Ejemplo de análisis de una huella JA4H

Este análisis muestra que, al conocer los principios de formación de la huella, se puede experimentar con reglas de detección personalizadas. Por ejemplo, es posible buscar solicitudes similares con un número diferente de encabezados (po11cn*0000_*_eb49a3237520_*) o solicitudes sin cookies establecidas (po11nn050000_bb52516416a2_*).

Las tres últimas partes de la huella JA4H (_b, _c y _d) son más difíciles de reproducir, ya que no son legibles para el ser humano. Al igual que cualquier hash criptográfico, no se pueden simplemente modificar ni utilizar comodines para incluir o excluir elementos.

Para reproducir JA4H_b y JA4H_c de la huella de Altaus (bb52516416a2 y eb49a3237520), es necesario saber qué encabezados usa el malware. En este caso, dado que el malware se comunica con su C2 a través de HTTP, no se requiere una ingeniería inversa exhaustiva.

Solicitudes recibidas por el implante, según Arctic Wolf

A partir de estos datos se ha confirmado que el malware establece 5 encabezados: Host, User-Agent, Content-Length, Upgrade-Insecure-Requests y Accept-Encoding. Esto coincide con la primera parte de la huella JA4H: po11cn050000.

Con el siguiente script de CyberChef se puede reproducir JA4H_b:

Reproducción de JA4H_b con CyberChef (https://gchq.github.io/CyberChef/)

 Find_/_Replace({'option':'Regex','string':'(Cookie\\:.+|Referer\\:.+)\\r\\n'},'',true,false,true,true) Find_/_Replace({'option':'Regex','string':'(POST|PUT|GET|HEAD).+\\r\\n'},'',true,false,true,false) Find_/_Replace({'option':'Regex','string':'\\:.+'},'',true,false,true,false) Find_/_Replace({'option':'Regex','string':'\\r?\\n'},',',true,false,true,false) SHA2('256',64,160) Regular_expression('User defined','^.{0,12}',true,true,false,false,false,false,'List matches') 

Script de CyberChef para la preparación previa de la huella

También podemos reproducir JA4H_c, que es el SHA256 truncado de la cookie SSID, establecida por el malware:

 import hashlib hashlib.sha256("SSID".encode()).hexdigest()[:12] # eb49a3237520 

Igualmente, podemos usar el script de CyberChef para introducir otras firmas del malware si sospechamos que el virus puede emplear otros encabezados o un orden distinto de los mismos. Cuanto más sepamos sobre el malware y sobre cómo se comporta en la red, mejor podremos ajustar la huella JA4H para lograr detecciones más sólidas y detalladas.

En este caso, el atacante utilizó un framework de C2 de código abierto muy popular, Sliver. Estos frameworks de código abierto ofrecen oportunidades únicas de detección: no necesitamos tener una muestra concreta ni ser expertos en ingeniería inversa. Aun cuando muchos de estos frameworks incluyen ofuscación “listos para usar”, los atacantes a menudo no modifican las configuraciones por defecto. Por ejemplo, el servidor HTTP de Sliver, por defecto, usa los siguientes encabezados de respuesta:

 serverHeaders := []*clientpb.HTTPC2Header{ { Method: "GET", Name: "Cache-Control", Value: "no-store, no-cache, must-revalidate", Probability: 100, }, } 

Cabe destacar que en este fragmento de código, los valores de Cache-Control coinciden con los que aparecen en la muestra analizada por Arctic Fox. Esta coincidencia por sí sola es una posible vía de detección.

Detección de servidores C2 adicionales

El equipo de Webscout utilizó un conjunto amplio de fuentes para recopilar metadatos que enriquecieran y contextualizaran direcciones IP a gran escala. Una de dichas fuentes es la colección de huellas JA4+. Al examinar diversas variantes de la huella JA4H en esta colección, los especialistas descubrieron varias víctimas y otros servidores de C2 dentro del mismo clúster de actividad descrito por Arctic Wolf.

Mediante variaciones ampliadas de la huella JA4H, se identificaron varios servidores C2 adicionales activos, relacionados con la actividad descrita:

• Direcciones IP: 172.232.195[.]234, 194.182.164[.]149

Ambas direcciones son servidores de administración Sliver evidentes, ya que:

1. Abren el puerto TCP 31337;

2. El valor del emisor del certificado SSL es: CN=operators;

3. El valor del sujeto del certificado SSL es: CN=multiplayer.

Huellas JA4H po11cn050000_bb52516416a2_e1eae9e373ba_913d7ea84b88 y po11cn050000_bb52516416a2_a9f2370d1a00_3e59a4bec10d

Suponiendo que el implante por defecto establece solo una cookie, como se muestra en el ejemplo de reproducción de JA4H_b, un rápido rastreo de nombres de cookie llevó a dos nuevas huellas JA4H_c, que antes no se habían observado.

 cookies = [] # lista muy larga de nombres de cookies comunes for cookie in cookies: hash = hashlib.sha256(cookie.encode()).hexdigest()[:12] # JA4H_c if hash == "e1eae9e373ba" or hash == "a9f2370d1a00": print(f"{hash}:{cookie}") > e1eae9e373ba:refreshToken > a9f2370d1a00:csrf-state 

Ambas huellas se incluyen en el conjunto de nombres de cookies que se utilizan por defecto en la configuración del servidor HTTP de Sliver, como puede verse en el código fuente disponible aquí.

La posibilidad de usar una sola huella JA4H para detectar varios otros servidores maliciosos, con conocimientos mínimos sobre el malware subyacente, demuestra la principal ventaja del paquete JA4+: su capacidad para localizar “vecinos maliciosos en huellas digitales” usando cambios apenas perceptibles, cookies, encabezados y otros artefactos en las solicitudes HTTP.

¿Por qué sucede esto?

Los atacantes continúan utilizando configuraciones estándar de los servidores C2, lo que los vuelve más propensos a ser detectados. Los desarrolladores de malware se esfuerzan en ocultar sus herramientas, pero los errores de los operadores —al no configurar estos parámetros— ofrecen oportunidades para su detección. Por ejemplo, Sliver puede alterar dinámicamente su huella JARM aleatorizando los conjuntos de cifrados TLS.

Ejemplo de código para la aleatorización de cifrados:

// Aleatorización de conjuntos de cifrados

 allCipherSuites := []uint16{ tls.TLS_RSA_WITH_RC4_128_SHA, // uint16 = 0x0005 1 tls.TLS_RSA_WITH_3DES_EDE_CBC_SHA, // uint16 = 0x000a 2 tls.TLS_RSA_WITH_AES_128_CBC_SHA, // uint16 = 0x002f 3 tls.TLS_RSA_WITH_AES_256_CBC_SHA, // uint16 = 0x0035 4 tls.TLS_RSA_WITH_AES_128_CBC_SHA256, // uint16 = 0x003c 5 tls.TLS_RSA_WITH_AES_128_GCM_SHA256, // uint16 = 0x009c 6 tls.TLS_RSA_WITH_AES_256_GCM_SHA384, // uint16 = 0x009d 7 tls.TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, // uint16 = 0xc007 8 tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, // uint16 = 0xc009 9 tls.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, // uint16 = 0xc00a 10 tls.TLS_ECDHE_RSA_WITH_RC4_128_SHA, // uint16 = 0xc011 11 tls.TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, // uint16 = 0xc012 12 tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, // uint16 = 0xc013 13 tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, // uint16 = 0xc014 14 tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, // uint16 = 0xc023 15 tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, // uint16 = 0xc027 16 tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, // uint16 = 0xc02f 17 tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, // uint16 = 0xc02b 18 tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, // uint16 = 0xc030 19 tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, // uint16 = 0xc02c 20 tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, // uint16 = 0xcca8 21 tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, // uint16 = 0xcca9 22 } 

// CipherSuites ignora el orden de los cifrados. Este orden aleatorio permite elegir un conjunto aleatorio de cifrados.

 insecureRand.Shuffle(len(allCipherSuites), func(i, j int) { allCipherSuites[i], allCipherSuites[j] = allCipherSuites[j], allCipherSuites[i] }) nCiphers := insecureRand.Intn(len(allCipherSuites)-8) + 8 tlsConfig.CipherSuites = allCipherSuites[:nCiphers] 

No obstante, las funciones de protección contra la detección no sirven de nada si los operadores no las utilizan. Desde el punto de vista del sigilo y la posibilidad de ser detectado, el sistema de protección es tan sólido como su eslabón más débil, que en este caso es el propio atacante.

Otro aspecto importante es la continuidad en el uso de tráfico sin cifrar en muchos frameworks de malware. ¿Por qué pueden hacerlo los atacantes? Porque la mayoría de las organizaciones solo registra datos de NetFlow, los cuales contienen información de alto nivel sobre direcciones IP, puertos, duración de sesiones y volumen de datos transferidos, pero rara vez incluyen detalles de capa 7 (capa de aplicación del modelo OSI), lo que hace ineficaces los métodos de detección.

Mientras las organizaciones no analicen el contenido de los paquetes, el tráfico malicioso sin cifrar seguirá pasando desapercibido. La falta de visibilidad en la capa de paquetes permite a los atacantes emplear canales de comunicación abiertos casi sin riesgo de ser detectados, otorgándoles una ventaja inmerecida.

Conclusión

El uso de huellas JA4H ha demostrado ser eficaz para la detección y el análisis de actividades maliciosas, especialmente en el contexto de la explotación de vulnerabilidades en los cortafuegos de Palo Alto Networks. El análisis y la comprensión de la huella proporcionada por John Altaus (po11cn050000_bb52516416a2_eb49a3237520_*) permitieron identificar servidores de administración adicionales y confirmar la actividad descrita por Arctic Wolf.