Alternate Data Streams

I recently attended a web seminar by TripWire, and one of the things discussed was Alternate Data Streams. I was wondering if anyone knew how to track these things down. For those that do not know, it is a way to hide a file within a file. From what I understand, some hackers use the technique as an easy way to hide needed data in existing files. As an example, you could create a test file in notepad by typing notepad test.txt at a Run prompt, and type a few characters of data. It doesn't really matter what you put in it. Ok, now save it to any location, and you have a valid file, right? You can pull up a dir at a command prompt and see the file exists with a "reported size" and everything. Ok, now, using the same file at the beginning of the naming convention, you can open up an alternate data stream like so:
"notepad test.txt:test1.bat". The file extension can really be almost anything for the alternate file at the end; I just chose to use .bat for this example. You will notice that a blank notepad document will come up. Here you can enter some "secret" information and save after you are done. Now you can go back and do another dir to see that the file size has not even changed! To open the secret file, you can type "notepad test.txt:test1.bat" again and the secret information will be displayed. Trip Wire claims that their product will pick up these files, but does anyone out there have any other tool for this or know of any other way to check for these files?

This should be in "Microsoft security discussions" but in answer to your question:

There are command line utilities in the NT server resource kit (and probably now in the win2k server resource kit) that list, extract and delete Alternate Data Streams.

I don't think they're really a big security risk - normal programs never look in these streams for data, web servers don't serve data from them and they cannot normally be executed (although I think they can be present in an executable file)

Ok, thanks for letting me know where this should be. I felt it was an interesting tidbit of information, but, obviously, I didn't know what the implications were or I wouldn't have put it in this section of the forum. Also, thanks for the tip on how to find them. Have a Blessed one.

Quote:

---

and they cannot normally be executed (although I think they can be present in an executable file)

---

sure they can.

try this.

Code:

---

c:\winnt\system32>echo foo > test.txt

c:\winnt\system32>type notepad.exe > test.txt:notepad.exe

c:\winnt\system32>.\test.txt:notepad.exe

c:\winnt\system32>c:\winnt\system32\test.txt:notepad.exe

---

i'm actually on a win98 box right now - so the above is untested.

as far as dangerous...?

open up nt's process viewer...does it list test.txt or notepad.exe?

what does this mean? well, the default process viewer uses the primary stream for display. so an executable appended as an ads to say svchost.exe wouldn't be as noticeable.

here's something else to do.

rename test.txt to something else...let's say test.blah.

relaunch the ads application, and open or refresh the process-viewer. does it say test.blah or test.txt?

hmmm. very interesting, now we could create an empty or trash file in a temporary directory and name it svchost.exe, add the stream, and then rename the primary stream to something innocent (ado1952.tmp) and fill it with typical temp file trash. svchost will still be listed as the process, however not only is svchost the actual process running, it's also not the name of the primary stream. note if you move the file into a new directory the same effect does not occur.

the choice of using svchost.exe is that it's common to have 2 or more instances of it running.

but going back, if you have the right tools, auditing for this is rather simple...but very few admins in my experience actually do this.

another fun trick is to copy msscript.ocx or other com based dll, ocx, exe as a secondary stream, and then register it in com+ or other dcom host - provided that you can establish a session to the host (which we'd assume as you've gotten this far)...well i'll leave the rest up to the imagination. i've actually seen this in the field a few times - using microsoft's own products (libraries and services) as the rats. if the host isn't using com+, iis, msmq, extensively, then the maliciously registered application and components (usually something named "System Queuing Service" or similiar to blend in)tend to go unnoticeable for extended periods of time.

I don´t think it poses a security threat, but the use is good if you want to hide info! Although a little unpractical, if it info you would like to use more than once a week! :) Don´t think many admins search for them!

Now if you copy a file with alternate data streams do the alternate data stream get copied as well?

I must agree that it is a little impractical, and I can see how you could easily forget the path to your "hidden file." I did a preliminary search for a tool to locate the alternate data streams. I found a nifty little utility called lads. The link is below:

http://www.heysoft.de/nt/ntfs-ads.htm

Quote:

---

Now if you copy a file with alternate data streams do the alternate data stream get copied as well?

---

locally and on distributed fs, yes.

but there are instances where this does not happen - for instance web or ftp transfers.



as far as impractical...if it wasn't an issue it wouldn't have ever been presented. (at blackhat, at defcon, by TripWire, by Keydet [hate to bring his name up on these boards] who travels all over giving presentations on ADS, by myself in the context in which i present to others....99% of the time ADS provides the adequate shield to stay below the waves once i'm in. now, imagine being told that you've not only been compromised but that signatures show that the compromise actually occured 9 months ago. with the exception of gh's rootkit, ads is about as pre-fab as you are going to get to a public nt rootkit. what may seem impractical to you as an admin, is everyday, allday for experienced malicious hackers.

I see your point droby. The good thing is that we are implementing Tripwire, and I have found that it picks these up. I think I also mentioned about the tool I found called "lads" - it's very nice.

I'd like to point out a few things regarding Alternate Data Streams (ADSs):

1) It should be noted that Perl scripts, for example, could be hidden and subsequently executed on a target system using Alternate Data Streams. A mitigating factor is of course that the target system would need the relevant interpreter/compiler on their system in order to for this type of attack to be successful.

2) The main reason streams are supported is for compatibility with the Macintosh. Windows relies on the file extension of the file name (e.g. *.doc or *.txt) to identify a filetype with an application. The Mac divides a file up into two forks, a data fork containing the actual file data, and a resource fork for use by the OS. The Mac uses the resource fork to associate a file with an application. To support the two branches of information contained in a Mac file, Microsoft used the concept of Alternate Data Streams.

3) ADSs may be used legitimately. If so, an integrity issue is raised here in that some back-up utilities may not back up the contents of an ADS. As such, this data would be lost should the hard disk of a computer be trashed and the data be re-imported from a tape/CD archive. This undermines the integrity of the user's data.

4) The size of a file as reported by the OS will not change when an ADS is added to it, nor will its time and date stamp.

Thanks for the information alan. You put it into perspective for me.