Windows Hide and File Seek

The great Firefox news and tipster, Firefox Extension Guru made a comment on a recent post when I was tracing a malware file in the Firefox cache:

How can a file only be seen in DOS? I thought Windows Exploiter pulled everything from DOS?

It's a great question, and though I have touched on it several times in the past, really seems to need a more detailed post to respond to.

Olly Olly Oxen Free!

Despite my personal grumbling and complaints about Symantec the other day, their corporate/enterprise-grade products are pretty good. Their local workstation clients run pretty lightly on resources, even when scanning. The applications are unobtrusive and provide understandable feedback when alerts occur. Walking users through manual "Live Updates" is a breeze and the communications between the client findings and the central console management tool helps us identify and respond to workstations that could not "auto-heal" themselves.

One technique of malware writers that working with Symantec (and AVG and other AV solutions) has taught me is that they sometimes like to hide their malware executables from view on Windows platforms. There are multiple techniques for doing this but the end result is all the same; make it harder to locate and remove the malware from your machine.

My experience is that it is primarily virus and trojan type malware that uses this technique, though some more aggressive malware and rouge applications may use these as well.

Having a background familiarity with some of their more common techniques may allow a more focused and effective assessment of a system when you respond to a malware infection.

I'm primarily going to be addressing Windows XP/2000 systems, but this should apply (for the most part) to Vista systems as well.

Once I have provided some examples, I will return to providing helpful details about Windows (hidden) file hiding and provide additional resource links.

Case Study One - Worms in the System!

For my first example, I'm going to use a real response event I encountered several months ago, when a particularly aggressive virus outbreak occurred in our network. The root cause were exploits of unpatched Windows workstations. The outbreak source was one of several variants of the W32/Sdbot.worm.

Behavior Information

We never determined how exactly the worm entered our network. Most likely someone downloaded and installed an infected file, or attached an unauthorized laptop to our network which had been previously infected. At the point we became involved, the damage had begun.

When the Sdbot.worm is launched, it attempts to write itself into the registry to restart when the pc is rebooted.

At runtime, it can be observed spawning a new, randomly-named processes into memory, then deleting/hiding the original file that launched it.

The process itself is not heavily protected, and can be successfully terminated by using the Task Manager or Microsoft’s Sysinternals Process Explorer.

Fortunately, I did not see it re-spawn once killed, unless the machine was rebooted before being fully cleaned.

If the NirSoft utility CurrPorts is run on an infected system, you may be able to see the remote ports/stations the local virus is attempting to contacts and listen to; quite a few are established.

The launcher worm may be found hiding on the drive root, in temporary Internet files folder for all users on the pc, and in the system32 folder.

Propagation

There are several variants, but they all seem to propagate in a similar manner to machines vulnerable to the following exploits: MS05-039, MS06-040, propagates to machines with poorly secured network shares, propagates to MySQL and Microsoft SQL servers that are poorly secured, propagates to remote machines via random IPs by attempting to copy itself to a number of shares.

Cleaning

STEP ONE

Being familiar with the standard applications, processes, and services running on our workstations allowed me to quickly identify any potentially "rouge" running tasks using Task Manager or Process Explorer. After working on several machines I identified many names the running process took:

Sansv.exe, Sesvc.exe, Btlite.exe, Odbcmr32.dll, Jwmngr.exe, u.exe, lemsrv.exe, mstscc.exe, symmec.exe, 9129837r, dr.exe, fwcheck.exe, irc.exe, irn.exe, popmgr.exe, sansv.exe, secsrv.exe, sekure.exe, znnsvc.exe, load.exe, crcss.exe.

Of course, this was not an complete list and required an awareness of what should and should-not be running on the systems.

I terminated any of these (or other-named) processes.

What was interesting is that these processes were created and spawned into memory, but did not have a like-named executable file responsible for them on the hard-drive. Another file was running, creating the process into memory with a new name, then shutting down and hiding again.

That would be my real target.

STEP TWO

Next I ran the NirSoft CurrPorts utility to check the pc for any TCP or UDP connections to other servers/workstations. I made a note if I identified any other suspicious processes running TCP/UDP/FTP connections. Those were also terminated.

STEP THREE

At the time of the initial outbreak, Symantec did not have a specific signature for this file, but its heuristics engine did seem to alert to the files in some cases on infected machines. As such, often it would only be able to alert, but not quarantine or remove the actual infection. The logs Symantec generated however, allowed me to identify a series of file names to search the system for which was the true launcher.

