Dónde mira la regla: fuentes de datos

Ánfora quiere detectar el latido del canal de mando (T1071). Por bien escrita que esté la lógica —intervalo casi idéntico, tamaño constante—, no verá nada si no se están recogiendo las conexiones de red donde ese latido deja rastro. La técnica del canal de mando se observa en los registros de red y del proxy: ahí queda cada conexión saliente. Una regla brillante apuntada a un registro que no existe es una regla ciega. El primer paso de toda detección no es la lógica, es asegurarse de que el dato que necesita se está capturando.

Detectar empieza por recoger. La mejor lógica del mundo sobre un registro que nadie guarda no dispara jamás.

Hay un fallo silencioso que hunde detecciones: escribir la regla perfecta para una técnica cuyo registro nadie recoge. No da error, no avisa; simplemente no dispara nunca, y el equipo cree estar cubierto cuando no lo está. Por eso ATT&CK empareja cada técnica con sus fuentes de datos: antes de prometer que detectas algo, compruebas que recoges el registro donde deja rastro. Si no lo recoges, la honestidad es decir «esta técnica hoy es invisible para nosotros» y abrir el registro, no fingir cobertura.

Una técnica sin su fuente de datos recogida es un punto ciego que se disfraza de cobertura. El mapa de detección miente si no se cruza con lo que de verdad se captura.

La persistencia del actor es una tarea programada (T1053). ¿Dónde se detecta? No en la red —la tarea no manda tráfico por existir— sino en el propio equipo: en el registro de creación de tareas y en el del proceso que la crea. Cada técnica deja su huella en un sitio distinto, y acertar con el sitio es la mitad del trabajo. Buscar la tarea programada en los registros de red sería mirar donde no está; buscarla en el registro del equipo, donde se crea y se ejecuta, es donde sí aparece.

Cada técnica tiene su escenario del crimen. La tarea programada no se ve en el cable: se ve en la máquina donde nace.

La regla de inicios de sesión a horas raras (T1078) que Ánfora ya tenía lee los registros de autenticación —donde queda anotado quién inició sesión y cuándo—, no los de red ni los del proceso. Emparejar bien cada técnica con su fuente de datos evita dos errores: apuntar la regla a un registro donde la técnica no deja rastro (no dispara) y, al revés, no recoger un registro que una técnica importante necesita (punto ciego). El trabajo previo a escribir reglas es dibujar ese mapa: qué técnicas me importan, qué registro necesita cada una, y cuáles de esos registros estoy recogiendo.

Antes de escribir una regla, se traza el mapa de técnica a registro. Es lo que convierte una lista de deseos de detección en una cobertura real y medida.

Abre la tabla de cobertura de la plataforma. Para el canal de mando, la plataforma marca la técnica como detectable porque Ánfora sí recoge el registro donde deja rastro. Aísla esa entrada de cobertura y lee el código que la plataforma le asignó.