Cómo leer el registro
(traza) de un veredicto
Por cada veredicto, Threat Correlator deja registrado qué miró, a qué herramientas llamó y en qué evidencias basó su conclusión.
Todavía no tenemos registros de ejecuciones reales que podamos publicar, así que en esta página explicamos la estructura del registro y leemos un ejemplo de principio a fin.
Qué contiene un registro
Leído de arriba abajo, sigue el mismo orden en que se construyó el veredicto.
Cada veredicto lleva varios pasos (step), y cada paso agrupa una observación, las llamadas a herramientas, las evidencias y el razonamiento.
| Campo | Contenido | Qué revisar al leerlo |
|---|---|---|
| input_hash | SHA-256 del conjunto completo de entradas del veredicto | Con este valor se comprueba que una repetición usó la misma entrada |
| sources | De dónde vienen las entradas (EDR, pasarela de correo, proxy, etc.) y el intervalo de tiempo | Si falta una fuente, el alcance del veredicto se reduce en la misma medida |
| steps[].observation | El hecho en el que se fijó ese paso | Es un resumen de los logs originales; compruebe que cuadra con las evidencias de abajo |
| steps[].tool_call | Herramienta llamada, argumentos y resumen del resultado | Revise que argumentos como el intervalo de tiempo o el nombre de host sean correctos |
| steps[].evidence | ID de la evidencia, ubicación original y hash | Incluye el resultado de comprobar automáticamente que el log citado existe en el original |
| steps[].reasoning | Por qué se pasa de las evidencias a la conclusión, con el ID de técnica de ATT&CK | Cada frase del razonamiento debe apuntar a un ID de evidencia |
| verdict · confidence | Etiqueta del veredicto, nivel de riesgo, confianza y los motivos que la rebajaron | Compruebe que se explica por qué la confianza es baja |
| recommended_actions | Acciones recomendadas y si requieren aprobación | Aislar un host o bloquear una cuenta siempre requiere aprobación |
| approval | ID del rol que aprueba, decisión (aprobar, modificar o rechazar), hora y comentario | De aquí sale también el tiempo que tardó la aprobación |
| versions | Versión del modelo, de la plantilla de prompt y de la política | Basta con cambiar el texto del prompt para que cambie el criterio del veredicto |
| replay | Resultado de repetir el análisis más tarde en las mismas condiciones y su diferencia con el veredicto original | Las frases pueden variar. Lo que importa es que coincidan la etiqueta y el nivel de riesgo |
Leemos un registro de ejemplo desde el principio
Registro de ejemplo · no son datos de clientes ni una ejecución real. Lo hemos construido encadenando técnicas de las primeras fases de un ransomware documentadas en MITRE ATT&CK (adjunto de phishing, ejecución de PowerShell y borrado de instantáneas). Los nombres de host, las cuentas, las horas y los valores de confianza son ilustrativos, y los dominios e IP usan valores reservados para documentación (.example, 203.0.113.0/24).
Dónde mirar primero
Empiece por ver por qué la confianza del veredicto se quedó en 0,91. En este ejemplo consta que todavía no se había observado cifrado de archivos y que el hash del ejecutable descargado no coincidía con nada en la inteligencia de amenazas. Si un registro tiene una confianza alta y no explica nada de lo que la rebajó, ese es el que merece más desconfianza.
Después, la línea de aprobación. Por política, el aislamiento de un host nunca se ejecuta automáticamente. En el registro también se ve que, desde el veredicto hasta que el analista leyó las evidencias y lo aprobó, pasaron algo más de 2 minutos.
Lectura paso a paso
- Recepción del correo (step 1). En el log de la pasarela de correo hay un mensaje de
billing@invoice-notice.examplecon el adjuntopresupuesto_1021.docm. La IA consultó los metadatos del mensaje original conmail.search(message_id=…)y los datos del dominio conintel.domain_whois("invoice-notice.example"). Resultado: el dominio se había creado 3 días antes. La frase del razonamiento es "adjunto de Office con macros y dominio recién creado, posible T1566.001" y apunta a las evidencias E1 y E2. Con este paso solo, no emitió veredicto. - Ejecución de PowerShell (step 2). En el evento 1 de Sysmon (creación de proceso) aparece una línea con
WINWORD.EXEcomo padre ypowershell.exe -NoP -W Hidden -enc JABjAD0A…como hijo. La IA obtuvo el árbol de procesos conedr.process_tree(host="fin-ws-0412", from="09:12", to="09:20")y, al decodificar el comando, comprobó que descargabahttps://203.0.113.45/u.ps1. La consultabaseline.parent_child(host, 30d)mostró que en los últimos 30 días ninguna aplicación de Office había lanzado PowerShell en ese host. Razonamiento: T1059.001; evidencias: E3 y E4. - Borrado de instantáneas (step 3). El evento 11 de Sysmon (creación de archivo) registra
C:\Users\user01\AppData\Local\Temp\upd.exey, unos 20 segundos después, el evento 1 muestravssadmin.exe delete shadows /all /quiet, conupd.execomo proceso padre.intel.hash_lookupno devolvió ninguna coincidencia. El razonamiento cita T1490 (Inhibit System Recovery); la propia entrada de T1490 en ATT&CK recoge varios ransomware que borran las instantáneas antes de cifrar. - Veredicto. Verdadero positivo, fase de preparación de la ejecución de un ransomware, riesgo CRITICAL, confianza 0,91. Como motivos que rebajan la confianza figuran dos: "no se observan cambios masivos de archivos" y "el hash de upd.exe no coincide en inteligencia".
- Acciones recomendadas y aprobación. Aislar el host de la red (requiere aprobación), retirar los correos con el mismo hash de adjunto y bloquear el dominio remitente y 203.0.113.45. analyst-07 aprobó el aislamiento a las 09:17 con el comentario "comprobar las sesiones SMB del servidor de archivos". Los dos bloqueos entraban en la política de respuesta automática acordada con el cliente y se ejecutaron sin aprobación.
- Repetición. Al día siguiente se repitió con el mismo input_hash, la misma versión de modelo y la misma versión de política: la etiqueta y el riesgo coincidieron, la confianza fue 0,89 y parte de la redacción del razonamiento cambió. Las frases no se comparan, así que queda registrado como "coincide".
El mismo registro en bruto
Hemos trasladado el ejemplo anterior al formato del registro, abreviado.
Los nombres de campo son ilustrativos; el formato de exportación real se publicará en la documentación cuando salga el producto.
// Registro de ejemplo · no son datos de clientes ni una ejecución real
{
"trace_id": "VT-EXAMPLE-0001",
"input_hash": "sha256:9f3a…c21e",
"sources": [
{"type": "mail_gateway", "range": "09:00~09:20"},
{"type": "edr_sysmon", "host": "fin-ws-0412", "range": "09:00~09:20"}
],
"steps": [
{"n": 1,
"observation": "Adjunto con macros (presupuesto_1021.docm), dominio remitente creado hace 3 días",
"tool_calls": ["mail.search(message_id=…)", "intel.domain_whois(\"invoice-notice.example\")"],
"evidence": [{"id": "E1", "ref": "mailgw/2026/10/21/09.log#L2207", "sha256": "1c0d…7be2", "verified": true},
{"id": "E2", "ref": "intel/whois/invoice-notice.example", "verified": true}],
"reasoning": "E1+E2: posible adjunto de spearphishing", "attack": ["T1566.001"]},
{"n": 2,
"observation": "WINWORD.EXE → powershell.exe -NoP -W Hidden -enc …",
"tool_calls": ["edr.process_tree(host=\"fin-ws-0412\", from=\"09:12\", to=\"09:20\")",
"baseline.parent_child(host=\"fin-ws-0412\", window=\"30d\")"],
"evidence": [{"id": "E3", "ref": "sysmon:EventID=1 RecordID=884213", "verified": true},
{"id": "E4", "ref": "baseline/fin-ws-0412/parent_child", "verified": true}],
"reasoning": "E3: una aplicación de Office ejecuta PowerShell codificado, E4: sin precedentes en 30 días",
"attack": ["T1059.001"]},
{"n": 3,
"observation": "Se crea upd.exe y después vssadmin.exe delete shadows /all /quiet",
"tool_calls": ["edr.process_tree(…)", "intel.hash_lookup(\"sha256:3b7e…a19f\")"],
"evidence": [{"id": "E5", "ref": "sysmon:EventID=11 RecordID=884240", "verified": true},
{"id": "E6", "ref": "sysmon:EventID=1 RecordID=884251", "verified": true}],
"reasoning": "E6: borrado de los medios de recuperación, fase previa al cifrado", "attack": ["T1490"]}
],
"verdict": {"label": "true_positive", "severity": "critical",
"summary": "Fase de preparación de la ejecución de ransomware",
"confidence": 0.91,
"confidence_notes": ["No se observan cambios masivos de archivos", "El hash de upd.exe no coincide en inteligencia"]},
"recommended_actions": [
{"action": "isolate_host", "target": "fin-ws-0412", "requires_approval": true},
{"action": "recall_mail", "match": "attachment_sha256", "requires_approval": false},
{"action": "block", "targets": ["invoice-notice.example", "203.0.113.45"], "requires_approval": false}
],
"approval": {"action": "isolate_host", "by": "analyst-07", "decision": "approved",
"at": "2026-10-21T09:17:40+09:00", "comment": "Comprobar las sesiones SMB del servidor de archivos"},
"versions": {"model": "correlator-model-x.y", "prompt_template": "triage-vNN", "policy": "auto-response-YYYY.MM"},
"replay": {"at": "2026-10-22T10:05:12+09:00", "same_input_hash": true,
"label_match": true, "severity_match": true, "confidence": 0.89,
"text_diff": "Cambia parte de la redacción del razonamiento"}
}
verified es el resultado de comprobar automáticamente que el log citado existe de verdad en el almacenamiento original. Si uno solo es false, el veredicto queda en suspenso y pasa a un analista. Cómo contamos esta comprobación está explicado en el apartado de detección de citas inventadas de la página sobre la calidad de los veredictos de la IA.
Qué hace con el registro quien lo recibe
El registro de veredictos no se queda en un log interno que solo ve Genox.
Lo diseñamos partiendo de que el equipo de seguridad del cliente y los auditores lo abrirán directamente.
Auditorías
Si en una auditoría o en la investigación de un incidente le preguntan "¿por qué se aisló este host?", la respuesta es un registro. Lo que se vio está en evidence, quién lo aprobó está en approval y qué modelo y qué política estaban activos está en versions. Las evidencias se guardan como ubicación y hash, así que conviene que el periodo de retención de los logs originales coincida con el de los registros de veredictos.
Análisis de falsos positivos
Cuando un veredicto se confirma como falso positivo, se busca en qué paso se torció. Si un argumento de una llamada a herramienta era incorrecto, si la consulta de la línea base volvió vacía o si el razonamiento fue más allá de las evidencias, normalmente se ve siguiendo los step uno a uno. Cuando incluimos falsos positivos en el informe mensual, adjuntamos este mismo registro.
Mejora de reglas
Si se repiten veredictos cuya confianza baja por el mismo motivo, se ve dónde hay que ajustar el alcance de la recogida de datos o las reglas de detección. En el ejemplo de arriba, los logs de auditoría del servidor de archivos no estaban en sources y no se pudo comprobar si hubo movimiento lateral. Después de cambiar la política, se repiten los veredictos anteriores con la nueva versión y se revisan las diferencias.
Publicaremos registros reales
en cuanto los tengamos
En el entorno aislado de Research Lab estamos reproduciendo técnicas de ataque públicas y recopilando los registros de los veredictos de Threat Correlator. Cuando tengamos suficientes registros de ejecución sin datos de clientes, los subiremos a esta página tal cual. Hasta entonces, todos los registros de esta página son ejemplos.
Compromisos para la publicación
- Publicaremos los registros con veredictos erróneos junto con los acertados
- Indicaremos el ID de la técnica reproducida y el procedimiento seguido
- Cada registro llevará la versión de modelo y de política; si la versión cambia, añadiremos el resultado de repetir el análisis
- Los nombres de host y las cuentas del entorno aislado no coincidirán con los de entornos reales de clientes
Páginas relacionadas
Cómo medimos la calidad de los veredictos de la IA
Cómo medimos, a partir de los registros de veredictos, la exactitud, los falsos positivos y negativos, las evidencias que faltan y la coherencia al repetir el análisis.
Ver el métodoThreat Correlator
El motor que agrupa las alertas en casos y registra evidencias, razonamiento, veredicto, acciones recomendadas y confianza.
Threat CorrelatorPlataforma
Cómo se conectan Vulnerability Scanner, Behavioral Analyzer, Threat Correlator y Research Lab.
Ver la plataformaReferencias
- Phishing: Spearphishing Attachment (T1566.001), MITRE ATT&CK
- Command and Scripting Interpreter: PowerShell (T1059.001), MITRE ATT&CK
- Inhibit System Recovery (T1490), MITRE ATT&CK
- Sysmon, Microsoft Sysinternals (evento 1, creación de proceso; evento 11, creación de archivo)
- vssadmin delete shadows, Microsoft Learn
- RFC 5737 IPv4 Address Blocks Reserved for Documentation, IETF
- RFC 2606 Reserved Top Level DNS Names, IETF