Esecuzione Proxy via InstallUtil: Signed Binary Proxy Execution: InstallUtil (T1218.004)

Il cuore di questa tecnica è semplice: scrivere una classe C# che implementi il metodo Uninstall() (o Install()) all'interno di un assembly decorato con l'attributo RunInstaller(true), poi invocare InstallUtil per eseguirlo. In un esercizio red team questa catena permette di testare se i controlli di application control e gli alert EDR intercettano l'esecuzione proxy.

Per cominciare, il payload va compilato con il compilatore C# integrato nel framework .NET, disponibile su qualsiasi sistema Windows senza installazioni aggiuntive:

csc.exe /target:library /out:C:\Temp\payload.dll C:\Temp\payload.cs

Il file payload.cs contiene una classe che eredita da System.Configuration.Install.Installer e sovrascrive il metodo Uninstall. A questo punto l'esecuzione avviene tramite la modalità di disinstallazione, che è la variante più comune in ambiente offensivo perché non richiede privilegi elevati:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /U C:\Temp\payload.dll

I flag /logfile= e /LogToConsole=false sopprimono ogni output, riducendo le tracce visibili. La scelta tra Framework e Framework64 dipende dall'architettura del processo target — un dettaglio rilevante quando si inietta in processi a 32 bit su sistemi a 64 bit.

Covenant (open source), il framework C2 scritto in .NET, automatizza questa catena generando launcher basati su file XML InstallUtil. Il launcher produce un Grunt — l'agente di Covenant — che si connette al teamserver senza che l'operatore debba compilare manualmente l'assembly. Per chi preferisce un approccio manuale, il progetto LOLBAS documenta le varianti note di abuso di InstallUtil con payload di esempio.

In laboratorio è buona pratica testare anche la variante con assembly posizionati in directory inusuali — %TEMP%, %APPDATA%, profili utente — perché sono proprio questi path anomali a dover scatenare gli alert. Dopo l'esecuzione, verifica con Sysmon (open source) che l'evento di creazione processo (EventID 1) contenga la command line completa e che l'hash dell'assembly compaia nei log.

Un test complementare consiste nel verificare se la policy AppLocker o WDAC dell'ambiente blocca effettivamente il binario: esegui InstallUtil con un assembly innocuo e controlla se il sistema genera un evento di blocco (EventID 8004 nel log AppLocker). Se l'esecuzione riesce, la mitigazione non è efficace.

La detection di questa tecnica ruota attorno a un concetto chiave: InstallUtil è un binario legittimo ma raramente invocato nella maggior parte degli ambienti enterprise. Questo è un vantaggio enorme per il SOC, perché la baseline di utilizzo normale è quasi sempre prossima a zero, rendendo ogni esecuzione un segnale ad alta fedeltà.

Le log source primarie sono Sysmon e i log PowerShell, come indicato dalla detection AN0388. L'evento cardine è EventID 1 di Sysmon (Process Create): va monitorato qualsiasi processo il cui Image corrisponda al pattern InstallUtil.exe nelle directory .NET. La command line è il campo più ricco di informazioni — la presenza di /U seguita da un path verso directory utente (%TEMP%, %APPDATA%, Downloads) è un indicatore forte.

Per costruire una regola efficace, parti da una correlazione temporale a due fasi. Prima fase: rileva la creazione di un nuovo file .dll o .exe in directory non standard. Seconda fase: entro una finestra temporale configurabile (il parametro di tuning TimeWindow), rileva l'invocazione di InstallUtil che referenzia quel file. La correlazione riduce drasticamente i falsi positivi rispetto al monitoraggio della sola esecuzione di InstallUtil.

Il secondo livello di detection riguarda i processi figli. InstallUtil in uso legittimo non genera processi child significativi. Se dall'albero dei processi emergono figli come cmd.exe, powershell.exe o rundll32.exe, l'alert deve salire di severità. In ambiente SIEM, una lista di processi sospetti va mantenuta nel parametro di tuning ChildProcessList e aggiornata periodicamente.

Sul fronte delle mitigazioni preventive, la raccomandazione è netta: se InstallUtil non è necessario nell'ambiente — e nella stragrande maggioranza dei casi non lo è — va bloccato tramite AppLocker o WDAC (entrambi integrati in Windows, gratuiti). Una policy AppLocker che neghi l'esecuzione del binario dalle directory .NET elimina la superficie d'attacco alla radice. L'alternativa è la rimozione tramite policy di gruppo, in linea con la mitigazione M1042.

Per la gestione dei falsi positivi: identifica in fase di tuning i team di sviluppo .NET interni che potrebbero utilizzare legittimamente InstallUtil. Crea eccezioni basate su account di servizio specifici e path di installazione approvati, ma mai eccezioni globali sul binario. Ogni eccezione va documentata e revisionata trimestralmente.

Quando un'indagine porta a sospettare l'uso di InstallUtil come vettore di esecuzione proxy, la ricostruzione della timeline richiede di seguire due filoni paralleli: il binario legittimo che ha eseguito il codice e l'assembly malevolo che conteneva il payload reale.

Il punto di partenza è il log Sysmon, in particolare EventID 1 (Process Create). Cerca processi con immagine corrispondente a InstallUtil.exe e annota la command line completa — il path dell'assembly referenziato è il primo artefatto critico. Registra il ProcessGuid per correlare tutti gli eventi figli. L'EventID 7 (Image Loaded) mostra le DLL caricate dal processo InstallUtil: un assembly .NET malevolo comparirà tra queste, spesso con un path incongruente rispetto alle directory di installazione standard.

