Esecuzione via COM Object: Component Object Model (T1559.001)

L'abuso di COM in un ingaggio red team consente di dimostrare quanto sia semplice ottenere esecuzione codice, persistenza e persino bypass UAC senza mai toccare un eseguibile su disco. La superficie d'attacco è enorme: Windows espone migliaia di CLSID, e molte interfacce hanno capacità che vanno ben oltre il loro scopo originario.

Il primo passo è l'enumerazione. OleViewDotNet (open source) di James Forshaw è lo strumento di riferimento per ispezionare gli oggetti COM registrati, le interfacce esposte e i permessi associati. Da PowerShell, puoi anche elencare i CLSID registrati interrogando direttamente il registry:

Get-ChildItem -Path "HKLM:\SOFTWARE\Classes\CLSID" | Select-Object PSChildName | Measure-Object

Questo ti dà un'idea della superficie d'attacco: su un'installazione tipica di Windows troverai decine di migliaia di oggetti.

Per replicare la creazione di scheduled task via COM — uno dei pattern più documentati, usato da TrickBot, CLAIMLOADER, InvisiMole, Milan, Latrodectus e Ramsay — puoi usare PowerShell nativo:

$service = New-Object -ComObject "Schedule.Service" $service.Connect() $folder = $service.GetFolder("") $taskDef = $service.NewTask(0) $taskDef.RegistrationInfo.Description = "Test COM Task" $action = $taskDef.Actions.Create(0) $action.Path = "calc.exe" $folder.RegisterTaskDefinition("COMTestTask", $taskDef, 6, $null, $null, 3)

Questo script istanzia l'interfaccia ITaskService senza invocare schtasks.exe, evitando le detection basate sulla command-line del processo figlio.

Per simulare il bypass UAC alla maniera di Raspberry Robin e Medusa Group, il vettore è l'oggetto CMLuaUtil (CLSID {3E5FC7F9-9A51-4367-9063-A120244FBEC7}). Il tool UACME (open source) implementa questa tecnica e molte altre varianti di elevation via COM. In laboratorio, puoi compilare la variante specifica dal repository e osservare come dllhost.exe esegue codice con integrità elevata senza prompt UAC.

Per l'esecuzione remota via DCOM — il pattern usato da HermeticWizard e POWERSTATS — Impacket (open source) offre lo script dcomexec.py:

python3 dcomexec.py domain/user:password@ "whoami" -object MMC20.Application

Questa catena istanzia un oggetto COM remoto (tipicamente MMC20.Application, ShellWindows o ShellBrowserWindow) e invoca il metodo ExecuteShellCommand. Puoi sperimentare con diversi oggetti per valutare quali vengono intercettati dal SOC del cliente.

Infine, per replicare il pattern di Gamaredon Group e SILENTTRINITY — iniezione di macro via Microsoft.Office.Interop — puoi scrivere un breve script C# o PowerShell che istanzia l'applicazione Office e manipola il contenuto del documento. Questo approccio è particolarmente insidioso perché il processo padre risulta essere l'applicazione Office stessa, non uno script.

La detection dell'abuso COM è un esercizio di correlazione: nessun singolo evento è sufficiente, ma la combinazione di segnali racconta una storia chiara. Le log source fondamentali sono Sysmon e il Security Event Log di Windows.

Il punto di partenza è il monitoraggio delle catene processo. Quando un oggetto COM viene attivato out-of-process, Windows lancia dllhost.exe con il parametro /Processid:{CLSID}. Un alert sulla creazione di dllhost.exe con CLSID non presenti nella tua whitelist aziendale è il primo filtro ad alto valore. In Sysmon, l'EventCode 1 (Process Creation) cattura questa informazione nella command-line.

Il secondo pilastro è il monitoraggio dei module load. Quando un processo carica una DLL tramite attivazione COM in-process, Sysmon registra un EventCode 7 (Image Loaded). Il pattern da cercare è un'applicazione legittima — tipicamente excel.exe, winword.exe o outlook.exe — che carica DLL inattese o da percorsi anomali. Questo è esattamente il vettore usato dall'interazione con Microsoft.Office.Interop.

