Persistencia en Windows: 10 Tecnicas Documentadas y sus Contramedidas

La persistencia no es la parte glamorosa de un compromiso, pero es la que separa al adversario que pierde acceso en el primer reinicio del que vuelve tres semanas despues, cuando el equipo ya olvido la alerta. En Basilisk OffSec corremos ejercicios contra clientes donde mas del 70% de las detecciones que terminaron en caso real comenzaron con mecanismos triviales: claves Run, scheduled tasks con nombres pintorescos, servicios con rutas sin comillas. El objetivo de este catalogo no es ensenar a esconder implantes, sino documentar diez tecnicas reales que vemos cada semana, mapear cada una a su ID de MITRE ATT&CK y entregar consultas KQL que tu Defender XDR o Sentinel pueden ejecutar manana por la manana, junto a la contramedida que cierra cada puerta.

1. Claves de registro de ejecucion automatica (T1547.001)

La primera familia que importa cubrir es la de las claves de registro de ejecucion automatica. HKCU\Software\Microsoft\Windows\CurrentVersion\Run sigue siendo el T1547.001 mas explotado en campanas commodity, no porque los atacantes sean perezosos, sino porque funciona en cualquier perfil sin necesidad de privilegio. Una consulta simple como DeviceRegistryEvents | where RegistryKey has "CurrentVersion\\Run" and InitiatingProcessFileName !in ("explorer.exe","msiexec.exe") ya captura el 80% de los casos cuando haces baseline por hostname. La contramedida es un baseline por usuario mas AppLocker o WDAC bloqueando ejecucion desde rutas escribibles por el usuario, para que ni una clave Run escrita pueda lanzar. Para entender el contexto ofensivo de estas rutas, conviene revisar Initial Access Simulado: Macros, LNK e ISO en un Lab Windows 11 Aislado porque la mayoria de los macros que vemos en laboratorio termina escribiendo exactamente en esas claves.

2. Scheduled Tasks (T1053.005)

Las Scheduled Tasks son la segunda tecnica mas abusada y la mas subnotificada. El problema no es detectar la creacion de la tarea, sino filtrar el ruido: un Windows 11 corporativo crea en promedio 40 tareas legitimas en ciclos de update. La consulta que mejor nos ha servido es DeviceProcessEvents | where FileName == "schtasks.exe" and ProcessCommandLine has_any ("/create","/change") | where InitiatingProcessParentFileName !in (~"msiexec.exe",~"trustedinstaller.exe") combinada con enriquecimiento via Get-ScheduledTask filtrando Author vacio o autor sin firma. En paralelo, monitorear el evento 4698 en Security log y revisar TaskCache\Tree en el registro captura tareas ocultas que no aparecen en schtasks /query. La contramedida es alertar sobre creacion de tareas fuera de ventanas de cambio y negar el registro de tareas a no-admins via GPO.

3. Servicios Windows (T1543.003)

Los servicios Windows siguen siendo el vector preferido cuando el atacante ya tiene SYSTEM. Aqui el foco del blue team debe estar en tres senales: creacion de servicio apuntando a binario sin firmar, ImagePath en directorios mundialmente escribibles como ProgramData o Public, y el clasico unquoted service path. Una buena caceria empieza con DeviceEvents | where ActionType == "ServiceInstalled" | where FolderPath !startswith "C:\\Windows\\" and FolderPath !startswith "C:\\Program Files". Para no confundir con instalaciones legitimas, haz join con la tabla de certificados y descarta todo lo que tiene signer corporativo conocido. La contramedida es entrecomillar cada ruta de servicio, restringir SeCreateServicePrivilege y forzar code-signing. Este patron resuena con lo que cubrimos en Hunting de Living-off-the-Land Binaries en Windows con KQL sobre deteccion baseline-driven.

4. WMI Event Subscription (T1546.003)