By default, our workstations are not set to show hidden files and folders, nor protected system files in Windows Explorer. So I next had to enable Windows to show Hidden files and folders.

I browsed to each of the locations were the target files should be located according to the Symantec logs. Unfortunately, despite enabling Windows hidden files and folders, my target files were nowhere to be seen.

However, I had a trick up my sleeve!

I opened a DOS command-prompt session and run a directory search for each of the files logged by Symantec. It was pretty easy in this case as despite the fact multiple versions were found, they all were named in a similar pattern. Once I understood the pattern, I could use wildcards to speed my search:

I navigated to the root of the primary partition and ran a recursive search looking for the file using a wildcard to catch all the files:

C:\>dir sansv*.* /s (searching for files, in all subdirectories)

In this case, I wasn't concerned with adding the "h" (hidden) or "s" (system) attributes to refine my search as I just wanted the files to list for my review.

Sure enough, the DOS command-prompt window displayed the files. They were scattered on the root, in the Windows\system32 folder, and in the temporary (cache) file folders located in ALL the user profiles on the machine.

And when I checked with Windows Explorer, the files were not visible, even though they were listed in DOS.

To delete them I (carefully) used the following command:

C:\>del sansv*.* /s (delete files, in all subdirectories)

I used the “wildcard” symbol as shown to ensure I deleted all the “auto-incrementing" filenames for the worm I found.

I also had to delete this file as well that the worm used:

C:\>dir lemsrv*.* /s

STEP FOUR

