• Guide, Sicurezza, Sistemi Operativi
• 21 Agosto 2025

Il file system denominato New Technology File System (NTFS) fu introdotto per la prima volta da Microsoft nel 1993 con il rilascio di Windows NT 3.1. Il team di sviluppatori composto da Tom Miller, Gary Kimura, Brian Andrew e David Goebel, ideò NTFS quando Microsoft abbandonò lo sviluppo congiunto con IBM del sistema operativo OS/2 e decise di sviluppare internamente Windows NT, riproponendo alcune delle caratteristiche presenti nel file system HPFS di OS/2.

Probabilmente a causa di questo “legame”, HPFS e NTFS utilizzano lo stesso codice di identificazione del tipo di partizione del disco (07). L’utilizzo dello stesso Partition ID Record Number è, infatti, piuttosto insolito considerando che erano disponibili numerosi codici non utilizzati, e che gli altri principali file system dispongono dei propri codici (ad esempio FAT ha più di nove codici, uno per ogni tipo di FAT: FAT12, FAT16, FAT32, ecc.). Questo comporta che, per identificare il file system di una partizione di tipo 07, sia necessario eseguire controlli aggiuntivi per distinguere tra HPFS e NTFS.

Tra le varie funzionalità dell’NTFS venne introdotta anche l’Alternate Data Streams (ADS), con l’obiettivo di fornire compatibilità con i client Macintosh. Il file system HFS (Hierarchical File System) utilizzato sui Mac era infatti caratterizzato da una struttura con fork: data fork (contenuto) e resource fork (metadati). Per consentire ad un computer Windows NT di interagire correttamente con file provenienti da macOS, NTFS implementò gli ADS. Ciò permise di conservare i metadati (come icone, risorse, descrizioni, preferenze) associati ai file HFS senza comprometterne il contenuto principale, facilitando la condivisione e l’interoperabilità in ambienti eterogenei Windows / macOS.

In particolare, Windows NT 3.1 introdusse gli NTFS ADS per consentire ai Services for Macintosh (SFM) di archiviare i fork delle risorse. Gli SFM permettevano la condivisione di file e stampanti con computer Apple tramite l’Apple Filing Protocol (AFP), noto anche come AppleTalk Filing Protocol, parte di Apple File Service (AFS). Sebbene i SFM siano stati rimossi nella versione client di Windows a partire da Windows XP e nella versione server a partire da Windows Server 2008, le attuali versioni di Windows utilizzano ancora gli NTFS ADS.

Nell’articolo analizzeremo nel dettaglio la funzionalità degli ADS e come questa potrebbe essere sfruttata da utenti malintenzionati per nascondere dati.

Architettura dei NTFS Alternate Data Streams

Per comprendere l’architettura degli NTFS Alternate Data Streams è possibile fare riferimento alla documentazione resa disponibile da Microsoft tramite il programma Open Specifications che permette agli sviluppatori la consultazione di documenti tecnici relativi all’interoperabilità per alcuni prodotti Microsoft di uso comune.

E’ possibile trovare informazioni tecniche circa gli NTFS ADS nel documento tecnico [MS-FSCC]: File System Control Codes, per la precisione nella [MS-FSCC]: Appendix A: NTFS Alternate Streams.

Nella sezione [MS-FSCC]: NTFS Streams dell’Appendice AI viene spiegato come tutti i file su un volume NTFS sono costituiti da almeno uno stream, il main stream, ovvero il file normalmente visualizzabile in cui vengono archiviati i dati. Il nome completo di uno stream ha il seguente formato:

<filename>:<stream name>:<stream type>

Il default data stream non ha un nome. Pertanto, il nome completo del default stream per un file denominato “sample.txt” è “sample.txt::$DATA”, poiché “sample.txt” è il nome del file e “$DATA” è lo stream type.

Un utente può creare un named stream in un file e usare “$DATA” come nome valido. Ciò significa che per questo stream, il nome completo sarebbe “sample.txt:$DATA:$DATA”. Se, invece, l’utente avesse creato un named stream con il nome “info”, il suo nome completo sarebbe “sample.txt:info:$DATA”. Qualsiasi carattere valido per un nome di file è valido anche per lo stream name (inclusi gli spazi).