Le query al registro rappresentano il terzo segnale. Ogni istanziazione COM comporta una lookup su HKLM\SOFTWARE\Classes\CLSID\{...} o il corrispondente hive utente. Sysmon EventCode 12/13 (Registry Event) permette di tracciare queste operazioni. L'analista deve configurare una COMObjectAllowList contenente i CLSID e ProgID legittimi usati dalle applicazioni enterprise, escludendo dalla baseline tutto ciò che è noto e atteso.

Per le relazioni padre-figlio, è essenziale costruire una ParentProcessExclusions list. Ad esempio, explorer.exe che lancia dllhost.exe è normale; wmiprvse.exe o mshta.exe che istanziano oggetti COM per creare scheduled task non lo è. Il tuning richiede una TimeWindow di correlazione: se entro pochi secondi da un'attivazione COM si osserva una creazione processo o un caricamento DLL anomalo, la confidenza dell'alert sale significativamente.

Per DCOM remoto, monitora il traffico sulla porta 135/TCP (RPC endpoint mapper) seguito da connessioni su porte dinamiche. Sul lato endpoint, la creazione di mmc.exe o dllhost.exe da parte del servizio RPC senza interazione utente è un forte indicatore. L'EventCode 3 di Sysmon (Network Connection) combinato con l'EventCode 1 fornisce il contesto necessario.

Come controllo preventivo, la mitigazione Privileged Account Management (M1026) suggerisce di modificare le impostazioni di sicurezza COM via Dcomcnfg.exe o direttamente nei registry key HKLM\SOFTWARE\Classes\AppID\{GUID} e HKLM\SOFTWARE\Microsoft\Ole, restringendo i permessi di attivazione e lancio. La mitigazione Application Isolation and Sandboxing (M1048) raccomanda di abilitare tutti gli alert COM e la Protected View nelle applicazioni Office.

L'analisi forense di un abuso COM parte dal registro di sistema, transita per gli artefatti di esecuzione e si chiude con la ricostruzione della persistenza. Ogni fase lascia tracce specifiche, a patto di sapere dove cercare.

Il registro Windows è la fonte primaria. Ogni oggetto COM è registrato sotto HKCR\CLSID\{GUID} con riferimento alla DLL o all'EXE server. Un COM hijacking — dove l'attaccante sostituisce il server legittimo con il proprio payload — lascia modifiche in InprocServer32 o LocalServer32. Confronta i valori attuali con una baseline pulita o con i valori di default dell'installazione Windows. I timestamp delle chiavi di registro (LastWriteTime) forniscono un ancoraggio temporale preciso.

Per la persistenza via scheduled task creata tramite COM — il pattern di TrickBot, CLAIMLOADER, InvisiMole, Milan, Latrodectus e Ramsay — i task risultanti sono archiviati come file XML in C:\Windows\System32\Tasks\. Analizza il contenuto del file per identificare l'azione configurata e correla il timestamp di creazione del file con gli eventi di registro. La differenza chiave rispetto a un task creato via schtasks.exe è l'assenza della command-line nel log di processo: troverai solo l'istanziazione di svchost.exe o taskeng.exe come conseguenza.

Gli artefatti di Raspberry Robin sono particolarmente distintivi: cerca un valore di registro che punta a un file LNK malevolo, creato attraverso l'oggetto COM CMLuaUtil elevato. Il percorso del LNK e il suo target forniscono la catena completa dall'esecuzione iniziale alla persistenza.

Per i casi che coinvolgono FunnyDream, l'uso di CLSID_ShellLink con IShellLink e IPersistFile lascia file LNK nel filesystem. Analizza i metadati del collegamento — percorso target, argomenti, working directory, timestamp MAC — con tool come LECmd (open source, parte della suite di Eric Zimmerman). I file LNK contengono anche il volume serial number e, in alcuni casi, il MAC address della macchina di origine.

