There are some tools in the market which force delete the files. few tools use kernel driver as well. However when I force delete the files using those tools I dont get DELETE desired access in my IRP_MJ_CREATE. Also I am not receiving any IRP_MJ_SET_INFORMATION for that file though I have registered for pre and post callback.
I wanted to basically protect my files from force deletion. I have handled normal delete..However I dont see all callbacks getting triggered for force delete.
I can see IRP_MJ_CREATE but no DELETE desired access..Also I am not receiving any IRP_MJ_SET_INFORMATION for that file though I have registered for pre and post callback.
Is there a way to capture these force deletion.
few tools use kernel driver as well. However when I force delete the files using those tools
Which tools? The kernel driver ones or the non kernel driver ones?
If kernel driver - may sure you are below the filter
If not (or in fact in both cases) look at what they are doing with ProcMon.
Which tools? The kernel driver ones or the non kernel driver ones?
There are few which uses drivers. few which doesnt use drivers.
If kernel driver - may sure you are below the filter
you mean we should tap it by creating another minifilter with lower altitude than the one which is force deleteing????
If not (or in fact in both cases) look at what they are doing with ProcMon.
we looked for few IRPs like, create, mj_set, mj_directory control. we did not see anything in procmon..
all we could see is a create that too without delete desired access. and cleanup...
we checked in procmon and also our minifilter driver.
Use ProcMonLow as their driver is almist surely below regular ProcMon.
I hadn’t heard of that, excellent. I usually just go into the registry and dink the altitude for procmon (you used to have to lock it down, but that’s no longer needed)
Same thing, I call it ProcMonLow, because I doubt distributing the pre-patched one is legal.. not that MS is likely to have a real legal issue with it.
Thank u..I never knew about changing the altitude for procmon. will try that and get back with details.
I have tried lowering the procmon altitude. I get precreate calls with delete desired access for these malwares when they try to delete my files.
In my precreate callback routine(in my driver) I look for these desired access and take action. I am setting the status as status_access_denied and returning flt_preop_complete.
My understanding is that since I am returning flt_preop_complete the create request should not go to lower mini filter and to file system and my file shouldnt be deleted.
However this check and return value is not honoured and file is getting deleted with those 3rd party malware tools.
Just to add here the same code is honoured when I try to do a manual delete from file explorer.
Am I missing anything here?
One more update. I see few fast IO calls in the stack. Please find the procmon logs
After seeing the fastio calls in the procmon logs I returned status FLT_PREOP_DISALLOW_FASTIO instead of setting it access_denied and returning preop_complete status.
Still the file was getting deleted. Any thoughts?
I often encounter tools that bypass the minifilter and directly send SET_INFORMATION requests to the file system driver, such as constructing an IRP to send this request directly to the NTFS driver. For such approaches, changing the altitude methods isn't very useful.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.