FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION.md

Organizations who cannot take advantage of these protections can set the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry key to avoid exploitation. Please note that while these registry settings would mitigate exploitation of this issue, it could affect regular functionality for certain use cases related to these applications.

MS Documentation for the referenced registry settings:

• https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/general-info/ee330731(v=vs.85)#file-protocol-navigation (Thank you @johnmccash)

$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION"
$applications = @("Excel.exe", "Graph.exe", "MSAccess.exe", "MSPub.exe", "PowerPnt.exe", "Visio.exe", "WinProj.exe", "WinWord.exe", "Wordpad.exe")

if (!(Test-Path -Path $registryPath)) {
    New-Item -Path $registryPath -Force | Out-Null
}
foreach ($app in $applications) {
    Set-ItemProperty -Path $registryPath -Name $app -Value 1 -Type DWord
}

Do you know of a way to verify whether this setting is actually working, e.g. using a test document?
A simple word document containing a URL to file:///C:/Windows/System32/calc.exe, downloaded from the internet, doesn't seem to do the trick. calc.exe is still executed in spite of the registry setting (after clicking on "Enable editing" of course, and after two more confirmation dialogs).

Thanks!

I too am looking for a quick easy way to test this. I tried a shared .xlsm doc from onedrive and was able to execute a macro that had a child ping child process from explorer.exe and it was not blocked like I anticipated it would be.