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

[ForgottenSeer 98186]

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

Not necessary, but educational. Some people asked, and I replied.

What I do know is that the "LOLBins initiatives" began as security research movements as part of investigations of SRP protections - and continued on with SRPv2 (AppLocker) and SRPv3 (WDAC). So discussion of LOLBins is relevant. Does a user have to block every single LOLBin applicable to their OS? No. Not necessary. I know I have never said that. But users do have the option to do so if they so choose, using multiple different methods.

Microsoft's official position on LOLBins is a bit different. If it had its way, it would force S Mode, with its laundry-list of blocked processes and DLLs, onto every unmanaged Windows device user, but will not because users complain they cannot "use stuff" and undermine a superior protection model. Since it cannot force S Mode onto users, it came up with SAC.

As far as only discussing topics that are appropriate for "home users." Meh. This is a forum by and for security geeks - and not the average computer user that has little or no interest in what they can or cannot accomplish on Windows. I think detailed discussions get squashed here too often because the thinking is that a "home user" might read something and hurt themselves with it.

(This is not intended for you, @Andy Ful ). I just don't get it. In the Linux and Mac worlds, discussions about LOLBins trigger no strong feelings, and yet on this forum particularly, anything that blocks globally on Windows sets some members off into a tizzy. If one talks about addressing an entirely preventable and controllable primary issue - user behaviors - then that triggers people as well. Just odd.

 

[ForgottenSeer 98186]

Sorry about polluting the thread.

The thread is titled "Windows 11 22H2 no longer supports Software Restriction Policies (SRP)".

So it is natural that people would talk about alternatives to classic SRP here, in this very thread.

Is that pollution? Can I wring some "atmospheric warming" out of it? Sort of at the level of a cozy campfire would help at the moment.

 

[Andy Ful]

Sorry about polluting the thread.

I did not mean this (maybe a little).
I rather wanted to point out that it is better to configure the protection in a way that blocking LOLBins is not necessary. This mostly means that the attack has to be prevented at a very early stage. It is much harder to protect the system on the stage when LOLBins are used.
An example: blocking the LNK file type (shortcut) in UserSpace is more efficient than blocking two hundred LOLBins that can be run via shortcuts. That is why SAC does not block LOLBins, but can block LNK files (with MOTW).

 

[ForgottenSeer 98186]

I rather wanted to point out that it is better to configure the protection in a way that blocking LOLBins is not necessary.

I would agree, but Microsoft says otherwise. It blocks LOLBins on its own OS and advocates that users do the same - IF - they do not need the process. There is a lot of paranoia about "What-If" this or that gets blocked during usage and, in reality, those cases are rare or easily solved.

Examining SRP block logs from thousands upon thousands of endpoints, shows that a block that breaks something is rare. Even then, it is not permanently broken. It just takes a fix. But I get that most unmanaged home users have no inclination or aptitude for this.

I know there has been lots of mis-information that global blocking creates an overwhelmingly negative user experience. That just ain't true. That claim is just what it is - deliberate mis-information FUD spread by those with an agenda.

LOLBin blocking is a higher-level protection model. It takes a bit of knowledge, but its not as if people could not learn it - IF - they wanted to. The whole premise of LOLBin blocking is to throw-up a major speed-bump-wall against more sophisticated threat actors. Most home users don't even know what that is, let alone care. The protection model is not absolutely effective under any possible circumstances. However, to a large extent it handily deters all those talented malc0ders looking to exploit the chink in the armor.

There is no right or wrong protection model. Users should be provided ALL of the information so that they can determine for themselves what works best for them personally.

 

[oldschool]

The thread is titled "Windows 11 22H2 no longer supports Software Restriction Policies (SRP)".

So it is natural that people would talk about alternatives to classic SRP here, in this very thread.

Is that pollution?

I didn't mean it literally, and I agree with you.

Can I wring some "atmospheric warming" out of it?

??

Sort of at the level of a cozy campfire would help at the moment.

I doubt @Jack would allow a campfire but yes, we can and are ostensibly sitting around the campfire discussing this ...

Nobody's being cut off or asking to lock the thread.

 

[ForgottenSeer 98186]

I didn't mean it literally, and I agree with you.

I know you did not mean it, but I thought it was funny.

??

Failed climate-change humor.

I doubt @Jack would allow a campfire but yes, we can and are ostensibly sitting around the campfire discussing this ...

I just burnt me marshmallows.

Nobody's being cut off or asking to lock the thread.

I know. It is just the general vibe.

 

[ForgottenSeer 97327]

@Oerlink: Do you use the Exploit Protection Block method yourself and if so for which LoLBins and for how long are you running this ?

 

[Andy Ful]

@Oerlink,

I am sorry if you understood that I reproached you in any way. I was an active participant in the discussion about blocking LOLBins, so it would be strange to complain about it.
I explained this in my previous post. As you know, all my applications restrict Windows, so I feel obligated to point out which restrictions are necessary/recommended for home users.
You do not have to feel attacked in any way from my side, because I appreciate most of your posts even if rarely I have a different opinion.

 

[Andy Ful]

Back to the discussion. I think that there is a general agreement about blocking LOLBins in businesses. I would like to note that in businesses the LOLBins will be blocked mostly via SRP, AppLocker, WDAC, etc. There is no need to use Exploit Protection for that. It is probable that it can be more popular at home (including home businesses).
From my experience, most readers are attracted by restrictions and mitigations used in businesses and try to implement them at home. It is not necessarily a good idea. Home users should rather pay attention to Smart App Control. This is a recommendable approach at home.

I am not saying that blocking LOLBins at home is wrong. I am trying to say that it is not the optimal solution at home on Windows 10+.

Unfortunately, if one does not like the classic SRP and cannot live with SAC, then some LOLBins should be probably blocked. Blocking cmd, powershell, wscript, and cscript can be a starting point. From my tests, it follows that after installing Windows Updates the system sometimes tries to use cmd, regsvr32, and runonce, but I did not notice any negative impact after such blocks. On most computers, there will be a few blocks per day related to rundll32, because it is used in the Windows telemetry.

 

[ForgottenSeer 97327]

I have some time off, compensation for working in the weekend. The list below contains the sposors I am blocking with SRP. When they are in bold/capitals it means that they are also blocked with Exploit Protection. SRP blocks are only for unelevated processes/users, the MD-EP blocks are not real blocks. By enabling all exploit protections in MD these programs just don't run or crash (are crippled by MD-EP).

Spoiler: SRP blocks and EP-crippling

I intended to cripple legacy scriptors, remote and linux stuff with developers tools (debuggers and compilers etc). When I missed some (e.g. development tools) feel free to comment.

I kept them in the SRP blocklist, because this shows a clear blocked by admin warning (better than no message or a message that a program crashed)

 

[ForgottenSeer 98186]

@Oerlink,

I am sorry if you understood that I reproached you in any way. I was an active participant in the discussion about blocking LOLBins, so it would be strange to complain about it.
I explained this in my previous post. As you know, all my applications restrict Windows, so I feel obligated to point out which restrictions are necessary/recommended for home users.
You do not have to feel attacked in any way from my side, because I appreciate most of your posts even if rarely I have a different opinion.

Why, whatever do you mean - Andy? LOL. Online discussions are difficult. Open to many problems due to misunderstandings. I did not think you were attacking me. As for other comments regarding "some people" getting triggered by blocking LOLBins globally, that's not you. Some other parts are in "jest".

From my experience, most readers are attracted by restrictions and mitigations used in businesses and try to implement them at home. It is not necessarily a good idea.

It depends upon the individual user. They have to be a combination of knowledge, capable of figuring out things, and being able to resolve issues on their own. They also have to be the type that does not fret that blocking is "breaking things in some unknown, hidden way." That of course, is not how the majority of users are.

There is no need to use Exploit Protection for that. It is probable that it can be more popular at home (including home businesses).

Ease-of-Use

Home users should rather pay attention to Smart App Control. This is a recommendable approach at home.

Most homes users do not even know that SAC is on the system and running. But I get it. You are talking about more security-aware users.

 

[ForgottenSeer 98186]

@Oerlink: Do you use the Exploit Protection Block method yourself and if so for which LoLBins and for how long are you running this ?

I combine the two public Microsoft recommended block lists - the first is WIndows S Mode block list and the other is the WDAC bypass-prevention blocklist:

Windows 10 in S Mode Driver Requirements - Windows drivers

Windows 10 in S mode Driver Requirements

learn.microsoft.com

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

I would not block PowerShell.exe if you are going to use it for routine (as in "frequent") localhost sysadmin.

I remove any processes from the combined list that do not exist on the OS image. Since SAC is now running, I would also cross-reference and remove any LOLBins that are blocked by default SAC policy - IF - you are running it full-time in "ON."

My system is not 100% Microsoft. Over about 8 months I've had not a single major issue. The Windows Defender Security Center GUI can get unstable when many items are added, but that is just a GUI bug and not any kind of real problem. It is a lot faster and easier to many Exploit Guard using PowerShell if you are going to want to disable or re-enable Exploit Guard policies on a frequent basis.

There is some trial and error to figure out what works best for you personally.

 

[Andy Ful]

Blocking PowerShell is a most valuable restriction. I think that you have in mind also WDAC restrictions (Constrained Language Mode), but the attackers found some ways to bypass it.
A partial solution would be blocking powershell.exe and allowing powershell_ise.exe. In purpose to use powershell_ise.exe, one has to change the ExecutionPolicy to RemoteSigned (or Unrestricted).
Another useful restriction would be to block outbound connections for PowerShell.

If regedit.exe is not blocked, then Exploit Protection for any executable can be easily applied/removed by using a simple .reg file (so one does not have to use PowerShell for that).
For example:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\powershell.exe]
"MitigationOptions"=hex:00,00,00,10,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"MitigationAuditOptions"=hex:00,00,00,20,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"EAFModules"=""

It is easy to create the reg file for other LOLBins by replacing powershell.exe with another LOLBin.

Post edited/corrected.

 

[Andy Ful]

When using WDAC (with ISG) + blocked LOLBins, one attack vector can still be a problem = DLL hijacking.
When the EXE file has got MOTW then it is checked on execution by SmartScreen and if allowed, the ISG does not block the EXE and DLLs loaded by it. This special behavior was introduced to lower false positives when installing applications. If I correctly remember, SAC can prevent this attack vector (also WDAC without ISG).

 

[ForgottenSeer 98186]

Blocking PowerShell is a most valuable restriction. I think that you have in mind also WDAC restrictions (Constrained Language Mode), but the attackers found some ways to bypass it.

I agree.

My suggestion was for a person that uses PowerShell frequently to configure their Windows, it depends upon how often they uses PowerShell.

For heavy use, I would just use PowerShell (pwsh.exe) and set the registry key to permanently enable Constrained Language Mode and keep Execution Policy set to restricted.

One issue with PowerShell_ISE console is that it does not permit interactive commands and apps.

What solution (and there are multiple ways secure PowerShell) is dependent upon what the user is attempting to do.

 

[Andy Ful]

For heavy use, I would just use PowerShell (pwsh.exe) and set the registry key to permanently enable Constrained Language Mode and keep Execution Policy set to restricted.

This is probably a good idea at home. It is worth mentioning that applying Constrained Language Mode by a registry tweak can be bypassed with standard rights. But this probably will not happen in attacks on home users.
For a half year, I worked on similar protection which would simulate some SRP capabilities without using SRP.

CMD and PowerShell can be blocked by Exploit Protection, and Windows Script Host by Windows policy.
Furthermore, the user can block several file types similarly to SRP. I used the Windows built-in mechanism for choosing the default application to open files, so the files from the BlockList are opened by default via RunBySmartscreen tool (unpublished version so far). This also allows whitelisting scripts and a few other file types when they are located in the %WindDir% or %ProgramFiles% folders.
Such protection can be easily switched ON/OFF (current settings are remembered) from the application main Window. Furthermore, the user can open any blocked file via the 'Open with' option from the Explorer context menu (instead of whitelisting).
By adding AppLocker (via WMI MDM Bridge) one could get protection similar to SAC (but more flexible).

It is a nice tool, but If the SRP will work on Windows 11, I would prefer SimpleWindowsHardening (SWH) which is based on classic SRP.

 

[ForgottenSeer 97327]

When using WDAC (with ISG) + blocked LOLBins, one attack vector can still be a problem = DLL hijacking.
When the EXE file has got MOTW then it is checked on execution by SmartScreen and if allowed, the ISG does not block the EXE and DLLs loaded by it. This special behavior was introduced to lower false positives when installing applications. If I correctly remember, SAC can prevent this attack vector (also WDAC without ISG).

Do I understand correctly that for this scenario to succeed, the attacker needs a legitimate exe and has to couple it with a malicious dll using the name of a legitimate dll and that malicious dll has to be located in the same folder where the exe is executed from.

 

[Andy Ful]

Do I understand correctly that for this scenario to succeed, the attacker needs a legitimate exe and has to couple it with a malicious dll using the name of a legitimate dll and that malicious dll has to be located in the same folder where the exe is executed from.

Yes. Also, the files must have MOTW. This can be done by embedding the files in the ZIP archive or disk image (ISO, IMG, etc.). Another possibility is via HTML smuggling. When the archive or disk image is downloaded from the Internet and opened, the MOTW is transferred to the extracted files.

 

[ForgottenSeer 98186]

It is worth mentioning that applying Constrained Language Mode by a registry tweak can be bypassed with standard rights.

Would you please send me a PM? I would like to discuss privately.

For a half year, I worked on similar protection which would simulate some SRP capabilities without using SRP.

View attachment 273249

View attachment 273250

View attachment 273252

This is an awesome utility. There would be a lot of interest in it.

 

[ForgottenSeer 97327]

Would you please send me a PM? I would like to discuss privately.

I am also curious. I thought changing environment variables normally requires admin rights (when @Andy Ful is taling about __PSLockDownPolicy)