Persistencia WMI por suscripción de eventos, explicada

En resumen. Una suscripción de eventos WMI son tres objetos: un __EventFilter (una consulta WQL que describe cuándo), un consumidor de eventos (qué hacer) y un __FilterToConsumerBinding que los conecta. Registrada de forma permanente, sobrevive a los reinicios y se ejecuta como SYSTEM. MITRE la clasifica como T1546.003. Las evidencias residen en el repositorio CIM y pueden leerse sin conexión, incluidos los objetos eliminados.

Las tres piezas

WMI es la capa de administración de Windows. Además de responder a consultas, puede reaccionar: cuando ocurre un evento que coincide con una consulta, entrega el evento a un consumidor. Una suscripción permanente se compone de:

Windows incluye cinco clases de consumidor estándar:

• CommandLineEventConsumer: CommandLineTemplate, ExecutablePath, WorkingDirectory. Lo inicia el host de proveedores WMI (WmiPrvSE.exe).
• ActiveScriptEventConsumer: ScriptingEngine (VBScript o JScript) y ScriptText o ScriptFilename. Lo ejecuta scrcons.exe.
• LogFileEventConsumer: añade Text a Filename.
• NTEventLogEventConsumer: escribe una entrada en el registro de eventos.
• SMTPEventConsumer: envía un correo electrónico.

Solo los dos primeros ejecutan código arbitrario, por eso la mayor parte de la persistencia WMI los utiliza.

Por qué la usan los atacantes

Crear una suscripción requiere derechos de administrador, pero una vez instalada ofrece mucho:

• Sobrevive a los reinicios y no necesita ningún archivo en una clave Run, un servicio ni una tarea programada.
• La acción se ejecuta como SYSTEM, colgando de procesos WMI que siempre están en ejecución.
• El disparador puede ser cualquier cosa que WMI pueda ver: unos minutos después del arranque, un inicio de sesión, el inicio de un proceso, la inserción de un USB, una hora del día o un temporizador WMI.
• Se oculta a plena vista: las revisiones de tipo autoruns que omiten WMI no la ven, y el repositorio es una base de datos binaria que poca gente abre.

Un ejemplo clásico es un filtro sobre Win32_PerfFormattedData_PerfOS_System que se dispara cuando SystemUpTime está entre 240 y 325 segundos, de modo que la carga útil arranca unos cuatro minutos después de cada inicio:

SELECT * FROM __InstanceModificationEvent WITHIN 60
WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'
AND TargetInstance.SystemUpTime >= 240 AND TargetInstance.SystemUpTime < 325

Enlazado a un CommandLineEventConsumer cuya plantilla es C:\ProgramData\Intel\m64.exe -svc, constituye un mecanismo de persistencia completo; es exactamente lo que contiene el ejemplo de WMI Parser, en el host ficticio FIN-WKS-07.

Dónde residen las evidencias

Las suscripciones son objetos del repositorio WMI, C:\Windows\System32\wbem\Repository:

• OBJECTS.DATA contiene los propios objetos, en páginas de 8 KiB.
• INDEX.BTR es el índice que indica dónde está cada objeto.
• MAPPING1.MAP a MAPPING3.MAP traducen las páginas lógicas del índice a páginas físicas.

Normalmente se encuentran en el espacio de nombres root\subscription, pero una suscripción registrada en root\cimv2 o root\default también funciona. El formato se describe en Dentro de OBJECTS.DATA.

Dos propiedades son muy importantes en un caso:

• CreatorSID, en cada objeto, registra la cuenta que lo creó. Un SID terminado en -500, S-1-5-32-544 o el SID de un usuario concreto cuentan historias distintas.
• Los objetos eliminados no se borran. Sus páginas se liberan y solo se sobrescriben cuando WMI necesita el espacio, así que la limpieza de un atacante a menudo deja atrás el filtro, el consumidor o el enlace. Consulte recuperar persistencia WMI eliminada.

Lo que el repositorio no le da es una hora de creación documentada. Cada registro de instancia lleva dos FILETIME no documentados que a menudo siguen el momento en que se escribió; trátelos como pistas. Para la cronología, correlacione con el ID de evento 5861 en Microsoft-Windows-WMI-Activity/Operational y con los eventos 19 a 21 de Sysmon, tratados en la checklist de investigación.

Cómo encontrarla

1. Recopile el repositorio desde una instantánea de volumen, KAPE (target WBEM) o Velociraptor: cómo recopilar el repositorio WMI.
2. Analícelo sin conexión. Suelte la carpeta en WMI Parser: enumera cada enlace con su filtro y su consumidor, recupera los eliminados e indica para cada objeto si procede del índice o del carving.
3. Separe los predeterminados. Windows instala una suscripción SCM Event Log, y las imágenes antiguas una BVT. Son inofensivas cuando su contenido coincide: consulte SCM Event Log Consumer y BVTConsumer.
4. Lea lo que queda: la consulta disparadora, el comando o el script, las rutas y el creador.

Hallazgos que buscar: PowerShell codificado, binarios en carpetas escribibles por usuarios (C:\ProgramData, C:\Users\Public, %TEMP%), consumidores de script, disparadores de tiempo de actividad o de inicio de sesión, y suscripciones fuera de root\subscription.

FAQ

¿Qué es la persistencia por suscripción de eventos WMI?

Un atacante registra una suscripción de eventos WMI permanente: un __EventFilter que describe un evento, un consumidor que describe una acción y un __FilterToConsumerBinding que los vincula. Windows ejecuta entonces la acción como SYSTEM cada vez que ocurre el evento, también después de los reinicios.

¿Dónde se almacenan las suscripciones de eventos WMI?

En el repositorio WMI (CIM), C:\Windows\System32\wbem\Repository, principalmente en OBJECTS.DATA junto con su INDEX.BTR y sus archivos MAPPING. Normalmente residen en el espacio de nombres root\subscription.

¿Qué consumidores importan para la persistencia?

CommandLineEventConsumer (ejecuta una línea de comandos) y ActiveScriptEventConsumer (ejecuta VBScript o JScript) ejecutan código. LogFileEventConsumer, NTEventLogEventConsumer y SMTPEventConsumer escriben un archivo, un evento o un correo electrónico.

Artículos relacionados

• Dentro de OBJECTS.DATA: análisis forense del repositorio WMI
• Cómo recopilar el repositorio WMI
• Persistencia WMI: checklist de respuesta a incidentes