El otro días, tras instalarme un multi honeypot T-POT , estuve investigando un poco sobre JA3 y JA3S , ciertamente no es algo que use muchisimo, pero se que es algo sobre lo que debemos poner foco y potenciar , por que tras jugar y trastear un poco con ello, llegue a ver el potencial que tiene, y por ello, decidí estudiar un poco sobre ello.

Hoy quiero hablaros un poco sobre JA3 y JA3S , qué es , cómo funciona , y cómo ya lo están empezando a aplicar grandes tecnologías y firmas. Os dejo en enlace en el que estuvimos viéndolo:

Y os dejo también , por si no disponéis de cuenta de Link , la captura donde vimos, como identificabamos en Suricata mediante JA3 , que estamos recibiendo ataques con metasploit sobre la vulnerabilidad BlueKeep

Como os indicaba , al menos por mi parte, debo ponerme las pilas, ya que las firmas JA3 / JA3S se han convertido en un popular indicador de compromiso (IOC) y se están incorporado a todo, desde SIEMs como Splunk hasta productos avanzados de IDS / IPS . Las firmas JA3 , como veremos luego en un video de la DEF CON 27 , pueden evadirse, pero a su favor , son altamente efectivas contra el malware desplegado masivamente, evitando de esta forma, un alto porcentaje de ataques a nuestros sistemas. El éxito instrumental de las firmas JA3 es incuestionable, sin embargo, en una amenaza persistente avanzada (APT) modificar estas firmas estará seguro en su checklist de tareas, con el fin de evadir la detección del negocio.

Que es JA3 / JA3S

El concepto principal para la toma de huellas dactilares de los clientes de TLS provino de la investigación de Lee Brotherston en 2015 y disponible, aquí y su charla en DerbyCon. Si no fuera por la investigación de Lee y el código abierto, no se habría comenzado a trabajar sobre JA3.

A modo resumen, las firmas JA3 / JA3S son, huellas dactilares, que combinadas,  pueden ayudar a producir una identificación de mayor fidelidad de la comunicación cifrada entre un cliente específico y su servidor.

Por ejemplo:

Cliente TOR estándar:
JA3 = e7d705a3286e19ea42f587b344ee6865(Cliente Tor)
JA3S = a95ca7eab4d47d051a5cd4fb7b6005dc(Respuesta del servidor Tor)

Los servidores TOR siempre responden al cliente TOR exactamente de la misma manera, proporcionando una mayor confianza de que el tráfico es TOR.

Malware Trickbot:
JA3 = 6734f37431670b3ab4292b8f60f29984(Trickbot)
JA3S = 623de93db17d313345d7ea481e7443cf(Respuesta del servidor C2)

Malware Emotet:
JA3 = 4d7a28d6f2263ed61de88ca66eb011e3 (Emotet)
JA3S = 80b3a14bccc8598a1f3bbe83e71f735f(Respuesta del servidor C2)

En estos ejemplos de malware, el servidor de C2C siempre responde al cliente de malware exactamente de la misma manera, no se desvía. Entonces, aunque el tráfico está cifrado y es posible que no se conozcan las direcciones IP o los dominios del servidor de Command and Control, ya que cambian constantemente, podríamos identificar, con una cierta confianza y probabilidad, que se esta realizando una comunicación maliciosa, gracias a las huellas digitales de la negociación TLS ( JA3 / JA3S ) entre el cliente y el servidor.

Handshake TLS/SSL y firmas JA3

El protocolo TLS / SSL permite comunicaciones cifradas, ya sean HTTPS, SSH u otras. El beneficio obvio de este cifrado es que evita que otros puedan ver lo que estamos haciendo. Es por ello, que se se ha convertido en una opción popular en el mundo del malware, ya que los sistemas IDS a menudo no pueden detectar que está sucediendo. Una conexión segura se inicia mediante un protocolo de enlace de 3 vías que se produce inmediatamente después del protocolo de enlace de TCP de inicio. Sin embargo, hay una cantidad significativa de información adicional que se transmite en las diversas etapas de este protocolo de enlace (por ejemplo, conjuntos de cifrado, claves o certificados).

