Hidden in Plain Sight: How Attackers Weaponize Alternate Data Streams to Hide Malware

A while back I wrote about how Windows uses Alternate Data Streams to tag files downloaded from the internet — that Zone.Identifier trick that quietly labels your files as "came from the web." A lot of people found it interesting because it's one of those Windows features that silently runs in the background and most users never think about.

But here's the thing about ADS that I didn't cover in that article, and honestly it's the part that should make defenders a little nervous: the exact same feature that Microsoft uses to label your downloads? Attackers use it to hide malware. And they've been doing it for years, targeting major organizations, hiding ransomware payloads, and evading security tools — all inside a feature built right into Windows.

So if you read the first article and thought "huh, cool Windows feature" — this one's the darker chapter. Let's talk about how attackers actually weaponize ADS.

Section 1 — Quick Recap: What Is ADS Again?

Quick refresher before we get into the attack stuff. Every file on an NTFS volume (which is basically every modern Windows system) can carry more than one "stream" of data. You have the main data stream — that's the file content you normally see and interact with. But NTFS allows additional streams to be attached to the same file, hidden under a colon syntax like this:

filename.txt:hiddenstream

Most Windows applications, Windows Explorer, and a lot of security tools only look at the primary data stream. The hidden streams? Completely invisible to them. You can't see their size in Explorer, they don't show up in a normal DIR listing, and they travel with the file if you copy it on NTFS.

That last part is key. Zone.Identifier is the legitimate example — Windows writes it automatically when you download a file.

But the exact same mechanism works for an attacker who wants to tuck a malicious executable inside what looks like a completely harmless text file. MITRE ATT&CK tracks this as T1564.004 — Hide Artifacts: NTFS File Attributes.

Section 2 — Four Ways Attackers Actually Use This

So how does this actually show up in real attacks? There are four main things attackers do with ADS, and they often chain them together in the same campaign. Here's how each one works in practice.

Section 3 — Executing Payloads with Windows' Own Tools (LOLBAS)

This is where it gets really uncomfortable for defenders. Hiding a file in an ADS is one thing — but attackers don't even need a separate dropper to execute it. Windows ships with a long list of native binaries that will happily run content directly from an alternate data stream. The LOLBAS project (Living Off the Land Binaries and Scripts) documented a whole category of these, and it's a wild read.

The idea of LOLBAS is simple: if you can make a legitimate, signed Windows tool do your dirty work, you blend in perfectly. No sketchy executables, no unsigned code. Just Windows doing what Windows does — except the attacker is the one pulling the strings.

The classic example is rundll32.exe. This is the standard Windows utility for loading DLL files. Normally harmless. But if you point it at an ADS path, it'll execute whatever DLL is hiding in that stream — and to most security tools, all they'll see is rundll32 running, which is totally normal. Same story with wscript, certutil, bitsadmin, and others. They all have documented capability to interact with ADS.

Section 4 — Real Malware That Did This

This isn't theoretical. MITRE ATT&CK lists over a dozen named malware families that used ADS in real campaigns. Here are three of the most well-known examples — and they're a good reminder that this technique has been used by everyone from sophisticated APTs to big ransomware operations.

Section 5 — Okay, How Do We Actually Find These?

So now that we know what's possible, the obvious question is: how do defenders catch this? The good news is there are several ways to detect ADS abuse, both on live systems and during forensic analysis. The key is knowing where to look — because default Windows tooling doesn't make it easy.

The two built-in Windows commands that surface ADS data are dir /r in CMD, and Get-Item with the -Stream parameter in PowerShell. These will show you streams you wouldn't normally see. For forensic analysis, Sysinternals Streams.exe is the go-to tool for getting a clean list of non-standard streams across a directory.

On the detection and hunting side, MITRE's CAR analytics and tools like Sysmon give you command-line argument visibility — which is where ADS execution leaves its traces. When rundll32 or wscript get called with a path containing a colon followed by a stream name, that's your indicator. Normal legitimate calls to these tools don't look like that.

Conclusion

The thing that makes ADS such an effective attacker technique is the same thing that made Zone.Identifier interesting in the first article — it's hidden in plain sight. The file is right there on the filesystem. You can see it, you can open it, everything looks normal. The malicious content is just... attached to it in a place most people never think to look.

The good news is that with the right tooling — Sysmon, EDR with command-line visibility, or forensic tools that parse the MFT properly — ADS abuse leaves traces.

But the bigger takeaway is this: the security gap here isn't really technical — it's awareness. Most security teams know about ADS, but how many have actually tuned their detection rules for it? How many have checked whether their EDR surfaces ADS execution events? If the answer is "not sure," that's worth a few hours of your time to find out.

Because if ransomware groups like ALPHV and WastedLocker are using this technique in real campaigns against real companies, you can bet the less-famous threat actors are too.

---------------------------------------------Dean-----------------------------------------------------------