WMI Event Subscription es donde la cosa se pone seria. Es silenciosa, sobrevive al reinicio y rara vez aparece en playbooks junior. La receta: monitorear __EventFilter, __EventConsumer y __FilterToConsumerBinding en la clase root\subscription. En Defender, DeviceEvents | where ActionType == "WmiBindEventFilterToConsumer" funciona, pero en ambientes sin MDE necesitas Sysmon con los eventos 19, 20 y 21 habilitados. Combinalo con Get-WmiObject -Namespace root\subscription -Class __EventConsumer ejecutandose semanalmente como compliance check; un CommandLineEventConsumer o ActiveScriptEventConsumer en un endpoint casi nunca es legitimo. Tecnicas de movimiento lateral que terminan en persistencia WMI estan bien ilustradas en Movimiento Lateral en Lab: SMB, WMI y WinRM con Foco en Deteccion.

5. COM Hijacking (T1546.015)

El COM hijacking explota la precedencia de HKCU sobre HKLM en CLSIDs. El atacante registra un InProcServer32 en HKCU apuntando a una DLL controlada, y cualquier proceso que cargue ese CLSID en sesion de usuario ejecuta el codigo. Para cazar, enfocate en escrituras inesperadas en HKCU\Software\Classes\CLSID\*\InProcServer32 donde el valor por defecto no termina en DLL firmada por Microsoft. La contramedida es hacer baseline de que CLSIDs sobreescribe cada host en HKCU legitimamente (normalmente ninguno) y alertar sobre cualquier entrada nueva, ya que una imagen corporativa limpia casi nunca puebla esa clave.

6. AppInit_DLLs e Image File Execution Options (T1546.010 / T1546.012)

AppInit_DLLs e Image File Execution Options entran en la misma categoria de abuso de registry-based execution flow y merecen consultas dedicadas. AppInit_DLLs carga una DLL en todo proceso que enlaza user32.dll, y Windows moderno lo deshabilita bajo Secure Boot, asi que su sola activacion es una bandera roja: alerta sobre cualquier escritura en HKLM\...\Windows\AppInit_DLLs. El abuso de IFEO fija un valor Debugger bajo la clave de un ejecutable objetivo, de modo que lanzar, digamos, sethc.exe corre el binario del atacante; caza escrituras a los valores Debugger y GlobalFlag y correlaciona con procesos hijo inesperados. Quien quiera entender por que la evasion moderna sigue pasando por aqui debe leer Evasion de EDR para Investigacion: Direct Syscalls Explicados sin Romantizar.

7. Startup folder y Logon Scripts (T1037)

El Startup folder y los Logon Scripts cierran el trio clasico de user-land. Un acceso directo soltado en el Startup folder por usuario o para todos corre en el logon sin elevacion, y el valor de registro UserInitMprLogonScript bajo HKCU\Environment ejecuta un script en cada logon volando bajo la mayoria de los sets de reglas por defecto. Caza eventos de creacion de archivo en las dos rutas Startup donde el proceso escritor no es un instalador conocido, y alerta sobre cualquier valor en UserInitMprLogonScript, que esta vacio en un host limpio. La contramedida es una ACL bloqueada del Startup folder y auditoria GPO de los valores de registro de logon-script.

8. BITS Jobs (T1197)

BITS merece atencion especial porque sobrevive al logoff y puede descargar payloads usando proceso confiable: bitsadmin /list /allusers /verbose como check semanal ya captura el 95% de los casos, y el log Microsoft-Windows-Bits-Client/Operational registra creacion de jobs y comandos de notify. La variante peligrosa fija un SetNotifyCmdLine para que el propio BITS lance el payload al completarse la transferencia, lo que parece actividad de svchost a un analista descuidado. La contramedida es monitorear el canal operacional de BITS por jobs con notify command line y limitar el tiempo de vida de los jobs por politica para que una transferencia estancada no aceche por semanas.

9. Print Processors y otras extensiones de autostart (T1547.012)

