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

F

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).
 
F

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?
 
Last edited by a moderator:

Gandalf_The_Grey

Level 78
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Apr 24, 2016
6,744
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

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,215
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).
 
Last edited:
F

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

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,215
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.
 
F

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:

2023-02-26 11_58_25-Flashback Express.png


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.
 
Last edited by a moderator:
  • +Reputation
Reactions: oldschool

oldschool

Level 82
Verified
Top Poster
Well-known
Mar 29, 2018
7,182
The procedure below can be accomplished for a list of processes using PowerShell. If you want a script then I'll produce one.
Code:
# 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. (y) 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? 🤔
 
Last edited:

oldschool

Level 82
Verified
Top Poster
Well-known
Mar 29, 2018
7,182
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.
 
F

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

Level 21
Verified
Well-known
Nov 15, 2017
1,069
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:

2023-02-26 02_39_03-Flashback Express.png

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

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:


:)
 

oldschool

Level 82
Verified
Top Poster
Well-known
Mar 29, 2018
7,182
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.
 
Last edited:
F

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.
 
Last edited by a moderator:
F

ForgottenSeer 98186

Although I'm familiar with using Exploit protection, that would be nice. (y) 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.:

Code:
# 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 }
 
Last edited by a moderator:
  • Thanks
Reactions: oldschool

oldschool

Level 82
Verified
Top Poster
Well-known
Mar 29, 2018
7,182
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.:

Code:
# 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.
PS script result 2023-02-26 140239.png
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,215
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.
 
Last edited:

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top