Nascondersi in Piena Vista: File/Path Exclusions (T1564.012)

L'obiettivo in un engagement red team è dimostrare che le esclusioni AV dell'organizzazione rappresentano un rischio concreto. Il primo passo è l'enumerazione: identificare quali directory il software difensivo ignora, poi verificare che un payload depositato in quelle posizioni non generi alert.

Su Windows, le esclusioni di Microsoft Defender sono leggibili con PowerShell se si dispone di privilegi amministrativi:

Get-MpPreference | Select-Object -ExpandProperty ExclusionPath

Questo restituisce l'elenco completo dei percorsi esclusi. Per verificare anche le esclusioni per estensione e processo:

Get-MpPreference | Select-Object ExclusionPath, ExclusionExtension, ExclusionProcess

Oltre alle esclusioni configurate dall'utente, Defender applica esclusioni automatiche basate sui ruoli del server. Su un Domain Controller, ad esempio, la directory NTDS e i file di log di Active Directory sono esclusi. Su un Exchange Server, intere directory come il percorso di installazione e le code di trasporto vengono saltate. Queste esclusioni automatiche non compaiono necessariamente nell'output di Get-MpPreference, ma sono documentate da Microsoft.

Una volta identificata una directory esclusa, il red teamer può depositarvi un payload di test. Per una verifica rapida, si può usare il file di test EICAR — una stringa riconosciuta da tutti gli AV come "malware di prova" — e verificare se viene bloccata:

Invoke-WebRequest -Uri <URL-file-EICAR> -OutFile "C:\percorso-escluso\eicar.com"

Se il file sopravvive senza alert, la directory è confermata come cieca. Con Cobalt Strike (a pagamento) si può generare un dropper e posizionarlo nel percorso escluso per testare l'intera catena di evasione.

Su Linux l'approccio è analogo. Le esclusioni di ClamAV (open source) si trovano in /etc/clamav/clamd.conf alla direttiva ExcludePath. Per soluzioni EDR enterprise come CrowdStrike o SentinelOne, le esclusioni sono gestite centralmente, ma sul filesystem locale si possono individuare file di configurazione o policy cachate. L'utility auditctl può aiutare a verificare se il framework auditd stia monitorando un certo percorso:

auditctl -l | grep

Su macOS, le esclusioni di XProtect non sono direttamente configurabili dall'utente, ma soluzioni di terze parti come Sophos (a pagamento) o Malwarebytes (freemium) mantengono le proprie liste di esclusione nella directory /Library/Application Support/ del vendor.

Per un test end-to-end, il framework Atomic Red Team (open source) fornisce test atomici per la tecnica T1564, che possono essere adattati verificando prima le esclusioni locali e poi depositando l'artefatto nel percorso cieco.

Il paradosso di questa tecnica è che il payload si nasconde esattamente dove il vostro stack difensivo è cieco per scelta. La detection, quindi, non può basarsi sull'AV — deve appoggiarsi su telemetria indipendente che monitori le operazioni di file system anche nei percorsi esclusi.

Su Windows, Sysmon (gratuito) è lo strumento cardine. L'EventCode 11 (FileCreate) registra la creazione di file indipendentemente dalle esclusioni dell'antivirus. La strategia consiste nel creare una lista delle directory escluse dall'AV e configurare una regola Sysmon che generi alert specifici per scritture in quei percorsi. Il tuning è essenziale: occorre costruire una ProcessAllowlist con i processi legittimi che scrivono abitualmente in quei percorsi (ad esempio, il servizio Exchange Transport per le directory di Exchange) e generare alert solo quando il processo padre è anomalo.

Sul lato WinEventLog:Security, l'EventCode 4663 (tentativo di accesso a un oggetto) può complementare Sysmon, a patto che le SACL siano configurate sulle directory escluse. La combinazione dei due log è potente: Sysmon cattura la creazione, il Security log cattura gli accessi successivi.

La correlazione comportamentale è il vero discriminante. Un file creato in una directory esclusa, di per sé, non è malevolo. Ma un file creato in C:\Windows\Temp da un processo figlio di w3wp.exe (IIS) che poi viene eseguito con parametri di rete — questa è una catena da investigare. Impostate una finestra di correlazione di 5-10 minuti tra FileCreate e ProcessCreate (EventCode 1 di Sysmon) per lo stesso percorso.

Su Linux, auditd offre capacità analoghe. Le syscall openat e creat monitorate tramite regole audit sulle directory escluse dall'EDR forniscono telemetria grezza:

-w /percorso/escluso -p wa -k exclusion_write

Il log auditd:SYSCALL combinato con auditd:PATH permette di ricostruire quale processo ha scritto cosa e dove. Il parametro CorrelationWindow è cruciale anche qui: file scritti in directory escluse che entro pochi minuti mostrano attività di rete o escalation di privilegi devono generare alert ad alta priorità.

Su macOS, il Unified Log cattura eventi di file system, ma la granularità è inferiore. Per ambienti Apple, considerate soluzioni EDR che operino a livello kernel e monitorino le scritture anche nei percorsi ignorati da XProtect, come directory sotto ~/Library o cache temporanee.

Per la gestione dei falsi positivi, partite da una fase di baselining di almeno due settimane: raccogliete tutte le scritture nelle directory escluse, identificate i pattern legittimi e costruite la allowlist prima di attivare gli alert in produzione.

L'analisi forense di questa tecnica richiede un approccio sistematico: prima identificare le esclusioni configurate, poi ricostruire la storia di ogni file presente in quei percorsi.

Su Windows, il primo artefatto da acquisire è la configurazione delle esclusioni stesse. Le preferenze di Microsoft Defender sono archiviate nel registro sotto HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths. Esportate questa chiave e confrontatela con le policy aziendali documentate — eventuali discrepanze indicano manipolazione. Registry Explorer (gratuito, di Eric Zimmerman) permette di analizzare hive del registro offline.

Per ricostruire la timeline dei file nelle directory escluse, la $MFT (Master File Table) è la fonte primaria. Ogni file creato sul volume NTFS lascia un record nella MFT con timestamp di creazione, modifica, accesso e modifica del record stesso. Lo strumento MFTECmd (gratuito, suite Eric Zimmerman) estrae e parsa la MFT in formato CSV:

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

Filtrate l'output per le directory escluse e ordinate per timestamp di creazione. Cercate anomalie di timestomping: se il timestamp $STANDARD_INFORMATION diverge significativamente da $FILE_NAME, il file potrebbe essere stato manipolato.

Il journal $UsnJrnl complementa la MFT fornendo un log cronologico delle operazioni di file system. Con MFTECmd è possibile parsare anche il journal:

MFTECmd.exe -f "C:\percorso$J" --csv "C:\output" --csvf usn_output.csv

Cercate sequenze sospette: un file creato, rinominato e poi eseguito in rapida successione all'interno di un percorso escluso è un indicatore forte.

I log di Sysmon, se erano attivi durante l'intrusione, forniscono la correlazione processo-file che la MFT non offre. L'EventCode 11 registra il processo responsabile della creazione, il che permette di risalire all'intera catena: quale processo ha scritto il payload, da dove è stato lanciato, con quali privilegi.

Su Linux, la ricostruzione passa per i log di auditd (se configurato) e per i metadati del filesystem. Il comando stat su ciascun file sospetto rivela i timestamp, mentre il log /var/log/audit/audit.log contiene le syscall associate. Per filesystem ext4, lo strumento debugfs permette di esaminare i metadati a basso livello degli inode.

Il caso documentato di Turla è emblematico: il gruppo ha posizionato i file di installazione di LunarWeb in directory specificamente escluse dalla scansione. Nella ricostruzione forense, cercate binari non firmati o con firma non riconosciuta all'interno dei percorsi esclusi. Lo strumento Sigcheck (gratuito, Sysinternals) verifica la firma digitale dei file:

sigcheck.exe -e -u "C:\percorso-escluso"

Il flag -u mostra solo i file non firmati o con firma non valida, isolando rapidamente i candidati per l'analisi approfondita.

Turla (G0010)

Turla è uno dei gruppi di cyber-spionaggio più sofisticati attribuiti alla Federazione Russa, attivo da oltre un decennio con un arsenale in costante evoluzione. L'utilizzo della tecnica File/Path Exclusions si inserisce nella loro filosofia operativa di mimetizzazione profonda: piuttosto che disabilitare i controlli di sicurezza (azione rumorosa), preferiscono operare nei loro punti ciechi.

Il caso specifico riguarda LunarWeb, un impianto il cui file di installazione viene collocato in directory preventivamente identificate come escluse dalla scansione antivirus. Questa scelta presuppone una fase di ricognizione interna — coerente con il modus operandi di Turla, che tipicamente dedica tempo significativo alla comprensione dell'ambiente vittima prima di muoversi lateralmente.

Dal punto di vista dell'analista TI, questo pattern suggerisce che Turla stia investendo nella conoscenza delle configurazioni difensive degli obiettivi. L'implicazione operativa è chiara: se un'organizzazione individua indicatori di compromissione legati a Turla, una delle prime azioni deve essere la revisione delle esclusioni AV e la verifica di file anomali all'interno di quei percorsi.

Pattern e implicazioni strategiche

L'abuso delle esclusioni AV non è esclusivo di un singolo gruppo, ma la sua documentazione formale in contesto APT evidenzia un trend in crescita. L'approccio è particolarmente insidioso perché sfrutta decisioni difensive dell'organizzazione stessa — ogni esclusione aggiunta per "performance" diventa una superficie d'attacco potenziale.

Per gli analisti TI, la raccomandazione è integrare l'inventario delle esclusioni AV nei propri modelli di rischio. Quando un nuovo advisory menziona un attore che prende di mira il vostro settore, verificate se i vostri percorsi esclusi coincidono con quelli tipicamente sfruttati — directory di Exchange, percorsi di database, cartelle temporanee di build automation. La conoscenza delle esclusioni è parte integrante della superficie d'attacco e va trattata come informazione classificata, non come semplice configurazione operativa.

Le due mitigazioni raccomandate — la revisione delle esclusioni AV (M1049) e le linee guida per gli sviluppatori applicativi (M1013) affinché riducano la necessità di esclusioni personalizzate — indicano una direzione chiara: la riduzione della superficie cieca è tanto una responsabilità del vendor quanto dell'organizzazione.

Framework MITRE ATT&CK v16 — T1564.012 (File/Path Exclusions), TA0005 (Defense Evasion), G0010 (Turla), M1049, M1013, DET0051 (AN0139, AN0140, AN0141). Tool di detection: Sysmon, auditd, MFTECmd, Sigcheck, Registry Explorer. Integrato con conoscenza professionale per tool e procedure operative.