cert-polska/hfingerGenera huellas digitales únicas de solicitudes HTTP de malware a partir de archivos pcap usando Tshark, permitiendo la identificación y agrupación de familias de malware mediante el análisis de la estructura de la solicitud, encabezados y características del payload.
Herramienta para fingerprinting de peticiones HTTP de malware. Basada en Tshark y escrita en Python3. ¡Prototipo funcional! :-)
Su objetivo principal es proporcionar representaciones únicas (huellas digitales) de las peticiones de malware, que ayudan en su identificación. Único significa aquí que cada huella digital debería verse solo en una familia de malware en particular, aunque una familia puede tener múltiples huellas. Hfinger representa la petición de forma más corta que imprimir toda la petición, pero aún interpretable por humanos.
Hfinger se puede usar en análisis manual de malware, pero también en sistemas sandbox o SIEMs. Las huellas generadas son útiles para agrupar peticiones, localizar peticiones de familias de malware concretas, identificar diferentes operaciones de una familia, o descubrir peticiones maliciosas desconocidas omitidas por otros sistemas de seguridad pero que comparten huella digital.
Un artículo académico acompaña el trabajo de esta herramienta, describiendo, por ejemplo, la motivación de las decisiones de diseño y la evaluación de la herramienta en comparación con p0f, FATT y Mercury.
La suposición básica de este proyecto es que las peticiones HTTP de diferentes familias de malware son más o menos únicas, por lo que se puede generar una huella digital para proporcionar algún tipo de identificación. Hfinger retiene información sobre la estructura y valores de algunas cabeceras para proporcionar medios para análisis posteriores. Por ejemplo, la agrupación de peticiones similares – en este momento, sigue siendo un trabajo en progreso.
Tras analizar las peticiones HTTP y cabeceras de malware, hemos identificado algunas partes de las peticiones como las más distintivas. Estas incluyen:
Adicionalmente, también se consideraron algunas características estándar de la URL de la petición. Todas estas partes se tradujeron en un conjunto de características, descritas en detalle aquí.
Las características anteriores se traducen en una representación de longitud variable, que es la huella real. Dependiendo del modo de informe, se utilizan diferentes características para generar la huella de las peticiones. Más información sobre estos modos se presenta a continuación. El proceso de selección de características se describirá en el próximo artículo académico.
Requisitos mínimos necesarios antes de la instalación:
Python >= 3.3,Tshark >= 2.2.0.Instalación disponible desde PyPI:
pip install hfinger
Hfinger ha sido probado en Xubuntu 22.04 LTS con el paquete tshark en versión 3.6.2, pero debería funcionar con versiones anteriores como 2.6.10 en Xubuntu 18.04 o 3.2.3 en Xubuntu 20.04.
Tenga en cuenta que, como con cualquier PoC, debe ejecutar Hfinger en un entorno separado, al menos con un entorno virtual de Python. Su configuración no se cubre aquí, pero puede probar este tutorial.
Después de la instalación, puede llamar a la herramienta directamente desde la línea de comandos con hfinger o como módulo de Python con python -m hfinger.
Por ejemplo:
foo@bar:~$ hfinger -f /tmp/test.pcap
[{"epoch_time": "1614098832.205385000", "ip_src": "127.0.0.1", "ip_dst": "127.0.0.1", "port_src": "53664", "port_dst": "8080", "fingerprint": "2|3|1|php|0.6|PO|1|us-ag,ac,ac-en,ho,co,co-ty,co-le|us-ag:f452d7a9/ac:as-as/ac-en:id/co:Ke-Al/co-ty:te-pl|A|4|1.4"}]
La ayuda se puede mostrar con los modificadores cortos -h o largos --help:
usage: hfinger [-h] (-f FILE | -d DIR) [-o output_path] [-m {0,1,2,3,4}] [-v]
[-l LOGFILE]
Hfinger - fingerprinting malware HTTP requests stored in pcap files
optional arguments:
-h, --help show this help message and exit
-f FILE, --file FILE Read a single pcap file
-d DIR, --directory DIR
Read pcap files from the directory DIR
-o output_path, --output-path output_path
Path to the output directory
-m {0,1,2,3,4}, --mode {0,1,2,3,4}
Fingerprint report mode.
0 - similar number of collisions and fingerprints as mode 2, but using fewer features,
1 - representation of all designed features, but a little more collisions than modes 0, 2, and 4,
2 - optimal (the default mode),
3 - the lowest number of generated fingerprints, but the highest number of collisions,
4 - the highest fingerprint entropy, but slightly more fingerprints than modes 0-2
-v, --verbose Report information about non-standard values in the request
(e.g., non-ASCII characters, no CRLF tags, values not present in the configuration list).
Without --logfile (-l) will print to the standard error.
-l LOGFILE, --logfile LOGFILE
Output logfile in the verbose mode. Implies -v or --verbose switch.
Debe proporcionar una ruta a un archivo pcap (-f), o un directorio (-d) con archivos pcap. La salida está en formato JSON. Se imprimirá en la salida estándar o en el directorio proporcionado (-o) usando el nombre del archivo fuente. Por ejemplo, la salida del comando:
hfinger -f example.pcap -o /tmp/pcap
se guardará en:
/tmp/pcap/example.pcap.json
El modo de informe -m/--mode se puede usar para cambiar el modo de informe predeterminado proporcionando un entero en el rango 0-4. Los modos difieren en las características de la petición representadas o en los modos de redondeo. El modo predeterminado (2) fue elegido por nosotros para representar todas las características que suelen usarse durante el análisis de peticiones, pero también ofrece un bajo número de colisiones y huellas generadas. Con otros modos, puede lograr diferentes objetivos. Por ejemplo, en el modo 3 obtiene un menor número de huellas generadas pero una mayor probabilidad de colisión entre familias de malware. Si no está seguro, no tiene que cambiar nada. Más información sobre los modos de informe está aquí.
A partir de la versión 0.2.1 Hfinger es menos verboso. Debe usar -v/--verbose si desea recibir información sobre valores de cabeceras no estándar encontrados, caracteres no ASCII en la parte no payload de la petición, falta de etiquetas CRLF (\r\n\r\n) y otros problemas con las peticiones analizadas que no sean errores de aplicación. Cuando se encuentren tales problemas en el modo verboso, se imprimirán en la salida de error estándar. También puede guardar el registro en una ubicación definida usando el modificador -l/--log (implica -v/--verbose). Los datos del registro se añadirán al archivo de registro.
A partir de la versión 0.2.0, Hfinger admite la importación en otras aplicaciones Python. Para usarlo en su aplicación, simplemente importe la función hfinger_analyze desde hfinger.analysis y llámela con la ruta al archivo pcap y el modo de informe. El resultado devuelto es una lista de diccionarios con los resultados de las huellas digitales.
Por ejemplo:
from hfinger.analysis import hfinger_analyze
pcap_path = "SPECIFY_PCAP_PATH_HERE"
reporting_mode = 4
print(hfinger_analyze(pcap_path, reporting_mode))
A partir de la versión 0.2.1, Hfinger usa el módulo logging para registrar información sobre valores de cabeceras no estándar encontrados, caracteres no ASCII en la parte no payload de la petición, falta de etiquetas CRLF (\r\n\r\n) y otros problemas con las peticiones analizadas que no sean errores de aplicación. Hfinger crea su propio registrador usando el nombre hfinger, pero sin configuración previa, la información de registro se descarta en la práctica. Si desea recibir esta información de registro, antes de llamar a hfinger_analyze, debe configurar el registrador hfinger, establecer el nivel de registro en logging.INFO, configurar el manejador de registro según sus necesidades, y agregarlo al registrador. Más información está disponible en la cadena de documentación de la función hfinger_analyze.
Una huella se basa en características extraídas de una petición. El uso de características particulares de la lista completa depende del modo de informe elegido de una lista predefinida (más información sobre los modos de informe está aquí). La siguiente figura representa la creación de una huella ejemplar en el modo de informe predeterminado.
Se analizan tres partes de la petición para extraer información: URI, estructura de las cabeceras (incluyendo método y versión del protocolo) y payload. Las características particulares de la huella se separan usando | (pleca). La huella final generada para la petición POST del ejemplo es:
2|3|1|php|0.6|PO|1|us-ag,ac,ac-en,ho,co,co-ty,co-le|us-ag:f452d7a9/ac:as-as/ac-en:id/co:Ke-Al/co-ty:te-pl|A|4|1.4
La creación de las características se describe a continuación en el orden de aparición en la huella.
En primer lugar, se extraen las características URI:
log10(43)≈2),log10(20/3)≈1),hfinger/configs/extensions.txt,log10(4)≈0.6).En segundo lugar, se analizan las características de la estructura de las cabeceras:
PO),Para representar el orden de las cabeceras en la petición, el nombre de cada cabecera se codifica según el esquema en hfinger/configs/headerslow.json, por ejemplo, la cabecera User-Agent se codifica como us-ag. Los nombres codificados se separan por ,. Si el nombre de la cabecera no comienza con una letra mayúscula (o cualquiera de sus partes al analizar cabeceras compuestas como Accept-Encoding), entonces la representación codificada se prefija con !. Si el nombre de la cabecera no está en la lista de cabeceras conocidas, se aplica un hash usando hash FNV1a, y el hash se usa como codificación.
Al analizar cabeceras populares, se verifica si aparecen en la petición. Estas cabeceras son:
Cuando la cabecera se encuentra en la petición, su valor se compara con una tabla de valores típicos para crear pares de representación_del_nombre_de_cabecera:representación_del_valor. El nombre de la cabecera se codifica según el esquema en hfinger/configs/headerslow.json (como se presentó antes), y el valor se codifica según el esquema almacenado en el directorio hfinger/configs o en el archivo configs.py, dependiendo de la cabecera. En el ejemplo anterior, Accept se codifica como ac y su valor */* como as-as (asterisk-asterisk), dando ac:as-as. Los pares se insertan en la huella en el orden de aparición en la petición y se delimitan usando /. Si el valor de la cabecera no se encuentra en la tabla de codificación, se aplica un hash usando el hash FNV1a. Si el valor de la cabecera está compuesto por múltiples valores, se tokenizan para proporcionar una lista de valores delimitados por ,, por ejemplo, daría . Sin embargo, en este punto del desarrollo, si el valor de la cabecera contiene una etiqueta "quality value" (), entonces todo el valor se codifica con su hash FNV1a. Finalmente, los valores de las cabeceras y se codifican directamente usando sus hashes FNV1a.
Finalmente, en las características del payload:
N, y con A en caso contrario,Hfinger opera en cinco modos de informe, que difieren en las características representadas en la huella, por lo tanto, en la información extraída de las peticiones. Estos son (con el número usado en la configuración de la herramienta):
0 - produce un número similar de colisiones y huellas que el modo 2, pero usando menos características,1 - representa todas las características diseñadas, pero produce un poco más de colisiones que los modos 0, 2 y 4,2 - óptimo (el modo predeterminado), representa todas las características que suelen usarse durante el análisis de peticiones, pero también ofrece un bajo número de colisiones y huellas generadas,3 - produce el menor número de huellas generadas de todos los modos, pero logra el mayor número de colisiones,4 - ofrece la mayor entropía de huella, pero también genera ligeramente más huellas que los modos 0-2.Los modos fueron elegidos para optimizar las capacidades de Hfinger para identificar de forma única las familias de malware frente al número de huellas generadas. Los modos 0, 2 y 4 ofrecen un número similar de colisiones entre familias de malware, sin embargo, el modo 4 genera un poco más de huellas que los otros dos. El modo 2 representa más características de la petición que el modo 0 con un número comparable de huellas generadas y colisiones. El modo 1 es el único que representa todas las características diseñadas, pero aumenta el número de colisiones casi dos veces en comparación con los modos 0, 2 y 4. El modo 3 produce al menos dos veces menos huellas que otros modos, pero introduce aproximadamente nueve veces más colisiones. La descripción de todas las características diseñadas está aquí.
Los modos consisten en características (en el orden de aparición en la huella):
0:
1:
2:
3:
Accept: */*, text/*ac:as-as,te-asq=4: