The Process Monitor (also known as procmon) is part of Microsoft’s Sysinternals Suite and a well-known tool for troubleshooting a Windows system. In this blog post, I present how to reduce the altitude of the procmon in the filter driver stack.

The ABC Of Filter Driver Altitude

You may ask yourself: What is this altitude you are speaking about and why should I want to reduce it? Well, after you downloaded and successfully started procmon, you can run fltmc instances in an elevated cmd or PowerShell. The output of this command lists the minifilter drivers that are active on your operating system.

Minifilter drivers active on my Windows

You can see that by starting the procmon executable, the PROCMON24 minifilter driver was loaded. This minifilter driver is required such that procmon is able to intercept IO operations and log them. However, different applications may use filter drivers for other purposes. For example, anti-virus software can use minifilter drivers to intercept and prevent IO operations.

This is where the altitude of a minifilter driver comes into play. Filter drivers are set to unique altitude values that describe their relative order towards the file system. The lower the altitude of a filter driver, the nearer it is to the file system.

The Microsoft documentation defines different load order groups for filter drivers and also lists unique altitude values that have been assigned to filter drivers (https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes). You can see, in general, the altitude of anti-virus filter drivers are lower than the altitude of our PROCMON24 minifilter.

The idea behind reducing the altitude of the PROCMON24 minifilter is that additional information may get available that is otherwise invisible to procmon, because the correspondent filter driver is below PROCMON24 in the filter stack.

How To Reduce The Altitude Of Procmon

The altitude of procmon can be set in the registry. Therefore, open regedit.exe and navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\PROCMON24\Instances\Process Monitor 24 Instance and reduce the Altitude value from the default 385200 to, for example, 40000.

Modification of the Altitude value

Restart procmon and check whether the altitude of its minifilter driver has been adjusted by using fltmc instances in an elevated PowerShell.

Modified altitude of procmon

In older versions of procmon you may have to prevent procmon to overwrite this manually set altitude when it gets started. Therefore, right-click on Instances, select Permissions and click on the Advanced button.

Set the correct permission entry

Then, add a new permission entry and select Everyone as Principal. Use Type: Deny and check Set Value, as well as Delete.

Set the correct permission entry

This permission entry will prevent procmon to reset to the default altitude.

Demo: Process Monitor Trace With Reduced Altitude

Let’s dive into an example where our disp+work.exe process opens an instrumented file such that the Windows Defender gets active. This will be the setup that we want to monitor with procmon and compare how the altitude affects the trace.

I used a remote SMB share on a host where the Windows Defender was disabled. On this share, I created a regular .txt file for reference and an EICAR test file.  EICAR test files are harmless files that contain a specific string such that they are treated as malware by anti-virus software. Then, I accessed this share via the transaction AL11. In the following screenshot you can see that both files are displayed in the transaction AL11.

EICAR.txt and ordinary.txt in AL11

However, I was only able to display the content of ordinary.txt. The content of EICAR.txt is inaccessible.

Content of ordinary.txt

Let’s find out why and, therefore, compare the procmon traces that I recorded for different altitudes (default: 385200 and custom: 40000). Here, I set a filter to include the Process name disp+work.EXE and the Path of the EICAR.txt file.

Process Monitor traces with different altitude

By comparing the two different traces, you see that the trace with reduced altitude contains more events which I marked by the blue box. Further, the result of the CreateFile operations with the specified detail Generic Read (marked in red) differs. This means that the result of this operation is modified by a minifilter that is located between both altitudes.

More interestingly, let’s compare the call stack of the CreateFile operation with the call stack of one of the operations that were only captured with reduced altitude. For this example, we pick the QuerySecurityFile operation where the Result is ACCESS DENIED. In the following screenshot, you see that the call stack is quite similar.

Comparison of call stacks of CreateFile (left) and QuerySecurityFile (right)

In fact, you can see that both operations are triggered from the same call of get_file_attributes of the disp+work.EXE module. However, the call stack of the QuerySecurityFile operation suggests that the QuerySecurityFile operation was triggered by the CreateFile operation. And if you look even closer, you see that the module that triggered this operation is WDFilter.sys. Guessed what? WDFilter.sys is the minifilter driver of the Windows Defender.

The additional insights that can be achieved by investigating these procmon traces are the reason why the SAP support may request a procmon log where the altitude of the minifilter is modified from its default value.

I hope I was able to something new. Feel free to comment and leave feedback!