My name is Susan and a small group of us have joined together to provide you documentation on how to view a kernel filter driver in procmon on the stack, that is normally obfuscated. A special thanks to my colleague, Becky Burns for documentation collaboration; and a special shout out to Denis Pasos and Ron Stock for both creating a leaky kernel filter driver, and documentation collaboration.
Symptoms or Error
If you need to get Procmon's filter to run below us in the filter stack, it has a setting for that. Procmon is typically used to figure out what is happening on the machine, but you do not get to see the activity of things such as virus scanners because they happen at a lower level than the procmon filter. In our case, we have a driver called Leakyflt.sys but in procmon it only shows as FLTMGR.sys but we want to know which driver it is without performing more tracing.
From an administrative command prompt, we see the driver LeakyFlt at altitude 372000:
In this example below, you will see Procmon’s altitude at 385200 as well as Legacy Filter Drivers such as vdorctl, and dgmaster:
From Procmon, in the stack it looks like
Changing the "Altitude" that procmon will run, putting it lower in the filter stack. In doing so, you will be able to see all the activity that you want from most filter drivers.
To change the altitude of procmon, you will want to perform the following steps:
From an Administrative Command prompt, run FLTMC to see the Altitude of the filter drivers:
In the screenshot, the lowest filter driver altitude is 37200
Open Registry Editor (RegEdit)
Navigate to registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PROCMONXX\
In Example: PROCMON24 (name may have a different number on your machine)
Expand to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PROCMONXX\Instances\Process Monitor XX instance. (i.e., Process Monitor 24 Instance)
Change the Altitude Regkey value to lower than your lowest filter driver. For this example: change the Altitude value to 40000 (which will show you virtually everything that is happening on the machine). Alternatively, you could set the altitude to 372000 if you suspected a specific driver.
Ex. Default altitude currently set to 385200
Right click on Altitude, change value to 40000, click OK
You must also set the security on the "Process Monitor XX Instance" key and add deny rights for everyone for "delete" and "set value". Reason being that procmon will try to change its value back right away. You will have to select "Disable inheritance" to be able to set them at the Process Monitor XX Instance level.
Right click on Process Monitor 24 Instance, select Permissions…
In “Enter the object names to select:” type Everyone, click Check Names, then click OK.
Select Everyone, Click Advanced.
Select Everyone, click Edit.
Click Show advanced permissions.
Change Type: to Deny, check Set Value, check Delete, click OK.
(if Read Control is checked, uncheck it)
With Everyone highlighted, select Disable inheritance, click OK
Choose Convert inherited permissions into explicit permissions on this object.
Exit Registry Editor
If you have already started procmon before doing these changes, you will need to restart the machine. If not, you should be able to just start procmon.
From an elevated command prompt, run the command fltmc instances and verify that the procmon drivers are running at the altitude that you set (ex. 40000).
Then reproduce the scenario you want to capture. Your capture will be even larger than normal. Notice now when we review the new procmon, and view Stack we see the name of the driver LeakyFlt.sys.
Note: You can leave the setting as it just lowers the threshold of what we see. And more is always better when it comes to legacy kernel drivers. Once you get a procmon with that enabled, you can look at the stack and see it.
Note 2: Will the deny permission for Everyone only impacts that instance? Will it not interfere with other applications/permissions on the machine?
It only affects that procmon instance; not all procmons. So, if they installed e.g., something that had their own procmon instance it would not impact it. You can take ownership of the key to delete the key when you are done.