paint-brush
Breaking Software Integrity with NTFS Streamsby@SecEvangelism
2,571 reads
2,571 reads

Breaking Software Integrity with NTFS Streams

by Chris KubeckaFebruary 24th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

For security purposes, many applications use hashing to ensure software integrity. On Windows based NTFS file systems, there is a weakness. Files can be hidden within or behind files. Under <strong>certain circumstances</strong>, these hidden files can be hashed and remain hidden. Intrigued yet? As luck would have it, WikiLeaks leaked out part of an old CIA operations manual during a mega disclosure in 2016/17. One leaky technique caught my eye, <a href="https://wikileaks.org/ciav7p1/cms/page_13763461.html" target="_blank">hiding data in NTFS data streams</a>. The full instructions were lacking; however, since some of us have secretly have enjoyed using this technique for many years, it was time to spread the joy. Microsoft kindly posted a <a href="https://blogs.technet.microsoft.com/askcore/2013/03/24/alternate-data-streams-in-ntfs/" target="_blank">blog</a> on it back in 2013 from a developer perspective. Not an evil (puts hoodie on) hacker perspective. Quick, hide under the covers from the evil hackers and everything will be alright. We’re going to get all CIA level and break some sh*t.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Breaking Software Integrity with NTFS Streams
Chris Kubecka HackerNoon profile picture

For security purposes, many applications use hashing to ensure software integrity. On Windows based NTFS file systems, there is a weakness. Files can be hidden within or behind files. Under certain circumstances, these hidden files can be hashed and remain hidden. Intrigued yet? As luck would have it, WikiLeaks leaked out part of an old CIA operations manual during a mega disclosure in 2016/17. One leaky technique caught my eye, hiding data in NTFS data streams. The full instructions were lacking; however, since some of us have secretly have enjoyed using this technique for many years, it was time to spread the joy. Microsoft kindly posted a blog on it back in 2013 from a developer perspective. Not an evil (puts hoodie on) hacker perspective. Quick, hide under the covers from the evil hackers and everything will be alright. We’re going to get all CIA level and break some sh*t.

Self explanatory…

Let’s take it one step further than the innocently drafted MS blog post and throw in some hashing on the root of a drive. Microsoft has had a tool out called SysInternals Streams.exe available for free download which can be used with this technique. It can help detect NTFS Streams and verify the results.

If an attacker wants to hide data in plain sight, this is a sneaky little method to consider, based on the situation and target. NTFS Alternative Data Steams (ADS) is also referred to as Forking. Yes, it has been used maliciously in the past, great question. I decided to update the original posting with full instructions. Then take it up a notch to show you how to break file integrity by using SHA256++ with NTFS ADS.

And Ants

Formatted after the CIA Operations manual for your reading pleasure.

NTFS Alternate Data Streams (ADS)

Exfiltration, manipulation of software and file integrity, obfuscation

Alternate Data Streams on the Root of the Drive

Depending on the target and system configuration. An NTFS alternate data stream (ADS) should be considered a viable method to hide data and foil protection or alerting. Particularly cases where protection present relies heavily or is dependent on file hashing as a method to verify file integrity. Whether it’s for exfiltration, manipulation of integrity, obfuscation or general trade-craft. Great for bypassing many security controls and pivoting deeper into a target network.

There are several methods. One of the easiest is from the command prompt. Work in the root of a hard drive directory. This can also be accomplished remotely if you already have remote access to the victim.

Gain access to the victim local or remote

Using a victim D: data drive as an example, due to limited privileges. The attacker has a file of IP addresses, which are additional Command and Control domains related to both StoneDrill and NewsBeEF, in addition to Kaspersky’s list. As part of a targeted attack, the attacker needs to get this list onto a victim machine silently. The attack can also be done with PowerShell or a batch file. Renaming Batch files once they are on the system to bypass security controls is normally easy with limited access. If it’s an executable, you can also use this technique with PSExec.exe. Many anti-malware and other protection will catch PSExec, but not always.

Sample contents of the evil file

Perform the NTFS ADS and hide the Evil file

Open a command prompt local or remote on the victim machine. The attacker, for ease of use. Has placed the text file of Command and Control servers in the root of D, naming it evilcancips.txt

Create the file you want to hide the evil file in. In this example, we will call this file: testfile.txt. Type at the root the following commands. The command first creates the innocent file. The second command hides the evil file behind the innocent looking file.

ECHO “This is a test file” >testfile.txt

ECHO “This is the evil text in the ADS file” >testfile.txt:evilcancips.txt

Verify the NTFS ADS Stream worked

Check what the directory shows in the command prompt. It should look the same as before the NTFS ADS

What the directory looks like in the GUI

Although it is possible to display ADS NTFS streams/Forks easily in a command prompt. This is beyond the normal user level and most technical as well. The technique is still somewhat obscure as a method for attack or espionage. The GUI portion of Windows will not readily show the NTFS ADS file.

At the command prompt, ensure the NTFS ADS stream worked. It will show a double line with the original file, then show the hidden file.

dir /r

When practising, also verify using Streams.exe. In this example, Streams.exe was installed.

Open a command prompt and charge the working directory to where Streams is located. Then execute Streams against the innocent looking file: testfile.txt

streams d:\testfile.txt

Hashing to F*ck with File Integrity

To ensure you hid the evil file on the victim machine. Hash the innocent file prior to NTFS ADS, recording the hash. The default hashing level in PowerShell is Sha256. Because modern Windows based victim machines have PowerShell. No additional tools are required to hash. The attacker does not need to be an administrator to use the PowerShell to hash a file. PowerShell is not being run as an administrator in this example. Most users and enterprise administrators are still unfamiliar with PowerShell and leave functionality default configured in a manner an attacker could exploit.

At a PowerShell prompt, use the cmdlet Get-FileHash, then the -Path where the original file is located.

Get-FileHash -Path d:\testfile.txt

After the NTFS ADS, hash the original file again where the evil file is hidden.

The hash will show the same hash. 9BB114C0FE4F787EF64A43F310EA81F273FC87001503A141A125D9689AE8DFEF

If the victim uses the NTFS file system, which most modern Windows uses. Anyone can hide whatever evil file they wish into an innocent one in a root directory like the examples shown. The victim nor attacker can display the hidden file in the GUI. Defence is based on if the target protection mechanisms can recognize the evil file or behaviour. Rarely is dir /r used. The file can be hidden and hashed with MD5, SHA1, SHA256, etc… The evil file will look hidden. This technique can be easily recreated and practised prior to live testing on the target.

Conclusion (cue evil laugh)

Relying on hashes for file integrity does not mitigate this risk or attack technique completely. The Hash process in a way hides the data further by giving a false impression of limiting risk. Many security products rely on hashing for file integrity. It’s accepted best practice. Now everyone knows it can be manipulated under certain conditions. Like many security researchers who fear government stockpiling of vulnerabilities or misuse by dodgy criminals. The 2012 paper I wrote on this topic was kept private. Sh*t can get evil real quick. Look at Google, they turned so evil, they had to change their name.

2012 , that’s almost last century!

I guess I don’t need that password or encrypt that old paper any longer. Thanks CIA & WikiLeaks :-)

Enjoyed the read, leave a clap (or 50) and dive into the comments. Join me on Goodreads curling up to a good book or on Peerlyst for technical community discussions.