Iscriviti al webinar gratuito del 12 Maggio per diventare Forensic Analyst! Scopri di più
Corso Ethical Hacker: accedi alla promozione fino al 30 Aprile! Scopri di più
La creazione di un account locale è una delle tecniche di persistenza più dirette e universali a disposizione di un attaccante. Inserita nella tattica Persistence (TA0003), consente all'avversario di mantenere un punto d'appoggio stabile nel sistema compromesso, sopravvivendo a riavvii, rotazione delle credenziali e rimozione degli strumenti di accesso remoto.
Il principio è semplice: anziché dipendere da backdoor o impianti residenti in memoria, l'attaccante si crea un'identità legittima all'interno del sistema operativo. Un account locale con privilegi amministrativi offre accesso permanente senza generare il rumore tipico di un RAT attivo. La tecnica è trasversale: funziona su Windows con net user /add, su Linux con useradd, su macOS con dscl -create, su appliance di rete tramite comandi CLI, su hypervisor ESXi con esxcli system account add e persino in ambienti containerizzati Kubernetes via kubectl.
I numeri confermano la popolarità della tecnica: 14 gruppi APT documentati la impiegano, 15 software la implementano, e 2 mitigazioni specifiche sono raccomandate. Si tratta di una tecnica a bassa complessità ma ad alto impatto, perché un account creato con cura — nome plausibile, privilegi adeguati — può mimetizzarsi nell'ambiente per settimane prima che qualcuno lo noti.
Replicare T1136.001 in laboratorio è un esercizio fondamentale per validare i controlli di detection del cliente. L'obiettivo è verificare che la catena di monitoraggio — dal log di creazione all'alert nel SIEM — funzioni end-to-end su ogni piattaforma presente nell'ambiente.
Windows è il punto di partenza naturale. Il comando classico crea un utente e lo aggiunge al gruppo Administrators in due passaggi:
net user support_test P@ssw0rd123! /add net localgroup Administrators support_test /add
Variare il vettore è fondamentale: ripetere l'operazione tramite PowerShell con New-LocalUser consente di testare se il SOC rileva entrambi i percorsi. Un test più avanzato utilizza WMI per la creazione, perché alcuni ambienti monitorano solo i processi figli di cmd.exe e powershell.exe:
Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{CommandLine="net user shadow_adm Str0ng!Pass /add"}
Atomic Red Team (open source) automatizza questi scenari con il test T1136.001, eseguibile direttamente tramite il modulo PowerShell Invoke-AtomicTest. Questo approccio garantisce ripetibilità e documentazione dell'esecuzione.
Su Linux, il test base prevede la creazione di un utente privilegiato e l'assegnazione diretta alla wheel o sudo group:
sudo useradd -m -s /bin/bash -G sudo testpersist
Per simulare tattiche più evasive, si può scrivere direttamente in /etc/passwd senza usare useradd, una tecnica osservata in diversi malware reali. Questo testa se il SOC monitora le modifiche ai file di sistema oltre all'esecuzione dei binari.
Su macOS, la creazione via Directory Services CLI è la strada nativa:
dscl . -create /Users/backdoor_user dscl . -create /Users/backdoor_user UserShell /bin/zsh dscl . -create /Users/backdoor_user UniqueID 599
Per ESXi, in un lab con hypervisor di test:
esxcli system account add -i threat_actor -p ComplexPass1! -c ComplexPass1! -d "Test account"
In ambienti Kubernetes, la simulazione prevede la creazione di un ServiceAccount e il binding a un ClusterRole privilegiato tramite kubectl create serviceaccount seguito da un kubectl create clusterrolebinding. Questo scenario testa la visibilità del SOC sulle API audit log del cluster.
Per ogni test, documentare timestamp di esecuzione, utente operatore e piattaforma. Confrontare poi con il SOC: l'alert è scattato? In quanto tempo? Ha catturato la variante WMI quanto quella net user? Le risposte definiscono le lacune reali.
Scarica la guida gratuita e segui il percorso corretto fin dal primo passo