Los Print Processors volvieron al mapa despues de PrintNightmare y el monitoreo del registro HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments es barato: una nueva DLL de print processor cargada por spoolsv.exe desde una ruta no estandar es una senal de alta confianza. La misma familia de autostart de boot y logon (T1547) incluye manipulacion de Winlogon Shell y Userinit, LSA Security Support Providers y DLLs helper de Netsh; cada una es un unico valor de registro que nunca deberia cambiar en un host administrado, asi que una consulta de compliance que compara valores actuales contra una golden image los atrapa a todos de una vez. La contramedida es la misma en todos lados: conoce el valor bueno, alerta sobre la desviacion.

10. Convertir detecciones en un programa

La decima tecnica es la que ata a las otras nueve: operacionalizar la deteccion como un programa repetible en vez de un monton de reglas. Apila las diez consultas anteriores en una watchlist unica en Sentinel, configura baseline de 14 dias por host antes de alertar y revisa los hits en ventana semanal de threat hunting. Para correlacionar esto con el ciclo ofensivo completo, Adversary Emulation con Caldera y MITRE ATT&CK en Laboratorio Corporativo y Purple Team en la Practica: Construyendo Ciclo de Feedback Red vs Blue muestran como transformar estas detecciones en ejercicios continuos con el red team, para que cada regla se ejercite, se afine y se re-valide con cadencia en vez de pudrirse.

Priorizar las diez por prevalencia y costo

No las diez tecnicas merecen el mismo esfuerzo el primer dia, y un programa que intenta hervir el oceano se estanca antes de entregar nada. Ordenalas por prevalencia contra costo de deteccion: claves Run y scheduled tasks son de alta prevalencia y bajo costo, asi que van primero; servicios Windows y BITS son de prevalencia media y baratos de consultar, asi que van segundo; WMI Event Subscription, COM hijacking y la familia IFEO o AppInit son de menor prevalencia pero de impacto mucho mayor cuando aparecen, porque senalan un operador mas capaz, asi que van tercero pero no se saltan. Print Processors y los valores de autostart Winlogon o Userinit son raros pero trivialmente baratos como comparacion contra golden image, asi que integralos en el mismo barrido semanal de compliance. Mapea cada tecnica a si la prevencion, la deteccion o ambas son realistas en tu flota, porque algunas, como los unquoted service paths, se arreglan mejor una vez que se vigilan para siempre, mientras que otras, como las suscripciones WMI, solo se pueden detectar y revisar. Otro factor decisivo es donde vive la persistencia: la misma tecnica en un kiosco es un indicio de baja prioridad, en un controlador de dominio o un host de firma de codigo es una alerta del nivel mas alto, asi que pondera cada deteccion con la criticidad del activo. Publicar este orden como una matriz de una pagina mantiene honesto al programa.

FAQ

Que tecnica deberia detectar primero un equipo pequeno? Claves Run y scheduled tasks, en ese orden, porque cubren la mayoria de la persistencia commodity y las consultas son baratas; deja esas dos limpias antes de tocar las suscripciones WMI. Necesito Sysmon si ya corro Defender for Endpoint? Para la mayoria MDE alcanza, pero WMI Event Subscription (eventos 19-21) y cierta visibilidad de escrituras de registro son mas fuertes con Sysmon, asi que corre Sysmon en tus hosts joya-de-la-corona y de alto riesgo aunque la flota dependa solo de MDE. La cobertura es un espectro, y gastas Sysmon donde el radio de impacto es mayor.

Checklist y conclusion

El takeaway practico: la persistencia no se detecta con una regla brillante, se detecta con disciplina de revision. Recorre la checklist para cada una de las diez: canal de telemetria recolectado, consulta KQL escrita y versionada, baseline por host establecido, contramedida desplegada, y la regla validada con Atomic Red Team para haberla visto disparar. Empieza manana ejecutando las dos primeras consultas (Run keys y schtasks) en tu ambiente de produccion en modo solo-lectura, cuenta cuantos hits tienes, y descubriras que ya existe persistencia legitima que nadie documento. Ese es el punto de partida real del programa, y todo lo que sigue es iteracion disciplinada.