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

[ForgottenSeer 97327]

I never got AppLocker and SRP working together on Windows7, allthough official documentation at that time said it was possible (with a warning that for ambiqueous rules AppLocker rules would prevail).

I am inclined to believe Oerlink that the people writing dicumentation are more communication experts than IT-experts.

When I used the WDAC wizzard in 2019 I did not expect SRP to work also, but they work fine alongside each other.

Alongside Defender on MAX with SAC, I can see the benefits of SRP blocking sponsors/LoLbins for unelevated users/processes (this would never interfere with updates, only raise the bar for fileless attacks).

 

[ForgottenSeer 97327]

@oldschool

The beauty of blocking LoLbins with SRP is that this can be made to only apply for medium integrity rights processes, making it a 100% safe tweak.

Some of the Lolbins can be blocked by Exploit Protection because they are obsolete for home users (e.h. mshta.exe).

Microsoft itself publishes a 'recommended blocklist' so I guess these could also be safely blocked by MD Exploit Protection.

I am currently abroad for work again. I will apply Oetlink's tweak for Mictosoft recommended blocklist (assuming MS would not recommend it when it breaks monthly updates) when I get home and report back after first succesfull tuesday patch day.

Unless Oerlink had applied this tweak for himself. @Oerlink how long are you running this Exploit Protection tweak. And if so for which LoLBins?

 

[ErzCrz]

interesting reading and glad to hear SRP work with the workaround. I don't have plans to fresh install this new laptop, just too much installed and I don't want to lose OEM apps that came with this, so without SAC, seems H_C SRP is the way to go for me.

 

[Gandalf_The_Grey]

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.

And what did you do with LastWriteTime"=hex(b):01,00,00,00,00,00,00,00 ?
Keep or delete that?

 

[Andy Ful]

And what did you do with LastWriteTime"=hex(b):01,00,00,00,00,00,00,00 ?
Keep or delete that?

Just ignore it.

 

[Andy Ful]

There are several ways of blocking LOLBins. They were discussed many times on MT (including Exploit Protection tweaks):

1. SRP, AppLocker, WDAC (MDAC).
2. Image File Execution Options (Debugger tweak).
3. Exploit Protection (another Image File Execution Options tweak) - it can be done via Security Center.
   In some cases, additional mitigations can be needed to block the LOLBin.
4. Explorer Policies (user dependent).
5. Special policy for Windows Script Host.
6. Special policy for CMD (user dependent).

In my applications, I commonly use SRP, Exploit Protection (bitsadmin.exe in FirewallHardening), and Windows Script Host policy. The most comprehensive are methods from points 1 and 5 (especially WDAC).
SRP (Applocker) is most useful, because scripting LOLBins (CMD and Windows Script Host) and MSI Installer can be selectively whitelisted for some files.

Blocking LOLBins is easy, but I do not recommend this method without knowing how to find the info about blocked processes. In the case of Exploit Protection, this can be partially done via Event Id=26 (Application Popup).

 

[ForgottenSeer 97327]

Yes, blocking them with SRP for SUA is the most secure way. Blocking them with exploit protection by crippling them is more risky, but for some depreciated lolbins (like mshtma, cmd and wscript) and some non-corporate lolbins (wmi an remote) the risky cripple approach of @Oerlink probably is fine (although @Oerlink has again not confirmed he actually used it in practice )

 

[Andy Ful]

Yes, blocking them with SRP for SUA is the most secure way. Blocking them with exploit protection by crippling them is more risky, but for some depreciated lolbins (like mshtma, cmd and wscript) and some non-corporate lolbins (wmi an remote) the risky cripple approach of @Oerlink probably is fine (although @Oerlink has again not confirmed he actually used it in practice )

On MT the method of blocking LOLBins via Exploit Protection was first proposed probably in November 2021:
https://malwaretips.com/threads/simple-windows-hardening.102265/post-961964
https://malwaretips.com/threads/simple-windows-hardening.102265/post-967274

