Dissecting the WinRAR ADS Attack: How Malware Hides in File Streams and What to Do About It

A recent report described attackers abusing WinRAR archives and NTFS alternate data streams to hide malware. The important part is not the archive brand. It is the boundary where a file is written to an NTFS volume and the visible content is no longer the whole story.

If your triage still treats a filename as the complete object, you can miss the payload living in a named stream. That is why this pattern matters on Windows systems, even when the lure or operator changes from one campaign to the next.

What the reported WinRAR ADS abuse is doing

Why this attack pattern matters on Windows systems

NTFS alternate data streams are old Windows behavior, but they still surprise teams because most day-to-day tools only show the main file content. A malicious archive can drop a file that looks harmless in Explorer while the useful bytes sit in filename:streamname.

That matters for two reasons:

1. Visibility is weak by default. Many users, helpdesk tools, and even some security workflows only inspect the visible file.
2. Execution is separate from storage. A hidden stream does nothing on its own, but it can carry a loader, script content, or secondary payload that another process later reads and runs.

The report is useful not because it invents a new filesystem trick. It shows how well the trick still works when paired with a trusted decompression workflow. If the archive is opened on NTFS and the follow-up tooling preserves or consumes the stream, the operator gets a place to hide without needing exotic malware.

What a normal RAR extraction looks like versus a suspicious one

A normal extraction leaves behind files you can enumerate with Explorer, dir, or Get-ChildItem. The file names, sizes, and hashes line up with what you expect from the archive contents.

A suspicious extraction often has one or more of these signs:

• a visible file whose main content looks benign or empty
• an unexpected named stream on that file
• a parent process tree that goes from archive handler to script engine or shell
• files extracted into a user-writable path and executed soon after
• evidence that the visible file and the hidden stream do different jobs

The key point is that the archive itself is just the delivery container. The malicious part becomes relevant when the archive is extracted onto a filesystem that supports streams and some later step reads from them.

NTFS alternate data streams in practical terms

Main stream vs named streams

On NTFS, every file has a default unnamed stream. That is the content most people mean when they say “the file.”

A file can also have one or more named streams. Those streams live behind the same filename, but they are separate data forks. In practical syntax, you will see something like:

• report.txt for the main stream
• report.txt:notes for a named stream

Windows APIs can read and write both. Explorer usually shows only the main file, which is why ADS is useful to attackers and annoying for defenders.

The storage model is not malicious by itself. Windows uses streams for things like downloaded file zone markers. The risk starts when a hidden stream is used as a place to stash content that should have been visible, scanned, or blocked.

Why ADS is easy to miss in file browsers and casual inspection

Most file browsers are not stream-aware in the way an incident responder needs them to be. They show you the file, its icon, and maybe its visible size. They do not tell you whether the file has a second stream unless you ask a different tool.

That gap creates a false sense of completeness. A triage note might say “the file was just a PDF” or “it was only a text file,” when the real question should have been: what streams existed on disk after extraction?

This is especially easy to miss when the extracted object looks boring. A small script stub, a decoy document, or an empty visible file can all hide a much more interesting named stream.

Which filesystem and tooling assumptions make ADS attractive to attackers

ADS is attractive because it depends on a few assumptions that are very common in Windows environments:

• the endpoint uses NTFS
• the archive is extracted locally
• the extraction path is user-writable
• the user or a script later trusts the visible file name
• the review process does not enumerate streams

That combination shows up often enough to matter. A team may scan the downloaded archive but not the post-extraction filesystem object. Or they may check the file’s visible hash and miss the stream because the hash only covers the default content.

Cross-platform transfers also help the attacker by creating confusion. If the file is copied to a filesystem that does not support streams, the evidence can disappear. That does not make the original extraction safe; it just makes later inspection harder.

How an archive can carry hidden payloads

The archive-to-filesystem boundary where metadata becomes abuse surface

The archive format is not the only object that matters. The dangerous moment is the conversion from archive entry to filesystem entry.

At that boundary, the extraction tool decides:

• what file name to write
• where to place it
• whether metadata is preserved
• whether named streams survive
• whether the extracted file is allowed to run or is just staged

That is the point where a hidden payload can move from “bytes inside an archive” to “bytes on a live NTFS volume.” Once that happens, defenders are no longer looking at a compressed container. They are looking at a filesystem artifact that may have more than one stream.

Common delivery patterns to discuss without overclaiming the exact chain

I would not assume one universal operator workflow from the headline alone. The public report is about abuse of WinRAR and NTFS ADS, but it does not mean every sample uses the same sequence.

The broader patterns worth considering are:

• a decoy file visible to the user and a hidden stream carrying the real content
• an archive that drops a file which later causes a stream to be read or executed
• a script or loader that checks the visible file name but pulls bytes from a named stream
• a delivery chain that relies on a user opening a “normal-looking” archive and then following prompts or attachments after extraction

The exact lure is less important than the boundary test. If you can prove that extraction writes named streams, and that later execution trusts those files, you have found the abuse surface.

Where WinRAR fits in the extraction flow

WinRAR matters because it is a common archive handler in Windows workflows, not because the brand itself is special. Users trust it. Helpdesks trust it. Malware authors like anything that sits inside a normal decompression step.

In a practical chain, WinRAR or another archive tool is the ingress point. It takes a container file and emits filesystem objects. If the extracted result includes a named stream, the visible file is no longer enough to understand the object.

That is why patching the archive tool matters, but it is not the whole defense. The larger problem is still what got written to disk, where, and what executed after that.

Safe lab setup for inspecting the behavior

Build a disposable Windows VM on NTFS only

If you want to study the mechanics, set up a clean Windows VM with:

• an NTFS system volume
• no shared folders
• no cloud sync folders
• no production data
• a snapshot you can roll back

Do not test on exFAT, FAT32, removable media, or a synced download folder if your goal is to understand NTFS streams. Those environments can hide the behavior or remove the evidence entirely.

The goal of the lab is not to build malware. It is to verify that your inspection tools can see what Explorer does not show.

Create a harmless test file with an alternate stream

You do not need anything dangerous to prove the point. A plain text file with a harmless named stream is enough.

New-Item -Path C:\Temp\ads-lab -ItemType Directory -Force | Out-Null
Set-Content -Path C:\Temp\ads-lab\visible.txt -Value "visible content"
Set-Content -Path C:\Temp\ads-lab\visible.txt -Stream note -Value "harmless stream data"

Get-Item -Path C:\Temp\ads-lab\visible.txt -Stream *
Get-Content -Path C:\Temp\ads-lab\visible.txt -Stream note

What you are checking here is simple:

• the main file still exists and is readable
• the named stream is listed separately
• the stream content can be queried directly
• the visible file alone does not tell the full story

If you later copy or extract the file into another NTFS location, run the same stream listing again. That gives you a baseline for how your tools behave.

Inspect the extracted results with built-in Windows commands

The built-in commands are enough for first-pass inspection.

dir /r C:\Temp\ads-lab

/r is the important part. It shows alternate streams in a way Explorer does not.

You can also use PowerShell:

Get-Item -Path C:\Temp\ads-lab\visible.txt -Stream *

And if you want to read the stream directly:

Get-Content -Path C:\Temp\ads-lab\visible.txt -Stream note

For archive investigations, compare the directory before and after extraction. If the archive handler created a file and a hidden stream, dir /r will usually expose the difference even when the folder view looks normal.

Detecting ADS abuse on an endpoint

PowerShell and cmd checks for hidden streams

When I am checking a suspicious download directory, I start narrow and then expand.

Get-ChildItem -Path C:\Users\Public\Downloads -File -Recurse -ErrorAction SilentlyContinue |
  ForEach-Object {
    Get-Item -LiteralPath $_.FullName -Stream * -ErrorAction SilentlyContinue
  }

That is not a fleet-wide hunting query. It is a practical inspection pattern for a suspicious subtree.

You can also use dir /r against the folders most likely to contain extracted archives:

• Downloads
• Desktop
• Temp
• shared project folders
• email attachment staging paths

What you are looking for is not just “a stream exists.” You are looking for streams on files that should not need them, especially if those files appeared right after archive extraction.

What to look for in archive extraction paths and parent-child process trees

The archive tool rarely acts alone. The process tree is usually where the story becomes clear.

Look for flows like:

• email client or browser downloading an archive
• archive handler opening or extracting it
• shell, script engine, or launcher starting afterward
• the payload running from a user-writable folder

The exact processes matter less than the shape of the tree. A normal user opening a document should not usually end in a script engine launching from a freshly extracted path.

Also pay attention to the file path. If the extraction lands in Downloads, AppData, Temp, or another user-controlled location, and execution follows immediately, you have a useful signal even before you prove ADS.

Defender, EDR, and Sysmon signals that are worth alerting on

If your tooling supports it, stream-aware telemetry is the cleanest way to catch this class of abuse.

Useful signals include:

• file creation events in archive extraction directories
• process creation for archive handlers followed by shell or script engines
• named stream creation or access
• execution from user-writable folders
• unusual command lines containing file paths with colons
• extracted files whose visible size does not match later behavior

Sysmon is especially useful here because FileCreateStreamHash gives you visibility into stream creation when configured. That is a strong signal for IR because it tells you a named stream was actually written, not just theorized.

A good alert is not “WinRAR was used.” A good alert is “an archive was extracted, a named stream was created, and a process later executed from the same user-writable location.”

Practical forensic checks after a suspicious extraction

Confirm the filesystem type and the original archive source

Start with the boring question: what filesystem was the file written to?

If the endpoint is not NTFS, your ADS theory may be wrong, or the evidence may have been stripped later. Use the original host when possible and confirm the volume type before drawing conclusions.

Then trace the source of the archive:

• browser download history
• mail gateway or attachment logs
• endpoint download telemetry
• user browser cache
• EDR file creation timeline

A copied sample is not the same thing as the original artifact. If the file moved across systems, the named stream may already be gone.

Compare file hashes, timestamps, and stream listings

Do not rely on a single hash of the visible file. On Windows, Get-FileHash checks the default content, not every stream attached to the file.

A better sequence is:

1. list the streams
2. hash the visible file
3. capture the stream contents
4. note timestamps from the original host
5. compare extraction time to execution time

If you have multiple samples, compare the stream names as well as the file names. A common mistake is to say “the file hash is known” when the stream that mattered was never hashed.

Verify whether the visible file and the hidden stream behave differently

This is where the abuse becomes concrete.

The visible file may be:

• a decoy document
• a zero-byte placeholder
• a legitimate-looking configuration file
• a launcher that appears inert by itself

The hidden stream may hold:

• text used by a later script
• a binary blob
• instructions for a dropper
• content that another process reads directly

If you are doing forensics, do not execute anything from the stream on a live endpoint. Copy it into a controlled analysis environment, hash it, and inspect it as data first. The point is to prove the relationship between the visible file and the hidden content, not to run the sample.

Defensive controls that reduce the risk

Keep WinRAR and archive-handling tools updated

This sounds basic because it is basic. Archive tools sit on a dangerous boundary and should be updated like any other code that parses untrusted input.

Patch WinRAR and any other archive handlers in your environment. If you use more than one extractor, treat them all as part of the same exposure surface.

Updates alone will not solve ADS abuse, but they remove avoidable parsing bugs and reduce the chance that the tool itself becomes a second problem.

Restrict archive execution paths and attachment handling

The safest pattern is not “users can open anything and hope for the best.”

Better controls include:

• block direct execution from Downloads and Temp
• isolate email attachments before opening
• prevent auto-extraction in untrusted locations
• use application control for archive handlers and child processes
• require approval for scripts and binaries dropped from archives

If the archive lands in a folder that is allowed to execute code, the attacker gets a shorter path from extraction to impact.

Use controlled extraction locations and mark-of-the-web awareness

Have a standard staging folder for untrusted archives. Do not let users unpack directly into working directories or project roots.

Also pay attention to Mark-of-the-Web and similar download provenance markers. They are not perfect, but they are one more signal that a file came from outside the trust boundary.

The goal is simple: make extraction a deliberate step, not a casual double-click followed by execution.

Block or monitor script and binary execution from user-writable folders

If you only remember one hardening step, make it this one.

Most archive-based drops become dangerous when something later executes from a user-writable path. AppLocker, WDAC, or similar controls can make that much harder. Even when a payload lands successfully, blocking execution from Temp, AppData, and Downloads takes away the easy win.

That is especially important if your users regularly handle compressed files from email or chat. A stream hidden in an extracted file is only useful if some process trusts it enough to run it.

Add stream-aware scanning to security review and incident response

Your review and IR playbooks should include stream checks.

At minimum, that means:

• dir /r on suspicious folders
• PowerShell stream enumeration
• stream-aware EDR hunting
• Sysmon configuration that captures stream creation
• triage notes that record stream names, not just file names

If you have a sanitizer or quarantine workflow, decide whether it strips ADS or preserves it for evidence. Both approaches can be valid, but you need to know which one your process uses.

What developers and admins should change in their workflows

Treat archives as untrusted containers, not inert files

This is the mindset shift that matters.

An archive is not “just a file.” It is a container that can influence filenames, paths, metadata, and post-extraction behavior. That is true for RAR, ZIP, and every other format your users open every day.

Treat archives the way you treat any other untrusted input:

• validate source
• extract in a controlled place
• inspect the resulting filesystem objects
• do not trust the visible name alone
• never skip stream enumeration when Windows is involved

Build validation steps into download, decompression, and triage pipelines

A good pipeline is boring and explicit:

1. download into quarantine
2. record source and hash
3. extract to a staging directory
4. enumerate visible files and streams
5. scan the extracted tree
6. only then promote the files to a working location

That sequence gives you a chance to catch hidden content before it becomes execution. It also gives incident responders better data if something bad does slip through.

Normalize and log extracted file metadata before allowing execution

If your environment has build agents, triage hosts, or admin workstations that routinely unpack archives, log the metadata that matters:

• source URL or ticket ID
• user who initiated extraction
• archive handler used
• destination path
• visible file hash
• stream list
• process tree
• timestamp of extraction

That information is what lets you distinguish a harmless download from a staged drop. Without it, you are left guessing after the fact.

Limits, false positives, and edge cases

Legitimate software that uses ADS for metadata

Not every alternate stream is suspicious. Windows itself uses streams in ordinary workflows, and some applications do too.

A common example is the Zone.Identifier stream that marks files from the internet. Backup tools, developer utilities, and enterprise software can also create or preserve streams for their own reasons.

The rule is not “streams are bad.” The rule is “unexpected streams on freshly extracted archives deserve attention.”

Why not every ADS is malicious

A named stream by itself is not proof of compromise. You still need context:

• where the file came from
• what process created it
• whether the stream was expected
• whether execution followed extraction
• whether the stream content is benign metadata or active payload

Good detection uses ADS as one signal among several. Bad detection treats every stream as an incident and drowns the team in noise.

When cross-platform transfers strip the evidence

This is one of the easiest forensic traps.

If a file leaves NTFS and lands on FAT32, exFAT, a Linux filesystem, or a sync system that does not preserve alternate streams, the evidence may disappear. That means a later sample can look clean even though the original endpoint was not.

So if you suspect ADS abuse, acquire from the original host or from a disk image when possible. Do not assume a copied file tells the whole story.

Bottom line: the control point is extraction and execution, not just the archive

The reported WinRAR abuse is a good reminder that the file you click is rarely the whole object. On NTFS, a visible file can carry a hidden stream, and that stream can survive long enough to matter if your tools never look for it.

The practical defense is not complicated:

• update archive tools
• extract in controlled locations
• block execution from user-writable folders
• inspect streams with dir /r or PowerShell
• alert on stream creation and suspicious post-extraction process trees

If you only scan the archive, you miss the object that actually lands on disk. If you only trust the visible file, you miss the part that was hidden by design. The control point is the transition from archive to filesystem and from filesystem to execution. That is where your detection and hardening need to live.