Imphash, hash del Rich header y TLSH: agrupar muestras

En resumen. Un SHA-256 cambia cuando cambia un solo byte, así que no puede indicar que dos archivos están relacionados. Otras tres huellas sí pueden: el imphash (lo que importa el programa), el hash del Rich header (qué componentes de la cadena de herramientas de Microsoft lo compilaron) y TLSH (cuánto se parecen los bytes). Cada una falla de maneras conocidas. Úselas para formar grupos y después confírmelos con otras evidencias.

Imphash: la huella de las importaciones

Mandiant presentó el hash de importaciones en 2014 (Tracking Malware with Import Hashing). La implementación más utilizada es get_imphash() de pefile:

Para cada DLL importada, en el orden del archivo, se toma el nombre en minúsculas y se elimina la extensión .dll, .ocx o .sys.
Para cada función, se toma su nombre en minúsculas. Las funciones importadas por ordinal reciben su nombre de las tablas de pefile para ws2_32, wsock32 y oleaut32, y en los demás casos se escriben ordN.
Se unen los pares dll.función con comas y se calcula el MD5.

Como el enlazador escribe las importaciones en el orden en que las usa el código, las compilaciones de un mismo árbol de código fuente tienden a compartir imphash, mientras que los programas no relacionados rara vez lo hacen. En el ejemplo que carga PE Parser, las dos compilaciones de m64.exe tienen valores SHA-256 distintos pero el mismo imphash, y la tabla del lote las etiqueta como familia 1.

Dónde falla: archivos empaquetados (el imphash describe el stub del empaquetador, compartido por miles de muestras sin relación), ensamblados .NET (solo importan mscoree.dll!_CorExeMain) y programas muy pequeños cuyas pocas importaciones son comunes a todo. Las importaciones de carga diferida (delay-load) no forman parte del imphash de pefile. Consulte la entrada del glosario sobre imphash.

Hash del Rich header: la huella de la cadena de herramientas

El enlazador de Microsoft escribe un bloque no documentado en el stub DOS: una lista de valores comp.id (identificador de producto y número de compilación de cada compilador, ensamblador, enlazador y biblioteca de importación que aportó objetos) con un recuento para cada uno, enmascarada con XOR mediante una clave y cerrada por la palabra Rich. La clave no es aleatoria: es una suma de comprobación de la cabecera DOS y de las entradas, como describe Daniel Pistelli en Microsoft's Rich Signature (undocumented).

Esto aporta dos cosas:

un hash del Rich header (get_rich_header_hash() de pefile: MD5 de la cabecera decodificada), compartido por programas compilados con la misma combinación de herramientas, a menudo del mismo proyecto;
una comprobación de coherencia: si la clave almacenada no coincide con la suma de comprobación recalculada, la cabecera se editó o se trasplantó.

La falsificación existe. Kaspersky demostró que la muestra de Olympic Destroyer llevaba un Rich header copiado de otra familia para confundir la atribución (The devil's in the Rich header). Investigaciones como la de Webster et al., Finding the Needle: A Study of the PE32 Rich Header and Respective Malware Triage (DIMVA 2017), muestran lo bien que agrupa en la práctica. La entrada sobre el Rich header resume el formato; PE Parser traduce los comp.id a versiones de Visual Studio usando la lista pública que mantiene el proyecto richprint.

Dónde falla: las cadenas de herramientas que no son de Microsoft (MinGW, Go, Rust con el target GNU, Delphi) no escriben Rich header, y este puede eliminarse o ponerse a cero.

TLSH: la huella de similitud de bytes

TLSH (Trend Micro Locality Sensitive Hash) resume la distribución de trigramas de bytes en un resumen de 70 dígitos hexadecimales con el prefijo T1. Dos resúmenes se comparan mediante una distancia: 0 significa idénticos, y cuanto menor, más parecidos. Las variantes cercanas de un programa suelen quedar a distancias pequeñas; no hay un umbral universal, así que calibre con archivos que sepa relacionados y no relacionados de su propia colección. TLSH necesita al menos 50 bytes con suficiente variedad para generar un resumen.

La vista de comparación de PE Parser muestra la distancia TLSH entre dos archivos cargados cualesquiera. ssdeep, el otro hash difuso habitual, no está incluido: su implementación de referencia tiene licencia GPL y no encontramos ninguna con licencia permisiva.

Dónde falla: el empaquetado o la compresión cambian los bytes por completo; los recursos compartidos de gran tamaño (iconos, runtimes incrustados) pueden hacer que archivos sin relación parezcan cercanos.

Cómo combinarlos

Huella	Agrupa por	Resiste la recompilación	Resiste el empaquetado	Falsificable
SHA-256	bytes exactos	no	no	no
Imphash	lista de importaciones	a menudo	no (calcula el hash del stub)	sí, fácilmente
Hash del Rich header	combinación de herramientas	a menudo	a veces (el stub puede conservarlo)	sí
TLSH	distribución de bytes	en parte	no	con esfuerzo

Un flujo de trabajo sólido: agrupe una colección por imphash y hash del Rich header, compruebe las distancias TLSH y las marcas de tiempo de cada grupo (marcas de tiempo PE) y solo entonces escriba «misma familia» en un informe, con las evidencias enumeradas.

Preguntas frecuentes

¿Qué es un imphash?

Un MD5 de la lista ordenada de funciones importadas, escrita como pares dll.función en minúsculas unidos por comas. Dos compilaciones del mismo programa suelen compartirlo aunque todos los bytes de su código sean distintos.

¿Es fiable el Rich header para la atribución?

Es una pista útil, pero se puede copiar o falsificar: el malware Olympic Destroyer llevaba un Rich header tomado de otra familia. Compruebe si su suma de comprobación es coherente y valórelo junto con otras evidencias.

¿Por qué PE Parser no incluye ssdeep?

La implementación de referencia de ssdeep tiene licencia GPL y no encontramos ninguna implementación con licencia permisiva, así que la herramienta usa TLSH (Apache-2.0) para medir la similitud.