Ask The Performance Team

3 MIN READ

Change Altitude of Process Monitor (ProcMon)

Microsoft

Feb 08, 2021

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

Solution

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:

Install Procmon (assuming you have not already installed it) https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
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…

Click Add

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.

Click OK.

Click Yes

Click OK

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.

Updated Feb 08, 2021

Version 2.0

TeedaN

Microsoft

Joined January 13, 2020

View Profile

Ask The Performance Team

Follow this blog board to get notified when there's new activity

AaronMargosis_Tanium
Iron Contributor
Dec 12, 2022
This is very cool.
A few very minor suggestions for edits on changing the key's permissions:
Don't need to select "Everyone" before clicking "Advanced" or "Disable inheritance" -- both apply to the entire security descriptor, not just to the Everyone ACE.
In the screenshot where Set Value and Delete are set, I'd also point a red arrow at Read Control to make it clearer that it needs to be unchecked (as it will start out checked by default).
The screenshots that show only the Deny/Everyone ACE are incorrect -- they're what you'd see if you had clicked "Remove all inherited permissions from this object" instead of "Convert inherited permissions..."
The best way to revert the key's permissions to their original state is to right click the parent key (Instances), choose Permissions, click Advanced, check the "Replace all child object permission entries with inheritable permission entries from this object" box, click OK, then Yes. (Note that a reboot will be needed for any changes to the driver's altitude to take effect.)

SecureSphere

Copper Contributor

Jun 20, 2023

ShaneCreamer

Excellent article, but is there a way to script that out for all of the configuration & permissions work do be performed in a script such as PowerShell? Customer Support teams like ours ideally need a script that performs those steps to make this process faster and to avoid customer mistakes trying to follow a fairly complex set of instructions above.

If you can provide a PS script for enabling those permissions, we could use this instead of having to perform ETL traces that collect the Mini-Filter driver provider to see which security tool in kernel is hooking process stacks..

Here you are:

$Altitude = 40000 # default 385200

$ProcMonSvcRegKey = "HKLM:\SYSTEM\CurrentControlSet\Services\"

$IsRegKeyPresent = Get-ChildItem -Path $ProcMonSvcRegKey | Where-Object {$_.PSChildName -like "PROCMON*"}
$Number = ($IsRegKeyPresent.PSChildName).Split("N")[1]

if($IsRegKeyPresent){
    $FullPathToProperty = $ProcMonSvcRegKey + "$($IsRegKeyPresent.PSChildName)" + "\" + "Instances\Process Monitor $Number Instance"
    Set-ItemProperty -Path $FullPathToProperty -Name Altitude -Value $Altitudeude

    (Get-Acl -Path $FullPathToProperty).Access

    $SID = New-Object System.Security.Principal.SecurityIdentifier("S-1-1-0")
    # Use Translate to find user from sid
    $objUser = $SID.Translate([System.Security.Principal.NTAccount])
    # Print the converted SID to username value
    $EveryoneGroupName = $objUser.Value

    $NewAcl = Get-Acl -Path $FullPathToProperty
    $identity = [System.Security.Principal.NTAccount]("$EveryoneGroupName")
    $regKeyRights = "SetValue,Delete"
    $actype = [System.Security.AccessControl.AccessControlType]::Deny
    $inhFlags = 'ContainerInherit, ObjectInherit'
    $prFlags = [System.Security.AccessControl.PropagationFlags]::None
    $regKeyAccessRuleArgumentList = $identity, $regKeyRights, $inhFlags, $prFlags, $actype
    $regKeyAccessRule = New-Object System.Security.AccessControl.RegistryAccessRule ($identity, $regKeyRights, $inhFlags, $prFlags, $actype)
    $NewAcl.SetAccessRule($regKeyAccessRule)
    $NewAcl.SetAccessRuleProtection( $true, $false ) # True, True - Convert Inherited permissions form this object | True False Remove all inherited permissions from this object
    Set-Acl -Path $FullPathToProperty -AclObject $NewAcl
}

ShaneCreamer
Copper Contributor
Aug 04, 2021
Excellent article, but is there a way to script that out for all of the configuration & permissions work do be performed in a script such as PowerShell? Customer Support teams like ours ideally need a script that performs those steps to make this process faster and to avoid customer mistakes trying to follow a fairly complex set of instructions above.

If you can provide a PS script for enabling those permissions, we could use this instead of having to perform ETL traces that collect the Mini-Filter driver provider to see which security tool in kernel is hooking process stacks..
LawrenceLi
Microsoft
Feb 17, 2022
That should be better if provide a screenshot after the change to show the LeakyFlt in the stack in Procman.

Blog Post

Change Altitude of Process Monitor (ProcMon)

Symptoms or Error

Solution

Share