Script negli Stylesheet: XSL Script Processing (T1220)

XSL Script Processing è una tecnica di Defense Evasion (TA0005) che sfrutta una caratteristica legittima degli stylesheet XSL — la capacità di incorporare codice eseguibile — per aggirare i controlli applicativi ed eseguire payload in modo silenzioso. Lo standard XSL, nato per trasformare e rendere dati XML, supporta scripting inline in JScript e VBScript: una funzionalità di cui gli attaccanti abusano attraverso due vettori principali.

Il primo è msxsl.exe, un binario Microsoft per trasformazioni da riga di comando che non è installato di default ma può essere facilmente distribuito dall'attaccante. Il secondo è la variante nota come Squiblytwo, che utilizza WMIC con lo switch /FORMAT per invocare stylesheet XSL contenenti script malevoli, sfruttando così un tool nativo di Windows già presente nel sistema.

Ciò che rende la tecnica particolarmente insidiosa è la sua capacità di operare attraverso binari trusted o built-in, rendendo inefficaci le policy di application control che si basano su whitelist di eseguibili. I file XSL possono essere referenziati localmente o da URL remoti, e possono persino utilizzare estensioni arbitrarie come .jpeg per mascherare ulteriormente la propria natura. La tecnica è stata osservata in 2 gruppi APT, 1 software e 1 campagna documentati, a dimostrazione del suo impiego operativo consolidato.

Per simulare questa tecnica in laboratorio è necessario comprendere entrambi i vettori d'attacco e le loro varianti. Il primo passo è costruire un file XSL che contenga codice embedded: un semplice stylesheet con un blocco <msxsl:script> in JScript o un elemento <script> CDATA è sufficiente per dimostrare l'esecuzione.

Vettore msxsl.exe. Il binario va scaricato dal sito Microsoft (non è più ufficialmente distribuito, ma copie archiviate esistono) e posizionato nella directory di test. Le tre varianti di invocazione documentate mostrano la flessibilità dell'abuso:

  • msxsl.exe customers.xml script.xsl — forma canonica con file XML sorgente e stylesheet separati
  • msxsl.exe script.xsl script.xsl — il file XSL viene passato come entrambi gli argomenti, poiché è XML valido
  • msxsl.exe script.jpeg script.jpeg — estensione arbitraria per eludere filtri basati su filename

Quest'ultima variante è particolarmente rilevante in un engagement, perché molte regole di detection si basano sull'estensione .xsl e possono essere bypassate con un semplice rename.

Vettore Squiblytwo (WMIC). Questa variante non richiede binari aggiuntivi ed è quindi più realistica in scenari con accesso limitato:

wmic process list /FORMAT:evil.xsl

Per il test remoto, WMIC accetta URL diretti nello switch /FORMAT, permettendo il download e l'esecuzione in un singolo passo. In laboratorio, servite lo stylesheet XSL da un web server locale con Python:

python3 -m http.server 8080

Il framework Atomic Red Team (open source) include test atomici pre-costruiti per T1220 che automatizzano entrambi i vettori. Lo strumento consente di eseguire il test con un singolo comando PowerShell e verificare la corretta generazione di telemetria. Per la parte di payload delivery, è possibile usare Villain (open source) o Metasploit Framework (open source) per generare payload JScript da incorporare nello stylesheet.

Un aspetto spesso trascurato: durante il red team, verificate che il vostro XSL malevolo sia un documento XML ben formato, altrimenti il parser fallirà silenziosamente e il payload non verrà eseguito. Testate sempre la validità XML prima dell'uso con xmllint --noout script.xsl (disponibile nel pacchetto libxml2-utils su Linux).

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo