cert-polska/hfingerGera impressões digitais únicas de requisições HTTP de malware a partir de arquivos pcap usando Tshark, permitindo a identificação e agrupamento de famílias de malware através da análise da estrutura da requisição, cabeçalhos e características do payload.
Ferramenta para fingerprinting de requisições HTTP de malware. Baseada em Tshark e escrita em Python3. Estágio de protótipo funcional :-)
Seu principal objetivo é fornecer representações únicas (fingerprints) de requisições de malware, que auxiliam na sua identificação. Única significa aqui que cada fingerprint deve ser vista apenas em uma família de malware específica, porém uma mesma família pode ter múltiplas fingerprints. O Hfinger representa a requisição de forma mais curta do que imprimir a requisição inteira, mas ainda interpretável por humanos.
O Hfinger pode ser usado na análise manual de malware, mas também em sistemas de sandbox ou SIEMs. As fingerprints geradas são úteis para agrupar requisições, identificar requisições pertencentes a famílias específicas de malware, distinguir diferentes operações de uma mesma família, ou descobrir requisições maliciosas desconhecidas omitidas por outros sistemas de segurança, mas que compartilham a mesma fingerprint.
Um artigo acadêmico acompanha o trabalho nesta ferramenta, descrevendo, por exemplo, a motivação das escolhas de design, e a avaliação da ferramenta em comparação com p0f, FATT e Mercury.
A premissa básica deste projeto é que as requisições HTTP de diferentes famílias de malware são mais ou menos únicas, podendo ser fingerprintadas para fornecer algum tipo de identificação. O Hfinger retém informações sobre a estrutura e os valores de alguns cabeçalhos para fornecer meios para análises posteriores. Por exemplo, agrupamento de requisições semelhantes – nesse momento, ainda é um trabalho em andamento.
Após análise das requisições HTTP e cabeçalhos de malware, identificamos algumas partes das requisições como sendo as mais distintivas. Estas incluem:
Adicionalmente, algumas características padrão da URL da requisição também foram consideradas. Todas essas partes foram traduzidas em um conjunto de características, descritas em detalhes aqui.
As características acima são traduzidas em uma representação de comprimento variável, que é a fingerprint real. Dependendo do modo de relatório, diferentes características são usadas para criar as fingerprints das requisições. Mais informações sobre esses modos são apresentadas abaixo. O processo de seleção de características será descrito no artigo acadêmico a ser publicado.
Requisitos mínimos necessários antes da instalação:
Python >= 3.3,Tshark >= 2.2.0.Instalação disponível via PyPI:
pip install hfinger
O Hfinger foi testado no Xubuntu 22.04 LTS com o pacote tshark na versão 3.6.2,
mas deve funcionar com versões mais antigas, como 2.6.10 no Xubuntu 18.04 ou 3.2.3 no Xubuntu 20.04.
Observe que, como em qualquer PoC, você deve executar o Hfinger em um ambiente isolado, pelo menos com um ambiente virtual Python. Sua configuração não é abordada aqui, mas você pode tentar este tutorial.
Após a instalação, você pode chamar a ferramenta diretamente da linha de comando com hfinger
ou como um módulo Python com python -m hfinger.
Por exemplo:
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"}]
A ajuda pode ser exibida com as opções curta -h ou longa --help:
usage: hfinger [-h] (-f FILE | -d DIR) [-o output_path] [-m {0,1,2,3,4}] [-v]
[-l LOGFILE]
Hfinger - fingerprinting de requisições HTTP de malware armazenadas em arquivos pcap
argumentos opcionais:
-h, --help mostra esta mensagem de ajuda e sai
-f FILE, --file FILE Lê um único arquivo pcap
-d DIR, --directory DIR
Lê arquivos pcap do diretório DIR
-o output_path, --output-path output_path
Caminho para o diretório de saída
-m {0,1,2,3,4}, --mode {0,1,2,3,4}
Modo de relatório da fingerprint.
0 - número semelhante de colisões e fingerprints que o modo 2, mas usando menos características,
1 - representação de todas as características projetadas, mas um pouco mais de colisões que os modos 0, 2 e 4,
2 - ideal (modo padrão),
3 - menor número de fingerprints geradas, mas o maior número de colisões,
4 - maior entropia da fingerprint, mas ligeiramente mais fingerprints que os modos 0-2
-v, --verbose Relata informações sobre valores não padronizados na requisição
(por exemplo, caracteres não ASCII, ausência de tags CRLF, valores não presentes na lista de configuração).
Sem --logfile (-l) imprimirá no erro padrão.
-l LOGFILE, --logfile LOGFILE
Arquivo de log de saída no modo verboso. Implica a opção -v ou --verbose.
Você deve fornecer um caminho para um arquivo pcap (-f), ou um diretório (-d) com arquivos pcap. A saída está no formato JSON. Ela será impressa na saída padrão ou no diretório fornecido (-o) usando o nome do arquivo de origem. Por exemplo, a saída do comando:
hfinger -f example.pcap -o /tmp/pcap
será salva em:
/tmp/pcap/example.pcap.json
O modo de relatório -m/--mode pode ser usado para alterar o modo de relatório padrão fornecendo um número inteiro no intervalo 0-4.
Os modos diferem nas características da requisição representadas ou nos modos de arredondamento.
O modo padrão (2) foi escolhido por nós para representar todas as características que geralmente são usadas durante a análise das requisições,
mas também oferece baixo número de colisões e fingerprints geradas.
Com outros modos, você pode alcançar diferentes objetivos.
Por exemplo, no modo 3 você obtém um número menor de fingerprints geradas,
mas uma chance maior de colisão entre famílias de malware. Se não tiver certeza, não precisa alterar nada.
Mais informações sobre os modos de relatório estão aqui.
A partir da versão 0.2.1, o Hfinger é menos verboso. Você deve usar -v/--verbose se quiser receber
informações sobre valores não padronizados de cabeçalhos encontrados, caracteres não ASCII na parte não-payload da
requisição, ausência de tags CRLF (\r\n\r\n) e outros problemas com as requisições analisadas que não sejam erros de aplicação.
Quando tais problemas forem encontrados no modo verboso, eles serão impressos na saída de erro padrão.
Você também pode salvar o log em um local definido usando a opção -l/--log (que implica -v/--verbose).
Os dados do log serão anexados ao arquivo de log.
A partir da versão 0.2.0, o Hfinger suporta importação para outras aplicações Python.
Para usá-lo em seu aplicativo, basta importar a função hfinger_analyze de hfinger.analysis
e chamá-la com o caminho para o arquivo pcap e o modo de relatório.
O resultado retornado é uma lista de dicionários com os resultados do fingerprinting.
Por exemplo:
from hfinger.analysis import hfinger_analyze
pcap_path = "ESPECIFIQUE_O_CAMINHO_DO_PCAP_AQUI"
reporting_mode = 4
print(hfinger_analyze(pcap_path, reporting_mode))
A partir da versão 0.2.1, o Hfinger usa o módulo logging para registrar informações sobre valores
não padronizados de cabeçalhos encontrados, caracteres não ASCII na parte não-payload da requisição,
ausência de tags CRLF (\r\n\r\n) e outros problemas com as requisições analisadas que não sejam erros de aplicação.
O Hfinger cria seu próprio logger usando o nome hfinger, mas sem configuração prévia, as informações de log na prática são descartadas.
Se você quiser receber essas informações de log, antes de chamar hfinger_analyze, você deve configurar o logger hfinger,
definir o nível de log como logging.INFO, configurar um handler de log conforme suas necessidades e adicioná-lo ao logger.
Mais informações estão disponíveis na docstring da função hfinger_analyze.
Uma fingerprint é baseada em características extraídas de uma requisição. O uso de características específicas da lista completa depende do modo de relatório escolhido dentre uma lista predefinida (mais informações sobre os modos de relatório estão aqui). A figura abaixo representa a criação de uma fingerprint exemplificativa no modo de relatório padrão.
Três partes da requisição são analisadas para extrair informações: URI,
estrutura dos cabeçalhos (incluindo método e versão do protocolo) e payload.
As características específicas da fingerprint são separadas usando | (pipe). A fingerprint final gerada para a requisição POST
do exemplo é:
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
A criação das características é descrita abaixo na ordem de aparecimento na fingerprint.
Primeiramente, as características da URI são extraídas:
log10(43)≈2),log10(20/3)≈1),hfinger/configs/extensions.txt,log10(4)≈0.6).Em segundo lugar, as características da estrutura dos cabeçalhos são analisadas:
PO),Para representar a ordem dos cabeçalhos na requisição, o nome de cada cabeçalho é codificado de acordo com o esquema em
hfinger/configs/headerslow.json, por exemplo, o cabeçalho User-Agent é codificado como us-ag.
Os nomes codificados são separados por ,. Se o nome do cabeçalho não começar com uma letra maiúscula
(ou qualquer uma de suas partes ao analisar cabeçalhos compostos como Accept-Encoding),
então a representação codificada é prefixada com !.
Se o nome do cabeçalho não estiver na lista de cabeçalhos conhecidos,
ele é hashado usando FNV1a hash,
e o hash é usado como codificação.
Ao analisar cabeçalhos populares, a requisição é verificada para saber se eles aparecem nela. Esses cabeçalhos são:
Quando o cabeçalho é encontrado na requisição, seu valor é verificado em uma tabela de
valores típicos para criar pares de representação_do_nome_do_cabeçalho:representação_do_valor.
O nome do cabeçalho é codificado de acordo com o esquema em hfinger/configs/headerslow.json (como apresentado anteriormente),
e o valor é codificado de acordo com o esquema armazenado no diretório hfinger/configs ou no arquivo configs.py,
dependendo do cabeçalho. No exemplo acima, Accept é codificado como ac
e seu valor */* como as-as (asterisk-asterisk), resultando em ac:as-as.
Os pares são inseridos na fingerprint na ordem de aparecimento na requisição e são delimitados por /.
Se o valor do cabeçalho não puder ser encontrado na tabela de codificação, ele é hashado usando o hash FNV1a.
Se o valor do cabeçalho for composto por múltiplos valores, eles são tokenizados para fornecer uma lista de valores delimitada por ,,
por exemplo, resultaria em . No entanto, neste ponto do desenvolvimento, se o valor do cabeçalho
contiver uma tag de "valor de qualidade" (), então todo o valor é codificado com seu hash FNV1a.
Finalmente, os valores dos cabeçalhos e são codificados diretamente usando seus hashes FNV1a.
Por fim, nas características do payload:
N, e com A caso contrário,O Hfinger opera em cinco modos de relatório, que diferem nas características representadas na fingerprint, portanto,
nas informações extraídas das requisições. Estes são (com o número usado na configuração da ferramenta):
0 - produz um número semelhante de colisões e fingerprints que o modo 2, mas usando menos características,1 - representa todas as características projetadas, mas produz um pouco mais de colisões que os modos 0, 2 e 4,2 - ideal (modo padrão), representa todas as características que geralmente são usadas durante a análise das requisições,
mas também oferece um baixo número de colisões e fingerprints geradas,3 - produz o menor número de fingerprints geradas dentre todos os modos,
mas atinge o maior número de colisões,4 - oferece a maior entropia da fingerprint,
mas também gera ligeiramente mais fingerprints que os modos 0-2.Os modos foram escolhidos para otimizar as capacidades do Hfinger de identificar famílias de malware de forma única
versus o número de fingerprints geradas. Os modos 0, 2 e 4 oferecem um número semelhante de colisões
entre famílias de malware, no entanto, o modo 4 gera um pouco mais de fingerprints que os outros dois.
O modo 2 representa mais características da requisição que o modo 0 com um número comparável de fingerprints geradas e colisões.
O modo 1 é o único que representa todas as características projetadas, mas aumenta o número de colisões em quase duas vezes
em comparação com os modos 0, 1 e 4. O modo 3 produz pelo menos duas vezes menos fingerprints que os outros modos, mas
introduz cerca de nove vezes mais colisões. A descrição de todas as características projetadas está aqui.
Os modos consistem em características (na ordem de aparecimento na fingerprint):
0:
1:
2:
3:
Accept: */*, text/*ac:as-as,te-asq=4: