Dirottamento Binari di Servizio: Services File Permissions Weakness (T1574.010)
La tecnica T1574.010 — Services File Permissions Weakness sfrutta permessi mal configurati sui file eseguibili dei servizi Windows o sulle directory che li contengono. Quando un utente non privilegiato può scrivere sul binario associato a un servizio che gira come SYSTEM, può sostituirlo con un proprio payload che verrà eseguito al successivo avvio del servizio, ottenendo esecuzione con privilegi elevati.
MITRE ATT&CK cataloga questa tecnica in tre tattiche contemporaneamente: TA0003 Persistence, perché la sostituzione del binario garantisce il ritorno del codice malevolo a ogni riavvio; TA0004 Privilege Escalation, perché il salto di privilegi da utente a SYSTEM è immediato; TA0005 Defense Evasion, perché il processo malevolo viene lanciato dal Service Control Manager con un nome legittimo, mimetizzandosi tra i servizi di sistema.
Sul piano della kill chain il vettore appartiene alla fase di post-exploitation: presuppone un accesso iniziale già ottenuto e serve a consolidare la posizione. L'impatto è significativo perché combina tre effetti in un singolo passo tecnico e sfrutta configurazioni preesistenti, senza bisogno di exploit di vulnerabilità software. I dati MITRE associano alla tecnica 1 software documentato (BlackEnergy) e 3 mitigazioni (User Account Management, Audit, User Account Control), con una detection strategy dedicata (DET0436) centrata su modifiche non autorizzate ai binari dei servizi registrati.
L'esercitazione red team parte sempre da un'enumerazione sistematica dei servizi vulnerabili. Il modulo più diretto è PowerUp del framework PowerSploit (open source), che espone le funzioni Get-ServiceUnquoted, Get-ModifiableServiceFile e Get-ModifiableService. La prima cerca path non quotati con spazi, la seconda identifica servizi il cui binario o la cui directory sono scrivibili dall'utente corrente, la terza cerca servizi la cui configurazione può essere modificata.
Una catena tipica in laboratorio inizia con il caricamento del modulo e l'enumerazione:
Import-Module .\PowerUp.ps1
Get-ModifiableServiceFile
Se l'output mostra un servizio con binario scrivibile, l'operatore può fermare il servizio (se ha i permessi), sostituire il file e attendere il riavvio. In alternativa, accesschk (gratuito, Sysinternals) permette di verificare i permessi manualmente con:
accesschk.exe -uwcqv "Users" *
Questo elenca tutti i servizi su cui il gruppo Users ha permessi di scrittura. Un comando equivalente con icacls sul file binario conferma l'ACL: icacls "C:\Program Files\VendorX\service.exe".
Per la generazione del payload sostitutivo, in ambiente lab si usa msfvenom (open source, parte di Metasploit Framework) per produrre un eseguibile che rispetti l'interfaccia di un service Windows — un binario non-service viene terminato dal SCM dopo circa 30 secondi con errore 1053. Per ovviare, si può wrappare lo shellcode dentro un service stub scritto in C# o usare sc.exe per registrare un comando arbitrario, oppure ricorrere a SharpNoPSExec o SharpUp (open source) come alternative in C# a PowerUp, più adatte contro AMSI.
La sostituzione vera e propria richiede tre azioni: backup del binario originale, copia del payload al suo posto, restart del servizio con sc stop
Un caso complementare è la DLL hijacking su servizi che caricano librerie da directory scrivibili: strumento utile è Process Monitor (gratuito, Sysinternals) filtrando su Result=NAME NOT FOUND e Path che punta a directory con permessi deboli, per identificare DLL fantasma piazzabili. Nel report finale l'operatore deve documentare il percorso vulnerabile, l'ACL problematica, la catena di privilegi ottenuta e proporre remediation puntuali (correzione ACL, quoting del path, esecuzione con account meno privilegiato).
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo