Hi guys,
I am currently building a little driver to intercept file execution (including DLL loading). Since Windows itself doesn't offer a documented way to do so (PsSetCreateProcessNotifyRoutineEx only exists on Vista SP1+ and only works for process creation - not DLL loading). I had several approaches to this:
Since the driver is intended to run on x64 Kernel Mode Hooks aren't really an option.
I am currently building a little driver to intercept file execution (including DLL loading). Since Windows itself doesn't offer a documented way to do so (PsSetCreateProcessNotifyRoutineEx only exists on Vista SP1+ and only works for process creation - not DLL loading). I had several approaches to this:
- Use a file system filter with IRP_MJ_CREATE callbacks and check for the FILE_EXECUTE flag. That works but unfortunately Explorer essentially opens all files with maximum flags including FILE_EXECUTE. So while browsing directories there are a shit load of "detected executions". Unfortunately all flags are the same no matter whether you browse a directory, get the file properties or execute the file. So there is no easy way to filter those requests. Doing a user mode stack trace of the thread issuing the request may be possible. But I have no idea if that is at all doable.
- Use a file system filter with IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION callbacks to intercept the creation of file mappings and check if the mapping is created with execution rights. This works quite well. Unfortunately there is a strange bug within the CreateProces APIs: When I deny access using one of those callbacks the application issuing the CreateProcess call will leak a handle to the file it tried to execute. So essentially I can't delete it. There are some false positives as well but they are far less then the first method so in general they are acceptable. If I could prevent the handle from being leaked this method would be great.
Since the driver is intended to run on x64 Kernel Mode Hooks aren't really an option.