Abuso di Servizi di Sistema: System Services (T1569)

Su Windows il punto di partenza in un ingaggio red team è il Service Control Manager. La creazione di un servizio con binario controllato dall'attaccante avviene con la sintassi nativa sc.exe create binPath= "C:\path\payload.exe" start= auto seguita da sc.exe start . Attenzione allo spazio dopo l'uguale: è richiesto dal parser. In alternativa, il cmdlet PowerShell New-Service consente la stessa operazione con maggior flessibilità sui parametri. Per esecuzione remota il tool di riferimento resta PsExec (gratuito, suite Sysinternals di Microsoft), che installa un servizio temporaneo PSEXESVC sul target: psexec \\target -s cmd.exe apre una shell come SYSTEM. Equivalenti open source ampiamente usati in laboratorio sono Impacket (open source), in particolare psexec.py, smbexec.py e services.py, che replicano il pattern senza binario nativo installato.

Per scenari più stealth, SharpNoPSExec e moduli come Invoke-ServiceAbuse di PowerSploit (open source) manipolano servizi esistenti mal configurati: se un servizio ha ACL deboli, si può riscrivere il ImagePath e riavviarlo per ottenere esecuzione privilegiata senza crearne uno nuovo. Il tool AccessChk (gratuito, Sysinternals) è utile per enumerare servizi vulnerabili: accesschk.exe -uwcqv "Authenticated Users" * elenca i servizi scrivibili dagli utenti autenticati.

Su Linux la creazione di un unit file in /etc/systemd/system/backdoor.service con direttiva ExecStart seguita da systemctl daemon-reload && systemctl enable --now backdoor.service fornisce esecuzione e persistenza. Per ambienti privi di systemd si ricade su script in /etc/init.d/ o cron. In post-exploitation, framework come Metasploit (open source) e Sliver (open source) automatizzano queste operazioni tramite moduli dedicati.

Su macOS il pattern è la scrittura di un file .plist in /Library/LaunchDaemons/ (root) o ~/Library/LaunchAgents/ (utente), seguito da launchctl load . Il framework Mythic (open source) con l'agent Apfell copre questo scenario.

In ambienti ESXi, che espongono servizi tramite esxcli, si osserva l'abuso di script custom registrati come servizi persistenti sull'hypervisor. In laboratorio, ogni catena va testata con Sysmon attivo e telemetria centralizzata, così da validare anche la detection lato blue team nello stesso esercizio.

La strategia di detection DET0279 articola tre analitiche complementari, una per piattaforma, tutte incentrate sulla correlazione tra creazione/modifica di servizi e processi anomali.

Su Windows (AN0778) le fonti primarie sono WinEventLog:Security e WinEventLog:Sysmon. L'evento chiave del canale System è EventCode 7045 (installazione di un nuovo servizio), da correlare con EventCode 4697 nel Security log quando l'auditing avanzato è attivo. Su Sysmon, Event ID 1 (process create) evidenzia esecuzioni di services.exe con figli anomali, mentre Event ID 13 traccia modifiche alle chiavi HKLM\SYSTEM\CurrentControlSet\Services\\ImagePath. Una regola efficace correla creazione di servizio, ImagePath che punta a directory scrivibili dall'utente (C:\Users, C:\ProgramData, %TEMP%) e successiva esecuzione entro una finestra breve. Per PsExec, il pattern è EventCode 7045 con nome servizio PSEXESVC e binario in ADMIN$. I falsi positivi principali arrivano da software di gestione (SCCM, agenti EDR stessi, installer MSI): una allowlist di servizi noti e dei loro hash è indispensabile, come suggerito dai tuning parameters ServiceAllowlist e TimeWindow.