Per DCOM remoto (HermeticWizard, POWERSTATS), cerca negli event log di Windows gli eventi di autenticazione correlati: EventCode 4624 (Logon) di tipo 3 (Network) seguiti dall'attivazione COM. Sul sistema sorgente, i ShimCache e AmCache registrano l'esecuzione dei binari coinvolti. La Prefetch di dllhost.exe può indicare le DLL caricate durante l'attivazione.

Infine, per i casi di iniezione tramite Microsoft.Office.Interop (Gamaredon Group, SILENTTRINITY), esamina i file Office recenti in cerca di macro iniettate post-creazione. I metadati OLE del documento — in particolare il campo LastAuthor e i timestamp di modifica — possono rivelare la manipolazione automatizzata. Lo strumento olevba del pacchetto oletools (open source) permette di estrarre e analizzare il codice VBA incorporato.

L'abuso di COM accomuna attori con obiettivi e sofisticazione molto diversi, ma il pattern di utilizzo racconta la strategia di ciascuno.

MuddyWater (G0069) sfrutta COM, DCOM e l'interfaccia Outlook per eseguire codice malevolo. Il gruppo, attribuito alla sfera iraniana, impiega il malware POWERSTATS che utilizza DCOM verso il loopback 127.0.0.1 per eseguire payload aggiuntivi — una tecnica che evita di generare traffico di rete verso l'esterno pur sfruttando le capacità di esecuzione remota del protocollo. Questo pattern suggerisce un'attenzione specifica all'evasione dei controlli di rete perimetrali.

Gamaredon Group (G0047) utilizza COM in modo chirurgico: l'oggetto Microsoft.Office.Interop viene impiegato per iniettare macro malevole nei documenti. Questo approccio si integra con la strategia complessiva del gruppo, fortemente orientata allo spear-phishing documentale. L'iniezione COM permette di weaponizzare documenti già presenti sul sistema della vittima, trasformandoli in vettori di propagazione laterale senza distribuire nuovi file.

Medusa Group (G1051) ricorre a COM per il bypass UAC, un utilizzo focalizzato sull'escalation dei privilegi piuttosto che sull'esecuzione iniziale. Questo posiziona l'abuso COM in una fase successiva della kill chain, quando l'attaccante ha già un punto d'appoggio e necessita di elevare i propri permessi.

Sul fronte software, emerge un pattern dominante: 7 malware su 17 utilizzano COM per creare scheduled task tramite l'interfaccia ITaskService. Questa convergenza indica che la persistenza via task COM è diventata una commodity technique, adottata tanto da framework modulari come Bumblebee quanto da impianti specifici come CLAIMLOADER. Un secondo cluster riguarda il bypass UAC via CMLuaUtil (Raspberry Robin, Gelsemium), mentre un terzo pattern — l'uso di ShellLink e WshShortcut per creare file LNK (FunnyDream, DarkTortilla) — rappresenta un approccio alla persistenza alternativo e complementare.

La tendenza trasversale è chiara: COM viene usato per evitare la creazione di processi figli facilmente rilevabili. Invece di lanciare schtasks.exe, reg.exe o powershell.exe, gli attaccanti ottengono gli stessi risultati attraverso chiamate COM in-process, riducendo drasticamente la superficie di detection basata sulla command-line. Per il threat intelligence, questo implica che le regole di detection devono evolvere dal monitoraggio dei processi al monitoraggio delle interfacce COM attivate — un cambio di paradigma che richiede visibilità a livello di API e non solo di process tree.

Framework MITRE ATT&CK v16 — Tecnica T1559.001 (Component Object Model), Tattica TA0002 (Execution). Mitigazioni M1026 (Privileged Account Management), M1048 (Application Isolation and Sandboxing). Detection DET0224 / AN0628. Gruppi: G0069, G0047, G1051. Software: S0223, S0266, S1236, S0260, S1044, S0386, S1015, S1160, S1130, S0698, S1066, S0691, S0692, S1238, S1039, S0458, S0666. Integrato con conoscenza professionale per tool e procedure operative.