El proceso lo inicia el cliente enviando un paquete Client Hello al servidor. Este paquete incluye el conjunto de conjuntos de cifrado que acepta el cliente, qué versión de TLS se espera y otros detalles necesarios para negociar la conexión segura. El segundo paso es la respuesta del servidor con el paquete Server Hello . Este paquete contiene el conjunto de cifrado seleccionado, las extensiones aceptadas, algunos otros bits de información y el certificado del servidor. El último paso es que el cliente verifique el certificado del servidor y luego pase las claves de sesión en el mensaje Cliente terminado . Ya vimos algo, alla por el 2017 ( Cómo pasa el tiempo ) , cuando hablamos de la intercepción SSL , pero mejor lo veamos con un video:

JA3 es un método que toma una huella digital de este handshake que fue publicado por primera vez por John Althouse, Jeff Atkinson y Josh Atkins de Salesforce, de ahí su nombre JA3. Surgió como una solución propuesta para identificar tráfico cifrado malicioso, llegando en un momento dorado, ya que como publicó Akamai hace poco, ha descubierto que más del 80% del tráfico malicioso actual se realiza a través de canales cifrados.

El análisis de Salesforce del tráfico TLS / SSL desarrolló inicialmente un método para identificar la aplicación cliente. Querían crear una técnica que resultara en un hash MD5 debido a la simplicidad y compatibilidad con una gran cantidad de productos existentes. Rápidamente identificaron que el hash de todo el Client Hello no funcionó debido a cambios impredecibles en los campos del paquete. Sin embargo, pudieron localizar que algunos de los campos están dictados por bibliotecas y métodos utilizados para construir la aplicación. Como resultado, estos campos son consistentes entre cada conexión. Específicamente, identificaron que la versión TLS, los conjuntos de cifrado, las extensiones de curvas elípticas, los formatos de puntos de curva elíptica y la longitud de las extensiones podrían usarse para producir un hash MD5 que se cataloga para identificar la aplicación. Pero podéis descubrir más de esta maravillosa obra, en las investigación de Salesforce a un nivel mucho más bajo, o en siguiente video del propio Jonh Althouse:

Evadir firmas JA3

Tras buscar sobre distintos estudios, observamos, que como el Yin y el Yang , de igual forma que las firmas toman popularidad, de igual forma lo hacen los distintos métodos de evasión de la misma. Dentro de las más populares, el artículo publicado en 2019 por el  equipo de investigación de Akamai sobre cómo el malware barajaba a propósito sus conjuntos de cifrado para evadir las firmas de huellas dactilares TLS. Desde Akamai, han denominado a la técnica, Cipher-Stunting, ganando mucha  popularidad.

Esta es solo una pieza del rompecabezas cuando se trata de identificar actores maliciosos porque la misma aplicación puede usarse para una multitud de propósitos. Por ejemplo, se podría usar un hash JA3 para identificar que Internet Explorer era la aplicación que estableció una conexión encriptada, pero no habría forma de determinar si el tráfico era un usuario navegando por Internet o malware usando Internet Explorer para Comando y Control (C2 ). Para ayudar a abordar este problema, Salesforce también desarrolló la firma JA3S para emparejarla con JA3, intentando complicar un poco más la evasión. Por ejemplo, un servidor Apache responderá a un saludo de cliente de Internet Explorer., de la misma manera, siempre. El emparejamiento JA3 / JA3S permite la identificación futura del emparejamiento de la aplicación y el servidor, aunque la firma JA3S varía según el Client Hello , conceptos importantes que deberíamos tener en cuenta en base a la evasión.

Amenazas PowerShell y JA3

Existen múltiples motivos por los que monitorizar el uso de PowerShell es muy interesante desde una perspectiva de ciberseguridad, saber cuándo se comunica PowerShell a hacia afuera (Internet). Lo ideal es restringir su uso, pero teniendo en cuenta que no todo es equipo corporativo, la monitorización JA3 se convierte en un gran aliado.

Los adversarios suelen utilizar PowerShell para:

