De hallazgo de red team a regla Sigma probada en una tarde

Casi todas las evaluaciones mueren en el traspaso. Llega el informe, los hallazgos se triangulan hacia un backlog, el equipo de ingeniería de detección lee un párrafo de narrativa escrito para un directivo y seis meses después la misma técnica vuelve a funcionar porque nadie tradujo «escalamos por una ruta de servicio sin comillas» a algo que un SIEM pueda evaluar. La distancia no es de destreza. Es que los dos equipos producen y consumen artefactos distintos, y nadie es dueño de la conversión.

La conversión es una tarde de trabajo por hallazgo, y es la misma tarde siempre. Lo que sigue es su forma.

Qué tiene que llevar el hallazgo

Un hallazgo escrito para remediar responde a «qué deberíamos cambiar». Un hallazgo escrito para detectar tiene que responder a «cómo se habría visto esto en los logs», y ese es otro conjunto de datos. Captúralos mientras el acceso siga vivo, porque reconstruirlos después de memoria es como las reglas acaban casando con lo que no toca.

• La línea de comandos exacta, tal cual se ejecutó. No una versión limpia para el informe.
• El proceso padre, y el proceso anterior a ese. Las reglas más duraderas se apoyan en el linaje y no en la hoja.
• Marcas de tiempo al segundo, y el host. Sin eso no se puede recortar el corpus de reproducción.
• Cuáles de los parámetros de la técnica son esenciales y cuáles fueron elección circunstancial. Este es el campo más valioso de todos y sale del criterio del operador, no de la telemetría.
• La técnica de MITRE ATT&CK, para que la regla entre en un mapa de cobertura en vez de quedarse sola.

El penúltimo punto merece atención. Un operador eligió un flag, un nombre de fichero, un directorio de trabajo. Algunas de esas decisiones venían forzadas por la técnica y otras fueron arbitrarias. Un ingeniero de detección que lee la transcripción no puede saber cuál es cuál, y si se equivoca al adivinar la regla caza a ese operador y a nadie más. Preguntárselo a quien la ejecutó cuesta treinta segundos y es la diferencia entre una regla con una vida útil de años y otra que caduca en cuanto alguien renombra un binario.

Escribir la regla contra la capa equivocada primero

El primer borrador casi siempre es demasiado específico, y no pasa nada: escríbelo y después sube.

Empieza por el artefacto literal. Después pregúntate a qué tendría que renunciar un atacante para evadir el borrador actual. Si la respuesta es «a nada, renombra el fichero», la regla se apoya en lo que no debe y subes un nivel: a la relación padre-hijo, a la API que se llama, al cambio de estado resultante. Sigue subiendo hasta que la respuesta sea «tendría que abandonar la técnica». Ahí es donde va la regla, y suele estar dos o tres niveles por encima de donde quedó el primer borrador.

title: Service binary path modified to a user-writable location
id: 9f3c0a51-4c1c-4c73-9f0e-6f2c1b5d7a48
status: experimental
description: >
  Detects reconfiguration of an existing service to execute from a path the
  invoking user can write. Keyed on the reconfiguration, not on the tool that
  performs it.
references:
  - https://attack.mitre.org/techniques/T1574/
logsource:
  product: windows
  category: process_creation
detection:
  reconfigure:
    Image|endswith: '\sc.exe'
    CommandLine|contains|all:
      - 'config'
      - 'binPath'
  writable_target:
    CommandLine|contains:
      - '\Users\'
      - '\ProgramData\'
      - '\Temp\'
  condition: reconfigure and writable_target
falsepositives:
  - Installers reconfiguring their own service during upgrade. Baseline by parent.
level: high
tags:
  - attack.persistence
  - attack.privilege_escalation

El campo falsepositives no es documentación. Es el registro de lo que ya sabes que va a disparar, y es lo que evita que la misma conversación de triaje se repita cada trimestre con un analista distinto.

Demostrar que dispara

Una regla que no ha disparado nunca es una hipótesis. Dos pruebas separan una cosa de la otra, y las dos son rápidas.

La prueba de verdadero positivo consiste en reejecutar la técnica en un laboratorio y confirmar que la regla casa. Ejecútala más de una vez y varía los parámetros circunstanciales: otro nombre de fichero, otro directorio, otro usuario invocante. Si alguna de esas variaciones evade la regla, subiste un nivel de menos. Aquí es donde la anotación del operador sobre lo esencial y lo circunstancial se gana su sitio.

La prueba de falso positivo es la que la gente se salta. Reproduce la regla contra una ventana de telemetría real de producción, treinta días es un valor razonable por defecto, y cuenta las coincidencias. El número te dice qué hacer después:

• Cero coincidencias: bien, suponiendo que la prueba de verdadero positivo pasó. A producción.
• Un puñado, todas explicables: identifica la fuente, añade una exclusión ajustada sobre algo que un atacante no pueda asumir con facilidad y déjalo escrito en falsepositives.
• Cientos: la regla está mal para este entorno. O el comportamiento es normal aquí, o te apoyaste en algo demasiado genérico. No la despliegues detrás de una pila de filtros; una regla que necesita nueve exclusiones para ser usable estará desactivada en silencio antes de un mes.

Probar contra datos históricos cuesta una consulta y zanja la discusión antes de que un analista tenga que tenerla a las dos de la madrugada.

Una detección que no has disparado a propósito no es un control. Es una intención con sintaxis YAML.

Cerrar el círculo

La regla se mergea. Eso no es el final del flujo, porque una regla que dispara hacia una cola que nadie triangula no ha cambiado nada.

Tres cosas rematan el trabajo. La alerta necesita una acción de respuesta asociada: el analista que la recibe no debería tener que deducir qué hacer a partir del título de la regla. El hallazgo del informe recibe una referencia al ID de la regla, de modo que el ticket de remediación y la detección quedan visiblemente conectados. Y la técnica entra en una lista de re-test, porque el estado final correcto es que la misma técnica se intente de nuevo más adelante y la regla dispare, en producción, sin avisar.

Ese último paso es lo que convierte una evaluación de documento en medición. También suele destapar los casos incómodos: la regla que disparó correctamente hacia una cola con cuatro días de retraso, o la regla que se desactivó en la tercera semana porque hacía ruido en una unidad de negocio a la que nadie consultó. Esos son hallazgos más útiles que la ruta de escalada original.

Dónde se va la tarde en realidad

La regla lleva veinte minutos de escritura. La reproducción de la técnica lleva una hora si el laboratorio ya existe. Probar contra el histórico es una consulta. El resto, que es casi todo, es la conversación entre el operador que ejecutó la técnica y el ingeniero que tiene que detectarla, sobre qué detalles importaban.

Protege esa conversación. Todo lo demás en este flujo es mecánico y se puede plantillar. Eso no, y es la razón de que la regla funcione contra el próximo atacante y no solo contra el último.