Persistenza via WMI: Windows Management Instrumentation Event Subscription (T1546.003)

La sottoscrizione WMI è un classico della persistenza fileless e va padroneggiata in laboratorio perché molti EDR la monitorano in modo specifico. L'obiettivo è capire quali varianti generano più rumore e quali scivolano sotto i radar.

Il metodo più diretto è PowerShell nativo. Si creano i tre oggetti in sequenza: filtro, consumer e binding. Il filtro definisce quando scatta la trappola, il consumer definisce cosa esegue, il binding li collega.

$filter = Set-WmiInstance -Namespace "root\subscription" -Class __EventFilter -Arguments @{Name="EvilFilter"; EventNamespace="root\cimv2"; QueryLanguage="WQL"; Query="SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'"}

$consumer = Set-WmiInstance -Namespace "root\subscription" -Class CommandLineEventConsumer -Arguments @{Name="EvilConsumer"; CommandLineTemplate="C:\Windows\System32\cmd.exe /c calc.exe"}

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

Questo approccio attiva Sysmon EventID 21 (WmiEvent - Consumer Created) e genera log nel canale Microsoft-Windows-WMI-Activity/Operational, quindi è perfetto per validare le detection del Blue Team.

La variante con mofcomp.exe è storicamente rilevante perché diversi gruppi la preferiscono. Si prepara un file .mof che definisce filtro, consumer e binding in sintassi MOF nativa, poi si compila con:

mofcomp.exe C:\temp\persistence.mof

Questa variante è interessante perché il processo che esegue la compilazione è un binario Microsoft legittimo (living-off-the-land), e il file .mof può essere cancellato subito dopo — la sottoscrizione resta nel repository WMI.

Per un approccio C#, lo strumento SharpWMI (open source, repository GhostPack) permette di creare sottoscrizioni WMI da un assembly .NET, utile quando PowerShell è vincolato da Constrained Language Mode. In alternativa, PoshC2 (open source) e SILENTTRINITY (open source) includono moduli dedicati alla persistenza WMI con opzioni di configurazione flessibili su timer, trigger di processo o evento di login.

Per la pulizia post-esercizio, è fondamentale rimuovere tutti e tre gli oggetti:

Get-WmiObject -Namespace "root\subscription" -Class __EventFilter | Where-Object {$_.Name -eq "EvilFilter"} | Remove-WmiObject

Ripetere per CommandLineEventConsumer e __FilterToConsumerBinding. Verificare con Get-WmiObject -Namespace "root\subscription" -Class __EventFilter che il namespace sia pulito prima di chiudere l'engagement.

La detection di questa tecnica si gioca su tre canali di log distinti e sulla correlazione temporale tra eventi di creazione WMI e processi figli anomali.

Il canale primario è Sysmon, che dalla versione 3.x dedica tre EventID specifici alle operazioni WMI: EventID 19 (WmiEventFilter activity created), EventID 20 (WmiEventConsumer activity created) e EventID 21 (WmiEventConsumerToFilter activity created). Qualunque creazione di oggetti nel namespace root\subscription genera questa tripletta. Una regola Sigma efficace correla la comparsa di EventID 19 seguita da EventID 21 nella stessa sessione, con attenzione al campo Consumer che contiene il comando eseguito.

Il secondo canale è il log nativo Microsoft-Windows-WMI-Activity/Operational, disponibile da Windows 10 e Server 2016 senza software aggiuntivo. Gli eventi EventID 5857, 5858, 5859 e 5860 tracciano rispettivamente il caricamento di provider, errori di esecuzione e registrazione di consumer permanenti. L'EventID 5861 segnala specificamente la creazione di una sottoscrizione permanente — è il segnale più pulito in ambienti senza Sysmon.

Il terzo pilastro è il monitoraggio dei processi figli di WmiPrvSE.exe. In condizioni normali, questo processo genera pochi child process e quasi mai interpreti di comando. Un alert su WmiPrvSE.exe → cmd.exe, WmiPrvSE.exe → powershell.exe o WmiPrvSE.exe → rundll32.exe ha un tasso di falsi positivi molto basso in ambienti enterprise tipici.

Per il tuning, i parametri chiave sono:

• TimeWindow: correla la creazione del filtro WMI con l'esecuzione del consumer entro 5-10 minuti per ridurre il rumore
• UserContext: prioritizzare le sottoscrizioni create nel contesto SYSTEM o da account non amministrativi
• ProcessNameAllowlist: escludere consumer legittimi come quelli di tool di backup (Veeam, SCCM) che usano WMI in modo intensivo
• ParentProcessAnomalyThreshold: definire una baseline dei child process normali di WmiPrvSe.exe per ambiente

L'esecuzione di mofcomp.exe merita un alert dedicato: in ambienti di produzione, la compilazione di file MOF è rara. Un semplice alert su process creation con Image che termina in mofcomp.exe è ad alta fedeltà.

Sul fronte preventivo, l'Attack Surface Reduction (ASR) di Windows 10/11 include una regola specifica per bloccare l'abuso di WMI a fini di persistenza: va abilitata tramite Group Policy o Microsoft Intune. Lato accessi, limitare la connessione remota WMI ai soli amministratori e monitorare le modifiche alle ACL del namespace WMI chiude il vettore laterale.

L'analisi forense di una persistenza WMI ruota attorno a un artefatto principale: il repository WMI, un database binario che risiede in C:\Windows\System32\wbem\Repository\. Questo database contiene quattro file critici: OBJECTS.DATA, INDEX.BTR, MAPPING1.MAP, MAPPING2.MAP e MAPPING3.MAP. È qui che il sistema operativo persiste le sottoscrizioni permanenti, e un'analisi offline di questi file rivela filtri, consumer e binding anche quando l'attaccante ha rimosso ogni altro artefatto.

