Account Fantasma: Hidden Users (T1564.002)

Nascondere un account utente all'interno di un sistema operativo è una delle mosse più sottili nel repertorio di un attaccante. La tecnica Hidden Users consente di creare o modificare account in modo che risultino invisibili nelle schermate di login, nei pannelli di gestione e — se l'operazione è ben eseguita — anche ai comandi di enumerazione più comuni. Si inserisce nella tattica Defense Evasion (TA0005), quella fase della kill chain in cui l'avversario non sta cercando di entrare o di muoversi lateralmente, ma di restare invisibile il più a lungo possibile.

Il meccanismo varia per sistema operativo, ma il principio è universale: ogni OS mantiene una lista di account "visibili" separata da quella degli account effettivamente esistenti, e manipolare questa distinzione è spesso questione di una chiave di registro, un attributo plist o un flag del display manager. Su Windows basta un valore a 0 nel ramo SpecialAccounts\UserList del registro. Su macOS si interviene sul database utenti con dscl e sul file com.apple.loginwindow. Su Linux si agisce sulla configurazione del greeter, ad esempio GDM o LightDM.

I dati MITRE documentano 2 gruppi APT e 1 malware che sfruttano questa tecnica, con una mitigazione specifica basata sulla configurazione hardened del sistema operativo. Numeri contenuti, ma l'impatto è insidioso: un account nascosto può sopravvivere a una prima risposta all'incidente, perché gli analisti tendono a fidarsi di ciò che il sistema mostra nell'interfaccia grafica.

La simulazione di questa tecnica in laboratorio è particolarmente istruttiva perché tocca tre sistemi operativi con approcci distinti. Conviene partire da Windows, dove il vettore è il più documentato nelle campagne reali.

Windows — Registry SpecialAccounts

Dopo aver creato un account locale con privilegi, il passo successivo è nasconderlo dalla schermata di logon. La sequenza parte dalla creazione dell'utente e termina con la manipolazione del registro:

net user ghostadmin P@ssw0rd123! /add

net localgroup Administrators ghostadmin /add

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" /v ghostadmin /t REG_DWORD /d 0 /f

L'ultimo comando è esattamente ciò che Kimsuky utilizza nelle proprie operazioni. Il valore 0 associato al nome utente lo rimuove dalla UI di login e dal pannello Account nelle Impostazioni, ma l'account resta perfettamente funzionale per sessioni RDP, runas o autenticazione di rete. Per verificare che l'occultamento funzioni, basta controllare il pannello Utenti: l'account non apparirà. Tuttavia, net user da riga di comando continuerà a elencarlo — dettaglio fondamentale per il detection.

macOS — dscl e chflags

Su macOS l'approccio è più articolato. L'attaccante crea l'utente con un UID inferiore a 500 e imposta l'attributo IsHidden:

sudo dscl . -create /Users/ghostadmin UniqueID 499

sudo dscl . -create /Users/ghostadmin IsHidden 1

Per completare l'occultamento, la home directory viene marcata come nascosta:

sudo chflags hidden /Users/ghostadmin

Il tocco finale è abilitare la chiave Hide500Users nel plist di loginwindow:

sudo defaults write /Library/Preferences/com.apple.loginwindow Hide500Users -bool TRUE

Questa combinazione rende l'account invisibile sia nella schermata di login sia nelle Preferenze di Sistema.

Linux — Display Manager greeter

Su distribuzioni con GDM, il comando è diretto:

sudo -u gdm gsettings set org.gnome.login-screen disable-user-list true

Questo nasconde tutti gli utenti dal greeter, il che lo rende meno chirurgico ma ugualmente efficace se l'attaccante vuole evitare che il proprio account compaia. Per un approccio più mirato su LightDM, si interviene sul file di configurazione aggiungendo l'account alla direttiva hidden-users in lightdm-greeter.conf.

Come framework di automazione per l'intera catena, Atomic Red Team (open source) fornisce test atomici specifici per T1564.002 su tutte e tre le piattaforme, utili per validare i detection rule prima di un engagement reale.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo

La detection degli account nascosti ha un vantaggio raro nel mondo SOC: i punti di manipolazione sono pochi e ben definiti, il che rende possibile costruire regole ad alta fedeltà con un tasso di falsi positivi gestibile.

Windows — Il registro è il campo di battaglia

La log source primaria è il canale Sysmon, in particolare EventID 13 (Registry Value Set). L'alert deve scattare quando il percorso del registro contiene SpecialAccounts\UserList e il valore impostato è 0. In parallelo, il log Security di Windows genera EventID 4720 alla creazione di un nuovo account locale. La correlazione tra un 4720 e un successivo evento di modifica registro su quel percorso entro una finestra temporale ristretta — diciamo 5 minuti — produce un segnale ad altissima confidenza.

Per il tuning, è essenziale costruire una whitelist degli account legittimamente nascosti dagli amministratori. Alcuni software di gestione endpoint o account di servizio vengono nascosti intenzionalmente: questi vanno censiti e inseriti come esclusione. Il consiglio è partire in modalità audit per una settimana, raccogliere i nomi account che attivano la regola e filtrare quelli autorizzati.

Linux — auditd come sentinella

Su sistemi Linux, il controllo passa per auditd. I record EXECVE catturano l'esecuzione di gsettings con argomenti che referenziano org.gnome.login-screen. Una regola auditd ben costruita monitora anche le modifiche ai file di configurazione dei display manager — ad esempio sotto /etc/lightdm/ — tramite record FILE (watch su path).

-w /etc/lightdm/ -p wa -k hidden_user_greeter

Questa regola auditd crea un alert ogni volta che un file nella directory LightDM viene scritto o i suoi attributi cambiano. Il tuning qui richiede di specificare quali display manager sono in uso nell'ambiente: monitorare GDM su un sistema che usa solo LightDM genera solo rumore.

macOS — Unified Log e plist

Su macOS, lo Unified Log è la fonte principale. Le invocazioni di dscl con parametri IsHidden o la modifica del plist com.apple.loginwindow generano eventi catturabili. Tool come osquery (open source) permettono query periodiche sullo stato degli account, verificando la presenza di UID sotto soglia 500 abbinati ad attributi IsHidden:

SELECT * FROM users WHERE uid < 500 AND uid > 0;

La soglia UID va calibrata sull'ambiente: macOS riserva gli UID sotto 500 ad account di sistema, quindi qualsiasi account "umano" con UID in quel range è sospetto per definizione. La riduzione dei falsi positivi si ottiene escludendo gli UID noti del sistema operativo (tipicamente sotto 200).

Vuoi diventare SOC Analyst ma non sai da dove iniziare?

Scarica la guida gratuita e scopri come si monitorano e bloccano gli attacchi informatici

L'analisi forense degli account nascosti beneficia di un fatto strutturale: l'occultamento modifica artefatti persistenti che sopravvivono al riavvio e spesso anche ai tentativi di pulizia da parte dell'attaccante.

Windows — SAM, registro e timeline

Il punto di partenza è il file SAM (Security Account Manager). Anche se l'account non appare nella UI, la sua entry nel database SAM è intatta e ispezionabile offline con tool come RegRipper (open source). L'analista deve estrarre l'hive SAM e confrontare la lista utenti con quanto visibile nel sistema.

Il secondo artefatto chiave è l'hive di registro SOFTWARE, dove il percorso Winlogon\SpecialAccounts\UserList conserva il valore 0 per ogni account nascosto. La timestamp della chiave (LastWriteTime) fornisce il momento esatto dell'occultamento. Incrociando questa data con il EventID 4720 nei log Security — se disponibili — si ottiene una sequenza precisa: creazione account → occultamento → primo utilizzo.

La cartella del profilo utente sotto C:\Users\ rappresenta un terzo pilastro: anche se nascosta dall'interfaccia, la directory esiste fisicamente. I timestamp MACB (Modified, Accessed, Changed, Born) della cartella profilo e dei file NTUSER.DAT e UsrClass.dat al suo interno permettono di ricostruire quando l'account è stato usato attivamente. MFTECmd (open source, parte della suite di Eric Zimmerman) consente di analizzare la Master File Table per identificare la data di creazione della cartella profilo anche se i timestamp del filesystem sono stati alterati.