I tested it for a few months without any issues. I also planned to release a simple application similar to the Hard_Configurator <Block Sponsors> module, but it seems that it will not be necessary when SRP still works on Windows 11. Furthermore, blocking LOLBins via MDM AppLocker is more comprehensive.
The advantage of this method is that it can be configured via Security Center.

 

[ForgottenSeer 98186]

Blocking them with exploit protection by crippling them is more risky

Where do you come up with this? A block is a block; the method is irrelevant. All block methods "cripple" the process insofar as the blocked process does not execute. Using Exploit Guard to block processes does not create system instabilities.

Unlike AppLocker, SRP and WDAC, there are no known bypasses of Exploit Guard (if interpreters and other utilities that can modify Exploit Guard policies or tamper with the service are blocked). Microsoft is worried about allow policies (AppLocker) and WDAC bypasses to the extent that it explicitly puts a warning on the official WDAC learn documents page - and provides a laundry list of .exe and DLLs that should be blocked to provide full security:

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

The advantage of this method is that it can be configured via Security Center.

Exactly. A user can go into Security Center and temporarily turn off the block policy if they need to use one of the blocked processes, and then turn it back on when finished to restore security to a locked down state. The "On-Off" of Exploit Guard policies is immediate without a need to log-out\log-in or reboot the system. To some people this is decent "usability."

Furthermore, blocking LOLBins via MDM AppLocker is more comprehensive.

What @Andy Ful means here is that AppLocker is "block by default, allow by exception" and can include DLLs and other file types which cannot be added to Exploit Guard.

 

[oldschool]

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

Although I'm familiar with using Exploit protection, that would be nice. I know configurations can be written in XML (which I don't know) and imported via PS. Otherwise, I assume all the LOLbins in MS's recommended blocklist would need to be individually.

In the example above, I assume I could just copy the last line and substitute the other LOLBins?

 

[oldschool]

Microsoft is worried about allow policies (AppLocker) and WDAC bypasses to the extent that it explicitly puts a warning on the official WDAC learn documents page - and provides a laundry list of .exe and DLLs that should be blocked to provide full security:

Indeed, I've read it before in MS docs.

Interesting discussion @Andy Ful @Max90 @Oerlink. You're helping me refine my understanding of Windows' different features.

 

[ForgottenSeer 98186]

Indeed, I've read it before in MS docs.

There are always "Pros" and "Cons" to whatever a user chooses - Microsoft or otherwise.

The "What-Ifs" are fringey and blown out of proportion, much like most things in security. But if you are the type of person that adheres to the philosophy of "Better to be prepared than sorry," well you change AV every other day when a new test, report or document indicates any weakness. Either that or you apply nuclear ballistic armor to your devices. Others just disconnect and throw their devices off a bridge and be done with it all.

 

[eonline]

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

I tried this on a production machine, adding and disabling the execution of all the executables in the GitHub repository. My recommendation from my experience is that it can bring more problems than solutions, especially when installing a driver for a video card, etc.

The configurations and their different variants that were shared in another thread in the following link:

Advice Request - Maximum Anti-Exploit protection settings for your program

I like to open a thread about maximum possibly anti-exploit protection settings (from Windows Defender) so every user can import/ export that settings. First, here some reading material...

malwaretips.com

 

[oldschool]

But if you are the type of person that adheres to the philosophy of "Better to be prepared than sorry," well you change AV every other day when a new test, report or document indicates any weakness. Either that or you apply nuclear ballistic armor to your devices.

I prefer the "Stay safe, not paranoid" approach. The simpler, the better, and I enjoy learning about built-in options.

 

[ForgottenSeer 98186]

I tried this on a production machine, adding and disabling the execution of all the executables in the GitHub repository. My recommendation from my experience is that it can bring more problems than solutions, especially when installing a driver for a video card, etc.

That is true no matter what method is used to block a process. You disable the blocking mechanism, install the software, then re-enable the protection. It cannot get any more simple. Like a light switch. "On-Off-On." The process of installs is no different than using other methods to block such as SRP, any of the hardening utilities available, anti-executables, Group Policy and so on.

Lots of people who have managed Windows systems and enterprises block 150+ processes globally and they have zero troubles. Then there are those unmanaged users (home users) that block the entire LOLBin list (e.g. using Hard_Configurator) without a single issue. They can sort out any "blocks" and they find it perfectly trouble-free.

Microsoft created S Mode - deliberately to prevent users from downloading stuff from non-Microsoft sources - like drivers. It was, and remains, the most secure version of Windows.

I get that lots of users cannot resolve issues based solely on block event logs nor do they want a system that prevents them from installing stuff. Not everybody has the inclination, the aptitude nor the desire. For those users, they are best served by a default allow solution such as F-Secure or Kaspersky.

That said, every user has to decide for themselves what works best for them personally.

 

[ForgottenSeer 98186]

Although I'm familiar with using Exploit protection, that would be nice. I know configurations can be written in XML (which I don't know) and imported via PS. Otherwise, I assume all the LOLbins in MS's recommended blocklist would need to be individually.

In the example above, I assume I could just copy the last line and substitute the other LOLBins?

Try this for a simple test - just to make sure it works for you. Later the LOLBin list can be expanded to include as many process names as you wish.:

# PowerShell ForEach loop to add contents of LOLBins array (list) to Exploit Guard and disable
# execution by creating a blocked Win32k syscall policy.
#
# Copy-paste the lines below into a PowerShell console running with Administrative permissions > Enter
#
# For the process names to appear in the Exploit Guard GUI you might have to close Windows Security Center and re-open it.

 $LOLBins = @("cscript.exe","wscript.exe")
 ForEach ($LOLBin in $LOLBins) { Set-ProcessMitigation -Name $LOLBin -Enable DisableWin32kSystemCalls -Verbose }

 

[oldschool]

Try this for a simple test - just to make sure it works for you. Later the LOLBin list can be expanded to include as many process names as you wish.:

# PowerShell ForEach loop to add contents of LOLBins array (list) to Exploit Guard and disable
# execution by creating a blocked Win32k syscall policy.
#
# Copy-paste the lines below into a PowerShell console running with Administrative permissions > Enter
#
# For the process names to appear in the Exploit Guard GUI you might have to close Windows Security Center and re-open it.

 $LOLBins = @("cscript.exe","wscript.exe")
 ForEach ($LOLBin in $LOLBins) { Set-ProcessMitigation -Name $LOLBin -Enable DisableWin32kSystemCalls -Verbose }

This was post-execution, before restart.

 

[Andy Ful]

The discussion about blocking LOLBins is interesting, but not really necessary for home users in the thread about (classic) SRP. Blocking LOLBins is not necessary when using a properly configured SRP at home on Windows 10+, with some hardening of Microsoft Office. The same is probably true when using SAC, because it has got some SRP-like features (for files with MOTW) that are not included in AppLocker and WDAC. People who turned ON the SAC, can block some LOLBins to protect the system against infections from flash drives (no MOTW).
Some LOLBins should be blocked when using AppLocker or WDAC to avoid known bypasses.

In the business environment, blocking some LOLBins (and unnecessary Windows features) is advantageous with any protection, because of the danger of lateral movement.

 

[ForgottenSeer 98186]

This was post-execution, before restart.
View attachment 273181

You ran the cmdlets inside a non-Admin Windows PowerShell console. So the cmdlets were run with non-elevated permissions and therefore threw the "wonky" Microsoft technobabble errors.

Try again using an Admin Windows PowerShell console session.

 

[oldschool]

The discussion about blocking LOLBins is interesting, but not really necessary for home users in the thread about (classic) SRP.

Sorry about polluting the thread.