Script di Automazione Malevoli: AutoHotKey & AutoIT (T1059.010)

La simulazione di questa tecnica in laboratorio è accessibile e non richiede infrastrutture complesse. L'obiettivo è dimostrare come un attaccante trasformi uno script di automazione in un vettore di esecuzione capace di eludere controlli basati su firma.

Preparare l'ambiente. Scaricate l'interprete AutoHotKey dal sito ufficiale del progetto e il compilatore AutoIT (Aut2Exe), entrambi distribuiti gratuitamente. Su una macchina Windows 10/11 di laboratorio, assicuratevi che Sysmon (open source, Microsoft Sysinternals) sia configurato con un file di configurazione che catturi ProcessCreate, FileCreate e ImageLoad.

Scenario 1 — Script AHK interpretato. Create un file payload.ahk con contenuto che simuli un'azione malevola osservabile, ad esempio l'apertura di calc.exe o la scrittura di un file marcatore in %TEMP%:

AutoHotkey.exe payload.ahk

Questo comando esegue lo script tramite l'interprete. Osservate nella telemetria Sysmon (EventCode 1) la catena di processi: il padre sarà AutoHotkey.exe, il figlio calc.exe. In un attacco reale, il figlio sarebbe un loader o un keylogger.

Scenario 2 — Script AutoIT compilato. AutoIT permette di compilare uno script .au3 in un eseguibile standalone tramite il tool Aut2Exe incluso nella distribuzione:

Aut2Exe /in test.au3 /out payload.exe /icon custom.ico

Il binario risultante incorpora l'interprete e lo script offuscato. Distribuitelo sulla macchina target e verificate che l'EDR lo rilevi — o meno. Molti engine faticano perché la firma dell'eseguibile appartiene ad AutoIT, un software legittimo.

Scenario 3 — Catena phishing simulata. Per replicare il vettore documentato per APT39, incorporate uno script AutoIT in un documento Office tramite una macro VBA che estragga il payload nella directory %APPDATA% e lo esegua. Il flusso è:

1. L'utente apre il documento e abilita le macro
2. La macro scrive loader.au3 e AutoIt3.exe in una sottocartella di %APPDATA%
3. La macro lancia AutoIt3.exe loader.au3
4. Lo script AutoIT decifra e carica il payload finale in memoria

Per il testing, sostituite il payload reale con un canary che contatti un listener Netcat locale. Strumenti come Atomic Red Team (open source) contengono test atomici per la sotto-tecnica T1059 che potete adattare. Infine, verificate l'impatto delle mitigazioni: configurate AppLocker per bloccare l'esecuzione di AutoIt3.exe e AutoHotkey.exe da directory utente e ripetete i test per confermare l'efficacia del controllo.

La detection di AutoIT e AHK abusati richiede un approccio comportamentale: bloccare ciecamente questi interpreti potrebbe impattare automazioni IT legittime, ma ignorarli lascia una superficie d'attacco significativa. La log source primaria è Sysmon su Windows, con focus su tre classi di eventi.

Process Creation (EventCode 1). L'indicatore più affidabile è la comparsa di AutoHotkey.exe, AutoHotkey32.exe, AutoHotkey64.exe o AutoIt3.exe nella telemetria di creazione processi. Filtrate per il campo ParentProcessName: se il padre è winword.exe, excel.exe, outlook.exe o mshta.exe, la probabilità di abuso è elevata. Uno spawn da explorer.exe in orario lavorativo su una macchina dove l'IT usa AHK è invece probabilmente legittimo — da qui l'importanza del tuning sulla finestra temporale (TimeWindow) e sul processo padre.

La command line merita attenzione speciale. Gli script AHK interpretati mostreranno un percorso a un file .ahk; gli script AutoIT un riferimento a .au3. Quando invece vedete un .exe sconosciuto che genera numerosi processi figli in rapida successione, potrebbe trattarsi di uno script compilato. Il parametro di tuning ChildProcessCount serve proprio a questo: impostate una soglia (ad esempio più di 5 processi figli in 30 secondi) per catturare comportamenti di automazione modulare come quelli documentati per DarkGate, che deposita script .au3 in directory nascoste.

File Creation (EventCode 11). Monitorate la creazione di file con estensione .ahk, .au3 e .a3x in directory insolite — %TEMP%, %APPDATA%, sottocartelle nascoste del profilo utente. DarkGate utilizza esattamente questo pattern, creando file come test.au3 in directory hidden durante le fasi iniziali di installazione.

Image Load (EventCode 7). Quando uno script AutoIT viene compilato, il binario risultante carica in memoria le DLL dell'interprete AutoIT. Potete costruire una regola che rilevi il caricamento di moduli firmati "AutoIt Consulting Ltd" da parte di eseguibili il cui nome non corrisponde a AutoIt3.exe. Questo cattura payload compilati anche se rinominati.

Per la gestione dei falsi positivi, mantenete una whitelist di hash SHA256 degli script AHK autorizzati dall'IT e delle macchine su cui AutoIT è un prerequisito operativo. Incrociate sempre con il contesto: uno script AutoIT lanciato da un documento Office su un endpoint di un dipartimento HR è un incident, lo stesso script eseguito dal server di build dell'automazione IT è business as usual.

L'analisi forense di un'intrusione che sfrutta AutoIT o AHK produce artefatti caratteristici, a patto di sapere dove cercarli. La ricostruzione della timeline si articola su tre strati: filesystem, registro di sistema e memoria.

