Manipolazione Permessi Windows: Windows File and Directory Permissions Modification (T1222.001)

La simulazione di questa tecnica in laboratorio è una delle più immediate dell'intero framework, perché gli strumenti necessari sono già installati su qualsiasi macchina Windows. L'obiettivo dell'esercizio è dimostrare come un operatore con privilegi locali possa smantellare le protezioni ACL su directory critiche in pochi secondi.

Il primo scenario replica esattamente il comportamento di Ryuk e WannaCry. Entrambi i malware concedono accesso completo alla directory corrente — e a tutte le sottodirectory — con un singolo comando:

icacls C:\TargetFolder /grant Everyone:F /T /C /Q

Il flag /T propaga la modifica ricorsivamente, /C continua anche in caso di errore su singoli file, e /Q sopprime l'output verboso. In un engagement reale, questo comando viene lanciato su share di rete o directory di backup prima della cifratura.

Il secondo scenario emula BitPaymer e WastedLocker, che preferiscono un approccio in due fasi: prima assumono la proprietà del file, poi resettano le ACL. La catena è:

takeown /F C:\Program Files\SecurityTool\agent.exe

icacls C:\Program Files\SecurityTool\agent.exe /reset

Questo pattern è particolarmente efficace contro agent EDR o antivirus il cui eseguibile è protetto da ACL restrittive impostate durante l'installazione. Dopo il reset, l'attaccante può sovrascrivere, rinominare o cancellare il binario.

Per simulare il comportamento di Storm-1811, che opera tramite batch script usando cacls.exe, si può creare un semplice file .bat:

cacls C:\Windows\System32\config\SAM /E /G Users:F

Sebbene cacls.exe sia deprecato a favore di icacls.exe, resta funzionante su Windows 10/11 e viene ancora sfruttato attivamente.

Sul versante PowerShell, la modifica dei permessi avviene tramite i cmdlet nativi del framework .NET. Un operatore red team può usare:

Set-Acl -Path "C:\SensitiveData" -AclObject (Get-Acl "C:\SensitiveData" | ForEach-Object { $.SetAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule("Everyone","FullControl","Allow"))); $ })

Per il reporting, il tool AccessChk di Sysinternals (gratuito) è ideale per documentare lo stato delle ACL prima e dopo la modifica: accesschk.exe -dqv C:\TargetFolder. Sigma (open source) offre regole pronte per validare che il SIEM rilevi questi comandi durante il test.

La detection di questa tecnica ruota attorno a un principio semplice: i binari legittimi che modificano le ACL (icacls.exe, cacls.exe, takeown.exe, attrib.exe) vengono invocati raramente in ambienti di produzione, e quasi mai in modo ricorsivo su directory critiche. Questo rende la baseline relativamente stabile e gli alert ad alto rapporto segnale/rumore.

La strategia di rilevamento documentata (DET0418) descrive una catena comportamentale multi-stadio articolata su cinque fasi. La prima è la creazione del processo: l'evento EventCode 4688 (Security) o Sysmon Event ID 1 registra l'avvio di uno dei binari chiave. La seconda fase è l'analisi della command line, dove parametri come /grant, /T, Everyone:F, /reset o il cmdlet Set-Acl segnalano intento malevolo.

La terza fase è la correlazione con l'evento EventCode 4670 — "Permissions on an object were changed" — che conferma la modifica effettiva della DACL. La quarta verifica se, entro una finestra temporale di 300 secondi (configurabile), compare un EventCode 4663 che indica accesso riuscito al file precedentemente protetto. La quinta fase cerca attività di follow-on: persistenza, movimento laterale, cifratura.

Le log source essenziali sono quattro: WinEventLog:Security per gli eventi 4670 e 4663, WinEventLog:Sysmon per la process creation e la command line, WinEventLog:PowerShell per i blocchi di script contenenti cmdlet ACL, e WinEventLog:WMI per invocazioni di Win32_SecurityDescriptor.

Per il tuning dei falsi positivi, il punto critico è la whitelist degli account amministrativi. Strumenti di gestione come SCCM, software di backup e script di provisioning modificano legittimamente le ACL. La detection va calibrata su tre assi: la whitelist degli account autorizzati (da aggiornare a ogni cambio di personale IT), le directory sensibili sotto monitoraggio rafforzato (C:\Windows\System32, C:\Program Files, %USERPROFILE%\AppData), e la soglia temporale per le modifiche fuori orario lavorativo, che alzano il punteggio di rischio.

Un alert Sigma efficace filtra le process creation dove il parent process non è un tool di gestione noto e la command line contiene pattern sospetti. Tool come Wazuh (open source) e Splunk (a pagamento) permettono di implementare la correlazione multi-evento necessaria per la catena a cinque stadi.

L'analisi forense della manipolazione DACL beneficia di un vantaggio raro nella risposta agli incidenti: ogni modifica ai permessi lascia tracce multiple e correlabili in log distinti. La sfida non è trovare gli artefatti, ma ricostruire la sequenza temporale corretta collegando creazione del processo, modifica della DACL e accesso successivo.

Il punto di partenza è il Security Event Log. L'evento 4670 registra il cambio di permessi con dettaglio su vecchia e nuova DACL in formato SDDL (Security Descriptor Definition Language). Questo formato, sebbene criptico, contiene informazioni preziosissime: il SID dell'account che ha modificato la ACL, il SID del nuovo beneficiario e i permessi concessi. Un analista che trovi la stringa "(A;;FA;;;WD)" nella nuova DACL sa immediatamente che è stato concesso Full Access al gruppo Everyone — il pattern esatto di Ryuk e WannaCry.

L'evento 4663 — che richiede l'abilitazione preventiva dell'Object Access Auditing tramite Group Policy — registra invece l'accesso effettivo al file dopo la modifica. La correlazione temporale tra un 4670 e un 4663 sullo stesso oggetto, a distanza di pochi secondi, è un indicatore forte di exploitation riuscita.

Sul versante Sysmon, l'Event ID 1 (Process Create) cattura la command line completa dell'utility invocata. Per ricostruire la catena di BitPaymer, ad esempio, si cercano due eventi ID 1 in rapida successione: il primo con takeown /F e il secondo con icacls /reset, entrambi con lo stesso ParentProcessId. Il campo ParentImage rivela se il comando è stato lanciato da cmd.exe, powershell.exe o da un binario sospetto.

Per i casi che coinvolgono PowerShell, i blocchi ScriptBlock Logging (Event ID 4104 nel log Microsoft-Windows-PowerShell/Operational) contengono il testo integrale degli script eseguiti. La ricerca di stringhe come SetAccessRule, FileSystemAccessRule o Set-Acl nei blocchi di script è determinante.

I tool di acquisizione forense da impiegare sono Eric Zimmerman's MFTECmd (open source) per l'analisi della Master File Table — dove i timestamp $SI e $FN possono rivelare il momento esatto della modifica — ed EvtxECmd (open source) dello stesso autore per il parsing massivo degli event log. Hayabusa (open source) è particolarmente utile per applicare regole Sigma direttamente sugli EVTX acquisiti, accelerando il triage iniziale.

La tecnica T1222.001 è un indicatore tattico significativo perché distingue nettamente due profili operativi: gruppi ransomware a doppia estorsione e malware mirati alla disabilitazione dei controlli di sicurezza.

Wizard Spider utilizza icacls con l'obiettivo specifico di ottenere controllo completo sulle directory dei server di backup. Questo pattern è coerente con il loro modus operandi: prima neutralizzano la capacità di ripristino della vittima, poi distribuiscono il payload di cifratura. La modifica delle ACL sui backup server è un precursore affidabile della detonazione ransomware, con una finestra operativa tipicamente breve. Il malware Ryuk, attribuito a questo gruppo, automatizza l'operazione con il comando icacls /grant Everyone:F /T /C /Q, propagandosi ricorsivamente su intere strutture di directory.

Storm-1811 si distingue per l'approccio basato su batch script con cacls.exe. L'uso di un binario deprecato suggerisce il riutilizzo di tooling legacy o una scelta deliberata per evadere detection rule focalizzate su icacls.exe. Questo è un indicatore utile per il tuning delle regole: monitorare solo icacls lascerebbe un punto cieco.

Sul versante malware, emerge un pattern chiaro nel ransomware: Ryuk, WannaCry, BlackByte Ransomware, BitPaymer e WastedLocker — cinque famiglie su nove — sono ransomware che usano la modifica ACL come fase preparatoria alla cifratura. CaddyWiper, classificato come wiper, segue lo stesso schema ma con finalità distruttiva anziché estorsiva. Grandoreiro rappresenta invece un caso distinto: un banking trojan che modifica le ACL dei binari di sicurezza per impedirne l'esecuzione, un approccio orientato alla persistenza silenziosa piuttosto che alla detonazione rapida.

Il denominatore comune è l'abuso di Living Off The Land Binaries: nessuno dei software documentati utilizza tool custom per la modifica delle ACL. Questa dipendenza dai binari di sistema suggerisce che il rafforzamento delle AppLocker policy o delle WDAC rule su icacls.exe, cacls.exe e takeown.exe — limitandone l'esecuzione a contesti amministrativi autorizzati — ridurrebbe significativamente la superficie d'attacco sfruttabile da queste famiglie.

Framework MITRE ATT&CK v16 — Tecnica T1222.001, Gruppi G0102, G1046, Software S0201, S0570, S0531, S0693, S0446, S1068, S0366, S1180, S0612, Mitigazioni M1026, M1022, Detection DET0418/AN1177. Tool di detection: Sigma, Hayabusa, Wazuh, Splunk. Tool forensi: MFTECmd, EvtxECmd (Eric Zimmerman). Integrato con conoscenza professionale per tool e procedure operative.