Esecuzione Proxy tramite Script di Stampa: PubPrn (T1216.001)

L'obiettivo in un esercizio red team è dimostrare che l'ambiente non rileva o non blocca l'abuso di script firmati Microsoft. PubPrn è un classico Living Off the Land Binary (LOLBin) — o meglio, LOLScript — e la catena d'attacco è sorprendentemente lineare.

Il primo passo è preparare il payload. Serve un file scriptlet (.sct) che contenga codice COM scriptlet valido. In un laboratorio controllato, il file .sct può lanciare un semplice calc.exe come proof of concept, oppure una reverse shell per dimostrare l'impatto completo. Il file va ospitato su un web server sotto il tuo controllo — un semplice listener Python è sufficiente:

python3 -m http.server 8080

Sul sistema target, l'esecuzione avviene invocando cscript con PubPrn.vbs. Il percorso dello script varia leggermente tra le versioni di Windows, ma di norma si trova in C:\Windows\System32\Printing_Admin_Scripts\en-US\. Il comando canonico è:

cscript.exe /b C:\Windows\System32\Printing_Admin_Scripts\en-US\pubprn.vbs 127.0.0.1 script:/payload.sct

Il flag /b sopprime l'output a console, rendendo l'esecuzione meno visibile. Il primo parametro (127.0.0.1) è il server di stampa, ma nel contesto dell'abuso è irrilevante — l'esecuzione del codice remoto avviene tramite il secondo parametro con il moniker script:.

Per un test più realistico, concatena l'esecuzione all'interno di una catena di comandi via cmd.exe, simulando uno scenario dove un documento macro o un initial access dropper lancia lo script:

cmd.exe /c cscript.exe /b C:\Windows\System32\Printing_Admin_Scripts\en-US\pubprn.vbs "" script:/payload.sct

Alcuni punti operativi da tenere a mente durante il test:

• Verifica la versione dell'OS prima di procedere: su Windows 10+ la tecnica è patchata. Usa systeminfo | findstr /B /C:"OS Version" per accertarti.
• Monitora il traffico in uscita con Wireshark (open source) per confermare che la connessione HTTP al server .sct avvenga effettivamente.
• Il progetto LOLBAS (open source) cataloga PubPrn e fornisce dettagli sulla superficie d'attacco dello script, consultabile come riferimento per la reportistica.
• Atomic Red Team (open source) include test preconfigurati per questa tecnica, utilizzabili per validare la detection in modo ripetibile.

La detection di questa tecnica si fonda su un indicatore estremamente affidabile: la presenza del moniker script: seguito da un URI HTTP o HTTPS nella command line di cscript.exe o wscript.exe che invocano pubprn.vbs. Non esiste un caso d'uso legittimo in cui PubPrn venga lanciato con un riferimento a uno scriptlet remoto via HTTP — il che rende questo pattern un candidato ideale per un alert ad alta confidenza con bassissimo tasso di falsi positivi.

La sorgente log primaria è Sysmon (EventCode 1 — Process Creation), dove puoi intercettare la command line completa. Configura una regola che cerchi la co-occorrenza di pubprn.vbs e script: nel campo CommandLine. In ambienti con centralizzazione via SIEM, la regex di detection si può esprimere come pattern che individua il moniker script: combinato con protocolli HTTP/HTTPS negli argomenti dello script.

Il secondo layer di detection sfrutta la telemetria di rete. Quando PubPrn esegue lo scriptlet remoto, il processo cscript.exe genera una connessione HTTP in uscita — un evento catturato da Sysmon EventCode 3 (Network Connection). Un alert che correli la creazione del processo cscript.exe con una connessione di rete verso un dominio esterno entro una finestra temporale di pochi secondi produce risultati molto precisi.

Il tuning è minimo ma va curato. I parent process legittimi variano: cmd.exe, wscript.exe e cscript.exe possono tutti comparire come processi padre a seconda della catena d'esecuzione. Evita di filtrare su un singolo parent, o rischi di perdere varianti. Più utile è concentrare il tuning sulla destinazione di rete: connessioni verso domini interni noti (come server di stampa legittimi via LDAP) possono essere escluse con una whitelist mirata.

Per la prevenzione, le mitigazioni sono chiare. Execution Prevention (M1038) impone di bloccare l'esecuzione di PubPrn.vbs se non necessario nell'ambiente: Windows Defender Application Control (WDAC) o AppLocker possono creare regole esplicite per impedire il lancio dello script. Behavior Prevention on Endpoint (M1040) suggerisce di aggiornare le policy WDAC per bloccare le versioni vulnerabili di PubPrn, quelle precedenti alla patch che limita il protocollo a LDAP. Un EDR moderno dovrebbe rilevare la relazione anomala tra cscript.exe e la connessione HTTP in uscita come comportamento sospetto.

La regola Sigma (open source) per questa tecnica è disponibile nel repository SigmaHQ e può essere convertita per il tuo SIEM tramite il tool sigma-cli (open source).

