Tema 17
La detección convierte hallazgos de análisis en capacidad defensiva. YARA ayuda a reconocer archivos y memoria, Sigma expresa patrones de eventos, las reglas de red observan comunicaciones y el enriquecimiento da contexto para priorizar.
Analizar malware produce conocimiento. La detección transforma ese conocimiento en mecanismos que permiten encontrar muestras, comportamientos, conexiones o eventos similares en otros sistemas.
Una detección puede ser exacta y puntual, como un hash, o más general, como una regla que busca una combinación de cadenas, eventos o comportamiento de red. Cuanto más general es una regla, más cuidado requiere para evitar falsos positivos.
Este tema aborda detección desde una perspectiva educativa y defensiva: cómo elegir indicadores, escribir reglas, validar resultados, enriquecer contexto y mantener calidad.
No todo hallazgo debe convertirse en regla. Primero hay que evaluar si es estable, específico, observable y útil.
Las detecciones pueden agruparse por fuente de telemetría y tipo de señal.
| Tipo | Fuente | Uso típico |
|---|---|---|
| Archivo | Hash, YARA, metadatos | Encontrar muestras o familias en disco |
| Memoria | YARA, dumps, EDR | Detectar código desempaquetado o config en ejecución |
| Endpoint | Procesos, registro, archivos, eventos | Detectar persistencia y comportamiento |
| Red | DNS, proxy, IDS, firewall, NDR | Detectar C2, beaconing, descarga o exfiltración |
| Correlación | SIEM o plataforma centralizada | Relacionar señales débiles en una alerta más fuerte |
YARA es una herramienta y lenguaje de reglas para identificar archivos o memoria por patrones. Es muy usada en análisis de malware porque permite combinar cadenas, bytes, metadatos y condiciones lógicas.
Una regla YARA puede buscar:
Una regla YARA suele contener metadatos, strings y una condición. Los metadatos documentan; las strings definen patrones; la condición decide cuándo hay coincidencia.
rule ejemplo_familia_sospechosa
{
meta:
description = "Detecta rasgos de una familia analizada en laboratorio"
author = "Equipo defensivo"
confidence = "media"
strings:
$s1 = "ruta_configuracion" ascii
$s2 = "User-Agent" ascii
$h1 = { 4D 5A }
condition:
uint16(0) == 0x5A4D and 2 of ($s*)
}Esta regla es ilustrativa. En un entorno real se debe ajustar a evidencias específicas, probar contra corpus benigno y documentar limitaciones.
YARA también puede aplicarse sobre memoria. Esto es útil cuando el malware está empaquetado, descifra strings durante ejecución o carga payloads que no existen completos en disco.
Casos de uso:
Sigma es un formato genérico para expresar reglas de detección basadas en logs. Permite describir patrones de eventos de forma portable y luego convertirlos a consultas para distintas plataformas SIEM o EDR.
Sigma se usa para detectar comportamiento, por ejemplo:
Una regla Sigma define título, estado, descripción, fuentes de log, condiciones de detección, falsos positivos y nivel.
title: Ejecucion Sospechosa Desde Directorio Temporal
status: experimental
description: Detecta procesos ejecutados desde rutas temporales por contexto sospechoso
logsource:
category: process_creation
detection:
selection:
Image|contains:
- '\Temp\'
- '\AppData\Local\Temp\'
condition: selection
falsepositives:
- Instaladores legítimos
level: mediumLa regla es educativa y simplificada. En producción se debe ajustar por entorno, procesos permitidos, firmas, hashes y contexto.
Las reglas de red buscan actividad en DNS, HTTP, TLS, IDS, proxy, firewall o NDR. Pueden detectar destinos, patrones de protocolo, cabeceras, certificados, tamaños o periodicidad.
| Fuente | Patrón detectable | Cuidado |
|---|---|---|
| DNS | Dominio, subdominio largo, NXDOMAIN repetido | Evitar bloquear dominios legítimos comprometidos sin contexto |
| HTTP | URL, método, User-Agent, cabeceras | Muchos valores pueden ser imitados o genéricos |
| TLS | SNI, certificado, huella de cliente | Puede haber CDNs y servicios compartidos |
| IDS | Firma de protocolo o contenido | Requiere tuning y revisión de falsos positivos |
| Proxy | Destino, categoría, volumen, usuario | Necesita correlación con endpoint |
Beaconing requiere mirar patrones temporales. Una regla simple por dominio puede ser útil, pero una detección más resistente observa frecuencia, tamaño, proceso y destino.
Señales combinables:
Detectar exfiltración exige correlacionar host, datos y red. El volumen por sí solo no siempre basta; una transferencia pequeña puede contener secretos y una grande puede ser legítima.
Enriquecer IOCs consiste en agregar contexto para priorizar y decidir acciones. El enriquecimiento puede venir de fuentes internas o externas.
| IOC | Enriquecimiento útil | Decisión posible |
|---|---|---|
| Hash | Prevalencia interna, primera vez visto, firma | Buscar, aislar o permitir según contexto |
| Dominio | Edad, reputación, resolución, presencia en logs | Bloquear, monitorear o investigar |
| IP | ASN, servicio, historial, relación con CDN | Evitar bloqueos amplios si es compartida |
| Ruta | Frecuencia en endpoints, firmante, proceso creador | Crear alerta contextual |
| Comportamiento | Usuarios afectados, frecuencia, secuencia de eventos | Elevar severidad si hay correlación |
Las fuentes internas suelen ser más relevantes que la reputación externa porque muestran qué ocurre en el propio entorno.
Las fuentes externas pueden aportar reputación, relaciones conocidas, reportes de campañas o datos históricos. Deben usarse con cuidado y no reemplazan evidencia propia.
Siempre conviene registrar fuente, fecha y nivel de confianza del enriquecimiento externo.
Una detección que alerta demasiado pierde valor operativo. El ajuste de falsos positivos es parte del ciclo de vida de una regla.
Una regla debe indicar qué tan grave es una coincidencia y qué acción se espera. No todas las detecciones implican bloqueo o aislamiento inmediato.
| Severidad | Ejemplo | Respuesta inicial |
|---|---|---|
| Baja | IOC débil o indicador genérico | Enriquecer y observar |
| Media | Comportamiento sospechoso con contexto parcial | Investigar host y usuario |
| Alta | Persistencia maliciosa o payload conocido | Contener y buscar alcance |
| Crítica | Exfiltración confirmada o ransomware activo | Respuesta inmediata coordinada |
Antes de desplegar una regla, hay que probarla. Las pruebas deben incluir casos positivos y negativos.
Las reglas envejecen. Cambian las familias de malware, la infraestructura, los formatos de logs y el entorno de la organización.
Medir detecciones ayuda a mejorar cobertura y reducir ruido.
La detección es el puente entre análisis técnico y defensa operativa. Al convertir configuraciones, artefactos y comportamientos en reglas bien documentadas, un equipo puede buscar actividad relacionada, alertar con contexto y responder con menos incertidumbre.
En el próximo tema iniciaremos el bloque de vulnerabilidades: fundamentos de memoria, validación de entrada y lógica insegura, para entender cómo las fallas se convierten en condiciones explotables.