Mascheramento con Nomi Account Simili: Masquerade Account Name (T1036.010)

La simulazione di questa tecnica inizia con la ricognizione degli account esistenti. Su Windows, il comando net user fornisce la lista completa degli utenti locali. Per un approccio più sofisticato, PowerShell offre maggiore flessibilità:

Get-LocalUser | Select-Object Name, Enabled, LastLogon

Una volta identificati i pattern di naming, la creazione di account mimetizzati diventa semplice. Per Windows, il comando classico net user support_388945a0 P@ssw0rd123 /add crea un account che sembra legato a processi di supporto. La variante PowerShell permette maggiore controllo:

New-LocalUser -Name "backup_service" -Password (ConvertTo-SecureString "Complex123!" -AsPlainText -Force) -Description "Automated Backup Service"

Su sistemi Linux, la tecnica si adatta utilizzando useradd. Un approccio efficace consiste nel creare account che sembrano servizi di sistema:

sudo useradd -m -s /bin/bash -c "System Backup Service" backup_helper sudo passwd backup_helper

Per aumentare la credibilità, modifica il file /etc/passwd per far apparire l'account come un servizio di sistema. L'aggiunta ai gruppi appropriati completa il mascheramento: sudo usermod -aG sudo help_admin.

In ambienti cloud, l'approccio richiede l'uso delle API specifiche. Per Azure AD, il comando PowerShell diventa:

New-AzureADUser -DisplayName "IT Support Agent" -UserPrincipalName "support_team@domain.com" -AccountEnabled $true

La chiave del successo sta nell'osservare i pattern di naming esistenti. Tool come BloodHound per Active Directory o ldapsearch per ambienti Linux permettono di mappare la struttura degli account prima di creare quelli mascherati.

La detection efficace richiede un approccio multistrato che combini analisi comportamentale e pattern matching. Il primo livello di difesa consiste nel monitorare gli EventID critici di Windows Security Log.

L'EventID 4720 (creazione account) e 4738 (modifica account) devono essere correlati con analisi di similarità. Un alert efficace verifica la distanza di Levenshtein tra il nuovo account e quelli esistenti. Quando la similarità supera l'80%, scatta l'allarme.

Per Linux, auditd fornisce visibilità granulare attraverso le syscall. La configurazione richiede:

-w /etc/passwd -p wa -k user_modification -w /etc/shadow -p wa -k user_modification

L'analisi comportamentale aggiunge un livello critico. Monitora la sequenza: ricognizione account (query LDAP/net user) seguita da creazione account entro 30 minuti. Questo pattern indica possibile attività malevola.

I falsi positivi rappresentano la sfida principale. Account di servizio legittimi spesso seguono pattern simili. La soluzione sta nel mantenere una whitelist dinamica di account autorizzati e nel verificare il contesto di creazione. Un account creato da processi di deployment automatizzato differisce da uno creato manualmente fuori orario.

Per ambienti cloud, le API di auditing forniscono ricchezza di dettagli. Azure Sentinel o AWS CloudTrail permettono query complesse che correlano creazione account, assegnazione ruoli e primo accesso.

L'ottimizzazione continua degli alert richiede feedback dal team. Mantieni metriche su falsi positivi per pattern e affina le soglie di similarità basandoti sui dati reali del tuo ambiente.

La ricostruzione forense di account mascherati richiede l'analisi di artefatti multipli distribuiti nel sistema. Il Security.evtx di Windows contiene la cronologia completa delle operazioni sugli account, ma la chiave sta nel correlare eventi apparentemente non collegati.

L'analisi inizia dal registro SAM per gli account locali. Tool come RegRipper estraggono timestamp di creazione e ultimo cambio password. La discrepanza tra data di creazione e primo utilizzo spesso rivela account dormienti creati per uso futuro.

Su sistemi Linux, /var/log/auth.log e /var/log/secure documentano ogni operazione sugli account. La presenza di comandi useradd o usermod eseguiti da shell interattive invece che da script di sistema indica attività sospetta. Il file lastlog rivela pattern di accesso anomali per account apparentemente di servizio.

APT3 ha dimostrato sofisticazione creando account come "support_388945a0" che sembrano generati automaticamente. L'analisi del prefisso "support_" seguito da hash apparente inganna molti analisti. La timeline della campagna 2016 Ukraine Electric Power Attack mostra come Sandworm Team abbia creato gli account "admin" e "система" in momenti strategici, sfruttando la familiarità con nomi comuni.

La correlazione temporale è cruciale. Cerca cluster di attività: ricognizione LDAP, creazione account, assegnazione privilegi, primo login. Questo pattern, compresso in finestre temporali ristrette, distingue l'attività malevola da quella amministrativa legittima.

Memory forensics con Volatility può rivelare processi che hanno creato gli account. Il plugin getsids mostra l'evoluzione dei privilegi nel tempo, particolarmente utile per identificare escalation post-creazione.

L'analisi dei gruppi APT che utilizzano questa tecnica rivela pattern operativi distintivi che permettono attribuzione e previsione delle mosse successive.

APT3 mostra predilezione per account con pattern alfanumerici che simulano identificatori di sistema. Il suffisso numerico-esadecimale è la loro firma. Questo gruppo tipicamente crea multipli account dormienti per garantire persistenza ridondante. La presenza di un account "support_" con hash apparente dovrebbe triggare ricerche di account simili creati nella stessa finestra temporale.

Dragonfly dimostra maggiore sofisticazione, creando account che si integrano perfettamente nell'infrastruttura target. I loro account backup e amministrazione email indicano focus su accesso a lungo termine. Il gruppo studia l'ambiente prima di agire, creando account che rispecchiano convenzioni di naming locali.

Magic Hound preferisce semplicità con account generici come "help" e "DefaultAccount". Questa apparente mancanza di sofisticazione è ingannevole: sfruttano la tendenza degli amministratori a ignorare account con nomi comuni. Il gruppo spesso combina questa tecnica con privilege escalation rapida.

Storm-1811 rappresenta l'evoluzione moderna, creando account Microsoft Teams per social engineering. Questo indica shift verso piattaforme collaborative come vettore di attacco. L'integrazione di account mascherati con campagne di vishing suggerisce operazioni multi-canale coordinate.

I malware Flame e ServHelper automatizzano la creazione di account backdoor, indicando che la tecnica è sufficientemente efficace da essere standardizzata in toolkit. La scelta di nomi come "HelpAssistant" e "supportaccount" rivela preferenza per account che sembrano legittimi ma non attirano scrutinio.

Analisi basata sul framework MITRE ATT&CK per la tecnica T1036.010. Riferimenti alle campagne "2016 Ukraine Electric Power Attack" di Sandworm Team. Dati di detection strategy derivati da implementazioni real-world in ambienti enterprise Windows, Linux e cloud. Metriche di rischio da report IBM Cost of Data Breach 2023.