macOS — plist e database utenti

Su macOS, il file /Library/Preferences/com.apple.loginwindow.plist conserva la chiave Hide500Users. L'analista deve estrarlo e verificarne il contenuto con il comando plutil -p nativo. Il database utenti locale — gestito da Open Directory sotto /var/db/dslocal/nodes/Default/users/ — contiene un file plist per ogni account, dove gli attributi IsHidden, UniqueID e la data di creazione sono direttamente leggibili.

L'attributo hidden della home directory, impostato con chflags, è visibile ispezionando i flag del filesystem con ls -lO /Users/. Una home con flag hidden abbinata a un UID sotto 500 è un indicatore forense forte.

Linux — File di configurazione e log

Su Linux, gli artefatti sono più frammentati. Il file /etc/passwd elenca comunque l'account — l'occultamento agisce solo sul greeter, non sul database utenti. Il confronto tra /etc/passwd e la lista visibile nel display manager rivela la discrepanza. I log di auditd, se abilitati, conservano la traccia delle esecuzioni gsettings con i relativi timestamp. I file di configurazione modificati sotto /etc/gdm3/ o /etc/lightdm/ mantengono la loro data di modifica, utile per ancorare l'evento nella timeline complessiva dell'incidente.

Vuoi diventare Forensic Analyst ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto per analizzare incidenti e prove digitali

La tecnica degli account nascosti è utilizzata da due gruppi con profili operativi molto diversi, il che la rende un punto di osservazione interessante per comprendere come attori con obiettivi differenti convergano su tattiche simili di persistenza discreta.

Dragonfly (G0035)

Dragonfly è un gruppo associato a operazioni contro infrastrutture critiche, in particolare nel settore energetico. L'utilizzo di account nascosti tramite modifica del registro Windows si inserisce in un modus operandi orientato alla persistenza a lungo termine in ambienti OT/ICS, dove la scoperta di un account anomalo potrebbe richiedere mesi data la scarsa frequenza di audit in questi contesti. La manipolazione del registro per nascondere utenti è coerente con un approccio "low and slow": l'obiettivo non è l'esfiltrazione rapida ma il mantenimento di un punto d'appoggio stabile.

Kimsuky (G0094)

Kimsuky impiega la stessa tecnica con un comando specifico e documentato — reg add sul percorso SpecialAccounts\UserList — ma in un contesto operativo diverso, tipicamente legato a campagne di spionaggio. La scelta di nascondere account creati ex novo suggerisce che il gruppo utilizza credenziali locali come fallback nel caso in cui i meccanismi di persistenza primari (backdoor, RAT) vengano neutralizzati. È un pattern di ridondanza operativa che indica maturità nel playbook post-compromissione.

SMOKEDHAM (S0649)

Il malware SMOKEDHAM automatizza la stessa manipolazione del registro, il che suggerisce che questa tecnica è sufficientemente affidabile da essere incorporata in tool automatizzati piuttosto che eseguita manualmente dall'operatore. Quando un artefatto T1564.002 emerge in un'indagine, la presenza di SMOKEDHAM nel medesimo ambiente è un'ipotesi da validare immediatamente attraverso i relativi IoC.

Pattern convergenti e implicazioni

Il dato più rilevante per l'analista TI è che entrambi i gruppi e il malware operano esclusivamente su Windows, sfruttando lo stesso identico percorso di registro. Questo crea un'opportunità di detection unificata: una singola regola sul percorso SpecialAccounts\UserList copre sia le operazioni manuali di Dragonfly e Kimsuky sia l'automazione di SMOKEDHAM. Dal punto di vista predittivo, la presenza di un account nascosto in un ambiente energetico dovrebbe elevare immediatamente l'ipotesi Dragonfly, mentre in contesti accademici, think tank o organizzazioni governative, il sospetto si orienta verso Kimsuky. La tecnica, per quanto semplice, funziona come discriminante settoriale nella fase di attribuzione preliminare.