What is an NTFS alternate data stream, and how does Windows use one to mark files downloaded from the internet?

## A file is a set of streams Most people picture a file as one sequence of bytes plus metadata. NTFS does not work that way. Internally an NTFS file is a record in the Master File Table holding a set of *attributes*, and file content is stored in `$DATA` attributes — plural. The unnamed `$DATA` attribute is the content every tool shows you. Any additional `$DATA` attribute has a name, and that is an alternate data stream (ADS). The naming syntax exposed to userland is `path:streamname`, with a fully explicit form of `path:streamname:$DATA`. The default stream can be written explicitly as `file.txt::$DATA`. Streams are addressable by the normal file APIs, so anything that can open a path can open a stream: ``` echo hidden > notes.txt:secret more < notes.txt:secret dir /R ``` Properties worth knowing: - Streams belong to the file, so they share one security descriptor, one set of timestamps and one hard-link identity. You cannot ACL a stream separately from its file. - They consume real allocation, but `dir` and Explorer's size column report the default stream. A 1 KB file can be sitting on megabytes of stream data. - Directories can carry streams too. - They are an NTFS feature (also present on ReFS in a limited form); FAT32 and exFAT have no equivalent. ## Mark-of-the-web The feature most engineers actually meet is the `Zone.Identifier` stream. When Edge, Chrome, Outlook or a modern archive tool writes a file that came from outside the machine, it attaches a stream whose content is an INI fragment: ``` [ZoneTransfer] ZoneId=3 HostUrl=https://example.com/setup.exe ``` `ZoneId` maps to the old Internet Explorer security zones: 0 local machine, 1 local intranet, 2 trusted sites, 3 internet, 4 restricted sites. Anything at 3 or above is treated as untrusted content. A surprising amount of Windows security UX hangs off that one stream. Office opens the document in Protected View instead of enabling macros. SmartScreen evaluates the executable before running it. The script hosts and some installers warn. Right-clicking the file and ticking **Unblock** — or running PowerShell's `Unblock-File` — simply deletes the stream, after which the file behaves like anything you authored locally. This is also the mechanism behind a class of "it works on my machine" support tickets: a colleague emails a ZIP, the recipient extracts it with a tool that propagates the mark to every extracted file, and suddenly a build script or DLL is treated as untrusted. ## Why streams silently disappear Because the mark is metadata that only NTFS can store, it is lost whenever the file crosses a boundary that cannot carry streams: - copying to FAT32 or exFAT (a USB stick, an SD card); - most archive formats — a plain ZIP stores the default stream only, which is why zipping and unzipping is a folk remedy for "unblocking" a whole folder; - transfers over protocols and tools that copy only the primary stream. The inverse is the security worry: because streams are hidden from casual listings, they have been used to stash payloads. `dir /R` in cmd, and `Get-Item -Stream *` in PowerShell, are how you look. Modern endpoint tooling inspects streams, so this is more of a forensics topic than a live evasion technique — but an interviewer asking about ADS is usually probing whether you know files can carry content that `dir` does not show. ## What to say in an interview Lead with the model: NTFS files are multi-stream, the alternate stream is addressed with a colon, it shares the file's ACL and timestamps, and it is invisible to size-based tooling. Then give the one use everybody has actually hit — `Zone.Identifier` and the downloaded-file warnings — and close with the practical consequence that copying through a non-NTFS filesystem or a ZIP silently strips it. That sequence shows you understand the mechanism rather than having read a list of NTFS features.