File System Nascosto: Hidden File System (T1564.005)
La tecnica T1564.005 - Hidden File System rappresenta una delle forme più sofisticate di occultamento adottate da attori avanzati per sottrarre componenti malevoli alla visibilità degli strumenti di sicurezza. Un file system nascosto è una struttura di archiviazione parallela a quelle standard (NTFS, FAT, ext4, APFS) che l'avversario crea per ospitare payload, configurazioni e dati esfiltrati fuori dalla portata delle API di sistema comunemente monitorate.
L'implementazione può assumere diverse forme: uso di spazio riservato non allocato tra le partizioni, immagini di partizione portabili droppate come file singoli sopra il file system legittimo, oppure frammentazione non convenzionale sfruttando strutture come la Master File Table di NTFS o il Volume Boot Record. Alcune varianti memorizzano l'intero volume cifrato all'interno del Registro di Windows.
La collocazione tattica è in TA0005 (Defense Evasion): l'obiettivo non è ottenere accesso o persistenza in sé, ma rendere invisibili i componenti a EDR, antivirus e strumenti di triage. Il framework MITRE censisce 2 gruppi APT (Equation e Strider) e 4 famiglie malware (Regin, Uroburos, BOOTRASH, ComRAT) che hanno impiegato questa tecnica, tutti riconducibili a operazioni di espionaggio di alto profilo. L'impatto operativo è severo: un file system nascosto ben progettato può sopravvivere per anni su un endpoint compromesso senza emettere segnali rilevabili dalle telemetrie convenzionali basate su file system events.
La simulazione controllata di un file system nascosto in laboratorio serve a validare l'efficacia dei controlli EDR e delle procedure di triage. L'approccio deve essere isolato, con snapshot VM ripristinabili, perché alcune tecniche coinvolgono aree critiche del disco.
Su Windows, l'esperimento più pulito riproduce lo schema di BOOTRASH: creare una piccola area non allocata tra le partizioni e scrivervi dati raw. Usando diskpart si può ridimensionare una partizione di test per lasciare spazio non allocato, poi con Python e il modulo pywin32 aprire \.\PhysicalDrive0 con CreateFile e scrivere blocchi arbitrari a offset specifici. In alternativa, si può usare dd for Windows (open source) per leggere e scrivere settori grezzi. Per lo scenario Equation, si costruisce un blob cifrato con AES via openssl (open source) e lo si memorizza in una chiave di registro sotto HKLM\SOFTWARE usando il tipo REG_BINARY: la dimensione può raggiungere diverse centinaia di KB per chiave.
Lo schema ComRAT/Uroburos è particolarmente istruttivo: si genera un'immagine FAT16 con mkfs.fat su Linux, la si cifra con openssl enc -aes-128-cbc, si trasferisce come singolo file in %TEMP% sull'endpoint Windows e la si monta on-demand tramite driver custom o tool come OSFMount (freemium) o ImDisk Toolkit (open source). Il vantaggio didattico è mostrare come un file apparentemente innocuo possa contenere un intero volume operativo.
Su Linux il pattern più realistico usa loopback: dd if=/dev/urandom of=/tmp/.cache.bin bs=1M count=50 per creare il container, cryptsetup luksFormat (open source, parte di cryptsetup-luks) per cifrarlo, poi losetup e mount per attivarlo solo durante le operazioni. La chiave di simulazione è mantenere il volume smontato al di fuori dei task attivi, replicando il comportamento di Regin.
Su macOS si usa hdiutil create per generare un'immagine sparse cifrata e hdiutil attach -nomount per collegarla senza esporla in Finder; l'accesso avviene tramite device node in /dev/.
Per il red team maturo, framework come Metasploit (open source) e Cobalt Strike (a pagamento) non implementano nativamente file system nascosti, ma permettono di caricare moduli custom in memoria che gestiscono l'I/O verso il container occultato. La reportistica deve documentare offset esatti, chiavi di cifratura e procedura di cleanup completa.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo