Path Non Quotato: Path Interception by Unquoted Path (T1574.009)

L'enumerazione dei servizi con path non quotati è il punto di partenza. Su un host Windows, un comando wmic ancora funzionante nelle release meno recenti restituisce rapidamente i candidati:

wmic service get name,displayname,pathname,startmode | findstr /i "auto" | findstr /i /v "c:\windows\" | findstr /i /v "

Su sistemi moderni dove wmic è deprecato, la stessa logica si ottiene via PowerShell interrogando la classe Win32_Service e filtrando le proprietà PathName che contengono spazi ma non iniziano con virgolette. Un approccio classico è iterare su Get-CimInstance -ClassName Win32_Service e valutare via regex la presenza di spazi non protetti nella prima parte del path.

Una volta identificato un servizio candidato, occorre verificare i permessi di scrittura sulle directory intermedie del percorso. Il tool icacls (nativo Windows) risponde a questa domanda:

icacls "C:\Program Files\Vendor"

Se l'ACL espone un gruppo come BUILTIN\Users o Authenticated Users con permessi di scrittura o CreateFiles, la vulnerabilità è sfruttabile. Il payload viene collocato con il nome della prima parola del path successiva a uno spazio non quotato e con estensione .exe.

Nel mondo dei framework offensivi, PowerSploit (open source) espone il modulo PowerUp con la funzione Get-UnquotedService e la controparte automatizzata Write-ServiceBinary, che genera un binario di test e lo installa nel percorso di intercettazione. Analogamente Empire (open source, oggi mantenuto dalla community BC-Security) integra moduli privesc/powerup/write_serviceexe per la stessa catena.

Un workflow tipico di red team prevede tre fasi: prima si mappa il parco servizi vulnerabili con Invoke-AllChecks di PowerUp, poi si valida quali di questi girano con account privilegiati confrontando la colonna StartName (LocalSystem è il target ideale), infine si stagea un service binary compilato con la struttura ServiceMain corretta per non far crashare il Service Control Manager al primo avvio.

In ambiente lab è utile creare uno scenario controllato installando un servizio custom con sc.exe create TestSvc binPath= "C:\Test Folder\bin\svc.exe" start= auto, notando l'assenza di quoting attorno al path, per poi esercitare rilevazione e sfruttamento senza toccare produzione. Per gli shortcut .lnk, l'analisi con LECmd di Eric Zimmerman (open source) rivela i TargetPath vulnerabili in profili utente e cartelle Startup.

La detection di T1574.009 ruota attorno a tre segnali correlati: la presenza in registro di configurazioni di servizio con path non quotati, la creazione di eseguibili sospetti nelle directory padre di tali path, e infine l'esecuzione di processi da location anomale.

La telemetria primaria proviene dal Windows Security log e da Sysmon (open source, Microsoft Sysinternals). Sul fronte registro, l'EventCode 4657 traccia modifiche ai valori sotto HKLM\SYSTEM\CurrentControlSet\Services<nome>\ImagePath, mentre l'EventCode 7045 del canale System registra l'installazione di nuovi servizi. Una query di baseline efficace è estrarre periodicamente tutti gli ImagePath con Sysmon Event ID 13 (Registry value set) filtrando quelli che contengono spazi ma non iniziano con il carattere di virgoletta.

Sul lato filesystem, Sysmon Event ID 11 (FileCreate) evidenzia la creazione di file .exe in directory di primo livello come *C:* o in path radice di Program Files. Correlare questi eventi con un Sysmon Event ID 1 (Process create) che mostra un processo genitore services.exe che avvia un binario dal path anomalo entro una finestra temporale ristretta è il pattern comportamentale di massima confidenza.

Secondo la modellazione D3FEND, i controlli difensivi mappati includono Process Analysis e Service Binary Verification. In pratica il SOC dovrebbe implementare regole che confrontano il path effettivamente eseguito dal Service Control Manager con la baseline nota dei servizi legittimi (parametro di tuning BaselineServiceConfig della strategia DET0064). Un cambio di ImagePath fuori da una finestra di manutenzione autorizzata è quasi sempre sospetto.

Alcuni indicatori concreti su cui costruire alert:

• Creazione di file C:\Program.exe, C:\Program Files\Common.exe o simili
• Esecuzione di processi con genitore services.exe il cui path non corrisponde all'ImagePath configurato
• Nuovi servizi installati con ImagePath privo di quoting e contenente spazi
• Attività di PowerShell che invoca Get-WmiObject Win32_Service o Get-CimInstance Win32_Service con proiezione sul campo PathName, spesso segnale di ricognizione con PowerUp

I falsi positivi arrivano tipicamente da software legacy di terze parti installato con installer sciatti che lasciano path non quotati come configurazione legittima. La strategia di tuning consiste nel mantenere una allowlist (parametro MonitoredServices) dei servizi noti-vulnerabili-ma-non-sfruttabili perché le directory padre hanno ACL restrittive, riducendo il rumore senza cieco filtering. La revisione trimestrale della lista è essenziale dopo cicli di patching applicativo.

L'indagine forense su un'ipotesi di T1574.009 si sviluppa lungo tre assi: registro di sistema, filesystem e artefatti di esecuzione. Il registro è la fonte di verità per lo stato di configurazione del servizio abusato. L'hive SYSTEM contiene sotto ControlSet001\Services<nome> i valori ImagePath, Start, ObjectName e DisplayName. Un analista che lavora offline su una copia dell'hive con Registry Explorer di Eric Zimmerman (open source) può filtrare tutti i servizi con Start=2 (Automatic) e ImagePath contenente spazi senza virgolette iniziali.

Il valore LastWriteTime della chiave del servizio è cruciale per la timeline: indica quando il servizio è stato installato o riconfigurato. Confrontare questo timestamp con la creazione del binario di intercettazione consente di stabilire l'ordine causale dell'attacco. La creazione file si estrae dalla MFT con MFTECmd (open source, Zimmerman), correlando $STANDARD_INFORMATION e $FILE_NAME per identificare eventuali tentativi di timestomping sul payload.

Gli artefatti di esecuzione confermano che il binario intercettato è stato effettivamente lanciato. Prefetch in C:\Windows\Prefetch fornisce prova diretta con nome eseguibile, path completo, contatore di esecuzioni e timestamp delle ultime otto esecuzioni; il parsing con PECmd (open source) è lo standard. Amcache.hve integra con l'hash SHA1 del binario e il path di origine, utile per pivoting su altri host compromessi. Su sistemi con AppCompat attivo, la chiave ShimCache completa il quadro con i file eseguiti anche in assenza di Prefetch.

Per i servizi effettivamente avviati, il log System.evtx conserva EventID 7045 (nuovo servizio installato) e EventID 7036 (cambio di stato), mentre Security.evtx registra EventID 4697 con dettagli sull'account che ha creato il servizio. La correlazione tra l'utente indicato in 4697 e le sessioni interattive di 4624 consente di ricondurre l'installazione a un vettore di accesso iniziale specifico.

Sul fronte shortcut, i file .lnk nelle cartelle Startup utente e all-users vanno parsati con LECmd per estrarre TargetPath, WorkingDirectory e MAC address della macchina d'origine (utile in indagini multi-host).

La timeline consolidata si costruisce con Plaso/log2timeline (open source), che unisce registro, MFT, Prefetch ed EVTX in un supertimeline navigabile. Il pattern discriminante è la sequenza: modifica ImagePath → creazione file in directory intermedia → primo EventID 7036 di avvio servizio → esecuzione del payload rilevata in Prefetch/Amcache, tutto entro una finestra tipicamente inferiore ai dieci minuti nelle intrusioni interattive.

Il quadro di threat intelligence su T1574.009 presenta una caratteristica peculiare: pur essendo una tecnica ampiamente conosciuta e discussa fin dai tempi delle prime edizioni di ATT&CK, il dataset MITRE non attribuisce l'uso della tecnica a gruppi APT specifici né a campagne nominate. Questa assenza non è casuale: l'unquoted service path viene tipicamente sfruttato in fase di privilege escalation locale, un momento dell'attacco meno visibile alla threat intelligence pubblica rispetto a Initial Access o Command and Control. Le tracce lasciate rimangono confinate all'host compromesso e raramente emergono in reportistica pubblica di incident response.

Ciò che è invece ben documentato è l'ecosistema di tooling che rende la tecnica accessibile a qualunque livello di attaccante. PowerSploit (S0194) rappresenta storicamente lo standard di fatto per l'audit offensivo del privilege escalation su Windows. Il modulo PowerUp automatizza l'intera catena di scoperta e sfruttamento di path non quotati, abbassando drasticamente la barriera d'ingresso. Nato come progetto di ricerca di Will Schroeder ed altri, PowerSploit è distribuito open source ed è oggi in modalità di mantenimento minimo, ma il codice resta pienamente funzionale e viene ancora ampiamente incorporato in framework derivati.

Empire (S0363), framework post-exploitation nato dalla scena red team statunitense, integra la stessa logica di PowerUp nei suoi moduli privesc/powerup. Dopo un periodo di abbandono, il progetto è stato ripreso e mantenuto dal gruppo BC-Security come Empire 5.x (open source), che continua a supportare i moduli di path interception. La disponibilità in Empire ne fa uno strumento di scelta anche per attori di livello medio-basso, dato che l'orchestrazione di agenti e moduli è pienamente automatizzata.

Il pattern operativo che emerge dai due tool è convergente: entrambi eseguono ricognizione via WMI sui servizi, verificano permessi ACL sulle directory intermedie, e generano automaticamente un service binary funzionante. Questa somiglianza suggerisce che qualunque rilevazione comportamentale efficace su uno dei due copra implicitamente anche l'altro e la gran parte dei fork.

Sul piano dei trend, la tecnica mantiene rilevanza principalmente in tre scenari: assessment interni contro parchi Windows con software legacy di terze parti, ransomware operator che privilegiano tecniche living-off-the-land per elevare privilegi prima della fase di deployment, e commodity malware che integra check automatici sulle vulnerabilità di path per opportunistica escalation. Le mitigazioni MITRE M1022, M1038 e M1047 — rispettivamente restrizione dei permessi filesystem, application control e audit periodico — coprono la superficie in modo complementare e vanno adottate congiuntamente per una difesa robusta.

MITRE ATT&CK T1574.009 (Hijack Execution Flow: Path Interception by Unquoted Path); software S0194 (PowerSploit) e S0363 (Empire); mitigazioni M1022, M1038, M1047; detection strategy DET0064 con analytic AN0176. Framework MITRE D3FEND per il mapping dei controlli difensivi di Process Analysis e Service Binary Verification. Integrazioni di conoscenza professionale su tooling forense (Eric Zimmerman suite, Plaso) e telemetria Sysmon per commands e artefatti operativi verificati contro documentazione ufficiale dei rispettivi progetti.