Nel caso delle directory, non esiste un default data stream, ma esiste un default directory stream. Lo stream type per le directory è $INDEX_ALLOCATION. Il nome del default stream per il tipo $INDEX_ALLOCATION (un directory stream) è $I30. Questo differisce dal default stream name per un $DATA stream, che ha invece uno stream name vuoto. Quindi le seguenti sono di fatto equivalenti:

Sebbene le directory non abbiano un default data stream, possono avere named data streams. Questi alternate data streams non sono normalmente visibili, ma possono essere osservati da riga di comando utilizzando l’opzione /R del comando DIR.

Per meglio comprendere gli NTFS data stream è possibile fare riferimento anche a quanto riportato in How NTFS Works: Local File Systems – Multiple Data Streams in cui viene spiegato che un data stream è una sequenza di byte. Un’applicazione popola lo stream scrivendo dati in specifici offset all’interno dello stream stesso. L’applicazione può quindi leggere i dati leggendo gli stessi offset nel percorso di lettura. Ogni file ha un main, unnamed stream ad esso associato, indipendentemente dal file system utilizzato.

Tuttavia, come visto precedentemente, NTFS supporta gli alternate data streams ovvero ulteriori named data streams, in cui ogni data stream è una sequenza di byte alternativa, come illustrato nella Figura 1.

Figura 1: Unnamed and Named Streams

Le applicazioni possono creare additional named streams e accedervi facendo riferimento ai loro nomi. Questa funzionalità permette di gestire dati correlati come un’unica unità. Ad esempio, un programma di grafica può memorizzare un’immagine in miniatura di una bitmap in un named data stream all’interno del file NTFS che contiene l’immagine principale.

I volumi FAT supportano solo il main, unnamed stream, quindi se, ad esempio, si prova a copiare o spostare “Streamexample.doc” su un volume FAT si riceverà un avviso che indica che alcune proprietà del file saranno perse come si può vedere nella Figura 2.

Figura 2: Copia file con NTFS Streams su file system diverso da NTFS

In un volume NTFS, ogni unità di informazione associata a un file, inclusi il suo nome, il proprietario, il timestamp, il contenuto e così via, è implementata come un file attribute. Esistono diversi attributi e i nomi degli attributi utilizzati da NTFS sono riportati in [MS-FSCC]: NTFS Attribute Types.

Anche i dati del file sono un attributo ovvero il “Data Attribute” conosciuto come $DATA e tale attributo può avere più istanze (i cosiddetti Alternate Data Streams).

In NTFS, la correlazione tra Attribute Types e Stream Type non è limitata al solo $DATA. Esistono infatti anche altri Attribute Type che hanno una corrispondenza diretta con gli Stream Type, descritti in [MS-FSCC]: NTFS Stream Types, ovvero $INDEX_ALLOCATION e $BITMAP. (a riguardo si veda anche File Streams (Local File Systems) – Win32 apps | Microsoft Learn).

Per quanto riguarda la nomenclatura degli stream, come riportato in [MS-FSCC]: NTFS Stream Names, NTFS per convenzione usa nomi che iniziano con ‘$’ per i file di metadati interni e per gli stream su questi stessi file di metadati. Dal momento che non esiste un meccanismo che impedisca alle applicazioni di usare nomi in questo formato, quindi si raccomanda che i nomi in questo formato non vengano usati internamente da un object store per un ambiente server a meno che non si stia emulando degli NTFS metadata streams.

Utilizzo dei NTFS Alternate Data Streams in Windows

Come indicato in [MS-FSCC]: Known Alternate Stream Names Windows fa uso dei NTFS Alternate Data Streams in diverse situazioni.

Un esempio che spesso può capitare di osservare è quello relativo ad un file scaricato da Internet, in questo caso il file avrà due NTFS Alternate Data Streams e ciò permette di indicare nelle proprietà del file l’indicazione che proviene da un altro computer come mostrato in Figura 3.

Figura 3: File scaricato da Internet

Come mostrato in Figura 4, per visualizzare i due NTFS Alternate Data Streams è possibile usare, come già indicato in precedenza, il comando DOS DIR /R.

Figura 4: NTFS Alternate Data Streams di un file scaricato da Internet

