Abuso di Sudo e Sudo Caching: Sudo and Sudo Caching (T1548.003)

In un esercizio red team, l'abuso di sudo caching richiede due precondizioni: accesso a un account utente che compaia in /etc/sudoers e una sessione tty in cui quell'utente abbia già autenticato sudo di recente. La prima verifica è banale: sudo -n -l elenca i permessi senza prompt e restituisce errore se non c'è cache attiva.

Per scoprire una finestra di caching aperta, ispeziona i file di timestamp. Su distribuzioni moderne il percorso è /var/run/sudo/ts/<username>; su macOS storicamente /var/db/sudo. Se il file esiste e il suo mtime rientra nel timestamp_timeout (default 5 minuti), un comando sudo -n whoami eseguito dallo stesso tty restituirà root senza chiedere password.

Per identificare configurazioni sfruttabili, cerca regole permissive:

grep -E 'NOPASSWD|!tty_tickets' /etc/sudoers /etc/sudoers.d/* 2>/dev/null

Una regola user ALL=(ALL) NOPASSWD: /usr/bin/find è un classico vettore: l'utility find consente esecuzione arbitraria tramite -exec, quindi sudo find /etc -exec /bin/sh ; -quit apre una root shell. Il database GTFOBins (open source) documenta centinaia di binari sfruttabili in configurazioni sudo permissive ed è la reference standard per questa fase.

Per l'enumerazione automatica in laboratorio, gli strumenti canonici sono LinPEAS (open source) e linux-smart-enumeration (open source), entrambi disponibili su GitHub. Eseguiti come utente non privilegiato, evidenziano regole sudoers sfruttabili, file di timestamp attivi e binari SUID correlati. pspy (open source) permette di osservare processi lanciati da altri utenti senza privilegi, utile per intercettare quando un admin esegue sudo e sfruttare la finestra di caching.

Su macOS, la manipolazione di tty_tickets richiede già privilegi root (il file /etc/sudoers è protetto), quindi rappresenta più una tecnica di persistenza post-escalation che un vettore iniziale. Un comando tipico osservato in malware come Proton è:

echo 'Defaults !tty_tickets' >> /etc/sudoers

seguito da killall Terminal per forzare l'applicazione della modifica alle sessioni attive.

Per testare in ambiente controllato la finestra di caching, uno script bash che monitora /var/run/sudo/ts/ con inotifywait (pacchetto inotify-tools, open source) permette di reagire istantaneamente quando un utente autentica sudo. In un engagement autorizzato, questa tecnica dimostra al cliente quanto sia rischioso lasciare timestamp_timeout sui valori default su workstation di amministratori.

La detection di T1548.003 si basa su tre pilastri: monitoraggio delle modifiche a /etc/sudoers e alla directory /etc/sudoers.d/, correlazione tra chiamate sudo ed effettiva elevazione del contesto utente, osservazione di pattern anomali di uso della cache.

Su Linux, la sorgente primaria è auditd. Una regola dedicata al monitoraggio dei file sudoers è essenziale:

-w /etc/sudoers -p wa -k sudoers_change -w /etc/sudoers.d/ -p wa -k sudoers_change

Ogni evento generato su questa chiave deve produrre alert ad alta priorità, correlato con l'utente che ha eseguito la modifica e il processo padre. Regole legittime prevedono modifiche solo tramite visudo da parte di account amministrativi in finestre di change management approvate; qualsiasi altra scrittura è sospetta. La detection MITRE AN0142 suggerisce inoltre di correlare esecuzioni sudo con euid=0 risultante, filtrando comandi appartenenti a un'allowlist di script amministrativi noti.

Per intercettare la disabilitazione di tty_tickets o l'inserimento di regole NOPASSWD, una regola auditd sui syscall write, combinata con analisi del contenuto del file post-modifica (via file integrity monitoring), è efficace. Strumenti come Wazuh (open source), auditbeat di Elastic (open source) o osquery (open source) espongono la tabella sudoers interrogabile per verificare la presenza di direttive pericolose:

SELECT * FROM sudoers WHERE rule_details LIKE '%NOPASSWD%';

Su macOS, la fonte è Unified Log. La detection AN0143 raccomanda di monitorare modifiche a /etc/sudoers seguite a breve distanza da restart di processi Terminal, pattern classico osservato in Dok e Proton. Un predicato utile è:

log stream --predicate 'process == "sudo" OR eventMessage CONTAINS "sudoers"'

Per la detection comportamentale, i falsi positivi principali derivano da tool di configuration management (Ansible, Puppet, Chef) che modificano legittimamente sudoers. La strategia di tuning corretta è mantenere una allowlist di account di servizio e di finestre temporali di deploy, alertando su tutto il resto. Un secondo falso positivo tipico è l'uso di sudo da parte di admin durante troubleshooting: la correlazione con il ticket ITSM attivo per quell'host aiuta a discriminare.

Un indicatore ad alto valore è l'esecuzione di sudo -n (modalità non-interactive) da processi non-shell: uno script Python o un binario ELF non firmato che invoca sudo -n sta quasi certamente tentando di sfruttare una cache aperta. La telemetria EDR con visibilità sui processi figli di sudo è il complemento naturale ai log auditd.

L'analisi forense di un abuso di sudo caching parte dalla ricostruzione temporale dell'uso del meccanismo. Su Linux moderno, i file di timestamp risiedono in /var/run/sudo/ts/ (una directory per utente); su sistemi più vecchi e su macOS legacy in /var/db/sudo. Il mtime di questi file indica l'ultimo sudo autenticato con successo. In un'immagine forense, questi timestamp vanno correlati con la timeline generata da plaso/log2timeline (open source) per identificare finestre in cui la cache era attiva.

La fonte principale di evidenze è il log di sudo stesso, tipicamente /var/log/auth.log su Debian/Ubuntu o /var/log/secure su RHEL/CentOS. Ogni invocazione produce righe del tipo sudo: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/bash, con timestamp preciso. Righe con authentication failure seguite immediatamente da esecuzioni riuscite senza prompt indicano riuso di cache. Righe che citano modifiche a /etc/sudoers (evento sudo: user : session opened for user root seguito da editor) meritano attenzione particolare.

Il file /etc/sudoers stesso è un artefatto critico. Va estratto dall'immagine e confrontato con una baseline nota. La presenza di direttive NOPASSWD, !tty_tickets o inclusioni tramite #includedir /etc/sudoers.d di file sospetti sono indicatori diretti di compromissione. I file in /etc/sudoers.d/ vanno enumerati singolarmente: Dok e famiglie simili tendono a droppare file con nomi innocui in questa directory piuttosto che modificare il sudoers principale, per ridurre visibilità.

Su Linux con auditd configurato, il log /var/log/audit/audit.log fornisce granularità a livello di syscall. Query con ausearch permettono di filtrare eventi rilevanti:

ausearch -k sudoers_change ausearch -c sudo -ts recent

Su macOS, l'Unified Log si estrae con log collect e si analizza con log show --predicate 'subsystem == "com.apple.sudo"'. Il database SQLite dell'Unified Log conserva eventi per periodi variabili (tipicamente giorni o poche settimane), quindi la raccolta va effettuata rapidamente.

La timeline di attacco tipica mostra: (1) initial access con esecuzione di codice come utente standard; (2) enumerazione delle regole sudoers; (3) modifica di /etc/sudoers o attesa di finestra di caching; (4) esecuzione di comandi privilegiati; (5) opzionalmente, restart di Terminal su macOS o kill di sessioni shell su Linux per applicare modifiche a tty_tickets. Correlare il mtime di sudoers con l'esecuzione di editor (vim, nano, sed) e con comandi shell privilegiati successivi permette di ricostruire la sequenza completa. La bash history dell'utente compromesso (~/.bash_history) e dell'account root (/root/.bash_history), quando non cancellata, chiude il cerchio dell'attribuzione operativa.

I dati MITRE per T1548.003 non associano gruppi APT specifici, ma censiscono tre famiglie malware che documentano bene lo spettro d'uso della tecnica: uno strumento offensive commerciale ampiamente abusato e due famiglie native macOS con finalità distinte.

Cobalt Strike (S0154) è il framework commerciale di adversary emulation più diffuso, ampiamente ri-utilizzato da threat actor di ogni livello, da ransomware operator a gruppi state-sponsored. Nel contesto di T1548.003, Cobalt Strike documenta la capacità di invocare sudo per eseguire comandi con privilegi elevati durante operazioni post-exploitation su target Unix-like. Il fatto che questa capacità sia integrata nel toolkit standard indica che la tecnica è considerata affidabile e a bassa detection in ambienti non hardenati.

Proton (S0279) è un backdoor macOS distribuito storicamente tramite trojanizzazione di software legittimo (celebri i casi di HandBrake e di Elmedia Player). Modifica la direttiva tty_tickets nel file sudoers per rendere più semplice l'esecuzione scriptata di comandi privilegiati attraverso sessioni terminale multiple. Il pattern operativo di Proton indica priorità sulla persistenza operativa: una volta ottenuto root, la modifica di sudoers garantisce accesso ripetuto senza friction.

Dok (S0281) è un altro malware macOS, orientato al furto di credenziali bancarie tramite man-in-the-middle su traffico TLS. Dok aggiunge la riga admin ALL=(ALL) NOPASSWD: ALL al file /etc/sudoers, garantendosi capacità di eseguire qualsiasi comando come root senza interazione utente. Questo pattern è particolarmente rumoroso da un punto di vista di detection ma estremamente efficace su target che non monitorano modifiche a sudoers.

Il pattern comune ai tre software è l'uso di sudo non come vettore iniziale di privilege escalation, ma come meccanismo di consolidamento dell'accesso privilegiato una volta ottenuto root con altri mezzi. Questo suggerisce che la tecnica sia particolarmente valorizzata nella fase di persistenza operativa.

Da un punto di vista di trend, la prevalenza di due famiglie macOS su tre indica che T1548.003 è stata storicamente più abusata su ecosistema Apple che su Linux server-side, probabilmente perché workstation macOS di sviluppatori e amministratori tendono ad avere configurazioni sudo permissive per convenience, mentre server Linux enterprise seguono più spesso baseline CIS con timestamp_timeout=0. In ambienti cloud moderni con orchestrazione container, la tecnica perde rilevanza sui workload effimeri ma resta critica sui bastion host e sulle jump box. L'adozione di soluzioni PAM enterprise (CyberArk, BeyondTrust) e di modelli just-in-time access (Azure PIM) riduce ulteriormente la superficie d'attacco eliminando le sessioni sudo persistenti.

MITRE ATT&CK T1548.003 (Sudo and Sudo Caching), tattiche TA0004 e TA0005. Software: S0154 Cobalt Strike, S0279 Proton, S0281 Dok. Mitigazioni M1022, M1026, M1028. Detection strategy DET0052 con analytics AN0142 (Linux/auditd) e AN0143 (macOS/unifiedlog). Le sezioni tecniche integrano conoscenza professionale di cybersecurity per comandi, tool (LinPEAS, GTFOBins, Wazuh, osquery, auditd, plaso) e procedure operative, tutti verificabili tramite documentazione ufficiale e repository pubblici.