Tema 8

8. Análisis estático inicial: hashes, strings, firmas, empaquetado y triage

El análisis estático inicial permite extraer información de una muestra sin ejecutarla. Es la primera capa de triage: identifica el archivo, revela pistas de comportamiento, detecta anomalías y define qué análisis conviene hacer después.

Objetivo Extraer evidencia útil sin ejecutar la muestra
Enfoque Hashes, strings, firmas, metadatos, packing y triage
Resultado Formular hipótesis y priorizar el análisis posterior

8.1 Introducción

El análisis estático inicial estudia una muestra sin ejecutarla. Esto reduce riesgo y permite obtener información rápida sobre tipo de archivo, arquitectura, tamaño, hashes, cadenas, imports, recursos, metadatos, firmas y posibles señales de empaquetado.

Esta etapa no busca responder todo. Su objetivo es orientar. Un buen triage ayuda a decidir si la muestra requiere análisis dinámico, ingeniería inversa profunda, comparación con familias conocidas o extracción de indicadores para una respuesta rápida.

En malware, cada ejecución puede cambiar el entorno, activar comunicaciones o destruir evidencia. Por eso, siempre conviene extraer primero lo que el archivo revela en reposo.

8.2 Qué es triage

Triage es una evaluación inicial para clasificar prioridad, riesgo y próximos pasos. En análisis de malware, permite responder preguntas básicas con rapidez antes de invertir tiempo en reversing o debugging.

  • Qué tipo de archivo es.
  • Para qué plataforma y arquitectura fue creado.
  • Si parece comprimido, cifrado u ofuscado.
  • Qué capacidades sugiere por imports, strings o recursos.
  • Si coincide con reglas, firmas o familias conocidas.
  • Qué indicadores preliminares pueden compartirse o buscarse.
El triage no reemplaza el análisis completo. Sirve para decidir con evidencia qué camino conviene tomar.

8.3 Preparación antes de tocar la muestra

Aunque el análisis estático no ejecuta la muestra, sigue manipulando material peligroso. Debe realizarse dentro de un entorno controlado, con rutas claras y sin mezclar archivos maliciosos con documentos comunes.

  1. Ubicar la muestra en una carpeta identificada.
  2. Evitar doble clic o apertura con aplicaciones asociadas.
  3. Registrar origen, fecha y contexto de recepción.
  4. Calcular hashes antes de modificar, descomprimir o extraer contenido.
  5. Trabajar con una copia si se necesitan transformaciones.
  6. Guardar notas de herramientas, versiones y resultados.

8.4 Hashes criptográficos

Un hash resume el contenido de un archivo en un valor fijo. Si el archivo cambia, el hash cambia. En análisis de malware, los hashes permiten identificar muestras, correlacionar reportes, buscar coincidencias y asegurar integridad durante transferencias.

Hash Uso común Consideración
MD5 Identificación histórica y compatibilidad No usar como prueba fuerte de integridad criptográfica
SHA-1 Correlación en fuentes antiguas También considerado débil para seguridad criptográfica
SHA-256 Identificación moderna de muestras Preferible para reportes e intercambio técnico
ssdeep / TLSH Similitud aproximada entre archivos Útil para agrupar variantes, no para identidad exacta

8.5 Hashes como indicadores

Un hash exacto es un indicador preciso, pero frágil. Si el atacante recompila, empaqueta o cambia un byte, el hash cambia. Por eso, los hashes son útiles para confirmar una muestra específica, pero no alcanzan para detectar toda una familia.

Buenas prácticas:

  • Registrar al menos SHA-256.
  • Indicar a qué archivo corresponde cada hash.
  • Distinguir hash de muestra original, payload extraído y archivos creados.
  • No basar toda la detección en hashes exactos.
  • Combinar hashes con rutas, nombres, comportamiento, red y reglas.

8.6 Identificación de tipo de archivo

El nombre y la extensión pueden engañar. Una muestra puede llamarse factura.pdf aunque sea un ejecutable, un script o un archivo comprimido. La identificación debe basarse en cabeceras, magic bytes y estructura interna.

Elementos a revisar:

  • Firma inicial del archivo.
  • Formato detectado por herramientas.
  • Arquitectura y plataforma.
  • Si es ejecutable, biblioteca, script, documento, archivo comprimido o instalador.
  • Si contiene otros archivos embebidos.
La extensión sirve como pista débil. La cabecera y la estructura del archivo pesan más que el nombre.

8.7 Strings

Las strings son cadenas de texto presentes dentro del archivo. Pueden revelar rutas, URLs, dominios, comandos, nombres de funciones, mensajes, claves, extensiones objetivo, errores, configuración o artefactos del compilador.

Una revisión de strings puede encontrar:

  • Dominios, IPs, rutas o nombres de archivos.
  • Comandos de sistema o scripts embebidos.
  • Mensajes de error, notas o textos de interfaz.
  • Nombres de APIs y bibliotecas.
  • Indicadores de packers, compiladores o frameworks.
  • Fragmentos de configuración o claves codificadas.

8.8 Limitaciones de strings

Las strings son útiles, pero fáciles de ocultar. Una muestra puede cifrar cadenas, generarlas en tiempo de ejecución, comprimirlas, dividirlas o resolver nombres por hashes. También puede incluir strings falsas para distraer.

Errores comunes:

  • Asumir que toda URL encontrada será usada.
  • Ignorar codificaciones Unicode o formatos no ASCII.
  • Confundir strings de bibliotecas o runtime con lógica propia del malware.
  • Concluir familia solo por una cadena aislada.
  • No distinguir strings embebidas de strings extraídas de recursos o payloads.

8.9 Imports y capacidades probables

Los imports permiten inferir qué funciones externas puede usar el archivo. En triage, ayudan a ubicar capacidades probables: red, archivos, registro, procesos, memoria, criptografía o servicios.

Tipo de import Capacidad sugerida Qué confirmar después
Red Comunicación externa o C2 Dominios, protocolos, frecuencia y datos enviados
Archivos Lectura, escritura, borrado o cifrado Rutas objetivo y volumen de cambios
Registro Configuración o persistencia Claves modificadas y propósito
Procesos Ejecución, inyección o enumeración Procesos creados o manipulados
Criptografía Cifrado, hashing o protección de datos Algoritmo, claves y datos afectados

8.10 Firmas digitales

La firma digital puede indicar si un archivo fue firmado por un editor y si el contenido conserva integridad desde la firma. En triage, ayuda a distinguir software legítimo, archivos modificados, certificados inválidos o abuso de confianza.

Aspectos a registrar:

  • Si el archivo está firmado.
  • Si la firma es válida o está rota.
  • Nombre del firmante y entidad emisora.
  • Fecha de firma y vigencia del certificado.
  • Coherencia entre editor, metadatos, ruta y comportamiento esperado.

Un archivo firmado puede ser malicioso o abusado. Una firma válida no reemplaza el análisis de comportamiento.

8.11 Firmas de detección

Las firmas de detección comparan una muestra con patrones conocidos. Pueden provenir de antivirus, reglas YARA, motores internos, bases de reputación o herramientas de clasificación.

Interpretación responsable:

  • Una detección aislada puede ser falso positivo.
  • Muchos motores coincidentes aumentan confianza, pero no explican comportamiento.
  • Los nombres de detección no son taxonomía perfecta.
  • Una muestra sin detección no es necesariamente benigna.
  • Las reglas propias deben documentar qué patrón observan.

8.12 YARA en triage

YARA permite crear reglas basadas en strings, bytes, metadatos y condiciones lógicas. En triage, sirve para identificar familias, packers, artefactos de compilación, recursos o características compartidas.

Una regla de triage no necesita ser perfecta, pero debe ser clara sobre qué detecta. Puede apuntar a una familia, una herramienta, una técnica o una combinación de indicadores.

Una buena regla YARA busca rasgos relevantes y relativamente estables. Una mala regla se basa en una cadena genérica que aparece en software legítimo.

8.13 Metadatos y recursos

Los metadatos y recursos pueden revelar información sobre origen, compilación, intención o engaño. En PE, los recursos pueden contener iconos, manifiestos, versión, diálogos, datos embebidos o payloads comprimidos.

  • Nombre interno y descripción del producto.
  • Compañía declarada y versión.
  • Iconos que imitan software conocido.
  • Manifiestos que solicitan privilegios.
  • Recursos grandes o de alta entropía.
  • Datos embebidos que podrían extraerse para análisis separado.

8.14 Entropía

La entropía mide cuán aleatorios parecen los datos. Secciones con entropía alta pueden indicar compresión, cifrado, packing u ofuscación. También pueden aparecer en software legítimo protegido o con recursos comprimidos.

Observación Posible explicación Qué hacer
Alta entropía en casi todo el archivo Packing, cifrado o compresión Revisar imports, secciones y punto de entrada
Alta entropía en recursos Datos embebidos comprimidos o cifrados Extraer y analizar como artefacto separado
Baja cantidad de strings Ofuscación, packing o binario simple Buscar desempaquetado o generación dinámica
Sección ejecutable y escribible Desempaquetado, código generado o mala configuración Confirmar con análisis dinámico o debugging

8.15 Packing y ofuscación

Un packer transforma un ejecutable para comprimirlo, protegerlo u ocultar su contenido. Al ejecutarse, un stub desempaqueta el código real en memoria y le transfiere control. La ofuscación busca dificultar lectura, análisis y detección.

Señales comunes:

  • Pocos imports visibles.
  • Secciones con nombres no habituales.
  • Entry point en una sección extraña.
  • Alta entropía.
  • Strings escasas o sin sentido.
  • Uso de APIs para asignar memoria, cambiar permisos y resolver funciones dinámicamente.

El packing no prueba intención maliciosa. Muchos programas legítimos usan protectores. En malware, sin embargo, suele ser una señal de que el análisis estático inicial será limitado.

8.16 Análisis de documentos y scripts

No todo malware llega como ejecutable nativo. Documentos con macros, scripts, accesos directos, archivos comprimidos o instaladores pueden actuar como etapa inicial.