Il primo NTFS Alternate Data Stream è descritto in [MS-FSCC]: Zone.Identifier Stream Name, ovvero lo stream denominato Zone.Identifier in cui viene memorizzato l’URL security zone. Per visualizzare il contenuto dello stream Zone.Identifier per il file Streams.zip è possibile, ad esempio, usare notepad avviato tramite il seguente comando :

notepad Streams.zip:Zone.Identifier

Come si può notare nella Figura 5 lo stream Zone.Identifier memorizza le informazioni degli url da cui è stato scaricato il file e lo ZoneId ovvero la Security Zone (0= My Computer; 1 = Local Intranet Zone; 2 = Trusted sites Zone; 3 = Internet Zone; 4 = Restricted Sites Zone), a riguardo si vedano About URL Security Zones (Windows) | Microsoft Learn e IE security zones registry entries for advanced users – Internet Explorer | Microsoft Learn.

Figura 5: Contenuto del NTFS Alternate Data Streams Zone.Identifier

Il secondo NTFS Alternate Data Stream denominato SmartScreen viene creato solo se il file viene scaricato tramite un’applicazione compatibile con Microsoft Defender SmartScreen (come Microsoft Edge o Google Chrome entrambi basati su Chromium) ed agisce come un marcatore di sicurezza. Il sistema operativo crea questo stream per memorizzare i metadati relativi alla valutazione di sicurezza del file effettuata da Microsoft Defender SmartScreen. Per visualizzare il contenuto dello stream SmartScreen per il file Streams.zip è possibile, ad esempio, usare notepad avviato tramite il seguente comando

Come si può notare nella Figura 6 nel caso in cui il file sia stato scaricato tramite un browser basato su Chromium lo stream conterrà il testo Anaheim che è l’identificatore del browser che ha avviato il download, infatti “Anaheim” è stato il nome in codice del progetto per la versione di Microsoft Edge basata su Chromium.

Figura 6: Contenuto del NTFS Alternate Data Streams SmartScreen

Va però precisato che al momento non esiste una documentazione ufficiale Microsoft sul NTFS Alternate Data Streams SmartScreen e le informazioni riportate sono derivate da diverse risorse tecniche (blog e comunità) come ad esempio la seguente discussione System File containing “Anaheim” – Microsoft Q&A.

Quando viene selezionato il flag “Annulla blocco” nelle proprietà del file il sistema operativo provvede ad eliminare l’NTFS Alternate Data Stream denominato Zone.Identifier e, se esiste, l’NTFS Alternate Data Stream denominato SmartScreen, analogamente se si eliminano manualmente gli NTFS Alternate Data Stream verrà anche eliminata dalle proprietà del file l’indicazione che proviene da un altro computer.

Per altri esempi di come il sistema utilizza gli NTFS Alternate Data Stream per l’implementazione di funzionalità si veda, come indicato precedentemente, [MS-FSCC]: Known Alternate Stream Names, per informazioni tecniche sulla strutture per la persistenza delle informazioni sui metadati dei file tramite NTFS Alternate Data Stream si faccia riferimento al documento [MS-FCIADS]: File Classification Infrastructure Alternate Data Stream (ADS) File Format.

Gestione dei NTFS Alternate Data Streams in Windows

Come diceva Mark Russinovich nel 2016 nell’introduzione al tool Streams, NT non dispone di alcuno strumento che permetta di vedere quali file NTFS hanno stream associati. Infatti Windows Explorer consente di vedere e gestire il main o unnamed stream di un file, ma non consente di vedere i named data streams ovvero gli alternate data streams di un file (o di una directory).

Sebbene come vedremo oltre al tool Streams ci sono vari modi per la visualizzazione e la gestione dei NTFS Alternate Data Streams, va precisato che la loro finalità è quella fornire alle applicazioni o al sistema operativo un metodo per la gestione dei metadati associati ai file da trattare. Quindi il fatto che la User Experience destinata all’utente eviti la visualizzazione dei NTFS Alternate Data Streams ha una sua logica dal momento che è l’applicazione o il sistema che deve provvedere autonomamente alla gestione dei NTFS Alternate Data Streams.

Un primo approccio per la visualizzazione e la gestione dei NTFS Alternate Data Streams è quello di ricorre ai comandi DOS, di seguito alcuni esempi di quanto è possibile fare.