Su Linux (AN0779) le fonti sono auditd:SYSCALL e linux:syslog. Regole auditd mirate su execve di systemctl, service e systemd-run forniscono la base; l'aggiunta di watch su /etc/systemd/system/, /lib/systemd/system/ e /etc/init.d/ rileva la scrittura di unit file. Un pattern sospetto è l'esecuzione di systemctl daemon-reload seguita da systemctl enable da parte di account non amministrativi o da shell interattive lanciate da servizi web (www-data, nginx). I parametri di tuning ServiceBinaryPaths e UserContext filtrano rispettivamente i percorsi legittimi e gli account attesi.

Su macOS (AN0780) il unified log è la fonte di riferimento, interrogabile con log show --predicate 'subsystem == "com.apple.xpc.launchd"'. La detection si concentra su creazione o modifica di file .plist in /Library/LaunchDaemons/, /Library/LaunchAgents/ e nelle equivalenti user-level, correlate con launchctl load. L'entropia del binario referenziato nel ProgramArguments aiuta a isolare payload offuscati (parametro PayloadEntropyThreshold).

Sul fronte preventivo, in linea con M1040, le regole Attack Surface Reduction di Windows Defender bloccano processi creati da PsExec; M1026 e M1018 impongono la separazione dei privilegi che rende non replicabili molte di queste catene; M1022 protegge i binari dei servizi ad alto privilegio da sovrascrittura. Strumenti EDR come Microsoft Defender for Endpoint, CrowdStrike Falcon e SentinelOne (tutti a pagamento) implementano nativamente queste analitiche, mentre Wazuh (open source) offre copertura equivalente su Linux e Windows con regole custom.

L'analisi forense di T1569 poggia su artefatti che sopravvivono al riavvio e si prestano a ricostruzioni timeline precise.

Su Windows la fonte primaria è il registro: la chiave HKLM\SYSTEM\CurrentControlSet\Services\ contiene i valori ImagePath, ServiceDll, Start, Type e ObjectName. Il timestamp LastWrite della chiave, estraibile con RegRipper (open source) o Registry Explorer di Eric Zimmerman (gratuito), fissa il momento di creazione o modifica. I file hive rilevanti sono SYSTEM in C:\Windows\System32\config\. In parallelo, il log System.evtx conserva EventCode 7045 con nome servizio, binario, tipo e account; EventCode 7034/7036 documentano start/stop successivi. Il Security.evtx fornisce EventCode 4697 quando abilitato e EventCode 4688 per la creazione del processo services.exe con figli. Artefatti di esecuzione come Prefetch (C:\Windows\Prefetch\, analizzabili con PECmd, gratuito) e Amcache (C:\Windows\AppCompat\Programs\Amcache.hve) confermano l'esecuzione del binario referenziato. Per PsExec, la presenza di PSEXESVC.exe in C:\Windows\ e la sua traccia in Prefetch sono indicatori diretti; sul lato client attaccante, la chiave HKCU\Software\Sysinternals\PsExec\EulaAccepted rivela l'uso storico del tool.

