Deprecated Windows 11 22H2 no longer supports Software Restriction Policies (SRP)

[Gandalf_The_Grey]

A brief note to Windows administrators who still rely on Software Restriction Policies (SRP). This security feature has been deprecated since 2020, but is still supported in Windows 10. But Windows 11 version 22H2 will definitely put an end to the use of Software Restriction Policies – App-Locker should be used instead.

Software Restriction Policies (SRP) deprecated

Software Restriction Policies (SRP) are a mechanism, with which administrators in Windows could specify over guidelines, which software may be executed in the operating system. The Software Restriction Policies are already available since Windows Server 2003 and are currently (according to this Microsoft page) still available under the following server variants:

• Windows Server 2012
• Windows Server 2012 R2
• Windows Server 2016
• Windows Server 2019
• Windows Server 2022

In addition, software restriction policies are supported in Windows clients (Windows 7, Windows 8.1, Windows 10, Windows 11 21H1). I still read (also within my German blog in user comments) some recommendations to use software restriction policies to harden the system.

However, Microsoft had already discontinued the Software Restriction Policies (SRP) in June 2020 (see my blog post Windows 10 Version 2004: Deprecated/removed features). Microsoft already wrote about Windows 10 version 1803:

Software Restriction Policies in Group Policy: Instead of using the Software Restriction Policies through Group Policy, you can use AppLocker or Windows Defender Application Control to control which apps users can access and what code can run in the kernel.

The Microsoft article Deprecated features for Windows client, which was last updated on November 2, 2022, also lists the Software Restriction Policies as deprecated. Until now, however, Software Restriction Policies (SRP) were still supported in Windows 10 as well as Windows 11 version 21H1. But with the discontinuation, administrators should have long been warned that this security feature will eventually fail.

SRP in Windows 11 22H2 without function

I just came across this on Twitter via the following Tweet from Will Dormann that Microsoft now has removed Software Restriction Policies (SRP).

Will Dormann writes that the list of Windows security/defense measures that seem to do nothing is now quite long. A new addition is the Software Restriction Policies (SRP), which don't seem to do anything as of Windows 11 22H2. He concludes by saying, "Hopefully no one relies on this feature!". I assume that the blog readers has long been aware and has said goodbye to Software Restriction Policies. If not, keep this trap in mind when using Windows 11. Let's see when the feature is removed from Windows 10.

Windows 11 22H2 no longer supports Software Restriction Policies (SRP)

[German]A brief note to Windows administrators who still rely on Software Restriction Policies (SRP). This security feature has been deprecated since 2020, but is still supported in Windows 10. But Windows 11 version 22H2 will definitely put an end to the use of Software Restriction Policies - App-L

borncity.com

 

[SpiderWeb]

Oh man. So many companies are about to be stuck with Windows 10 for a decade.

 

[wat0114]

I guess Applocker will only be available in the Enterprise and Education versions of Windows 11

 

[WhiteMouse]

The only option left for those who have Home and Pro SKU is WDAC.

 

[Andrezj]

the reports of srp not function on clean install win11 22h2 and odd behavior on upgraded to win11 OS are accurate, yet born's tech states and draws conclusions not confirmed by microsoft
born say srp was removed win 10 build 1803, not true as group policy controls were not removed, microsoft official documents list srp support for server 2022 back to 2003, then workstation from 11 all the way back to 7
the page they reference only says further development is stopped

microsoft has not discontinued srp on windows 11, it is a bug connected to clean installs of windows 11 and sac, microsoft is aware of it
this bug was reported many times during the insider build tests

microsoft official documentation for srp on windows 11 is listed as supporting srp, just think about it, millions of domain controllers, jump servers, radius servers, kerberos servers, servers of all kinds, all connected device members of a domain with the domain controller distributing srp through group policy or using other microsoft distribution methods like microsoft endpoint configuration manager or intune or using non-microsoft software policy distribution software (there are many)

microsoft is going to tell them all "sorry about your luck but srp gone on windows 11 22h2, downgrade to 21h1 or windows 10"? , watch an enterprise uprising and revolt against microsoft
a move from srp to applocker or wdac at the enterprise scale can cost in the many millions, not to mention all the editions of windows workstations and servers still being used that do not support applocker or wdac

published 12/09/2022 still lists support srp on windows 11

Application Control for Windows

Application Control restricts which applications users are allowed to run and the code that runs in the system core.

learn.microsoft.com

we will see

here is the official page where microsoft lists removed features for win10 and win11 workstation
srp is not listed

Features and functionality removed in Windows client

In this article, learn about the features and functionality that have been removed or replaced in Windows client.

learn.microsoft.com

 

[Gandalf_The_Grey]

Software Restriction Policies (SAFER) still possible under Windows 11 22H2 …

We was told, that Software Restriction Policies and SAFER no longer work out-of-the-box under Windows 11 22H2. This is caused by registry entries left in the ISO images, that make Windows 11 think that AppLocker is active (although it itsn't). This can be fixed with a small registry hack. Here is a short overview about the topic including the hack to continue using SAFER.

Stefan Kanthak has now contacted me by mail to point out that Software Restriction Policies and also SAFER can still be used under Windows 11 22H2. He wrote about this:

The cause of the behavior observed by Will Dormann is the usual sloppiness in Redmond: They ship Windows 11 with registry entries "thanks to" which it thinks AppLocker is active – which (as documented) overrides or disables SAFER.

Kanthak had already left this German comment there, pointing to the causal registry entries that trigger the mess. Stefan Kanthak mentions a simple workaround in his mail, which he already documented on seclists.org in February 2023 (see also), to get this behavior back on track and to be able to use SAFER and the Software Restriction Policies under Windows 11 22H2 again:

After deleting the registry entries:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp]
"RuleCount"=dword:00000002
"LastWriteTime"=hex(b):01,00,00,00,00,00,00,00
SAFER / SRP works as usual again. Kanthak notes that the timestamp is 100ns after 1/1/1601, so is grossly wrong, and that the rule count 2 (at RuleCount) is also wrong!

Kanthak has therefore adapted his NTX_SAFER.INF file to make these fixes automatically. Perhaps for your one or other blog reader, who also failed with the Software Restriction Policies under Windows 11 22H2, of interest.

Software Restriction Policies (SAFER) still possible under Windows 11 22H2 …

[German]We was told, that Software Restriction Policies and SAFER no longer work out-of-the-box under Windows 11 22H2. This is caused by registry entries left in the ISO images, that make Windows 11…

borncity.com

@Andy Ful Does this mean that Hard_Configurator and Simple Windows Hardening are back in business on a freshly installed Windows 11 22H2 ?

 

[Andy Ful]

@Andy Ful Does this mean that Hard_Configurator and Simple Windows Hardening are back in business on a freshly installed Windows 11 22H2 ?

Thanks. Yes, H_C works with this registry correction. On Windows 11 Home ver 21H2 this registry key is empty and SRP works well.
After introducing SAC to Windows 11 ver 22H2, some Applocker functionality is triggered automatically to monitor scripts and MSI files. It is activated in all SAC modes (even when SAC is turned OFF).

I must investigate the Kanthak correction to see if this can be a true solution, without issues on Windows 11 ver. 22H2.

 

[oldschool]

I must investigate the Kanthak correction to see if this can be a true solution, without issues on Windows 11 ver. 22H2.

Indeed, caution is the best advice at this point. I'll leave well enough alone. Thanks, @Andy Ful

 

[Gandalf_The_Grey]

Thanks. Yes, H_C works with this registry correction. On Windows 11 Home ver 21H2 this registry key is empty and SRP works well.
After introducing SAC to Windows 11 ver 22H2, some Applocker functionality is triggered automatically to monitor scripts and MSI files. It is activated in all SAC modes (even when SAC is turned OFF).

I must investigate the Kanthak correction to see if this can be a true solution, without issues on Windows 11 ver. 22H2.

Please keep us posted, I would be great if there is a solution

 

[Andy Ful]

Here is an interesting citation from the Windows Internals book:

The AppID and SRP services co-exist in the same binary (%SystemRoot%\System32\AppIdSvc.dll),
which runs within an SvcHost process. The service requests a registry change notification to monitor any changes under that key, which is written by either a GPO or the AppLocker UI in the Local Security Policy MMC snap-in. When a change is detected, the AppID service triggers a user-mode task (%SystemRoot%\System32\AppIdPolicyConverter.exe), which reads the new XML rules and translates them into binary format ACEs and SDDL strings, which are understandable by both the user-mode and kernel-mode AppID and AppLocker components. The task stores the translated rules under HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp. This key is writable only by SYSTEM and Administrators, and it is marked read-only for authenticated users. Both user-mode and kernel-mode AppID components read the translated rules from the registry directly. The service also monitors the local machine trusted root certificate store, and it invokes a user-mode task (%SystemRoot%\System32 \AppIdCertStoreCheck.exe) to reverify the certificates at least once per day and whenever there is a change to the certificate store. The AppID kernel-mode driver (%SystemRoot%\System32\drivers \AppId.sys) is notified about rule changes by the AppID service through an APPID_POLICY_CHANGED DeviceIoControl request. See Figure 6-27.

It looks like this registry key is used only when AppLocker is enabled. So, it should not be used on Windows Home when SAC is turned OFF. On Windows Home, the AppLocker functions cannot work without SAC.
For now, I am not sure if there can be any issue with Kanthak correction when SAC is in Evaluate or ON mode.

 

[Andy Ful]

The Kanthak correction does not work on my test machine (Windows 11 Home ver. 2022) when SAC is ON, because after restarting Windows, the previous registry values are automatically restored. But, I simply copied the values from my Windows 10 Pro (real system) and replaced the default values on Windows 11. Now both Hard_Configurator and SAC work together without issues. SAC blocks come first, before H_C blocks. We will see if this setup will survive the Windows Updates.

 

[ForgottenSeer 98186]

Indeed, caution is the best advice at this point. I'll leave well enough alone. Thanks, @Andy Ful

I thought you might find Kanthak's position on the matter a bit entertaining:



Just a FYI... the Microsoft learn pages for WDAC have a notice of deprecation of SRP and IT pros are advised to use either AppLocker or WDAC. Did you know that the people that create and maintain Microsoft documentation are not the feature developers? They are just document specialists with some knowledge of the project. Some doc maintainers know a lot more about the subject matter and internals than others, but generally, they know nothing about current feature internal issues (such as discussed here) and do not represent the formal position(s) of the developers. There is no process whereby the developers of a Microsoft feature or project "sit at a round table" to establish and guide the document creators & maintainers on what to publish. Think about that for a moment.

 

[oldschool]

I love built-in features but I'm going to rely on SAC alone for system stability. Maybe MS will fix the SRP issue or clarify but I'm not holding my breath.

 

[ForgottenSeer 97327]

@Andy Ful

So the H_C settings survive Reboot?

 

[Andy Ful]

@Andy Ful

So the H_C settings survive Reboot?

Yes.
Anyway, I think that for now, the Defender + SAC is enough for home users. Some basic SRP features are implemented in SAC, although they work only for files with MOTW (shortcuts, disk images, scripts, etc.).
So, users must be careful with flash drives where files cannot get MOTW due to the FAT32 format.
Another problem can be the attacks via documents (remote templates, add-ins, etc.) - the most popular attack is currently via MS Office XLL add-ins.
Many of these attacks will be mitigated by blocking unsigned executable payloads, but the malware can bypass SAC by using shellcode, reflective loading, signed executables, and some new techniques that will be probably developed in near future.

 

[ForgottenSeer 98186]

I love built-in features but I'm going to rely on SAC alone for system stability. Maybe MS will fix the SRP issue or clarify but I'm not holding my breath.

Microsoft provides everything that a (inclined, initiated, persevering) user needs to protect their system. No 3rd party software is ever needed. We can call the effort required to harden Windows a "usability" issue, but Microsoft does not see it that way. Microsoft's official position has always been that Windows is meant to be managed, and its administration is meant for IT pros. Its learn documentation pages are not written for the home user; they are written for IT professionals. The Home version is a "trickle-down" (more like a 'hand-me-down') and userland species get what Microsoft chooses to give them as far as security. If nobody noticed, security on the Home version is most definitely not a priority to Microsoft. Pretty desktop icons are.

This bit about the "remnant" or "bogus" AppLocker keys being "left behind" in Windows 11 22H2 might or might not be accurate. There is no indication whatsoever that Microsoft created those keys intentionally. However, as Kanthak states (paraphrase): "the key values are incorrect and non-sensical in that there are no AppLocker rules are connected to them". Looking at the evidence, I am inclined to think it is just sloppy work - as opposed to purposeful - on the part of whomever at Microsoft.

I would think someone that wants to enable SRP lockdown mode would not be so concerned about SAC working alongside SRP. SAC is for those "users who want to use stuff" and need a software to make security decisions for them. Oh, SAC and SRP working together can arguably be called a "nice-to-have," except for the security geek it is best if the home user relies upon default-allow (white-listing) SAC.

A user can add the Microsoft recommended block-list (or the entire LOLBin list if they choose) to Microsoft Exploit Guard and set a rule to block Win32 syscalls and then set program installs to Microsoft Store only - and they have an operating system default-deny configuration (S mode) that was the most malware-free in the company's history. The great security supplied by S Mode, a extremely low infection rate, are the very reasons why Microsoft developed SAC and is currently pushing that initiative.

SAC can do a lot of great things for userland, but it remains to be seen. Afterall, Microsoft is trying to cater to "users that want to use stuff," so user whims and profitability come first. (Think about it, what does Microsoft care if some gamer downloads a game cheat that turns out to be LAN-spreading ransomware and they infect all the home group connected devices in the household? lol, Microsoft offers $75 per device malware removal service= clean install Windows.) Microsoft will get a lot of user and developer complaints about SAC (which, at this point, is absolutely guaranteed) and then it will silently place SAC into maintenance.

 

[Andy Ful]

After some trial and error, I found out that the Kanthak correction can be simplified by the tweak:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp]
"RuleCount"=dword:00000000

Simply, one has to correct the invalid number of Applocker rules under this key (there are no rules at all). This value will not change, because SAC uses WDAC policies to control AppLocker, so no policies are added under this key.
This tweak works well with SAC, also if it is turned ON.

Update 09.03.2023
In fact, after the fresh installation of Windows 11 ver. 22H2 there are two rules in AppLocker. But, they are invisible in the Local Security Policy snap-in (Secpol. msc). So the "RuleCount"=dword:00000002 is valid. But it is also true that these rules do not add any restrictions. See for details:
https://malwaretips.com/threads/applocker-on-windows-home-part-2.121392/post-1029334

 

[oldschool]

A user can add the Microsoft recommended block-list (or the entire LOLBin list if they choose) to Microsoft Exploit Guard and set a rule to block Win32 syscalls

It would be great if someone started a thread to explain how to do this.

 

[oldschool]

Did you know that the people that create and maintain Microsoft documentation are not the feature developers? They are just document specialists with some knowledge of the project. Some doc maintainers know a lot more about the subject matter and internals than others, but generally, they know nothing about current feature internal issues (such as discussed here) and do not represent the formal position(s) of the developers.

I believe this is typical across industrial and professional companies, etc.

There is no process whereby the developers of a Microsoft feature or project "sit at a round table" to establish and guide the document creators & maintainers on what to publish. Think about that for a moment.

I think this can be intuited, at least by me, from reading MS docs.

 

[ForgottenSeer 98186]

It would be great if someone started a thread to explain how to do this.

Block LOLBins by adding to Exploit Guard:

NOTE 1: DLLs cannot be added to Exploit Guard; only .exe can be added.
NOTE 2: This method will block Office macros from launching or abusing the processes the user adds to Exploit Guard > Block Win32k system calls.
NOTE 3: The procedure below can be accomplished for a list of processes using PowerShell. If you want a script then I'll produce one.

# Basic cmdlet and syntax to add a process to Exploit Guard with Win32k system calls disabled.
# Run cmdlet within an Administrative PowerShell session.

Set-ProcessMitigation -Name "pwsh.exe" -Enable DisableWin32kSystemCalls

Procedure:

1. Open Windows Security Center
2. Select in left menu > App & browser control
3. Select beneath App & browser control (top of main window) > Exploit protection > Exploit protection settings
4. Select beneath Exploit protection (top of main window) > Program settings (tab)
5. Select beneath Program Settings (main window) > (+) Add program to customize (left-click on +)
6. Select > Add by program name (a program-add wizard window will open
7. Enter the program name (e.g. notepad.exe -- just for testing purposes)
8. Select Add
9. A Program Settings: process_name.exe window will open
10. Scroll down to "Disable Win32k system calls"
11. Tick > Override system settings
12. Click on radio button to set value to "ON"
13. Select > Apply

Test:

14. WIN key + R
15. Enter "notepad.exe"
16. Exploit Guard "Disable Win32k system" policy should block process (in this case, notepad.exe) and produce the following notification:



Source of executables (LOLBins; crowdsourced) to be added to Exploit Guard:

Applications that can bypass App Control and how to block them

View a list of recommended block rules, based on knowledge shared between Microsoft and the wider security community.

learn.microsoft.com

LOLBAS

lolbas-project.github.io

Configure Windows 10/11 to permit install of only Microsoft Store apps:

1. Open Settings app
2. Select > Apps in left menu
3. Select > Advanced app settings
4. Select > Choose where to get apps > Drop-down menu > The Microsoft Store only (Recommended)