Lo strumento PyWMIPersistenceFinder.py (open source, di David Pany / FireEye) analizza il file OBJECTS.DATA ed estrae le sottoscrizioni permanenti in formato leggibile. In alternativa, python-cim (open source) offre un parser completo del repository WMI per analisi più granulari. Il comando chiave su un sistema live è:

Get-WmiObject -Namespace "root\subscription" -Class __EventFilter

Ripetuto per CommandLineEventConsumer, ActiveScriptEventConsumer e __FilterToConsumerBinding, restituisce l'intera catena di persistenza attiva.

Per la timeline, gli artefatti si stratificano su più livelli. I log WMI-Activity/Operational (percorso C:\Windows\System32\winevt\Logs\Microsoft-Windows-WMI-Activity%4Operational.evtx) contengono l'EventID 5861 con timestamp di creazione della sottoscrizione. Se Sysmon era attivo, gli EventID 19-20-21 nel canale Sysmon offrono la stessa informazione con metadati aggiuntivi.

Sul filesystem, la presenza di file .mof in directory temporanee (%TEMP%, C:\Windows\Temp) è un indicatore forte, specialmente se correlata all'esecuzione di mofcomp.exe nei log di processo. La MFT ($MFT) e il Journal USN ($UsnJrnl) possono rivelare la creazione e successiva cancellazione di file .mof anche settimane dopo l'evento.

Dalle campagne documentate emergono pattern forensi precisi. Nella campagna SolarWinds Compromise (C0024), APT29 ha usato un WMI event filter per invocare un command-line consumer al boot di sistema, lanciando una backdoor tramite rundll32.exe — la catena forense mostra quindi un EventFilter legato al tempo di avvio e un consumer con riga di comando contenente rundll32.exe. In Operation Ghost (C0023), lo stesso gruppo ha utilizzato sottoscrizioni WMI come meccanismo di persistenza per malware custom, e il malware RegDuke si attivava specificamente alla comparsa del processo WINWORD.EXE — un trigger insolito che spicca immediatamente in un'analisi del repository.

Il malware metaMain, legato al gruppo Metador, registrava un consumer chiamato "hard_disk_stat" — un nome che imita la telemetria di sistema ma risulta anomalo in qualunque baseline WMI standard.

La persistenza via WMI è adottata trasversalmente da gruppi con mandati, sponsor e aree geografiche diverse, il che la rende un indicatore debole per l'attribuzione ma un eccellente pivot per tracciare l'evoluzione operativa di un avversario.

APT29 è il gruppo più documentato su questa tecnica, con due campagne confermate. In Operation Ghost (C0023, 2013-2019) ha utilizzato sottoscrizioni WMI per persistere con malware come RegDuke, POSHSPY e TrailBlazer. Nella SolarWinds Compromise (C0024, 2019-2021), ha combinato la persistenza WMI con l'esecuzione tramite rundll32.exe al boot di sistema. Il pattern è chiaro: APT29 usa WMI come elemento stabile della propria catena operativa attraverso campagne pluriennali, affiancandolo a tecniche supply chain e steganografia. Lo sponsor statale russo (SVR) e il targeting di ministeri degli esteri e organizzazioni governative confermano un mandato di spionaggio strategico.

Turla condivide il contesto geopolitico russo e ha implementato WMI con filtri e consumer dedicati. L'overlap con APT29 sull'uso di WMI non implica collaborazione diretta, ma suggerisce un ecosistema offensivo che privilegia le tecniche living-off-the-land per la persistenza in ambienti ad alta sicurezza.

APT33 e HEXANE rappresentano la componente iraniana. Entrambi hanno adottato sottoscrizioni WMI per persistenza, con APT33 che lo ha fatto in tentativi documentati contro infrastrutture critiche. La convergenza verso WMI da parte di gruppi iraniani tradizionalmente meno sofisticati indica una maturazione delle capability offensive.

FIN8, gruppo a movente finanziario, utilizza WMI tramite il malware Sardonic e BADHATCH. La sua adozione conferma che la tecnica non è esclusiva dello spionaggio statale ma ha valore operativo anche per il cybercrime, dove la persistenza silenziosa è essenziale per operazioni di esfiltrazione dati di pagamento prolungate.

Metador rappresenta un caso particolarmente interessante: ha combinato la persistenza WMI con l'uso di cdb.exe (il debugger console di Windows), un binario living-off-the-land insolito che evade molte detection basate su allowlist di processi. Il malware metaMain con il consumer "hard_disk_stat" mostra un'attenzione al mimetismo nei nomi degli oggetti WMI.

Mustang Panda e Rancor portano la prospettiva del Sud-Est Asiatico. Mustang Panda usa il tool custom ORat con consumer WMI dedicati, mentre Rancor compila file MOF generati da VBScript — una variante tecnica che aggiunge un livello di offuscamento. Blue Mockingbird, infine, conferma l'uso di mofcomp.exe con file .mof preconfezionati per operazioni di cryptomining, dimostrando che la tecnica scala dall'APT al cybercrime opportunistico.

Il trend complessivo indica che la persistenza WMI è una tecnica cross-tier: adottata dai gruppi più sofisticati come dai threat actor a bassa sofisticazione, proprio perché sfrutta un componente nativo di Windows senza richiedere tool aggiuntivi.

Framework MITRE ATT&CK v16 — Tecnica T1546.003, tattiche TA0003, TA0004. Campagne C0024 (SolarWinds Compromise), C0023 (Operation Ghost). Detection DET0086 / AN0236. Mitigazioni M1018, M1026, M1040. Tool di detection: Sysmon (EventID 19-20-21), canale WMI-Activity/Operational, PyWMIPersistenceFinder, python-cim. Integrato con conoscenza professionale per tool e procedure operative.