Account Mascherati: Masquerade Account Name (T1036.010)

Simulare questa tecnica in laboratorio è immediato e non richiede tool esotici — bastano le utility native dei sistemi operativi. Il punto critico non è la creazione dell'account in sé, ma la scelta del nome e il contesto in cui viene inserito per testare la capacità di detection del Blue Team.

Su Windows, la creazione di un account locale con nome mimetico si esegue con net user:

net user HelpAssistant P@ssw0rd123! /add

Questo replica esattamente il comportamento del malware Flame, che creava un'utenza HelpAssistant sui sistemi connessi al dominio. Per simulare lo scenario di ServHelper, basta variare il nome:

net user supportaccount P@ssw0rd123! /add

Per aggiungere l'utenza al gruppo Administrators e verificare l'effettiva escalation:

net localgroup Administrators supportaccount /add

In ambiente Active Directory, PowerShell offre maggiore flessibilità. Con il modulo ActiveDirectory (open source, incluso in RSAT):

New-ADUser -Name "admin" -SamAccountName "admin" -AccountPassword (ConvertTo-SecureString "P@ssw0rd123!" -AsPlainText -Force) -Enabled $true

Questo replica la scelta di Sandworm Team durante la campagna 2016 Ukraine Electric Power Attack, dove furono creati gli account admin e система.

Su Linux, la simulazione passa per useradd:

sudo useradd -m -s /bin/bash help

Il nome help è quello scelto da Magic Hound sui sistemi compromessi. Per un test più realistico, si può creare un utente che imita un servizio di backup:

sudo useradd -r -s /usr/sbin/nologin backup-svc

Il flag -r crea un account di sistema con UID nel range riservato ai servizi, rendendolo ancora meno sospetto durante una revisione manuale.

In ambienti containerizzati, si può testare la creazione all'interno di un container Docker in esecuzione:

docker exec -it <container_id> sh -c "adduser --disabled-password --gecos '' kubelet"

Per il red team che vuole andare oltre la singola creazione, la catena d'attacco più realistica prevede tre fasi: prima una discovery degli account esistenti (net user /domain su Windows, cat /etc/passwd su Linux), poi la cancellazione di un account legittimo, infine la ricreazione con lo stesso nome ma credenziali controllate dall'attaccante. Questa sequenza testa la capacità del SOC di correlare eventi di tipo diverso in una finestra temporale ristretta.

La detection di questa tecnica ruota attorno a un concetto chiave: non basta monitorare la creazione degli account, bisogna analizzare i nomi scelti e correlarli con il contesto esistente. Una regola che si limita a generare alert su ogni EventCode 4720 (creazione utente locale su Windows) produrrà troppo rumore; una che confronta il nome con una baseline di account legittimi diventa chirurgica.

Su Windows, le log source principali sono il canale WinEventLog:Security e le query osquery. L'evento EventCode 4720 cattura la creazione di un account locale, mentre EventCode 4722 ne registra l'abilitazione. Il 4781 è altrettanto importante perché traccia la rinomina di un account — un percorso alternativo che gli attaccanti possono sfruttare. La strategia di detection raccomandata prevede il confronto del nome del nuovo account con una lista di utenze note mediante distanza di Levenshtein: se il nome è troppo simile a un account di servizio o amministrativo esistente, scatta l'alert.

I parametri di tuning sono tre e vanno calibrati sull'ambiente:

• SimilarityThreshold: la soglia di distanza di edit — un valore di 2-3 è un buon punto di partenza per catturare varianti come adm1n o admin1 senza esplodere in falsi positivi
• MonitoredAccountList: la lista di account legittimi contro cui confrontare — deve includere gli account di servizio, gli admin e gli account di sistema
• TimeWindow: la finestra temporale in cui correlare creazione, rinomina e cancellazione — 60 minuti è un intervallo ragionevole

Su Linux, i log da monitorare sono quelli generati da auditd. Una regola audit mirata cattura le syscall relative alla modifica di /etc/passwd e /etc/shadow:

