Occultamento Macro tramite P-code: VBA Stomping (T1564.007)

Simulare il VBA Stomping in laboratorio richiede la comprensione del formato Compound File Binary (CFB) usato da Office. Il tool di riferimento nella comunità è EvilClippy (open source), sviluppato da Outflank e disponibile su GitHub, che implementa direttamente lo stomping delle macro. Un flusso operativo tipico su Windows parte da un documento .docm contenente una macro AutoOpen che lancia PowerShell o esegue shellcode via CreateObject("WScript.Shell").

La catena si sviluppa in tre fasi. Prima si genera il payload malevolo in VBA e lo si salva nel documento con Office della stessa versione della vittima target (fondamentale per il matching di _VBA_PROJECT). Il comando di stomping tipico è:

EvilClippy.exe -s fake.vba -t 2019x86 payload.docm

Dove -s sostituisce il sorgente con un file benigno (fake.vba può contenere un semplice MsgBox "Hello") e -t specifica la versione target di Office per garantire l'esecuzione del p-code. Il flag -g consente di rendere invisibili i moduli VBA nell'IDE integrato, aumentando ulteriormente l'occultamento.

Su Linux, la controparte analitica è oletools (open source) del progetto decalage2, in particolare olevba e pcodedmp. Per la simulazione red team, si può usare pcodedmp (open source) per verificare che il p-code stomped sia effettivamente diverso dal sorgente:

pcodedmp -d payload.docm

e confrontarlo con:

olevba payload.docm

Se le due uscite divergono in modo significativo, lo stomping è riuscito.

Per catene più elaborate, il payload VBA può caricare shellcode tramite DynamicWrapperX o eseguire in-memory download-and-execute con URLDownloadToFileA via Declare PtrSafe. Gli operatori maturi combinano lo stomping con VBA purging (rimozione totale del sorgente lasciando solo p-code) usando il flag -r di EvilClippy, che rende il file completamente invisibile agli scanner classici.

In un ingaggio autorizzato è essenziale documentare la versione esatta di Office bersaglio: un mismatch causa la ricompilazione del sorgente benigno e il fallimento del payload. Su macOS, dove Office ha un runtime VBA differente, la tecnica è meno affidabile: le versioni Office for Mac 2019+ ricompilano più frequentemente il sorgente, riducendo la finestra operativa. Test in sandbox isolate (FLARE VM (open source) o REMnux (open source)) sono lo standard per validare la resa reale prima del deployment.

La detection del VBA Stomping richiede un approccio che superi l'ispezione statica del sorgente e si concentri sulla discrepanza tra sorgente VBA e p-code, come indicato dalla strategia DET0012 con analitiche AN0034 per Windows, AN0035 per Linux e AN0036 per macOS.

Su Windows, la telemetria chiave arriva da Sysmon (open source) configurato con una policy che tracci Event ID 1 (Process Create) e Event ID 11 (File Create). L'indicatore comportamentale più forte è l'esecuzione di un processo Office (winword.exe, excel.exe, powerpnt.exe) seguita entro una finestra ristretta — tipicamente 5-30 secondi — dalla creazione di processi figli anomali come powershell.exe, wscript.exe, cscript.exe o cmd.exe. Il tuning suggerito prevede di limitare l'analisi ai file .docm, .xlsm e .pptm, che sono i formati macro-enabled per eccellenza.

Una query SIEM efficace correla la catena parent-child così:

ParentImage in ("winword.exe","excel.exe") AND Image in ("powershell.exe","wscript.exe","mshta.exe") AND TimeDelta < 30s

A questo si aggiunge il monitoraggio degli EventCode 4688 nativi di Windows Security con command-line auditing abilitato, utile per catturare l'argomento passato agli interpreti figli.

Su Linux, dove l'esecuzione di macro avviene tipicamente via Wine o LibreOffice, la telemetria di riferimento è auditd:SYSCALL con regole su execve che tracciano l'invocazione di soffice o wine seguita da spawn di shell o interpreti. Su macOS, l'unifiedlog registra tramite subsystem com.microsoft.office gli eventi di apertura documenti; la correlazione va fatta con ProcessMonitor di Objective-See per identificare macro che aprono connessioni di rete senza sorgente VBA visibile.

La detection strutturale — cioè l'analisi diretta del file — richiede l'integrazione di oletools (open source) nella pipeline email o EDR. Il modulo olevba include già flag di allerta specifici (VBA_Stomp_Detected) quando riscontra p-code senza sorgente coerente. Una detection ancora più affidabile è confrontare l'hash del p-code disassemblato con pcodedmp (open source) contro il sorgente estratto: divergenze sostanziali sono indicative.

I falsi positivi principali derivano da documenti aziendali legittimi con macro firmate ma vecchie, dove ricompilazioni parziali possono creare disallineamenti minori. Il baseline dei template macro legittimi (finance, HR, ERP) è essenziale prima di attivare l'alerting. In ottica preventiva, l'applicazione di M1042 tramite GPO che disabilita le macro non firmate (VBAWarnings = 4) rimane la mitigazione più solida.

L'analisi forense di un documento sospettato di VBA Stomping parte dalla conservazione integrale del file originale con hashing SHA-256 e catena di custodia. Il documento è tecnicamente un contenitore CFB (Compound File Binary) e va trattato come tale: prima dell'analisi va copiato in un ambiente isolato, idealmente su una workstation forense con REMnux (open source) o SIFT Workstation (open source).

Il primo passo è l'estrazione degli stream OLE con oledump.py (open source) di Didier Stevens:

oledump.py sospetto.docm

L'output elenca gli stream numerati; quelli rilevanti sono VBA/_VBA_PROJECT, VBA/dir e i module stream (tipicamente VBA/Module1, VBA/ThisDocument). L'indicatore chiave del stomping è la presenza di p-code sostanzioso in un module stream il cui sorgente compresso è vuoto, riempito di zeri o palesemente banale.

La disassemblazione del p-code si effettua con pcodedmp (open source):

pcodedmp -d sospetto.docm

L'output mostra le istruzioni VBA compilate: variabili, chiamate API (Shell, CreateObject, URLDownloadToFile), stringhe embedded. Il confronto con l'output di olevba rivela immediatamente la discrepanza. Per un'analisi più profonda, ViperMonkey (open source) emula l'esecuzione del p-code senza aprire Office, permettendo di estrarre IoC come URL, IP, path di scrittura e comandi shell.

Sull'endpoint compromesso, la timeline forense va costruita raccogliendo:

• MFT e USN Journal per identificare la creazione del documento e file dropped successivamente
• Prefetch (C:\Windows\Prefetch) di winword.exe/excel.exe e di eventuali binari lanciati
• Registry hive NTUSER.DAT con chiavi Software\Microsoft\Office\<versione>\Word\Resiliency\StartupItems e le Trusted Documents in Software\Microsoft\Office\<versione>\Word\Security\Trusted Documents
• Office MRU (Software\Microsoft\Office\<versione>\Word\User MRU) che conserva il path del documento aperto

La versione esatta di Office installata sull'endpoint è forensicamente cruciale: essendo il p-code eseguito solo con match di _VBA_PROJECT, la corrispondenza tra la build Office nel registro (HKLM\Software\Microsoft\Office\ClickToRun\Configuration) e i byte di versione nel documento conferma che l'esecuzione è avvenuta effettivamente.

Su Linux, gli artefatti provengono da ~/.config/libreoffice/ e dai log di auditd con syscall execve. Su macOS, l'unifiedlog filtrato per process == "Microsoft Word" e il contenuto di ~/Library/Containers/com.microsoft.Word/Data/ forniscono il contesto di apertura e i file recenti.

La reportistica deve documentare: hash del documento, elenco stream OLE, disassemblazione p-code, IoC estratti, timeline di esecuzione e correlazione con connessioni di rete outbound emerse dai log EDR.

I dati MITRE ATT&CK forniti per T1564.007 non riportano gruppi APT, software o campagne specificamente attribuiti all'uso documentato di VBA Stomping. Questa assenza nel dataset ufficiale non implica che la tecnica sia poco diffusa, ma riflette la difficoltà intrinseca di attribuzione: lo stomping è per definizione una tecnica anti-analisi, e la sua identificazione retroattiva su campagne storiche richiede la conservazione dei documenti originali e capacità analitiche p-code, non sempre presenti nei report pubblici.

Dal punto di vista dell'intelligence, il valore operativo della tecnica risiede nel gap di detection che apre nelle pipeline enterprise. Le organizzazioni che si affidano esclusivamente ad analisi statica del sorgente VBA — inclusi molti gateway email di fascia media e alcuni motori antivirus tradizionali — sono strutturalmente vulnerabili. Questo rende VBA Stomping particolarmente appetibile per operazioni dove la persistenza della fase di initial access è critica: campagne di spearphishing mirate contro pochi bersagli di alto valore, dove il costo di sviluppo del documento weaponizzato è ampiamente giustificato dal ROI del target.

Il pattern strategico che un TI officer deve monitorare è la co-occorrenza tra VBA Stomping e altre tecniche di evasione documento-centriche: T1027 (Obfuscated Files or Information), T1204.002 (User Execution: Malicious File) e T1218 (System Binary Proxy Execution). Documenti che combinano stomping con VBA purging (rimozione totale del sorgente) e caricamento di payload via mshta.exe o rundll32.exe rappresentano una firma comportamentale di operatori con competenze avanzate sul formato OLE.

Sul piano della tool intelligence, l'ecosistema offensivo ruota attorno a EvilClippy (open source), rilasciato pubblicamente nel 2019 da Outflank e da allora ampiamente adottato. La pubblicazione del tool ha democratizzato la tecnica, abbassando la barriera d'ingresso da researcher esperti in reversing OLE a operatori con competenze red team medie. Questo tipicamente precede un'ondata di adozione da parte di gruppi criminali e commodity malware, dopo la fase iniziale di uso da parte di attori APT.

Per un programma di threat intelligence maturo, la raccomandazione è integrare nell'analisi dei documenti sospetti provenienti da feed OSINT (VirusTotal (freemium), MalwareBazaar (gratuito) di abuse.ch) uno step automatizzato di confronto sorgente/p-code. La creazione di regole YARA (open source) mirate su pattern strutturali del _VBA_PROJECT stream — invece che sul solo contenuto sorgente — è un investimento strategico per identificare varianti stomped di famiglie note come Emotet, Qakbot o loader di access broker, anche quando il sorgente VBA appare pulito.

MITRE ATT&CK: T1564.007 (VBA Stomping), tattica TA0005 (Defense Evasion), mitigazione M1042 (Disable or Remove Feature or Program), strategia di detection DET0012 con analitiche AN0034, AN0035, AN0036. Tool di detection e analisi citati: oletools (olevba, oledump, pcodedmp), ViperMonkey, EvilClippy, Sysmon, REMnux, SIFT Workstation. Parti tecniche operative (sintassi comandi, artefatti registry, workflow forensi) integrate con conoscenza professionale di cybersecurity verificata contro documentazione ufficiale dei tool citati.