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.

[straphelp]

I Am having the exact same issue. currently running 1809 and when im trying to use the .xml file distributed by disa included with the latest windows 10 stig I get

WARNING: Warning: error while querying Payload policy: C000000D
WARNING: Warning: error while querying Payload audit policy: C000000D

@cohenda have you heard anything new?

[iadgovuser1]

@straphelp I haven't seen any response on the bug I submitted. I will press some of my contacts to see if we can get this on the radar of the right people sooner rather than later.

[cohenda]

I have not heard anything. @iadgovuser1 thank you for submitting the issue.

[straphelp]

Yes thank you I have been scratching my head to this one and my entire network is running windows 10 1809 and was a migration from 1803. these dep settings are getting the best of me and my nessus scans I swear

[straphelp]

@cohenda can you run a gpresult /h and output to a .html file to see your gp result. I discovered the gpo setting for Windows Defender Exploit Guard isn't listed as a policy being applied. this could be part of the issue.

report back

[straphelp]

also report back are you running windows pro or enterprise?

[iadgovuser1]

@straphelp @cohenda If you are using the GPOs available from DISA's site (which are the ones that are bundled with the SHB Framework download), then there is no default value specified for the EP policy path since it has to be a site specific path. Make sure there is a configured value for this GP setting: https://gpsearch.azurewebsites.net/#13664

[straphelp]

@iadgovuser1 I am not I have built my custom gpo from scratch and I have the xml file location pointing to right location via the gpo. the only thing I am using is the template for dep that is included with the stig.

running windows 10 pro 1809

[iadgovuser1]

@straphelp @cohenda

Here's the response I received.

This is fixed in the current 19H1 builds. There's a workaround for upgrades to 1809 that can be used in the meantime. Delete C:\Windows\Microsoft.NET\assembly\GAC_64\Microsoft.ProcessMitigations.Commands\v4.0_10.0.0.0__31bf3856ad364e35\Microsoft.ProcessMitigations.Commands.dll to cause the OS to pick up the correct PowerShell module DLL.

[straphelp]

YOU ARE A GODSEND!!!!!!!!!!!!!!! deleting that file worked!!!!!!!!!!!!!!!1 dep is not pulling correctly and my my nessus scans are working accordingly

Thanks @iadgovuser1

I hope you have have results @cohenda

[straphelp]

@cohenda if any machines are 32 bit delete the same file but from the GAC_32 dir. I have 2 that are 32 bit and the same fixed worked

[cohenda]

I wasn't as lucky. I deleted the file but the OS doesn't pick up an new one.

[cohenda]

Sorry for the late response. We are running Windows 10 Enterprise version 1809 (OB Build 17763.316), 64 bit systems. I ran a gpresult and verified that the policy setting the "Use a common set of exploit protection settings" is being set as expected.

The recommended solution hasn't worked for me yet. Maybe I'm missing a step on how to get the OS to pick it up.

[straphelp]

@cohenda where are you hosting the dod ep .xml file? what is your path in the GPO

[cohenda]

@straphelp it's being hosted on a Read only folder on a network share and the gpresult has the correct path. similar to \servername\STIG\READONLY\DoD_EP_V2.XML. I can copy the path from the gpresult, put it in windows explore and the xml file opens in notepad.

[straphelp]

@cohenda
are you using Ip address or hostname?

Here is mine and its working
\ADSERVER-1\Public\DOD_EP_V2.XML

[cohenda]

@straphelp hostname

[cohenda]

How did you get the OS to pick up the new DLL? Since I deleted the original one it hasn't been reestablished.

[straphelp]

all I did was delete the file that @iadgovuser1 mentioned and when I ran Get-ProcessMitigation -Name VISIO.EXE I had no errors

[cohenda]

Guess I waited long enough or threw enough reboots at it because it started working on my test system. @straphelp and @iadgovuser1 thank you for your assistance.

[iadgovuser1]

@cohenda

No reboot required. The correct module is ProcessMitigations version 1.0.11 from the PowerShell gallery. Looks like there was a also one in the GAC that conflicts. All it takes is deleting the DLLs from the GAC at C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.ProcessMitigations.Commands.resources\v4.0_10.0.0.0_en_31bf3856ad364e35\ and C:\Windows\Microsoft.NET\assembly\GAC_64\Microsoft.ProcessMitigations.Commands\v4.0_10.0.0.0__31bf3856ad364e35\

Run (Get-Module -ListAvailable) | Where-Object {$_.Name -eq 'ProcessMitigations'} and make sure it says 1.0.11. ((Get-Module -ListAvailable) | Where-Object {$_.Name -eq 'ProcessMitigations'}).Path will give the location which should be C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\ProcessMitigations\ProcessMitigations.psd1

[cohenda]

@iadgovuser1

(Get-Module -ListAvailable) | Where-Object {$.Name -eq 'ProcessMitigations'} --- Returns error:
Changed it to (Get-Module -ListAvailable) | Where-Object Name -eq 'ProcessMitigations')
The returned info
Directory:
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\ProcessMitigations\ProcessMitigations.psd1
Binary 1.0.11, ProcessMitigations, {Get-ProcessMitigation, Set-ProcessMitigation, ConvertTo-ProcessMitigationPolicy}

GAC_32 – No ProcessMitigation references
GAC_64 - C:\Windows\Microsoft.NET\assembly\GAC_64\Microsoft.ProcessMitigations.Commands\v4.0_10.0.0.0__31bf3856ad364e35 – No files since they were deleted earlier.
GAC_MSIL - C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.ProcessMitigations.Commands.resources\v4.0_10.0.0.0_en_31bf3856ad364e35\Microsoft.ProcessMitigations.Commands.Resources.dll – found and deleted

All but wordpad.exe are querying as expected. Partial Results below for wordpad.exe.

PS C:\WINDOWS\system32> Get-ProcessMitigation -name wordpad.exe
WARNING: Warning: error while querying Payload policy: 80000005
WARNING: Warning: error while querying Payload audit policy: 80000005

ProcessName : wordpad.exe
Source : Registry
Id : 0

DEP:
Enable : NOTSET
EmulateAtlThunks : OFF
Override DEP : False

[cohenda]

@iadgovuser1

update: I've tested the workaround on 5 or 6 more systems and only my testing machine has the issue with querying wordpad.exe.

Thank you
@cohenda

[iadgovuser1]

@cohenda Check under the IFEO paths (32-bit and 64-bit) that I mentioned in a previous comment. Look for a wordpad.exe entry and see if it has registry value names of MitigationAuditOptions and MitigationOptions under the entry..

[cohenda]

The IFEO settings for MitigationOptions were different. When I set the problem machine to match the working machines the query ran successfully.

Problem machine
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\wordpad.exe]
"MitigationOptions"=hex:00,00,00,00,00,00,00,00,00,00,11,11,01,01,00,00
"MitigationAuditOptions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"EAFModules"=""

Working machine
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\wordpad.exe]
"MitigationOptions"=hex:01,00,00,00,00,00,00,00,00,00,11,11,01,01,00,00
"MitigationAuditOptions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"EAFModules"=""

@iadgovuser1 Thank you for the assistance.

[iadgovuser1]

@cohenda In the future I would probably delete the wordpad.exe entry from the registry and force re-applying the XML config. That way you can make sure the error isn't originating from the XML config.