Get-ProcessMitigation query warning about payload - Exploit Guard

[cohenda]

Going through the windows 10 STIG for a system utilizing the SHB Windows 10 v1803 deployment, upgraded to 1809, there are a number of checks for Win10-EP-XXXX which uses the get-processmitigation -name appname.exe to verify Exploit protection is enabled and configured correctly. When I run the cmdlet I get the following "WARNING: Warning: error while querying Payload policy: 80000005". We are using the recommended DoD_EP_V2.xml file that is released with the STIG. With the exception of the Payload settings they match up. Any assistance in solving this warning would be greatly appreciated.

[iadgovuser1]

@cohenda

(U) Are you using the Tenable custom STIG audit files that come with Nessus? We came across this as well. There is a bug in the Get-ProcessMitigation cmdlets where process names are case sensitive when they need to be case insensitive. I filed for this about two weeks ago. Below is a description with a workaround. Does it sound like the problem you are experiencing?

We are using Get-ProcessMitigation -Name to check compliance for certain mitigations for certain programs.

I think the root cause is from the XML used to apply the mitigations. For example:

will create an IFEO entry named "EXCEL.EXE" under IFEO registry locations :

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\

• HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\

Get-ProcessMitigation -Name EXCEL.EXE works and returns the configuration.

Get-ProcessMitigation -Name excel.exe or Get-ProcessMitigation -Name Excel.exe do not work and returns nothing.

On our network we have some systems where EXCEL.EXE (and other Microsoft Office programs) exists in all caps exists and other systems where it does not exist in all caps. We get random compliance check failures due to this. I hope the protection is still applied despite the cmdlet not working.

Below is an example fix that we currently use. Unfortunately it is a very inefficient fix because of how PowerShell returns registry case sensitive or insensitive. I have to Get-ChildItem on the parent IFEO path in order to get PSChildName to return with the exact casing as it is in the registry. When I used Get-ChildItem directly on the Acrobat path, it always gave me the casing of the string that I specified ('adobe.exe' would always be 'adobe.exe, 'Adobe.exe' would always be 'Adobe.exe')

if (Test-Path 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Acrobat.exe') {
    # workaround by using GCI on IFEO
    $name = (Get-ChildItem 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\' | Where-Object {$_.PSChildName -like 'Acrobat.exe'}).PSChildName; $m = Get-ProcessMitigation -Name $name; $d = $m.Dep; $d.Enable -eq 'ON'
} else {
    $false
}

Please change ProcessMitigation cmdlets to be case insensitive to fix this issue. I have only tested Get-ProcessMitigation, but Set-ProcessMitigation might also have the same issue. Like I said, I import an XML file to apply the Exploit Protection settings. I haven't tested any other ways of potentially exercising this bug.

[iadgovuser1]

On closer reading, it sounds like you have a different problem than what I was thinking about. I'd have to look at the ProcessMitigation cmdlet to figure out where that message is sourced. 0x80000005 can have different meanings depending if it is an HRESULT (E_POINTER) or NTSTATUS (STATUS_BUFFER_OVERFLOW) return code. Ultimately it sounds like the current policy configuration could not be retrieved. The configuration is stored under the 32-bit and 64-bit IFEO registry locations.

[cohenda]

Your are correct but the info in your first comment is helpful. To verify that our security settings weren't blocking access I ran a few installation tests. First I installed version 1803 default install and had no issues, the get/set-processMitigation worked. Then I installed version 1809 default install and had no issues. 3rd test was a fresh default install of 1803 with the feature update patch to 1809 applied via the update catalog, processMitigation returns the error message. I have attached 2 documents that contain the results of the get/set-processmitigation and an export of the registry settings for IFEO for the 1803 updated to 1809.

IFEO.reg.txt
get-processMitigation - result.txt

Thank you for your assistance.

[iadgovuser1]

0xC000000D means STATUS_INVALID_PARAMETER. Definitely seems related to the upgrade process. Can you try clearing out the policy and then applying it again? I've never tried clearing the policy. I assume a barebones XML file might work:

<?xml version="1.0" encoding="UTF-8"?>
<MitigationPolicy>
</MitigationPolicy>

Check the IFEO registry values after applying the policy and see if it cleared out the old entries. If the old entries are removed, then try applying the DoD_EP_V2.xml file again. If none of those works, then I can file a bug via the TAP.

[cohenda]

Tried the empty XML file, it does not clean out the settings. The registry still lists all the apps.

[iadgovuser1]

Can you upgrade 1803 > 1809 > recent Windows Insider build? Example: Build 18329. If the problem still exists, then I can easily file it under the TAP to get it addressed.

[cohenda]

Upgraded from 1803 > 1809 >1903 Build 18329.1. Still has the same response to get-processmitigation.

get-processMitigation -Results - 1803-to-1809-1903-18329.1upgrade.txt

[iadgovuser1]

@cohenda Thank you! I have filed a bug via the Microsoft Technology Adoption Program. Do you know if someone in your org participates in the TAP?

[cohenda]

I don't believe so but I'm willing to participate if we meet the criteria.

[iadgovuser1]

Do you have someone who participates in the Joint Secure Host Baseline Working Group? Someone there should also be able to direct you to the TAP coordinators.

[cohenda]

Not that I am aware of, I'll have to ask around.