Dirottamento Servizi via Registry: Services Registry Permissions Weakness (T1574.011)

L'assessment di T1574.011 in laboratorio parte dall'enumerazione delle ACL sulle chiavi dei servizi. Lo strumento canonico è AccessChk della Sysinternals Suite (gratuito), che fornisce una lettura granulare dei permessi effettivi:

accesschk.exe -uwqs "NT AUTHORITY\Authenticated Users" HKLM\System\CurrentControlSet\Services

Il flag -w isola solo le chiavi con permessi di scrittura effettivi per il principal indicato, riducendo il rumore. In alternativa, PowerUp (modulo di PowerSploit, open source) automatizza la ricerca con la funzione Get-ModifiableRegistryAutoRun e con Get-ServiceUnquoted / Get-ModifiableService, che identificano rispettivamente path non quotati e servizi con configurazione riscrivibile.

Una volta individuato un servizio vulnerabile, il vettore classico è la riscrittura di ImagePath. Con permessi sufficienti si usa sc.exe (built-in Windows):

sc config VulnSvc binPath= "C:\Temp\payload.exe"

Oppure via PowerShell con Set-ItemProperty sulla chiave del servizio. Da notare lo spazio dopo binPath= in sc.exe, sintatticamente obbligatorio. L'attivazione avviene con sc start VulnSvc oppure attendendo un riavvio se il servizio è impostato su Auto.

Un vettore meno rumoroso passa per FailureCommand: modificando le azioni di recovery via sc failure VulnSvc reset= 0 actions= run/1000/run/1000/run/1000 con sc failureflag e crashando volutamente il servizio, il comando di recovery viene eseguito in contesto elevato senza toccare ImagePath, riducendo la superficie di detection basata sul monitoraggio della chiave principale.