-w /etc/passwd -p wa -k user_creation

Il tuning Linux aggiunge un parametro cruciale: ScriptInitiatorDetection, che identifica se la creazione dell'account è stata avviata da uno script o da una sessione shell interattiva sospetta. Questo aiuta a distinguere l'automazione legittima (Ansible, Puppet) da un attaccante che esegue useradd da una reverse shell.

Per gli ambienti cloud e Identity Provider, i log azure:audit e saas:okta devono essere configurati per catturare la creazione di utenti con nomi che corrispondono a pattern sospetti tramite regex: prefissi come helpdesk_, support_, root-admin sono indicatori ad alta fedeltà. Il parametro RoleScope permette di alzare la priorità quando all'account appena creato vengono assegnati ruoli privilegiati.

In ambienti containerizzati, il daemon Docker produce log che registrano l'esecuzione di comandi all'interno dei container. Il tuning si basa su una MasqueradePatternList personalizzata che includa nomi tipici dell'ecosistema Kubernetes: kubelet, cronjob_sync, etcd-backup. Limitare il perimetro ai container con volumi persistenti riduce i falsi positivi senza sacrificare la copertura.

Per la gestione dei falsi positivi, la mitigazione User Account Management suggerisce di definire una naming convention rigida: se tutti gli account di servizio seguono il formato svc-<applicazione>-<ambiente>, qualsiasi nome che devia dallo schema diventa immediatamente sospetto.

L'analisi forense di un account mascherato parte da un principio: l'account in sé è solo il punto d'arrivo di una catena di azioni che lascia tracce in più punti del sistema. Ricostruire la timeline significa collegare la discovery degli account esistenti, l'eventuale cancellazione, la creazione del nuovo account e le azioni successive.

Su Windows, il punto di partenza è il Security Event Log. L'EventCode 4720 registra la creazione dell'account con dettagli sull'utente che ha eseguito l'operazione — il campo SubjectUserName rivela chi ha creato l'account, e se quel soggetto è a sua volta un'utenza compromessa, si apre un secondo filone d'indagine. L'EventCode 4726 cattura la cancellazione, cruciale per ricostruire lo scenario in cui l'attaccante elimina un account legittimo e ne ricrea uno con lo stesso nome.

Il registro SAM (Security Account Manager) è un artefatto fondamentale. Un'estrazione offline tramite tool come RegRipper (open source) permette di analizzare i metadati degli account locali — data di creazione, ultimo login, appartenenza ai gruppi. La correlazione tra il timestamp di creazione nel SAM e gli eventi nel Security Log conferma o smentisce la timeline.

Su Linux, il file /etc/passwd e /etc/shadow contengono i dati dell'account, ma non registrano la cronologia delle modifiche. Per quello serve auditd: i log in /var/log/audit/audit.log con la key user_creation (se la regola era configurata) mostrano la syscall esatta, il PID del processo chiamante e il UID dell'operatore. Il file /var/log/auth.log (o /var/log/secure su distribuzioni Red Hat) registra gli eventi di useradd con timestamp preciso.

Un artefatto spesso trascurato è la bash_history dell'utente che ha eseguito la creazione. Se l'attaccante non ha ripulito la cronologia, è possibile trovare la sequenza completa: dal cat /etc/passwd (discovery) al userdel (cancellazione) al useradd (ricreazione). La presenza di questa sequenza in una finestra temporale ristretta è un indicatore ad alta fedeltà.

Per la campagna 2016 Ukraine Electric Power Attack (C0025), Sandworm Team creò gli account admin e система sui sistemi delle sottostazioni elettriche ucraine. In uno scenario simile, il forensic analyst cercherebbe la presenza di nomi account in cirillico nel SAM o nei log di Security — un'anomalia linguistica che, in un ambiente con naming convention in caratteri latini, rappresenta un indicatore immediato.