Artefatti su disco. Il primo passo è cercare file .ahk, .au3 e .a3x con una scansione ricorsiva del filesystem. Non limitatevi alle directory ovvie: DarkGate deposita i propri script in directory nascoste, quindi includete le cartelle con attributo Hidden e System. Con un'immagine disco montata, usate strumenti come Autopsy (open source) o il modulo file carving di Sleuth Kit (open source) per recuperare anche file cancellati con queste estensioni.

I timestamp MACB dei file .au3 individuati sono critici. Il timestamp di creazione ($SI_Created in $MFT) indica quando il payload è stato scritto su disco; confrontatelo con il timestamp di ultimo accesso per determinare quante volte è stato eseguito. Per estrarre questi dati dalla Master File Table, MFTECmd di Eric Zimmerman (open source) è lo strumento di riferimento:

MFTECmd.exe -f "C:\evidence$MFT" --csv "C:\output" --csvf mft_results.csv

Filtrate l'output per le estensioni .ahk, .au3, .a3x e per i nomi dei binari noti (AutoIt3.exe, AutoHotkey.exe).

Prefetch e Amcache. I file Prefetch di Windows (in C:\Windows\Prefetch) registrano l'esecuzione di binari. Cercate entry per AUTOIT3.EXE-*.pf e AUTOHOTKEY.EXE-*.pf utilizzando PECmd (open source):

PECmd.exe -d "C:\Windows\Prefetch" --csv "C:\output" --csvf prefetch_results.csv

Ogni entry contiene l'ultimo orario di esecuzione e il conteggio delle esecuzioni — se AUTOIT3.EXE è stato lanciato 47 volte su una macchina di contabilità, avete un indicatore forte. L'Amcache (C:\Windows\appcompat\Programs\Amcache.hve) registra inoltre l'hash SHA1 dell'eseguibile, permettendo il pivoting su piattaforme di threat intelligence come VirusTotal (freemium).

Memoria e processo. Se disponete di un dump di memoria, Volatility 3 (open source) permette di elencare i processi e identificare istanze di interpreti AutoIT/AHK ancora residenti. Il plugin windows.pstree mostra la gerarchia dei processi, evidenziando relazioni padre-figlio anomale. Per i payload compilati che decifrano ed eseguono codice in memoria — come documentato per XLoader — cercate regioni di memoria con permessi RWX (Read-Write-Execute) associate al processo sospetto tramite il plugin windows.malfind.

Nella timeline complessiva, correlate il momento di creazione dello script .au3 con eventuali artefatti di phishing (file Office nei download, entry nella cronologia browser) per ricostruire il vettore di accesso iniziale, particolarmente rilevante nei casi legati ad APT39 dove gli script AutoIT sono incorporati in documenti Office.

Il panorama di attori e malware che sfruttano AutoIT e AHK come vettore di esecuzione rivela un pattern trasversale: questa tecnica non è esclusiva di un singolo cluster di minacce ma viene adottata da gruppi con motivazioni, target e sofisticazione molto diversi tra loro.

APT39 (G0087) è un gruppo di spionaggio con nexus iraniano, storicamente focalizzato su settori telecomunicazioni, viaggi e alta tecnologia. L'uso di script AutoIT embedded in documenti Microsoft Office rappresenta per questo attore una scelta coerente con il suo modus operandi: ingegneria sociale tramite spear-phishing mirato, seguita da esecuzione di codice attraverso macro che depositano ed eseguono payload AutoIT. L'aspetto rilevante è che APT39 non usa AutoIT come strumento primario ma come loader intermedio, parte di una catena di esecuzione multi-stadio.

Sul fronte del malware commodity e dell'info-stealing, Lumma Stealer (S1213) sfrutta sia script AutoIT sia eseguibili compilati da AutoIT, dimostrando che l'ecosistema criminale ha industrializzato questo vettore. Lumma è uno stealer distribuito tramite modello Malware-as-a-Service, il che significa che centinaia di affiliati eterogenei possono impiegare questa tecnica senza comprenderne i meccanismi interni.

DarkGate (S1111) merita attenzione per il pattern operativo specifico: durante le fasi iniziali di installazione, deposita script AutoIT (come test.au3) in directory nascoste. Questo comportamento indica un'architettura modulare dove lo script di automazione funge da orchestratore che prepara l'ambiente per componenti successivi.

Melcoz (S0530) utilizza un approccio diverso: un loader script AutoIT che funge da primo stadio della catena di distribuzione, scaricando e attivando i componenti del trojan bancario. XLoader (S1207) aggiunge un ulteriore livello di complessità usando lo script AutoIT come meccanismo di decifratura e iniezione in memoria, combinando T1059.010 con tecniche di process injection.

OutSteel (S1017) rappresenta il caso estremo: non usa AutoIT come loader o wrapper ma è interamente sviluppato nel linguaggio AutoIT, dimostrando che il framework è sufficientemente maturo per costruire malware completi.

Il trend complessivo mostra una convergenza: gruppi APT statali e operatori criminali adottano AutoIT/AHK perché gli interpreti sono software legittimi firmati, spesso presenti negli ambienti enterprise per automazioni IT, e i binari compilati ereditano la firma digitale dell'interprete riducendo i tassi di detection. Per il threat intelligence, il consiglio operativo è monitorare le submission su sandbox pubbliche filtrando per indicatori AutoIT (stringhe compilatore, import specifici) e correlare con le proprie verticalità di settore.

Framework MITRE ATT&CK v16 — Tecnica T1059.010 (Command and Scripting Interpreter: AutoHotKey & AutoIT), Tattica TA0002, Gruppo G0087, Software S1213, S0530, S1207, S1017, S1111, Mitigazione M1038, Detection DET0332/AN0942. Integrato con conoscenza professionale per tool e procedure operative.