La sottochiave Parameters offre un ulteriore vettore per DLL hijacking. Servizi driver leggono qui path di DLL ausiliarie; il caso AutodialDLL sotto WinSock2\Parameters è documentato — sostituire il valore con una DLL controllata fa sì che venga caricata a ogni invocazione dello stack Winsock 2. Analogamente, creare una sottochiave Performance (se assente e se l'utente ha permesso Create Subkey) con valori Library, Open, Collect, Close forza il caricamento della DLL nel contesto del servizio di monitoraggio delle performance.

In ambiente red team, Covenant (open source) e Cobalt Strike (a pagamento) includono moduli per l'abuso di servizi. Per esercitazioni controllate, Atomic Red Team (open source) fornisce test riproducibili sotto l'ID T1574.011 con procedure di cleanup, essenziali per non lasciare backdoor persistenti nel lab.

La detection di T1574.011 si fonda sulla correlazione tra modifiche al registro dei servizi e successive esecuzioni anomale. La strategia DET0427 individua come artefatti chiave le modifiche non autorizzate a ImagePath, ServiceDll, FailureCommand e alle sottochiavi Performance e Parameters.

Le fonti primarie sono tre canali di log Windows. Dal WinEventLog:Security, l'EventCode 4657 registra modifiche a valori di registro purché sia attiva l'audit policy sugli oggetti; l'attivazione richiede sia auditpol /set /subcategory:"Registry" /success:enable /failure:enable sia le SACL sulle chiavi target — senza SACL, l'evento non viene generato. L'EventCode 4670 segnala variazioni sui permessi stessi, utile per intercettare tentativi di indebolimento delle ACL prima dell'attacco vero e proprio.

Dal WinEventLog:System, gli eventi 7040 (cambio start type) e 7045 (installazione nuovo servizio) offrono visibilità sui cambi di configurazione dal punto di vista del Service Control Manager, con un livello di rumore accettabile in ambienti stabili.

Il canale più ricco resta WinEventLog:Sysmon (open source). L'Event ID 13 cattura RegistryValue Set con maggiore fedeltà e senza dipendere dalle SACL, purché la configurazione includa regole sui path critici. Una configurazione derivata da SwiftOnSecurity/sysmon-config o Olaf Hartong/sysmon-modular (entrambi open source) copre bene i pattern rilevanti. Gli Event ID 12 (creazione/cancellazione chiave) intercettano la creazione ex-novo di Performance sotto un servizio esistente, indicatore ad alto valore data la rarità legittima dell'operazione.

La correlazione efficace lega tre eventi in una finestra temporale ristretta: modifica registry su chiave di servizio, seguita da Event ID 1 Sysmon che mostra services.exe come parent di un processo il cui path non coincide con la baseline nota. Il tuning richiede una lista di servizi critici con path attesi (BaselineServiceConfig) e una whitelist di account autorizzati a modificarli (PrivilegedAccounts), tipicamente installer MSI, agenti di gestione e SYSTEM stesso durante Windows Update.

I falsi positivi principali derivano da installazioni software legittime che registrano nuovi servizi o aggiornano ImagePath, e da aggiornamenti di agenti EDR/AV che modificano ServiceDll. Correlare l'evento con la presenza contemporanea di msiexec.exe, TrustedInstaller.exe o processi firmati dal vendor riduce drasticamente il rumore. Sul fronte preventivo, la mitigazione M1024 raccomanda hardening delle ACL via icacls, Set-Acl PowerShell e baseline dal Microsoft Security Compliance Toolkit (gratuito) o dai CIS Benchmarks (freemium).

L'analisi forense di un compromesso via T1574.011 ricostruisce la timeline attorno a tre artefatti chiave: la chiave di registro modificata, il binario o DLL sostituiti e il processo figlio generato dal Service Control Manager.

Il punto di partenza è l'hive SYSTEM, estraibile a caldo con reg save HKLM\SYSTEM system.hiv o da immagine disco tramite copia di C:\Windows\System32\config\SYSTEM. L'analisi offline con Registry Explorer di Eric Zimmerman (gratuito) espone le timestamp di ultima modifica delle chiavi sotto ControlSet001\Services, fondamentali per ancorare l'evento sulla timeline. RegRipper (open source) con il plugin services estrae in forma tabellare ImagePath, Start, Type, ServiceDll e FailureCommand di ogni servizio, facilitando il diff con una baseline pulita.

Sono da esaminare in particolare le sottochiavi Parameters di servizi driver — dove il caso AutodialDLL sotto WinSock2 è documentato — e ogni chiave Performance presente sotto un servizio che normalmente non la include. La creazione di Performance è di per sé un indicatore forense forte, perché è raro che software legittimo la aggiunga post-installazione.

Sul filesystem, i binari sostituiti conservano metadata utili. MFTECmd (gratuito) parsa la Master File Table per ricostruire $STANDARD_INFORMATION e $FILE_NAME del payload, mentre le anomalie di timestomping emergono confrontando i due attributi. La cartella di origine — spesso C:\Temp, C:\Users\Public o percorsi ProgramData scrivibili — è essa stessa un indicatore. La verifica della firma Authenticode con Get-AuthenticodeSignature PowerShell distingue binari legittimi da payload non firmati o firmati con certificati sospetti.

La correlazione con i log Sysmon archiviati (Event ID 13 per registry, Event ID 1 per esecuzione, Event ID 7 per image load nel caso DLL hijacking via ServiceDll) permette di legare il momento della modifica al primo caricamento del payload. EvtxECmd (gratuito) converte gli EVTX in formato analizzabile con timeline tools come Timeline Explorer o plaso/log2timeline (open source).

Il caso Operation Honeybee (C0006) fornisce un pattern di riferimento: gli attaccanti hanno usato un batch file per riconfigurare il servizio COMSysApp affinché caricasse ipnet.dll dentro svchost.exe. In un'analisi analoga, cercare batch file recenti in %TEMP%, artefatti Prefetch (C:\Windows\Prefetch*.pf parsati con PECmd gratuito) del batch e delle utility sc.exe o reg.exe eseguite in prossimità temporale della modifica registry è passo dovuto.

Infine, per la ricerca dell'accesso iniziale, le ShimCache e AmCache (parsabili con AmcacheParser gratuito) mostrano eseguibili apparsi sul sistema anche se successivamente rimossi, spesso preziosi per identificare il dropper che ha preceduto la modifica del servizio.

Il panorama documentato in MITRE ATT&CK per T1574.011 include una singola campagna di riferimento, ma il pattern operativo che essa illustra è rappresentativo di una classe più ampia di operazioni di persistenza a basso rumore.

Operation Honeybee (C0006), attiva tra agosto 2017 e febbraio 2018, ha colpito organizzazioni di aiuti umanitari e affari inter-coreani. Il perimetro geografico iniziale era la Corea del Sud, con successiva espansione a Vietnam, Singapore, Giappone, Indonesia, Argentina e Canada — un footprint che riflette interessi di intelligence su diaspora e attori diplomatici legati alla penisola coreana. Gli analisti hanno attribuito l'operazione a threat actor probabilmente di lingua coreana sulla base di metadata nei documenti esca e negli eseguibili, e il nome della campagna deriva dall'author name "Honeybee" ricorrente nei Word malevoli.

Dal punto di vista tecnico, la campagna illustra un uso maturo di T1574.011: gli attaccanti hanno eseguito un batch file che riconfigurava il servizio COMSysApp — un servizio Windows legittimo relativo a COM+ System Application — per caricare una DLL malevola ipnet.dll dentro svchost.exe. La scelta di COMSysApp non è casuale: è un servizio presente su ogni installazione Windows, di norma impostato in modalità manuale, il cui abuso non genera anomalie evidenti in inventari di servizi installati. Il caricamento dentro svchost.exe aggiunge un livello di mascheramento processuale che si allinea perfettamente alla tattica TA0005 Defense Evasion.

A livello di trend, l'abuso delle sottochiavi Services rimane attraente per attori state-sponsored per tre motivi convergenti. Primo, offre persistenza SYSTEM-level senza richiedere driver o boot components, che sono soggetti a controlli integrity più stringenti (Driver Signature Enforcement, HVCI). Secondo, la superficie di configurazione è ampia — ImagePath, ServiceDll, FailureCommand, Parameters, Performance — e ogni sottovettore ha profili di detection diversi, consentendo diversificazione operativa. Terzo, l'esecuzione via SCM produce catene parent-child (services.exe → payload) che si confondono con il traffico legittimo di startup, richiedendo baseline behavioral per essere isolate.

Il vettore Parameters\AutodialDLL di WinSock2, esplicitamente citato nella documentazione della tecnica, merita attenzione dedicata perché sfrutta un meccanismo di autoload della libreria Winsock ereditato dalle prime versioni di Windows e mai deprecato. Threat intelligence teams dovrebbero includere hunting query specifiche su questa chiave nelle rotazioni periodiche, indipendentemente dalla presenza di IOC noti, perché il basso baseline di modifiche legittime lo rende un canale privilegiato per persistenza opportunistica.

Sul fronte difensivo strategico, la mitigazione M1024 — restrizione delle Registry Permissions con audit continuo — resta il controllo cardine, integrato da baseline configuration management per rilevare drift silenziosi.

MITRE ATT&CK T1574.011 Services Registry Permissions Weakness; tattiche TA0003, TA0004, TA0005; campagna C0006 Operation Honeybee; mitigazione M1024 Restrict Registry Permissions; detection strategy DET0427 con analytic AN1195. MITRE D3FEND per mapping difensivo su Service Registry Permissions. Tool di detection e analisi citati: Sysmon, AccessChk, PowerUp, Registry Explorer, RegRipper, MFTECmd, EvtxECmd, AmcacheParser, Atomic Red Team. Alcuni dettagli su sintassi comandi e artefatti forensi derivano da conoscenza professionale di cybersecurity verificabile su documentazione ufficiale dei rispettivi tool.