Abuso di Verclsid: Verclsid (T1218.012)

Per un red team, la simulazione di T1218.012 in ambiente di laboratorio è utile per validare la copertura di AppLocker, WDAC e delle regole EDR contro l'esecuzione COM proxata. Il presupposto è avere un endpoint Windows di test isolato e la possibilità di ospitare un scriptlet su un web server interno.

La catena classica parte dalla registrazione di un CLSID nell'hive utente, che non richiede privilegi amministrativi. Si crea una chiave sotto HKCU\Software\Classes\CLSID{GUID}\InprocServer32 oppure una sottochiave ScriptletURL che punta a un file .sct raggiungibile via HTTP. Lo scriptlet contiene codice VBScript o JScript che istanzia WScript.Shell per lanciare il payload successivo — tipicamente un beacon Cobalt Strike (a pagamento) o Sliver (open source) in memoria.

L'invocazione avviene con:

verclsid.exe /S /C {CLSID-registrato}

Il flag /S forza modalità silent, /C specifica il ClassID da verificare. Poiché verclsid.exe è firmato Microsoft e categorizzato come componente di sistema, molte policy di application control lo consentono per default.

Per costruire lo scriptlet e testare la catena, strumenti utili sono Koadic (open source), che include stager basati su scriptlet COM, e Nishang (open source) per generare payload PowerShell da concatenare. La generazione manuale dello scriptlet richiede un file XML con tag e che dichiara ProgID e CLSID; la documentazione ufficiale Microsoft su Windows Script Components descrive la struttura.

Varianti interessanti da provare in lab:

• Parent process spoofing: lanciare verclsid.exe da un processo Office simulato (winword.exe) per replicare il pattern osservato in-the-wild con Hancitor.
• Living off trusted paths: hostare lo scriptlet su un servizio SMB interno per valutare se le regole di egress filtering intercettano solo HTTP/HTTPS.
• Chaining con altri LOLBin: verclsid come primo stadio che lancia mshta.exe o rundll32.exe, per testare la detection di catene multi-binary.

Su Linux e macOS la tecnica non è applicabile: verclsid è un binario esclusivo Windows. Per esercizi cross-platform su proxy execution, si guardi ad altre sotto-tecniche di T1218. Al termine del test, è essenziale rimuovere le chiavi di registro create e documentare i CLSID usati, perché rimangono in NTUSER.DAT e possono generare falsi positivi in indagini successive.

La detection di T1218.012 si fonda su tre pilastri: monitoraggio della process creation, ispezione dei moduli caricati in memoria e correlazione con traffico di rete uscente. La strategia DET0042 in MITRE indica esplicitamente queste tre dimensioni.

La fonte log primaria è Sysmon (open source, Microsoft Sysinternals), con configurazione derivata da template come sysmon-modular di Olaf Hartong. Gli EventCode rilevanti sono 1 (Process Create), 7 (Image Loaded) e 3 (Network Connection). Un alert di base cerca verclsid.exe con command line contenente /S /C e un CLSID come argomento; la query KQL su Microsoft Defender for Endpoint parte da DeviceProcessEvents | where FileName =~ "verclsid.exe" filtrando su ProcessCommandLine contains "/S".

Il segnale più forte è il parent process anomalo. Verclsid legittimo viene invocato da explorer.exe o da processi shell durante il caricamento di estensioni. Se il parent è winword.exe, excel.exe, outlook.exe o un binario dropped da temp, l'alert deve essere ad alta priorità — è il pattern osservato con Hancitor, dove un documento Office weaponizzato spawna verclsid come proxy loader.

Secondo indicatore: network connection da verclsid.exe. Il binario legittimo non contatta host esterni. Un Sysmon EventCode 3 con verclsid come Image e destinazione IP pubblico è quasi sempre malevolo. Correlare con EventCode 22 (DNS Query) permette di estrarre il dominio C2.

Terzo indicatore: caricamento di scrobj.dll o scrrun.dll — le librerie che gestiscono scriptlet COM. Un EventCode 7 che mostra verclsid.exe come Image e uno di questi DLL come ImageLoaded, in una finestra di correlazione di 5-10 secondi rispetto al process create, è pattern classico di scriptlet remoto.

Per il tuning, occorre stabilire una baseline dei CLSID legittimi invocati nell'ambiente: molte applicazioni installano shell extension che generano invocazioni benigne. Whitelistare i CLSID noti riduce drasticamente il rumore. Restringere gli alert di rete a IP esterni fuori dai range approvati elimina traffico interno di verifica.

Controlli preventivi coerenti con le mitigazioni MITRE M1038 e M1042: policy WDAC o AppLocker (entrambi nativi Windows, gratuiti) che bloccano l'esecuzione di verclsid.exe quando non necessario, oppure regole di firewall host (M1037) che negano il traffico egress dal processo. In ambienti dove nessuna workstation carica shell extension custom, la rimozione o il blocco totale è la mitigazione più pulita.

Falsi positivi tipici derivano da software di terze parti che installa shell extension proprietarie — driver di stampa, tool di sincronizzazione cloud, antivirus stessi.

L'analisi forense post-incidente su un caso T1218.012 deve ricostruire tre elementi: quando è stato invocato verclsid.exe, quale CLSID è stato risolto, e dove ha condotto la catena di esecuzione.

Sul filesystem, verclsid.exe risiede in C:\Windows\System32\verclsid.exe. Il file stesso è firmato Microsoft e non viene modificato: non ci sono artefatti nel binario. L'evidenza va cercata altrove.

Il primo artefatto è il Prefetch. Se il servizio Prefetch è attivo (default su workstation), il file C:\Windows\Prefetch\VERCLSID.EXE-{HASH}.pf registra timestamp di esecuzione, run count e path dei file referenziati durante l'esecuzione. Strumenti come PECmd di Eric Zimmerman (open source) parsano il prefetch e producono CSV con timeline; l'output rivela se verclsid ha toccato file inusuali come scriptlet in %TEMP% o %APPDATA%.

Secondo pilastro sono gli Event Log di Sysmon archiviati in %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-Sysmon%4Operational.evtx. Estraendoli con EvtxECmd (open source) si ottiene la ricostruzione completa: EventID 1 con command line integrale (quindi il CLSID), EventID 3 con IP di destinazione, EventID 7 con DLL caricate. La correlazione temporale tra questi eventi stabilisce la sequenza.

Terzo elemento fondamentale: il registro di sistema. Il CLSID abusato è stato tipicamente registrato in HKCU\Software\Classes\CLSID{GUID}. L'analisi offline dell'hive NTUSER.DAT dell'utente compromesso con Registry Explorer o RegRipper (entrambi open source) permette di estrarre:

• La chiave InprocServer32 o ScriptletURL che punta al payload
• Il timestamp LastWriteTime della chiave, che datano la creazione
• Eventuali sottochiavi ProgID utili per pivot su altri artefatti

Quarto artefatto: le cache di rete e i browser artifact. Se lo scriptlet è stato scaricato via HTTP, la connessione appare nei log del proxy aziendale e potenzialmente nella cache DNS locale. Il comando nativo ipconfig /displaydns è volatile, ma su sistema live può fornire ancora tracce; su immagine forense si guardano invece i log del resolver.

Quinto: memoria. Se è stata acquisita un'immagine RAM, Volatility 3 (open source) con i plugin windows.pslist e windows.cmdline mostra verclsid con la command line completa, mentre windows.netscan estrae le connessioni attive. Il plugin windows.dlllist conferma il caricamento di scrobj.dll.

Per la ricostruzione della campagna nel caso Hancitor, la timeline tipica mostra: apertura di un documento Word malevolo, macro che invoca verclsid, download di uno scriptlet, esecuzione di PowerShell offuscato e successivo drop del payload principale. Ricostruire questa catena richiede unire artefatti Office (.LNK recenti, RecentDocs) con la sequenza sopra descritta.

Il panorama di threat intelligence su T1218.012 è caratterizzato dalla bassa diffusione ma alta specificità: pochi attori documentati, ma quelli che la impiegano lo fanno in modo consistente all'interno di catene di infezione ben definite. I dati MITRE non riportano gruppi APT statuali con attribuzione confermata per questa sotto-tecnica; l'unico riferimento operativo documentato è al malware Hancitor.

Hancitor (S0499), noto anche come Chanitor o Tordal, è un loader/downloader attivo dal 2014 circa e associato a operazioni di eCrime piuttosto che a intelligence statuale. La sua funzione tipica è fungere da primo stadio per famiglie successive come Ficker Stealer, Cobalt Strike e in alcune campagne Zeppelin ransomware. Il vettore iniziale ricorrente sono email di phishing con documenti Word contenenti macro VBA che, una volta abilitate, invocano verclsid.exe per scaricare ed eseguire uno scriptlet malevolo. Questa scelta è tatticamente motivata: verclsid è firmato Microsoft, spesso non monitorato dagli endpoint tradizionali, e permette di aggirare policy AppLocker configurate solo su binari non firmati.

Dal punto di vista dei pattern di tooling, l'abuso di verclsid appartiene a una famiglia più ampia di tecniche di proxy execution via LOLBin che include regsvr32, mshta, rundll32. Attori che usano verclsid tendono a mantenere in rotazione più binari equivalenti nelle proprie catene, alternandoli in base a quale è meno monitorato in un dato momento. Questo comportamento è tipico dei loader-as-a-service dell'ecosistema underground russofono, dove Hancitor si è storicamente collocato.

Dal punto di vista geografico e settoriale, le campagne Hancitor osservate hanno colpito prevalentemente Nord America ed Europa Occidentale, con targeting opportunistico per credenziali bancarie, accessi VPN aziendali e distribuzione secondaria di ransomware. I settori più colpiti includono manifatturiero, servizi legali e healthcare — bersagli con alta probabilità di pagamento estorsione.

Il trend osservabile è duplice. Da un lato, la crescente adozione di WDAC in modalità enforcement e di EDR con visibilità sulle catene parent-child rende sempre più costoso per gli attaccanti sfruttare LOLBin comuni, spingendo verso binari meno noti come verclsid. Dall'altro, la migrazione di molti loader verso payload che caricano codice direttamente in memoria (senza scriptlet remoti) riduce l'utilità di questa specifica tecnica.

Per un CTI officer, gli indicatori di priorità da inserire nei feed sono: hash dei documenti weaponizzati associati a Hancitor, domini di secondo stadio noti per hosting di scriptlet, e pattern di URL con estensione .sct referenziati in registro utente. Il monitoraggio dei repository di threat sharing come MalwareBazaar e URLhaus (entrambi gratuiti, gestiti da abuse.ch) fornisce feed continuativi su campagne attive che sfruttano questa catena.

MITRE ATT&CK: tecnica T1218.012, tattica TA0005, software S0499 (Hancitor), mitigazioni M1037, M1038, M1042, detection DET0042. Framework MITRE D3FEND per mapping difensivo. Conoscenza professionale integrata per comandi Sysmon, tool forensi (PECmd, EvtxECmd, Registry Explorer, Volatility 3), configurazioni AppLocker/WDAC e feed di threat intelligence (MalwareBazaar, URLhaus di abuse.ch).