Nel caso in cui il file sample.txt non esista verrà creato un file vuoto e quindi verrà creato l’NTFS Alternative Data Stream denominato ADS.file con il contenuto specificato.

Figura 7: Visualizzazione NTFS Alternate Data Streams tramite il comando dir /r

Ovviamente questi comandi consentono una gestione molto basilare dei NTFS Alternate Data Stream, ad esempio non è possibile eliminare uno stream, per questo motivo sono stati creati vari tool di terze parti, per semplicità ne ho descritti due nella seguente tabella.

Come già visto precedentemente anche Notepad può essere usato per creare o visualizzare il contento dei NTFS Alternate Data Stream, infatti se a riga di comando si specifica come di aprire con Notepad un NTFS Alternate Data Stream se questo esiste ne verrà visualizzato il contento in caso contrario verrà creato.

Nel caso in cui il file sample.txt non esista verrà creato un file vuoto e quindi verrà creato l’NTFS Alternative Data Stream denominato ADS con il contenuto specificato.

Figura 8: Utilizzo di Notepad per la gestione dei NTFS Data Stream

Anche PowerShell consente di gestire gli NTFS Alternate Data Stream mettendo a disposizione una serie di cmdlet.

Utilizzo dei NTFS Alternate Data Streams in una applicazione

Come abbiamo visto lo scopo dei NTFS Alternate Data Streams è di fornire alle applicazioni oltre che al sistema operativo un metodo per la gestione, quando necessario, di metadati associati ai file da trattare.

Per la gestione dei NTFS Alternate Data Streams in una applicazione è possibile utilizzare le API di sistema Win32 ovvero le funzioni CreateFileW, WriteFileW, ReadFileW, CloseHandleW, DeleteFileW, FindFirstStreamW, FindNextStreamW a riguardo si vedano Creating, Deleting, and Maintaining Files – Win32 apps | Microsoft Learn e Using Streams – Win32 apps | Microsoft Learn.

In applicazioni .NET è possibile anche non ricorrere alle API di sistema tramite PInvoke, ma usare per la creazione, lettura ed eliminazione degli stream le funzioni del NameSpace System.IO in questo caso occorre però specificare i path con il prefisso \\?\ si veda il seguente esempio:

\\?\C:\cartella\file.txt:nomeStream

Il prefisso \\?\ indica alle Windows APIs di disattivare il parsing delle stringhe e inviare la stringa del path così com’è al file system come indicato in Naming Files, Paths, and Namespaces – Win32 apps | Microsoft Learn:

“For file I/O, the “\\?\” prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs.

Because it turns off automatic expansion of the path string, the “\\?\” prefix also allows the use of “..” and “.” in the path names, which can be useful if you are attempting to perform operations on a file with these otherwise reserved relative path specifiers as part of the fully qualified path.

Many but not all file I/O APIs support “\\?\”; you should look at the reference topic for each API to be sure.

Note that Unicode APIs should be used to make sure the “\\?\” prefix allows you to exceed the MAX_PATH.”

Senza specificare nel path il prefisso \\?\ la chiamata fallisce generando un’eccezione System.NotSupportedException come mostrato in Figura 9.

Figura 9: Esempio di creazione NTFS Alternate Data Stream tramite VB.NET con NAmespace System.IO

Per quanto riguarda invece l’enumerazione dei NTFS Alternate Data Streams in un’applicazione .NET sarà necessario utilizzare le API di sistema Win32 FindFirstStreamW, FindNextStreamW tramite PInvoke, a riguardo si veda .NET Matters: Iterating NTFS Streams | Microsoft Learn un vecchio articolo di Stephen Toub pubblicato su MSDN Magazine nel gennaio 2006.

Un’altra fonte di informazioni utile per lo sviluppo di applicazioni .NET che necessitano di gestire dei NTFS Alternate Data Stream è il progetto GitHub Richard Deeming GitHub – RichardD2/NTFS-Streams: A .NET library for working with alternate data streams on NTFS file systems.

NTFS Alternate Data Streams e impatti sulla sicurezza

Come abbiamo visto in NTFS ogni file/directory può contenere più named data streams (ovvero alternate data streams) oltre al main o unnamed stream e gli alternate data streams non sono mostrati dalle normali viste, ovvero non sono visibili in Esplora file e se non si utilizza il parametro /R il comando DIR non li visualizza.

Questo ha fatto sì che gli NTFS Alternate Data Streams venissero utilizzati da utenti malevoli per varie finalità.

Occultamento e living-off-the-land (LOTL)

Gli NTFS Alternate Data Streams possono essere usati per nascondere file/payload e talvolta eseguirli tramite strumenti di sistema, ovvero usando tecniche Living Off The Land Binaries and Scripts (LOLBAS).

Il MITRE ATT&CK cataloga ad esempio la tecnica “Hide Artifacts: NTFS File Attributes (T1564.004)“, mentre il MITRE Cyber Analytics Repository descrive i pattern d’esecuzione e rilevazione nelle analitiche CAR-2020-08-001: NTFS Alternate Data Stream Execution – System Utilities e CAR-2020-08-002: NTFS Alternate Data Stream Execution – LOLBAS | MITRE Cyber Analytics Repository.

Come mostrato negli articoli di Oddvar Moe Putting data in Alternate data streams and how to execute it e Putting data in Alternate data streams and how to execute it – part 2 gli strumenti di sistema tramite cui possono essere creati ed eseguiti gli NTFS Alternate Data Streams sono diversi, infatti oltre a quelli che abbiamo già visto in precedenza come type, Notepad.exe e PowerShell, Oddvar Moe ha fatto prove con esito positivo con i seguenti altri comandi o utility di sistema che consentono di accettare NTFS Alternate Data Streams come parametro tra cui Rundll32.exe, extrac32.exe, findstr.exe,sc.exe, Mavinject.exe, Forfiles.exe, Wscript.exe, Cscript.exe, MSHTA.exe start, etc.

Oddvar Moe ha raccolto nel seguente Gist i metodi che ha trovato per creare, estrarre ed eseguire NTFS Alternate Data Streams Execute from Alternate Streams.

Sempre sui temi Living Off The Land Binaries, Scripts and Libraries (LOLBAS) si veda il progetto https://lolbas-project.github.io/ in cui è possibile trovare tra le varie tecniche anche quelle afferenti alla tecnica del MITRE ATT&CK “Hide Artifacts: NTFS File Attributes (T1564.004)“.

Evasione/alterazione di marcature di provenienza (Mark-of-the-Web)

Come abbiamo visto il Mark-of-the-Web (MOTW) usa l’NTFS Alternate Data Stream denominato “Zone.Identifier” per indicare che un file proviene da Internet e abilitare protezioni (es. blocco macro in Office). Nel caso in cui l’NTFS Alternate Data Stream venga eliminato o aggirato le protezioni possono non attivarsi. Il MITRE ATT&CK cataloga ad esempio la tecnica “Subvert Trust Controls: Mark-of-the-Web Bypass (T1553.005)“.

Esfiltrazione e staging dati

Gli NTFS Alternate Data Streams possono fungere da “sotto-file” per raccogliere o impacchettare dati in preparazione all’esfiltrazione, minimizzando gli indicatori a vista. L’ articolo Using Alternate Data Streams in the Collection and Exfiltration of Data scritto da Dustin D. Updyke e Molly Jaconski e pubblicato dal Software Engineering Institute (SEI) presso la Carnegie Mellon University spiega il modello di accesso/esecuzione degli ADS e il loro impiego in raccolta/esfiltrazione.

Approfondimenti

Varie sono gli articoli e i white paper sull’argomento, ma segnalo di seguito alcuni riferimento per ulteriori approfondimenti:

• L’articolo Windows ::DATA Alternate Data Stream pubblicato dall’Open Worldwide Application Security Project (OWASP) foundation.
• Il white paper Alternate Data Streams: Out of the Shadows and into the Light scritto da Ryan Means e pubblicato dal SANS (SysAdmin, Audit, Network, Security) Institute nel 2004, l’articolo è ancora disponibile al seguente Alternate Data Streams: Out of the Shadows and into the Light sul sito del Global Information Assurance Certification (GIAC) un provider di certificazioni in ambito fondato dal SANS.
• L’articolo Alternate Data Streams ? Adversary Defense Evasion and Detection scritto da Ehsaan Mavani e pubblicato dal SANS Internet Storm Center nel 2025 rimarca l’uso crescente dei NTFS Alternate Data Streams nella evasione e negli attacchi stealth.