Su Linux i unit file in /etc/systemd/system/ e /lib/systemd/system/ sono l'artefatto centrale; i metadati inode (stat ) forniscono ctime e mtime. Il journal di systemd (journalctl -u ) conserva start, stop, exit code e output; l'audit trail (/var/log/audit/audit.log) documenta le syscall execve correlate. Per servizi legacy, gli script in /etc/init.d/ e i link in /etc/rc.d/* mostrano l'attivazione ai runlevel. La timeline si costruisce con Plaso/log2timeline (open source), che aggrega filesystem, journal e audit in un supertimeline navigabile con Timesketch (open source).

Su macOS i property list in /Library/LaunchDaemons/, /Library/LaunchAgents/, /System/Library/LaunchDaemons/ e nelle equivalenti user-level sono l'artefatto primario. Vanno esaminati con plutil -p per estrarre Label, ProgramArguments e RunAtLoad. Il unified log conserva le operazioni launchd per diversi giorni; l'estrazione avviene con log collect e l'analisi con Console.app o strumenti come macos-unifiedlogs (open source, Mandiant). Il framework KAPE (gratuito per uso non commerciale) automatizza la raccolta selettiva di questi artefatti su Windows, mentre UAC (Unix-like Artifacts Collector, open source) copre Linux e macOS.

La ricostruzione della catena richiede di correlare quando il servizio è stato creato (registry LastWrite o mtime del plist/unit), da chi (account nell'evento o UID del file), cosa ha eseguito (Prefetch/Amcache/journal) e quali connessioni di rete sono seguite (log firewall, Sysmon Event 3, netflow).

I dati MITRE forniti per T1569 non elencano gruppi APT, software o campagne specificamente attribuiti alla tecnica base. Questa assenza va letta correttamente: T1569 è una tecnica padre che raccoglie sotto di sé sotto-tecniche altamente popolate (in particolare l'abuso di Service Execution e Launchctl), dove risiedono le attribuzioni puntuali. Il ricorso a servizi di sistema per esecuzione è di fatto un comportamento trasversale all'intero panorama offensivo, adottato da attori statuali, gruppi cybercriminali e operatori ransomware con motivazioni e modalità differenti.

Sul piano dei pattern operativi osservabili nella prassi documentata dal framework, l'abuso di servizi ricorre in tre contesti tipici. Il primo è il movimento laterale amministrativo, dove il servizio remoto è il veicolo per eseguire codice su macchine adiacenti dopo aver ottenuto credenziali privilegiate: qui il pattern PsExec-like domina, ed è replicato da innumerevoli framework offensivi e loader ransomware. Il secondo è l'esecuzione privilegiata one-shot, in cui il servizio viene creato, eseguito e rimosso in pochi secondi per lanciare un payload come SYSTEM aggirando controlli utente. Il terzo è la persistenza mascherata da servizio legittimo, con naming che imita componenti Microsoft o vendor noti (WindowsUpdate, NvidiaService, IntelHelper).

A livello di priorità difensiva, la tecnica va considerata ad alto impatto per due ragioni. Prima ragione: l'esecuzione avviene con privilegi che scavalcano la maggior parte dei controlli endpoint pensati per contesti utente. Seconda ragione: il rumore amministrativo legittimo (installer, aggiornamenti, agenti di gestione) rende difficile distinguere l'abuso senza baseline mature. Le organizzazioni con inventario software instabile o parco applicativo eterogeneo hanno una superficie di detection significativamente più difficile da mantenere pulita.

Sul fronte trend, l'evoluzione recente mostra due direzioni. Da un lato, gli operatori più sofisticati stanno abbandonando pattern rumorosi come PsExec nativo a favore di implementazioni custom via Impacket o binari proprietari che riducono l'artefatto PSEXESVC. Dall'altro, l'estensione dell'attacco a piattaforme ESXi e a hypervisor in generale ha portato all'abuso di servizi dell'hypervisor stesso per persistenza a livello infrastrutturale, con impatto amplificato dalla criticità dei sistemi coinvolti.

Per un threat intelligence officer, il monitoraggio di T1569 in ambiente proprietario è più produttivo se combinato con l'analisi delle sotto-tecniche popolate (T1569.001 Launchctl, T1569.002 Service Execution) e correlato con la telemetria di Lateral Movement e Privilege Escalation, dove tipicamente questa esecuzione si innesta come snodo intermedio della kill chain.

MITRE ATT&CK: T1569 (System Services), tattica TA0002. Mitigazioni citate: M1018, M1022, M1026, M1040. Detection strategy DET0279 con analitiche AN0778 (Windows), AN0779 (Linux), AN0780 (macOS). MITRE D3FEND per mapping difensivo su Service Binary e Process. Per comandi, tool e artefatti forensi è stata integrata conoscenza professionale di cybersecurity relativa a strumenti reali e verificabili (Sysinternals, Impacket, PowerSploit, RegRipper, Plaso, KAPE, Wazuh, framework EDR commerciali).