L'abuso di PubPrn lascia tracce relativamente chiare se sai dove guardare, ma la finestra temporale degli artefatti è breve — lo scriptlet viene scaricato, eseguito in memoria, e la catena si sposta rapidamente verso il payload successivo. La ricostruzione della timeline richiede quindi di incrociare diverse sorgenti.

Il punto di partenza è il Prefetch. Il file CSCRIPT.EXE-{hash}.pf nella directory C:\Windows\Prefetch registra le ultime esecuzioni di cscript.exe, inclusi i riferimenti ai file caricati durante l'esecuzione. Analizzando il Prefetch con PECmd (open source, di Eric Zimmerman) puoi estrarre i percorsi dei file referenziati, tra cui pubprn.vbs e potenzialmente il percorso della cache locale dove lo scriptlet .sct è stato temporaneamente salvato.

PECmd.exe -f "C:\Windows\Prefetch\CSCRIPT.EXE-.pf" --csv output_dir*

Gli event log di Windows rappresentano il secondo pilastro. Il canale Microsoft-Windows-Sysmon/Operational (se Sysmon era installato al momento dell'attacco) contiene gli eventi di creazione processo (EventCode 1) con la command line completa, il hash dell'eseguibile e la relazione parent-child. Cerca eventi dove il campo Image termina con cscript.exe e il campo CommandLine contiene pubprn.vbs. L'EventCode 3 di Sysmon documenta la connessione di rete verso il server che ospitava lo scriptlet — IP, porta, dominio di destinazione.

In assenza di Sysmon, il log Microsoft-Windows-PowerShell/Operational può contenere tracce se lo scriptlet ha generato attività PowerShell come stadio successivo. Il log Security con audit delle creazioni processo (Event ID 4688) è un'alternativa, purché fosse abilitata la registrazione della command line.

Per la componente di rete, i log proxy o firewall sono essenziali per confermare il download del file .sct. Cerca richieste HTTP GET verso file con estensione .sct o verso domini non categorizzati. L'incrocio tra il timestamp della connessione di rete e l'esecuzione di cscript.exe nel Prefetch consolida la timeline.

Sul filesystem, verifica la directory IE/Edge cache e la directory %TEMP% dell'utente coinvolto: il motore COM di Windows potrebbe aver salvato temporaneamente lo scriptlet prima dell'esecuzione. Lo strumento MFTECmd (open source, di Eric Zimmerman) applicato alla Master File Table può rivelare la creazione e cancellazione di file .sct anche se già rimossi.

La superficie di utilizzo documentata di PubPrn è circoscritta ma significativa per comprendere un approccio operativo preciso: l'abuso di componenti Windows firmati per ottenere evasion durante le fasi iniziali di un'intrusione.

APT32 (noto anche come OceanLotus, gruppo associato al Vietnam) ha integrato PubPrn.vbs all'interno di catene di esecuzione più ampie, utilizzandolo come proxy per lanciare malware aggirando i controlli di sicurezza basati su firma digitale. Il gruppo è noto per un arsenale tecnico sofisticato e diversificato, e l'adozione di PubPrn si inserisce in un pattern più ampio di utilizzo di LOLBin e LOLScript per ridurre la propria impronta sul disco e confondersi con l'attività legittima dell'ambiente compromesso.

Dal punto di vista del profiling, l'uso di PubPrn racconta qualcosa di specifico sugli ambienti target di APT32: organizzazioni con infrastrutture Windows legacy dove lo script non è stato patchato. Un threat intelligence analyst dovrebbe correlare la presenza di macchine pre-Windows 10 nell'organizzazione protetta con il rischio di esposizione a questa tecnica — e più in generale all'intera classe di abusi LOLBin che funzionano solo su sistemi datati.

Il pattern strategico è chiaro: PubPrn è una tecnica di evasion di secondo livello. Non è il vettore di accesso iniziale, ma un anello nella catena post-compromissione che permette di scaricare ed eseguire payload senza che il file malevolo tocchi mai direttamente il disco in forma di eseguibile tradizionale. Questo lo rende complementare a tecniche di initial access basate su documenti macro o spear-phishing.

Per le organizzazioni nel mirino di APT32 — tipicamente enti governativi, media e aziende del Sud-Est asiatico — la raccomandazione è duplice: eliminare le versioni vulnerabili di PubPrn dall'ambiente e monitorare l'intero catalogo LOLBin/LOLScript come indicatore di attività post-compromissione. Il progetto LOLBAS (open source) mantiene un inventario aggiornato di questi vettori, utilizzabile per alimentare le regole di detection e le valutazioni di rischio.

Framework MITRE ATT&CK v16 — Tecnica T1216.001 (PubPrn), Tattica TA0005 (Defense Evasion), Gruppo G0050 (APT32), Mitigazioni M1038, M1040, Detection DET0528/AN1464. Tool di detection: Sysmon, Sigma, PECmd, MFTECmd. Integrato con conoscenza professionale per tool e procedure operative.