Investigando persistência via WMI Permanent Event Subscription
O Forensic Focus publicou um guia prático sobre como atacantes usam assinaturas permanentes de eventos WMI, em especial o consumidor ActiveScriptEventConsumer, para manter persistência furtiva em sistemas Windows comprometidos. O artigo percorre o ciclo completo: registro da assinatura, disparo e execução do código malicioso, artefatos deixados em disco e memória, detecção via regras Sigma e remoção segura durante a resposta a incidente.
Assinaturas permanentes de WMI (Windows Management Instrumentation) são um mecanismo legítimo do sistema operacional que permite disparar uma ação automaticamente quando um evento específico ocorre — por exemplo, a cada boot ou login. Atacantes abusam dessa funcionalidade combinando três objetos do repositório WMI: um __EventFilter, que define a condição de disparo (consultada em WQL); um EventConsumer, responsável por executar a ação; e um __FilterToConsumerBinding, que liga os dois. Quando o consumidor escolhido é o ActiveScriptEventConsumer, o atacante consegue executar VBScript ou JScript diretamente, sem depender de um binário ou script em disco, o que reduz a superfície detectável por antivírus tradicionais.
Do ponto de vista forense, esses objetos não residem no registro do Windows nem no sistema de arquivos convencional: eles ficam armazenados no repositório WMI, normalmente em OBJECTS.DATA, dentro de %SystemRoot%\System32\wbem\Repository. Isso significa que uma triagem baseada apenas em chaves de registro de persistência (Run keys, Services, Scheduled Tasks) frequentemente deixa essa técnica passar batido, e o examinador precisa extrair e parsear o repositório WMI — manualmente ou com ferramentas como PyWMIPersistenceFinder ou módulos específicos de suítes de DFIR — para enumerar filtros, consumidores e bindings ativos.
A execução do ActiveScriptEventConsumer ocorre dentro do processo WmiPrvSE.exe (WMI Provider Host), o que gera uma pista importante para análise de memória e de linha de execução: processos filhos ou atividade de script originados por esse host são um sinal de alerta, já que a maioria dos ambientes não usa esse consumidor para fins administrativos legítimos. Artefatos correlatos incluem os logs de operação do WMI (Microsoft-Windows-WMI-Activity/Operational), que registram a criação de filtros e bindings, e podem ser cruzados com Sysmon (Event ID 19-21, categoria WmiEvent) quando configurado para capturar essa telemetria.
No campo de detecção, regras Sigma voltadas a esse padrão tipicamente buscam a criação de __EventFilter ou __FilterToConsumerBinding fora de uma lista de permissões de software de gestão conhecido (SCCM, antivírus, monitoramento), e inspecionam o conteúdo do script embutido em busca de indicadores como downloads via XMLHTTP, ofuscação ou chamadas a WScript.Shell. Essa abordagem comportamental é crucial porque a técnica é nativa do SO e abusada por diversas famílias de malware e grupos de ameaça há anos — documentada inclusive no MITRE ATT&CK como T1546.003.
Para a resposta a incidente, a remoção segura exige eliminar os três objetos (filtro, consumidor e binding) e não apenas um deles, sob risco de deixar resíduos que podem ser reaproveitados; ferramentas de gestão de WMI (wmic, PowerShell CIM cmdlets) permitem essa limpeza, mas o ideal é documentar os objetos antes de removê-los, preservando a cadeia de custódia da evidência para eventual análise posterior ou atribuição.