I ran HiJackThis to look for any auto-run files set in the registry associated with these files. (MSCONFIG might work as well on XP systems...or use Sysinternal's AutoRuns utility.

O4 - HKLM\..\Run: [SANS Service] C:\WINNT\system32\sansv.exe

I delete them; and if I found a new filename listed there that wasn't known from above, I would return to the DOS command-prompt box and attempt to delete it.

I re-scanned the registry several times to verify they were not re-spawning into the registry. If that had occurred, it would have been a sign that I missed a running worm process or that a second, protective "watcher" process for the malware was also running.

STEP FIVE

I next applied the appropriate patches depending on OS. I chose to download these directly to my USB stick and install from there for fastest performance.

KB899588 Critical Update for Windows 2000/XP

KB921883: Critical Update for Windows 2000/XP

This helped protect the system from re-infection from other infected pc connections while I finished up.

STEP SIX

Time to check my work! I rebooted the pc to check again for any malicious running processes with Process Explorer. I also used CurrPorts to also check that no malicious processes have started TCP/UDP connections again. Finally I used AutoRuns to verify no new malicious entries had been re-added to my registry's startup keys.

STEP SEVEN

I now went and deleted all the temporary files and folder contents in the following location:

C:\Documents and Settings\(profile name)\Local Settings\Temp\ *.*

C:\Documents and Settings\(profile name)\Local Settings\Temporary Internet Files\Content.IE5\*.*

I checked all profiles, including the Administrator and the “Default User” accounts as well and deleted all temp files as indicated above.

STEP EIGHT

If the pc is still on the network, you will then want to run the Microsoft Windows Updates on-line to ensure ALL AVAILABLE critical Windows updates are discovered and applied to the workstation to prevent future infection. It it isn't on the network (not a bad thing to do if the malware keeps connecting to get files or infect other systems) I use the heise Security - Hands-on - Do-it-yourself Service Pack updater from a CD or where it was copied to a large USB stick.

After the final updates are installed, I rebooted the system and performed a final check with Process Explorer to verify I didn't see any of the malicious processes still running.

For one last time, I ran AutoRuns to verify new malicious startups had not been re-added to the Registry.

This isn't the only worm/trojan/virus that uses this technique. There are numerous others as well, but is a good illustration.

Case Study Two - Hidden Trash

Another case was when I ran into difficulties caused by a hidden file (non-malicious) located in my recycle bin:

XP How To: Empty Invisible Trash

In this case, I had to run the dir /ah command to find the recycle bin in the command-line, then once I had navigated into that folder, I had to again run a dir /ah command to find the files themselves. Finally I had to change the attributes on those files using attrib (filename) -a -h command to remove the attributes hiding them from the system. This allowed me to now fully empty my recycle bin.

Case Study Three - Fleas on the Firefox

My last example of encountering a hidden malware file is when Alvis had browsed across a website and a malicious Java-script file was brought down into the Firefox cache. AVG didn't catch it immediately, but either it wasn't Firefox compatible or the NoScript extension likely kept it from executing. See my post Hunting Me up a Malware File for the details.

Either way, during the daily full-system AV scan, the file was identified. When I attempted to find it on my drive using Windows Explorer, it wasn't visible. I again had to drop into the DOS command-line mode and run a search for it to find, capture, and delete it.

Recap

So in all of these examples, despite the fact that Windows had been set to show hidden and system files, the files in question were not visible. In addition, in some cases, the files were not visible in the DOS command-line mode unless I specifically requested them and/or changed the attrib(ute) setting on the file for it to be displayed.

What's going on?

Microsoft decided that in some cases, it might be beneficial to hide some files and folders from "normal" view by users:

• By enabling optional file and folder attributes to be set as "hidden" or "system,"
• By having certain "special" files for the system be hidden automatically,
• By allowing the file system to optionally hide these from Windows Explorer (and other file mangers) view.

And in some "advanced" cases, by using Alternate Data Streams (ADS) on NTFS partitioned drives or rootkits to cloak files, folders and processes.

Granted, sometimes there are legitimate uses and reasons for "hiding" these files and folder. Unfortunately, they also can be leveraged by malware writers to hide files, folders and processes as well.

Sony Hidden Stuff - Round Two

Sony had been in the news before for loading a root-kit for DRM protection off it's CD's. They took a lot of heat and eventually had a mess to clean up; TechBlog: Updated: Sony takes a page from spyware scum?

Recently, F-Secure and McAfee both identified a driver application used by Sony on its MicroVault USM-F fingerprint USB stick that uses "rootkit-like" behavior and creates a hidden folder:

This blog post has some good technical details on the behavior: McAfee Avert Labs Blog: Hide me Sony one more time!

Quoting from the F-Secure post : Double Whammy! Another Sony Case (And it's Not BioShock)

The Sony MicroVault USM-F fingerprint reader software that comes with the USB stick installs a driver that is hiding a directory under "c:\windows\". So, when enumerating files and subdirectories in the Windows directory, the directory and files inside it are not visible through Windows API. If you know the name of the directory, it is e.g. possible to enter the hidden directory using Command Prompt and it is possible to create new hidden files. There are also ways to run files from this directory. Files in this directory are also hidden from some antivirus scanners (as with the Sony BMG DRM case) — depending on the techniques employed by the antivirus software. It is therefore technically possible for malware to use the hidden directory as a hiding place.

F-Secure then did a series of additional posts on the situation: Sony's USB Rootkit vs Sony's Music Rootkit (in which the temper their initial evaluation) and Sony is awake (in which F-Secure announces they are in direct talks with Sony over the event now).

Tyler Reguly over at Computer Defense blog did a nice post that puts this Sony action into perspective: Sony… Another Root Kit… Not Quite! It's a quick read and reminds us that security researchers/responders need to be careful on how they present and label their findings. Else when they are picked up by general media, may become sensationalized a bit.

Seeing the Hidden

Knowing that these files and folders can exist is the first step.

How do you find them?

In the cases outlined above, I had logs and behavior (along with experience) to guide me to the locations and files in question.

1. Many hidden files and folders can be made visible simply by enabling them to be displayed in the Windows interface: Enable Windows to show Hidden files and folders (XP/2000).
2. Same goes for showing hidden files and folders in Vista: Show Hidden Files And Folders In Vista ~ Windows Fanatics
3. You can also make a registry change in XP/2000 to allow display of these: How can I view Super Hidden Files?
4. Same goes for modding the registry in Vista: Display Super Hidden Files In Windows Vista ~ Windows Fanatics.
5. You can use a command-line tool like HFind as found in Foundstone's Forensic Toolkit. From the developer's description: "HFind scans the disk for hidden files. It will find files that have either the hidden attribute set, or NT's unique and painful way of hiding things by using the directory/system attribute combination. This is the method that IE uses to hide data. HFind lists the last access times."
6. On Windows 2000/XP, run the command attrib | findstr SHR or attrib /s | find "SHR" . See the links SANS-ISC and by lockergnome for details. (I haven't tried these on Vista, but suspect they will need some tweaking to work correctly. If you know the proper technique on Vista, please drop a tip in the comments!) Update: For Vista try using one of the following commands dir /s/p /a:shr or dir /s/w/p /a:shr . The "/p" switch puts a pause in the display output if it fills the screen, the "/w" switch displays the listing in a wide format.
7. Look for suspicious running processes with Process Explorer or Task Manager, and note their names and path locations. If you can't see them in Windows Explorer, then you want to use a technique listed below and do some Google searching to see if it is legitimate or not.
8. Consider running CurrPorts, VStat, TCPView or a similar tool to look for running processes that have active or listening connections to the network. Again, if it is not familiar and not visible in Windows Explorer, it's worth investigating.
9. Run an ADS (Alternate Data Streams) and/or rootkit scanner to look for suspicious files hiding with an more complex method.

"Advanced" File and Folder Cloaking

Number nine above refers to what I deem "Advanced" file/folder cloaking techniques. When I say "advanced" I mean it in the context that these methods are generally less common and likely to be encountered in the course of investigating a system for hidden files...but they can and are being used and must be kept in consideration.

ADS (Alternative Data Streams)

I'm not a Windows file system expert so I won't pretend to understand why and how these are used in "legitimate" purposes. I do know they exist and can be used maliciously so I had better be able to look for them and then evaluate if they are legitimate or malicious.

Merijn describes them in these simple terms:

ADS are a way of storing meta-information about files, without actually storing the information in the file it belongs to, carried over from early MacOS compatibility from Windows NT4. This meta-information is not visible in Windows Explorer.

Recently browser hijackers began using this technique to store hidden information on the system, and even store trojan executable files in ADS streams of random files on the system. Use with caution, Windows and several antivirus programs also store (temporary) information in ADS.

For detailed reading on ADS, you may want to start by reviewing the following posts:

• FAQ - NTFS alternate data streams - Frank Heyne Software
• Windows Alternate Data Streams - BleepingComputer Tutorial
• Practical Guide to Alternative Data Streams in NTFS - Irongeek guide
• Hidden Threat: Alternate Data Streams - WindowsSecurity.com

Two tools (out of several) that I keep on hand to examine a machine for ADS files are Microsoft's Sysinternal's command-line tool Streams and Merijn's utility ADS Spy (freeware). This one is a GUI based "...tool to list, view or delete Alternate Data Streams (ADS) on Windows 2000/XP with NTFS file systems."

Again, let me be clear; jut because you find a file or files that use ADS techniques does not necessarily mean they are malware related. They might be legitimate and required for proper operation of your system or application. Do some research before deciding to delete them, willy-nilly!

Rootkits

Rootkits are a really advanced way of cloaking files, folders, and processes from the Windows API by intercepting requests by and for them and tossing evidence of their existence away before displaying results to the GUI observed by the user.

For more information and an extensive list of tools to locate these files see my post Anti-Rootkit Tools.

Bits and Pieces

Here are some additional interesting material I located on the web on the subject that if you really are interested in, might consider adding to your reading list as well:

Some Hidden/System Folders Not Showing in Windows Explorer

Microsoft's Really Hidden Files - SillyDog701

Configuring Windows Explorer - desktop.ini

Delete FXP Files - Previously mentioned GUI utility to locate and delete files and folders using special characters in their names to prevent identification and deletion. Well worth checking out.

Final Thoughts

Using a good Anti-Virus Tool coupled with Anti-Malware Tools provides a strong (but not perfect) first-line of defense against these hidden files. Most AV programs and many anti-malware tools can provide scanning and identification of these hidden files and programs.

Just because a file or folder is hidden, does not necessarily mean it is malware. There are some legitimate and beneficial reasons for the system or a program application to hide its presence. In some cases, malware will use these techniques to hide itself, or attempt to use legitimately hidden locations to prevent detection. It is just something that IT responders need to be aware of and check for.

Again, experience and research takes time to acquire so that you can evaluate and assess the potential threat level of an application. Mandiant's Red Curtain - Incident Review Software might help in the assessment.

I've hope this is helpful information, and I've tried to be as accurate as possible. Please leave any additional tips or suggestions for dealing with these files in the comments to help expand my knowledge and understanding of these files and folders.

Then we can all holler together: "Olly olly oxen free!"

--Claus