Nei casi che coinvolgono malware come Flame o ServHelper, la creazione dell'account è automatizzata dal codice malevolo. L'artefatto chiave diventa allora il processo padre: se l'account HelpAssistant è stato creato da un eseguibile sconosciuto anziché da lsass.exe o da un tool di gestione legittimo, la correlazione processo-evento è la prova della compromissione. Tool come Velociraptor (open source) permettono di interrogare simultaneamente centinaia di endpoint per cercare account con nomi nella lista di indicatori noti.

La tecnica di mascherare i nomi degli account è adottata da gruppi con profili operativi molto diversi, il che la rende un indicatore di maturità tattica piuttosto che di una specifica affiliazione geografica. Quattro gruppi e una campagna distruttiva offrono un panorama sufficientemente ampio per estrarre pattern utili.

Storm-1811 rappresenta il caso più sofisticato di social engineering combinato con account masquerading. Il gruppo ha creato account Microsoft Teams che imitavano membri del supporto IT e dell'helpdesk, utilizzandoli come vettore per phishing applicativo e vocale. Questo approccio suggerisce un'operazione orientata all'accesso iniziale tramite ingegneria sociale, dove il nome dell'account non serve a nascondersi nei log ma a guadagnare fiducia in tempo reale. Il pattern è particolarmente insidioso perché sfrutta la superficie di attacco delle piattaforme collaborative.

Magic Hound opera con un approccio più tradizionale e post-compromise. La creazione di account locali help e DefaultAccount su macchine già compromesse indica che il gruppo utilizza questa tecnica come meccanismo di persistenza e movimento laterale. La scelta di nomi generici ma plausibili — help richiama un account di assistenza, DefaultAccount è effettivamente un'utenza di sistema Windows — denota conoscenza dell'ambiente target.

Dragonfly ha portato il mascheramento a un livello organizzativo, creando account che simulavano servizi di backup, account di servizio e amministrazione email. Questo pattern è coerente con operazioni di lunga durata contro infrastrutture critiche, dove la persistenza deve sopravvivere a revisioni periodiche degli accessi. Un account chiamato backup-daily o mail-admin ha ottime probabilità di passare indenne un audit superficiale.

APT3 ha utilizzato un approccio diverso con l'account support_388945a0, che combina un prefisso plausibile (support) con un suffisso alfanumerico che imita i pattern autogenerati da software legittimi. Questo stile è più meccanico e suggerisce automazione nella creazione degli account.

La campagna 2016 Ukraine Electric Power Attack (C0025) offre un caso studio a sé: Sandworm Team creò gli account admin e система nell'ambito di un attacco distruttivo contro la rete elettrica ucraina con il malware Industroyer. L'uso del nome система in cirillico è un dettaglio significativo — in un contesto russofono poteva apparire legittimo, ma rappresenta anche un indicatore di attribuzione.

Il pattern trasversale che emerge è chiaro: i nomi degli account mascherati seguono tre categorie — nomi generici (admin, help, root), nomi di servizio (backup-svc, HelpAssistant, supportaccount) e nomi ibridi con suffissi pseudo-casuali (support_388945a0). Il TI officer dovrebbe costruire una watchlist basata su queste tre categorie, alimentandola con i nomi specifici emersi dalle campagne documentate e adattandola alla naming convention dell'organizzazione.

Sul fronte dei tool, sia Flame sia ServHelper automatizzano la creazione di account con nomi predefiniti. Questo suggerisce che la tecnica viene spesso integrata direttamente nel malware piuttosto che eseguita manualmente, il che implica che la detection basata sulla correlazione processo-account è più affidabile della sola analisi del nome.

Framework MITRE ATT&CK v16 — T1036.010 (Masquerade Account Name), TA0005 (Defense Evasion). Campagna C0025 (2016 Ukraine Electric Power Attack). Gruppi: G1046, G0059, G0035, G0022. Software: S0143, S0382. Mitigazioni: M1047, M1018. Detection: DET0383 (AN1077–AN1080). Integrato con conoscenza professionale per tool e procedure operative.