En triage de documentos y scripts conviene revisar:

  • Macros, objetos embebidos y relaciones externas.
  • Comandos codificados u ofuscados.
  • URLs, rutas y argumentos de ejecución.
  • Uso de intérpretes como PowerShell, cmd, wscript, bash o python.
  • Indicadores de descarga de payloads.
  • Metadatos del documento, autor, fechas y plantilla.

8.17 Reputación y fuentes externas

Las fuentes externas pueden aportar contexto: si un hash ya fue visto, qué detecciones tiene, qué nombres recibe, qué comportamiento fue reportado o con qué campaña se relaciona. Deben usarse con cuidado, especialmente si la muestra es privada o contiene datos sensibles.

Antes de subir una muestra a un servicio externo, hay que evaluar:

  • Si el archivo puede contener información confidencial.
  • Si la política de la organización permite compartirlo.
  • Si basta con consultar hashes en lugar de subir el archivo.
  • Si la publicación puede alertar a terceros o afectar una investigación.
  • Si los resultados externos distinguen hechos de etiquetas automáticas.

8.18 Correlación de hallazgos

El valor del triage surge de correlacionar datos. Una URL aislada puede ser ruido; una URL junto con imports de red, strings de beaconing y alta entropía en configuración tiene más peso.

Ejemplos de correlación:

  • Imports de red + dominios en strings + user-agent embebido: posible comunicación C2.
  • Imports criptográficos + lista de extensiones + nota embebida: posible ransomware.
  • Pocos imports + alta entropía + entry point extraño: posible packing.
  • Recursos grandes + drop de archivos observado después: posible dropper.
  • Metadatos de empresa conocida + firma inválida: posible suplantación.

8.19 Priorización de próximos pasos

Después del triage, el analista debe decidir qué hacer. No todas las muestras requieren el mismo esfuerzo.

Hallazgo inicial Prioridad probable Siguiente paso
Indicadores claros y muestra conocida Respuesta rápida Extraer IOCs, bloquear y buscar alcance
Alta entropía y pocos imports Análisis técnico Preparar debugging o desempaquetado controlado
Strings de ransomware Alta urgencia Analizar en laboratorio aislado y revisar exposición
Documento con descarga externa Cadena de infección Identificar URL, payload y condiciones de ejecución
Firmado por editor confiable pero comportamiento sospechoso Validación Verificar firma, origen, ruta y posible abuso

8.20 Registro de resultados

Un triage útil debe quedar documentado. Si los resultados solo viven en la memoria del analista, no sirven para respuesta, colaboración ni revisión posterior.

Un registro mínimo debería incluir:

  • Identificación de la muestra: hash, tamaño, nombre recibido y tipo.
  • Contexto: origen, fecha, caso o incidente asociado.
  • Herramientas usadas y versiones si son relevantes.
  • Strings, imports, metadatos y recursos destacados.
  • Firmas o reglas que coincidieron.
  • Hipótesis iniciales y nivel de confianza.
  • Recomendación de próximos pasos.

8.21 Checklist de análisis estático inicial

  1. Registrar origen y preservar muestra original.
  2. Calcular hashes, tamaño y tipo real de archivo.
  3. Identificar arquitectura, plataforma y formato.
  4. Revisar cabeceras, secciones, permisos y entropía.
  5. Extraer strings ASCII, Unicode y otros formatos relevantes.
  6. Revisar imports, exports, recursos y metadatos.
  7. Verificar firmas digitales y reputación con cautela.
  8. Buscar señales de packing u ofuscación.
  9. Aplicar firmas o reglas YARA si corresponde.
  10. Documentar hipótesis, IOCs y próximos pasos.

8.22 Errores frecuentes

  • Ejecutar la muestra antes de calcular hashes y revisar estructura.
  • Confiar en extensión, icono o nombre del archivo.
  • Tratar strings aisladas como conclusiones definitivas.
  • Subir muestras privadas a servicios externos sin autorización.
  • Confundir packing con prueba automática de malware.
  • No distinguir capacidades importadas de comportamiento observado.
  • No documentar herramientas, resultados y nivel de confianza.

8.23 Qué debes recordar de este tema

  • El análisis estático inicial extrae información sin ejecutar la muestra.
  • Hashes identifican archivos concretos, pero son indicadores frágiles ante cambios mínimos.
  • Strings, imports, metadatos y recursos ayudan a formular hipótesis, no conclusiones absolutas.
  • Packing y ofuscación limitan el análisis estático y suelen requerir técnicas posteriores.
  • El triage debe terminar con evidencia registrada y próximos pasos claros.

8.24 Conclusión

El análisis estático inicial es una etapa de bajo riesgo y alto valor. Permite identificar la muestra, reconocer capacidades probables, detectar anomalías y decidir qué análisis posterior será más rentable.

En el próximo tema avanzaremos hacia análisis dinámico: monitoreo de procesos, sistema de archivos, registro y red, para observar qué hace la muestra cuando se ejecuta en un laboratorio controlado.