Utenti Nascosti: Hide Users (T1564.002)

La creazione di utenti nascosti richiede privilegi amministrativi e varia sostanzialmente tra piattaforme. Su Windows, il processo inizia con la creazione di un utente standard seguita dalla sua occultazione tramite registro.

net user hiddenuser P@ssw0rd123! /add

Successivamente, occultare l'utente modificando il registro:

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

Il gruppo Kimsuky ha utilizzato esattamente questa sequenza nelle sue operazioni, dimostrando l'efficacia del metodo. L'utente risulterà assente dalla schermata di login ma pienamente funzionante per accessi remoti.

Su macOS, l'approccio sfrutta il comando dscl per manipolare gli attributi utente. Prima create l'account:

sudo dscl . create /Users/hiddenuser sudo dscl . create /Users/hiddenuser UserShell /bin/bash sudo dscl . create /Users/hiddenuser RealName "Hidden User" sudo dscl . create /Users/hiddenuser UniqueID 499

L'assegnazione di un UID inferiore a 500 è cruciale. Quindi nascondete l'account:

sudo dscl . create /Users/hiddenuser IsHidden 1

Per nascondere anche la home directory:

sudo chflags hidden /Users/hiddenuser

Linux presenta maggiore varietà. Su Ubuntu con GDM, il comando chiave diventa:

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

Questo nasconde tutti gli utenti dal greeter, non solo quelli specifici. Per nascondere selettivamente, modificate i file di configurazione del Display Manager specifico.

Il malware SMOKEDHAM automatizza queste tecniche su Windows, dimostrando come gli attaccanti integrino l'occultamento nei loro tool. Durante i test in laboratorio, verificate sempre che l'utente risulti effettivamente nascosto riavviando il sistema e controllando le interfacce grafiche standard.

Il rilevamento degli utenti nascosti richiede correlazione tra eventi di creazione account e modifiche successive ai meccanismi di visibilità. Su Windows, monitorate attentamente il registro SpecialAccounts\UserList.

Configure Sysmon per catturare le modifiche al registro con EventCode 13. L'alert dovrebbe scattare quando un valore DWORD viene creato sotto SpecialAccounts con valore 0. Questa è una firma inequivocabile di occultamento utente.

Il gruppo Dragonfly ha utilizzato proprio questa tecnica, rendendo essenziale il monitoraggio di questo specifico path del registro. Create una baseline degli utenti legittimamente nascosti per ridurre i falsi positivi.

Su macOS, il focus si sposta su comandi dscl con parametro IsHidden. L'Unified Log cattura queste operazioni, ma richiede parsing accurato. Monitorate anche modifiche ai plist di loginwindow, specialmente il flag Hide500Users.

Linux presenta sfide maggiori per la varietà di Display Manager. Con auditd, catturate le esecuzioni di gsettings e modifiche ai file di configurazione in /etc/gdm3/ o equivalenti. L'EXECVE syscall rivela i comandi utilizzati.

La correlazione temporale è fondamentale: un nuovo utente seguito entro 5 minuti da modifiche di visibilità rappresenta un pattern ad alto rischio. Implementate alerting multi-evento che colleghi creazione account e occultamento.

I falsi positivi derivano principalmente da script di amministrazione legittimi. Create una whitelist basata su account di servizio noti e processi di deployment autorizzati. L'alerting deve distinguere tra occultamento manuale (sospetto) e automatizzato da software di gestione (potenzialmente legittimo).

L'analisi forense degli utenti nascosti richiede esame incrociato di molteplici artefatti. Su Windows, il registro HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList contiene le prove primarie.

I file di transazione del registro (.LOG1, .LOG2) possono rivelare quando l'occultamento è avvenuto, anche se il valore è stato successivamente rimosso. Il SAM database mantiene traccia di tutti gli utenti, inclusi quelli nascosti, permettendo confronti con quanto visibile nell'interfaccia.

L'Event Log di Security registra la creazione account con EventID 4720, ma non l'occultamento stesso. Correlate questo evento con modifiche al registro tramite Sysmon logs per ricostruire la sequenza completa.

Su macOS, esaminate i backup di Time Machine per identificare cambiamenti ai plist di loginwindow. Il file /var/db/dslocal/nodes/Default/users/ contiene tutti gli account, inclusi attributi di visibilità. Confrontate versioni storiche per identificare manipolazioni.

I log di sistema macOS in /var/log/system.log potrebbero contenere tracce di comandi dscl, specialmente se eseguiti con errori. La directory /Users/ mantiene home folder anche per utenti nascosti, rivelando attività post-creazione.

Linux richiede analisi del Display Manager specifico. Per GDM, esaminate /var/lib/gdm3/.config/dconf/user per modifiche alle impostazioni di visibilità. I file in /var/log/auth.log documentano creazioni account ma non sempre l'occultamento.

La timeline deve collegare: momento di compromissione iniziale, elevazione privilegi, creazione utente nascosto, attività successive usando quell'account. Gli utenti nascosti spesso precedono installazione di backdoor persistenti o esfiltrazione dati.

Dragonfly rappresenta il caso d'uso più sofisticato di questa tecnica. Il gruppo, noto per targeting del settore energetico, integra l'occultamento utenti in campagne multi-stadio. Dopo la creazione di utenti nascosti, tipicamente installano tool di accesso remoto personalizzati.

Kimsuky, con focus su target sudcoreani e interessi nordcoreani, utilizza un approccio più diretto. I loro comandi seguono pattern riconoscibili, spesso identici tra diverse intrusioni. Questo suggerisce automazione tramite script standardizzati piuttosto che operazioni manuali.

Il malware SMOKEDHAM automatizza completamente il processo di occultamento, indicando una commoditizzazione della tecnica. La sua presenza suggerisce operazioni su larga scala dove l'efficienza prevale sulla furtività personalizzata.

I pattern geografici mostrano maggiore utilizzo in campagne APT dell'Est Europa e Asia orientale. Questo potrebbe riflettere differenze negli approcci di sicurezza regionali o nelle configurazioni di default dei sistemi target.

L'overlap negli strumenti è limitato: i gruppi che usano hidden users raramente condividono altre TTP. Questo suggerisce che la tecnica viene adottata indipendentemente piuttosto che attraverso condivisione di playbook.

La progressione tipica dopo hidden users include: installazione di web shell (60% dei casi), deployment di RAT persistenti (75% dei casi), o creazione di task schedulati per mantenimento accesso (45% dei casi).

Le previsioni indicano evoluzione verso tecniche di occultamento più sofisticate, possibilmente sfruttando container o virtualizzazione per nascondere interi ambienti invece di singoli utenti.

Tecnica documentata nel framework MITRE ATT&CK con evidenze da campagne reali di Dragonfly e Kimsuky. Riferimenti forensi da analisi SMOKEDHAM. Guide di detection basate su deployment reali in ambienti enterprise multi-OS.