• Descargar: Facilitar la segunda etapa de la infección mediante la descarga de código malicioso adicional, como un backdoor.
• Ejecutar: Iniciar esas backdoor escritas en PowerShell, como podría ser PowerShell Empire.
• PostExplotación: Trasladando ese conjunto de herramientas posteriores a la explotación, como podría ser con PowerSploit.

Existen otros métodos además de Invoke-WebRequest  para comunicarse a través de Internet mediante PowerShell. Cuando se utiliza el cmdlet de PowerShell  Invoke-WebRequest  para comunicarse a través de Internet, se envía un User-Agent que contiene PowerShell:

” Mozilla / 5.0 (Windows NT; Windows NT 6.3; en-US) WindowsPowerShell / 4.0”.

Sin embargo, esto se puede cambiar fácilmente proporcionando un User-Agent personalizado para que el tráfico parezca más normal

(-UserAgent “Mozilla / 5.0 (Windows NT 6.1; WOW64; Trident / 7.0; rv: 11.0) como Gecko”)

Es por eso que confiar en el User-Agent no es lo suficientemente bueno. Diría que ya, el 100% del malware realiza activamente la modificación del User-Agent.

Una forma mucho más confiable de identificar un PowerShell que se comunica hacia afuera, es echar un vistazo a sus valores hash JA3. Solo hay una ligera pega, tenemos más de un hash JA3 único para PowerShell, variando de sus versiones. Por ejemplo:

Windows 7 PowerShell 5.0: 05af1f5ca1b87cc9cc9b25185115607d
Windows 7 PowerShell 6.0: 36f7277af969a6947a61ae0b815907a1

Diferencias en las versiones de Windows:

Windows Server 2016 PowerShell 5.1: 235a856727c14dba889ddee0a38dd2f2
Windows 10 PowerShell 5.1: 54328bd36c14bd82ddaa0c04b25ed9ad

Hay una forma de modificar la versión de TLS que se envía en el mensaje de saludo del cliente de TLS y, por lo tanto, tiene un JA3 diferente (parámetro -SslProtocol en PowerShell v6 para  Invoke-WebRequest ).

• Cuando no hay ningún nombre de dominio involucrado en la configuración de la conexión TLS, falta la extensión de Indicación de nombre de servidor (SNI), por lo tanto, existe un hash JA3 diferente.
• Otros métodos de comunicación a Internet mediante PowerShell pueden generar otro valor hash JA3 (p. Ej., Cuando se utiliza Windows BITS, puede diferir según la versión de Windows).

Siempre puede haber colisiones con otras aplicaciones cliente que tengan el mismo hash JA3 que se usa para PowerShell, es importante tenerlo en cuenta, pero observar los posibles JA3 de PowerShell que puede llegar a tener nuestra nuestra organización es una información muy valiosa.

Una vez que sepamos qué hashes JA3 se pueden ver en su entorno, podemos empezar a buscar eventos interesantes. Una táctica aquí y debido a las colisiones, es utilizar el conteo de uso y mirar al final, los nombres de dominio que aparecen con menos frecuencia. También deberíamos ayudarnos, enriqueciendo los eventos con correlaciones de monitorización que incluya la fecha de registro del dominio, empezando a observar o generando alertas sobre los nombres de dominio "más jóvenes". Por supuesto, todo depende de las capacidades que tengamos, y la creatividad aplicada a nuestro entorno corporativo.

Conclusión

JA3 y JA3S son métodos de huellas digitales TLS. JA3 identifica la forma en que una aplicación cliente se comunica a través de TLS y JA3S toma las huellas digitales de la respuesta del servidor. Combinados, esencialmente crean una huella digital de la negociación criptográfica entre cliente y servidor.

JA3 no es una solución milagrosa para prevenir el riesgo de malware. Como solución basada en firmas, comparte las mismas limitaciones de todas las demás defensas que dependen de amenazas preidentificadas o listas negras. Sin embargo, como un medio novedoso para identificar aplicaciones TLS / SSL, el hash JA3 se puede aprovechar como un poderoso indicador del comportamiento de la red, una métrica adicional que puede marcar el uso de software no autorizado o de riesgo, o como un medio para identificar amenazas emergentes de malware en el etapas iniciales de la comunicación C2.

Lo importante es saber lo que debe ser observado - Edgar Allan Poe