← Todas las notas de campo

Barriendo la persistencia común, rápido

El puñado de claves de registro, tareas programadas y servicios que explican la mayoría de la persistencia en el mundo real, y cómo revisarlos en minutos.

Cuando salta una detección y hay que responder “¿esto vuelve después de reiniciar?”, no hay tiempo para enumerar cada técnica de persistencia del manual. En la práctica, un pequeño conjunto de mecanismos explica la abrumadora mayoría de lo que realmente se encuentra en un host Windows comprometido. Conocer ese conjunto, y poder revisarlo en una sola pasada, es la diferencia entre un triaje de cinco minutos y una tarde entera.

Dónde vive realmente la persistencia

La mayoría de la persistencia real cae en uno de estos grupos:

  • Claves Run / RunOnce: la clásica, y sigue siendo la más común. Tanto en el hive de máquina como en el de usuario. Barata para el operador, y sobrevive a los reinicios.
  • Tareas programadas: flexibles, fáciles de disfrazar con un nombre de apariencia inofensiva, y capaces de ejecutarse con disparadores distintos al inicio de sesión.
  • Servicios: más pesados, requieren privilegios, pero muy persistentes cuando el operador los tiene.
  • Carpetas de inicio: de bajo esfuerzo, en contexto de usuario, y todavía sorprendentemente comunes.
  • Suscripciones a eventos WMI: la que la gente olvida. Vínculos de filtro más consumidor que se disparan ante una condición, sin dejar rastro en las ubicaciones habituales de autoarranque.

La mentalidad del triaje

Dos principios mantienen honesto un barrido de persistencia.

Primero: establecer una línea base y luego comparar. Una instalación limpia de Windows tiene muchos autoarranques legítimos. La señal no es “esta clave tiene entradas”, sino “esta clave tiene una entrada que no debería estar ahí”. Con lo normal a la vista, la anomalía resalta de inmediato.

Segundo: leer las marcas de tiempo como una línea temporal. Una entrada de persistencia escrita a las 03:14 se alinea con el proceso que la creó y la conexión de red que le siguió. La persistencia aislada es una pista; la persistencia correlacionada con un evento de ejecución es un hallazgo.

Automatizando el barrido

Este es exactamente el tipo de recolección repetitiva y bien acotada que debería automatizarse: no para tomar la decisión, sino para reunir la evidencia y dejarla legible. Un buen recolector de persistencia extrae las ubicaciones comunes de autoarranque, las normaliza, marca las entradas que se desvían de una línea base confiable y devuelve un resumen limpio adjunto al caso.

Esa última parte importa. El resultado de la automatización debe ser evidencia que un analista lee, no un veredicto que se le pide aceptar. La herramienta encuentra la suscripción WMI; el analista decide si es el software de respaldo o el intruso.

Una nota sobre el punto ciego de WMI

Si se barren las claves Run, las tareas, los servicios y las carpetas de inicio pero se omiten las suscripciones a eventos WMI, queda un hueco que un operador experimentado usará con gusto. Hay que enumerar __EventFilter, CommandLineEventConsumer / ActiveScriptEventConsumer, y el __FilterToConsumerBinding que los une. Es un poco de trabajo extra que cierra uno de los escondites favoritos.

MITRE ATT&CK

Las técnicas de persistencia que este barrido está pensado para cubrir.

Táctica Técnica ID
Persistencia Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder T1547.001
Persistencia Scheduled Task/Job: Scheduled Task T1053.005
Persistencia Create or Modify System Process: Windows Service T1543.003
Persistencia Event Triggered Execution: Windows Management Instrumentation Event Subscription T1546.003

El punto central

No hace falta revisarlo todo. Hace falta revisar lo correcto, rápido, y leer con criterio lo que aparece. La persistencia es uno de los pocos lugares de una investigación donde el atacante está obligado a dejar algo atrás, y por eso es de lo más rentable que se puede mirar temprano.