Mitigazione contro gli abusi dei NTFS Alternate Data Streams

Innanzitutto, va detto che gli NTFS Alternate Data Streams sono di fatto una caratteristica nativa di NTFS e sono utilizzati in varie feature del sistema operativo Windows quindi non possono essere rimossi o disabilitati.

Le mitigazioni contro gli abusi dei NTFS Alternate Data Streams sono di tipo difensivo e di controllo; quindi, occorre come prima cosa assicurarsi che sui sistemi siano presenti Antivirus o EDR (Endpoint Detection and Response) che siano in grado di individuare esecuzioni da NTFS Alternate Data Streams come il tentativo di avviare processi del tipo file:stream.exe.

Inoltre, occorre implementare configurazioni e abilitare funzionalità volte all’hardening del sistema e alla riduzione della superficie d’attacco:

• Abilitare le Attack Surface Reduction rules di Microsoft Defender for Endpoint per impedire che script/tool abusino dei NTFS Alternate Data Streams, a riguardo si veda Use attack surface reduction rules to prevent malware infection – Microsoft Defender for Endpoint | Microsoft Learn.
• Limitare strumenti LOLBAS (come wscript.exe, powershell.exe) che possono leggere/eseguire contenuti da NTFS Alternate Data Streams.
• Integrare regole di rilevazione basate su MITRE ATT&CK, si veda la sezione Detection con ID ‘DS0009’, Data Source ‘Process’ e Data Component ‘Process Creation’ della tecnica citata precedentemente “Hide Artifacts: NTFS File Attributes (T1564.004)“.
• Preservare e sfruttare il Mark-of-the-Web (MOTW) evitando di eliminare o ignorare l’NTFS Alternate Data Stream Zone.Identifier che indica provenienza Internet e permette di bloccare le macro nei file marcati da MOTW.
• Implementare query/analisi (Splunk, Sysmon) per individuare esecuzioni di NTFS Alternate Data Streams, a riguardo si vedano le regole e le query (es. in Splunk o Sysmon) mostrate in CAR-2020-08-001: NTFS Alternate Data Stream Execution – System Utilities e CAR-2020-08-002: NTFS Alternate Data Stream Execution – LOLBAS | MITRE Cyber Analytics Repository. Per informazioni sul monitoraggio tramite Splunk e Sysmon si vedano Detection: Windows Alternate DataStream – Executable Content | Splunk Security Content e Sysmon and Alternate Data Streams – SANS Internet Storm Center.

Per quanto riguarda l’uso di Sysmon va precisato che sebbene non vi siano indicazioni in tal senso sulla pagina ufficiale del tool da prove fatte da fonti indipendenti e comunitarie Sysmon sembra registrarela creazione di un NTFS Alternate Data Stream solo se questo è testuale e il contenuto è inferiore ad 1 KB. Il motivo è legato al fatto che l’intento è quello di catturare gli streams di tipo Mark Of The Web (MOTW) ovvero quelli denominati Zone.Identifier. Una indicazione in tal senso la si trova nel già citato Sysmon and Alternate Data Streams – SANS Internet Storm Center e anche in SysmonCommunityGuide – File Stream Creation Hash, la pagina dedicata alla gestione del File Stream Creation Hash da parte di Sysmon (EventID 15) della TrustedSec Sysmon Community Guide.

Proof of Concept (POC) dei NTFS Alternate Data Streams

Come abbiamo visto l’uso dei NTFS Alternate Data Streams potrebbero essere utilizzati per scopi malevoli sebbene dal punto di vista dell’Antivirus l’applicazione che ne fa uso non esegua operazioni che violino palesemente la sicurezza.

A titolo di esempio ho scritto un’applicazione VB.NET basata sul .NET Framework 4.8 che ho reso disponibile sul mio GitHub ermannog al seguente repository ermannog/POC-NTFS-ADS: Proof of Concept of NTFS Alternate Data Stream.

