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.