1

I am trying to understand how to hide a file in windows as a way to learn about win api and malware analysis.

What I am trying to do is to make a file "disappear" via some kind of manipulation. But I am not sure how to do it.

If for instance i wanted to make a cmd or a specific browsing application not show the file, I would've, in my opinion, use hooking/dll injection so that if application equals the name of the app I am trying to hide, it would skip the offset, as if to the next file. However, I can't hook all the processes in the world and was wondering if there's a smarter way to do so. Is there any mechanism in windows, or some winapi that is responsible of keeping a "record" of the file system that will always be called when a program/process wants to traverse/find the contents of some directory?

How would you approach this simple task? I am pretty sure malware authors have done very tricky and sophisticated things and I am trying to learn ways to recognize this behavior so it's easier to be stopped.

Thank you very much.

  • Malware that was to hide itself against all processes usually manipulates not the processes but the kernel itself. See e.g. this article: Driver to Hide Process and Files. The article is old and may not applicable to a modern Windows 10 system but it explains a lot how something could be done. – Robert Mar 16 at 15:45
  • It is very interesting. I was wondering, for a much simpler case, theoretically, is it possible to somehow hook the native functions in memory rather than having something physical like an ioctl driver? – turtle Mar 16 at 17:57
2

There are ways to do it without resorting to hooking or drivers.

For example alternate data streams (ADS), or creating files with "illegal", i.e. reserved, names (NUL, CON ... trailing ., alternative casing to an existing file). Yep, that's right a trailing dot in a file name is illegal in Win32, but the most frequently used file system (NTFS) has no trouble creating or handling them. For ADS it's also possible to stick it onto a folder, which some tools don't handle improperly. That is, instead of C:\Windows\regedit.exe:yourfile you could stick it to C:\Windows:yourfile. Not sure if it's possible, but as a malware writer I'd also check out special files like \$Mft for a possibility to tack an ADS onto ...

Sidestepping the Win32 name parsing is one great way of hiding in plain sight without resorting to the NT native API. Some specific cases of accessing the file may still require the singular use of the NT native API, however (even though creating and removing such a file doesn't necessarily).

Another way would be to write a file system filter driver, but your trouble in this case is that Windows requires drivers to be signed. So if you write a dodgy driver chances are you won't get it counter-signed by Microsoft. Depends on how much testing they do on drivers before attestation signing.

For file system filter drivers you could opt for mini-filters, which are relatively easy to write (with comprehensive sample code in the Windows Driver Kit), but have to follow certain rules. Again, due to the signing requirements this may be impossible to get through signing. However, if it's just for learning you can enable test-signing on Windows and play around with it. In recent Windows 10 this is the only official method.

Another way would be to write a legacy file system filter driver (such as the filter manager, fltmgr.sys, is), as it gives you more liberties. Alas, it's also a much more involved endeavor with a steeper learning curve. And in the end the same signing requirements exist.

Aside from standard filter drivers you could do dodgy stuff such as stealing another driver's entry points (typically for the IRP major functions) and thereby piggyback on the functionality of such a driver. Yet again signing requirements are an obstacle.

And one last way I want to mention would be to analyze existing drivers and see if you can find any exploitable vulnerabilities in them. If you find some, it's like a jackpot and you can sidestep all those signing requirements. But it's also the most involved of all the possible routes.

Mandatory reading: "Rootkits and Bootkits", which explains how certain malware types hide outside the file system, and the older one named "Rootkits" from 2005 by Greg Hoglund.


One more note: not sure what you hope to get from this, but hooking seems to be the least reliable, yet most flag-raising option you have. Not sure why you insist (as per your comment) on this.

| improve this answer | |
  • But "illegal", i.e. reserved, names and similar techniques only hide the files in the Explorer. The APIs (and hence other file managers) are usually not affected as far as I remember. – Robert Mar 17 at 16:12
  • @Robert Most file managers use exactly the same set of APIs (Win32 / Shell API) as the Windows Explorer and use the same assumptions about files and file names. Some are actually worse. And besides, "hiding" should perhaps have been better qualified then. But for a fuzzy question I can only make assumptions to give an answer with different angles, which I am trying to. But you're right, these different means have different effects and different scope. – 0xC0000022L Mar 17 at 16:17
  • You cant make folder name "con" in explorer, but you can normally open them. You can create them via winapi or with other ways. I tried that in win 8 and win 10 (not recently) and it worked. I also remember that some user on other stackexchange user having problems with his windows username "con" and not knowing why. So windows can handle illegal names, but badly and not consistently. – Rok Tavčar Mar 19 at 20:53
  • @RokTavčar well "Windows" can handle them, obviously. That's what my answer is all about. NTFS can handle them as well. NTFS is even a case-sensitive file system, something that many people don't get. The issue is (mostly) the Win32 subsystem (aka csrss.exe) which uses the file system in a case-insensitive fashion. Likely file managers will try to prevent you from creating certain names, but especially since Windows 7 onward the Windows Explorer has learned some tricks it didn't know before. In Windows 10 it even knows "long" path names (those of ~64k characters). – 0xC0000022L Mar 20 at 20:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.