L’applicazione realizza un semplice keylogger sfruttando i Windows Hooks che consentono di catturare e gestire eventi del sistema operativo, come ad esempio messaggi relativi alla tastiera o al mouse, prima che questi raggiungano le applicazioni a cui sono destinati. Anche in questo caso, come per i NTFS Alternate Data Streams, la funzionalità che sta alla base dei Windows Hooks, tramite cui ho implementato un keylogger, non è classificabile come potenzialmente malevola in quanto il sistema la usa per varie attività di seguito alcuni esempi e per ulteriori approfondimenti si veda Hooks Overview – Win32 apps | Microsoft Learn:

• Monitorare i messaggi a scopo di debug
• Fornire supporto per la registrazione e la riproduzione di macro
• Fornire supporto per il tasto di aiuto (F1)
• Simulare l’input tramite mouse e tastiera
• Implementare un’applicazione di training basata su computer

La particolarità dell’applicazione di POC è quella di registrare il log dei tasti premuti su un NTFS Alternate Data Stream dell’eseguibile stesso e in particolare crea più stream con un identificativo hash univoco basato sulla data di avvio del POC, sul nome utente della sessione in cui è avviato il POC e sul nome computer su cui si sta eseguendo il POC. La creazione di una NTFS Alternate Data Stream collegato all’eseguibile può contribuire ad occultare maggiormente in fatto che l’applicazione stia registrando il log dei tasti su disco in quanto il nome dello stream simile a quello dell’eseguibile potrebbe indurre in confusione.

Figura 10: POC NTFS Alternate Data Stream – Keylog su stream

L’applicazione di POC permette di avviare e arrestare il keylog e aprire o eliminare gli NTFS Alternate Data Stream generati.

Figura 11: POC NTFS Alternate Data Stream – Gestione degli streams generati

Copiando l’applicazione in altra posizione di vengono copiati anche gli stream a patto che la nuova destinazione sia su un file system NTFS, si noti che se la copia viene fatta in una sessione Desktop Remoto gli stream vengono persi perché in questo caso il file viene prima copiato in memoria.

Ovviamente per ovviare alla perdita degli stream nelle copie su destinazioni non su file system NTFS l’applicazione potrebbe essere semplicemente modificata per inviare in Internet il contenuto degli streams.

Un approccio di questo tipo potrebbe essere poi semplicemente occultato in una applicazione d’apparenza innocua, ma che è stata incautamente scaricata da un sito Internet malevolo. Queste considerazioni, bastate su semplice esempio, evidenziano come sia importante in determinati scenari monitorare l’utilizzo dei NTFS Alternate Data Stream nel sistema.

Considerazioni finali

Gli NTFS Alternate Data Stream possono essere visti come una funzionalità che consente alle applicazioni e al sistema di gestire metadati per gli scopi più disparati. Questa finalità dei NTFS Alternate Data Stream implica che sia necessario che la User Experience destinata all’utente ne eviti la visualizzazione. Proprio quest’ultima caratteristica implica che gli NTFS Alternate Data Stream possano essere utilizzati in modo malevolo per occultare ed esfiltrare dati o come vettore per l’esecuzione di codice malevolo.

Ovviamente gli NTFS Alternate Data Stream possono essere creati solo su volumi formattati NTFS, ma questo è di fatto uno dei prerequisiti per l’installazione di Windows quindi occorre non sottovalutare l’uso malevolo di tali stream.

Va però precisato che NTFS non è l’unico file system ad utilizzare funzionalità simili ai NTFS Alternate Data Stream:

• in ambiente macOS il vecchio HFS+ utilizzava i resource fork, equivalenti ai NTFS Alternate Data Stream;
• sempre in ambiente macOS Il più recente APFS non prevede i resource forks, ma supporta gli extended attributes (xattr), utili per metadati aggiuntivi;
• in ambiente Linux vari filesystem (ext2/3/4, XFS, Btrfs, ZFS, ecc.) supportano gli extended attributes (xattr), ovvero coppie nome-valore legate a file o directory.

Anche se i resource fork (macOS) e gli xattr (Linux/macOS) non riproducono pienamente le capacità dei NTFS Alternate Data Stream (come l’esecuzione diretta di stream nascosti), consentono comunque di archiviare dati invisibili a utenti meno esperti.

A riguardo il MITRE ATT&CK cataloga ad esempio la tecnica “Hide Artifacts: Extended Attributes, Sub-technique T1564.014” utilizzabile in ambienti Linux e macOS.