Sul filesystem, il file assembly è l'artefatto principale. Recupera il file e analizzalo con strumenti di reverse engineering .NET come dnSpy (open source) o ILSpy (open source) per estrarre il codice della classe decorata con RunInstaller(true). Verifica il metodo Uninstall() o Install() — è lì che risiede la logica malevola, che spesso include download di stage successivi, iniezione in memoria o disabilitazione di controlli di sicurezza.

Il caso di WhisperGate è emblematico: il malware utilizzava InstallUtil come parte della catena per disabilitare Windows Defender, un'azione preparatoria prima della fase distruttiva. In un contesto forense, questo significa cercare nelle chiavi di registro di Windows Defender eventuali modifiche temporalmente correlate all'esecuzione di InstallUtil — in particolare sotto HKLM\SOFTWARE\Policies\Microsoft\Windows Defender e i valori DisableAntiSpyware o DisableRealtimeMonitoring.

Per i malware Chaes e Saint Bot, la catena prevedeva l'uso di InstallUtil per scaricare ed eseguire payload aggiuntivi. L'analista deve quindi cercare artefatti di rete correlati: connessioni in uscita generate dal processo InstallUtil o dai suoi figli, visibili tramite EventID 3 di Sysmon (Network Connection).

La Master File Table ($MFT) e il journal USN forniscono informazioni preziose sulla creazione e modifica dell'assembly malevolo. Utilizzando tool come MFTECmd (open source, parte della suite Eric Zimmerman Tools), è possibile estrarre i timestamp di creazione del file e correlare con il momento dell'esecuzione. La sequenza tipica mostra un intervallo brevissimo tra il $SI Creation Time dell'assembly e l'invocazione di InstallUtil — un pattern che distingue l'attacco dall'uso amministrativo legittimo, dove gli installer esistono sul disco da tempo.

Infine, controlla i Prefetch (C:\Windows\Prefetch\INSTALLUTIL.EXE-*.pf): il file Prefetch registra i path degli ultimi file referenziati dall'eseguibile, offrendo un'istantanea delle DLL e degli assembly coinvolti nell'ultima esecuzione. Lo strumento PECmd (open source) di Eric Zimmerman consente di parsare questi file in modo rapido.

L'uso di InstallUtil come proxy di esecuzione è adottato da gruppi con profili operativi molto diversi, a conferma della versatilità della tecnica come strumento di evasione universale.

Mustang Panda (G0129) è un gruppo di cyber-spionaggio attribuito alla Cina, noto per colpire organizzazioni governative, think tank e ONG in Asia sudorientale ed Europa. Il gruppo ha utilizzato InstallUtil per eseguire un Beacon stager di Cobalt Strike, integrando la tecnica in una catena di compromissione che combina spear-phishing con documenti esca e side-loading di DLL. L'impiego di un LOLBin firmato Microsoft è coerente con il profilo operativo di Mustang Panda, che privilegia tecniche a bassa visibilità per mantenere la persistenza a lungo termine nelle reti delle vittime.

menuPass (G0045), noto anche come APT10 e Stone Panda, è un altro gruppo di spionaggio legato alla Cina, specializzato nel targeting di provider di servizi gestiti (MSP) e settori ad alta intensità di proprietà intellettuale — difesa, aerospaziale, telecomunicazioni. Il gruppo ha utilizzato InstallUtil per eseguire software malevolo, inserendo la tecnica all'interno di operazioni caratterizzate da movimenti laterali estesi e dall'abuso di relazioni di fiducia tra fornitori e clienti.

Il denominatore comune tra i due gruppi è chiaro: entrambi operano nella sfera di influenza cinese e adottano InstallUtil come complemento a catene di attacco che già sfruttano binari firmati e tecniche Living-off-the-Land. Per il threat intelligence officer, questo significa che il rilevamento di InstallUtil in contesti anomali, specialmente in settori target di questi gruppi, deve alzare immediatamente il livello di attenzione verso un possibile scenario APT.

Sul fronte dei tool, il panorama è variegato. Covenant è un framework C2 open source che genera launcher InstallUtil in modo nativo, rendendolo accessibile anche ad operatori meno sofisticati. WhisperGate, impiegato in operazioni distruttive contro l'Ucraina, ha usato la tecnica per disabilitare Windows Defender — un obiettivo tattico diverso (preparazione al wiper) ma che sfrutta lo stesso meccanismo di evasione. Chaes e Saint Bot rappresentano il segmento del malware commodity, dove InstallUtil viene usato come downloader per payload successivi, abbassando la soglia di complessità dell'intera catena.

Il trend da monitorare è la convergenza tra strumenti di spionaggio statale e malware commodity: quando una tecnica è integrata sia in framework C2 sofisticati sia in malware di massa, la sua diffusione è destinata a crescere. Per i settori nel mirino di Mustang Panda e menuPass — governo, difesa, MSP — la priorità è verificare che i controlli su InstallUtil siano attivi e monitorati.

Framework MITRE ATT&CK: T1218.004 (InstallUtil), TA0005 (Defense Evasion). Gruppi: G0129 (Mustang Panda), G0045 (menuPass). Software: S0631 (Chaes), S0689 (WhisperGate), S1155 (Covenant), S1018 (Saint Bot). Mitigazioni: M1038, M1042. Detection: DET0138 / AN0388. Integrato con conoscenza professionale per tool e procedure operative.