New Update Applocker on Windows Home part 2.

[Andy Ful]

This thread is about a different method of applying the AppLocker policies on Windows Home. The first method was discussed in the thread:
https://malwaretips.com/threads/applocker-on-windows-home.118614/
It was based on MDM WMI Bridge implemented in PowerShell.

In this thread, I am going to use the GPO policies.
Yes, the GPO Applocker policies can work well on Windows 10 Home without GPO!!!

How to do it.
One has to use the binary policies made on the computer with Windows Pro (Appx.AppLocker, Dll.AppLocker, Exe.AppLocker, Msi.AppLocker, Script.AppLocker). They are located in the directory:
%WinDir%\System32\Applocker

1. Copy these 5 policies to the computer with Windows 10 Home (into %WinDir%\System32\Applocker).
2. Open the PowerShell console with Administrator rights and set the AppIDSvc service to automatic:
   sc.exe config appidsvc start= auto
3. Add the registry keys (the second key is QWORD):
   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp]
   "RuleCount"=dword:00000002
   "LastWriteTime"=hex(b):01,00,00,00,00,00,00,00
4. Restart the computer.

The AppLocker protection can be turned OFF/ON by changing the registry value:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp]
"RuleCount"=dword:00000002

If it is equal to 0 then AppLocker is turned OFF. If it is equal to 2, then AppLocker is turned ON.

WARNING:

• When AppLocker is turned ON, the SRP automatically turns itself OFF. So, the restrictions made by SimpleWindowsHardening or Hard_Configurator will not work with AppLocker.
• This method is incompatible with AppLocker introduced via MDM WMI Bridge (MDM policies should be removed from the AppLocker directory).

The method presented in this thread is new, so please test it first in the Virtual Machine.

 

[Andy Ful]

This method can be used at home or for home businesses to apply some basic AppLocker rules on Windows 10 Home. For example, here are rules kinda similar to Smart App Control on Windows 11 :

1. The unsigned EXE, DLL, and MSI files can be allowed in %ProgramFiles% and %Windows% folders and blocked otherwise (MSI files when executed with standard rights).
2. The signed files can be allowed everywhere.
3. Scripts can be allowed in %ProgramFiles% and %Windows% folders and blocked otherwise (when executed with standard rights).
4. All Scripts and MSI files can be allowed when executed with administrator rights.

If needed, the restrictions can be turned OFF/ON easily by a simple reg tweak. Whitelisting is not possible (would require new policies made on Windows Pro)

 

[ForgottenSeer 97327]

Thanks for investigating this and finding a solution, but I guess mos Windows10Home users find it easier to use SWH or H_C, appreciate the effort and time you put in these matters

 

[Andy Ful]

Thanks for investigating this and finding a solution, but I guess mos Windows10Home users find it easier to use SWH or H_C, appreciate the effort and time you put in these matters

I also prefer the solution based on SRP. But it does not hurt to explore other possibilities.
Until now I knew that SRP and WDAC policies can work on Windows Home. I was kinda surprised that also AppLocker GPO policies can work on Windows Home, where there is no GPO at all.
It means that the core of Windows built-in security is already implemented in Windows 10 Home and GPO is only a kind of front-end that makes this security more usable.

 

[Andy Ful]

On Windows 11, Microsoft introduced something new: LowBox Token Permissive Learning Mode.
It is possible that it is used in two non-standard (identical) AppLocker policy files: Exe.AppLocker and Dll.AppLocker. These policies are applied by default after installing Windows 11 ver. 22H2.

We can see the important strings:

• S-1-15-2-1 ----> the SID of APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
• LowBox ----> the original codename for AppContainer

From the article about LowBox Token Permissive Learning Mode, it follows that:

This feature allows you to start an AppContainer sandbox process, run a task, and determine what parts of that would fail if you actually tried to sandbox a process. This makes it much easier to determine what capabilities you might need to grant to prevent your application from crashing if you tried to actually apply the sandbox. It's a very useful diagnostic tool, ...

LowBox Token Permissive Learning Mode

I was recently asked about this topic and so I thought it'd make sense to put it into a public blog post so that everyone can benefit. Windo...

www.tiraniddo.dev

These two AppLocker policies were introduced by Microsoft without using GPO, so they are invisible on Windows 11 Pro via secpol.msc or gpedit.msc (also via PowerShell cmdlets). They are also the source of the trouble with SRP on Windows 11. One can switch OFF/ON the AppLocker by using the reg tweak:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp]
"RuleCount"=dword:00000000 ---> AppLocker switched OFF, rules inactive (but not removed) ---> SRP works.
"RuleCount"=dword:00000002 ---> AppLocker switched ON, and the previous rules activated again.

When SAC on Windows 11 is OFF, then one can delete this registry value which is the same as setting it to 0. The deleted value will not be restored after restarting Windows. This tweak can be used to turn ON SRP.

Anyway, when SAC is in Evaluate or ON mode, the value ("RuleCount"=dword:00000002) is restored after restarting Windows, so deleting it will not help to turn ON SRP. One has to set "RuleCount"=dword:00000000. If so, then the previous value will not be restored after restarting Windows. This tweak can be used to turn ON SRP when SAC is set to any mode.

 

[Andy Ful]

The correction to the previous post.

It is not probable that the policies discussed in the previous post are related to LowBox Token Permissive Learning Mode.
I examined the AppLocker policies created on Windows 10 Pro via GPO. The segment of code containing the strings related to AppContainer is present in all policies (EXE, DLL, MSI, Script, and Appx).
After removing the policies via GPO on Windows 10, AppLocker writes "empty" policies that do not contain that segment of code.

Things look slightly different on Windows 11 ver. 22H2. After removing the policies via GPO, AppLocker writes "empty" policies just like on Windows 10, with 2 exceptions. For EXE and DLL the nonstandard (and binary equal) policies are restored as in the previous post:

So, it is still kinda a mystery what is the purpose of two nonstandard policies (Exe.AppLocker and Dll.AppLocker) on Windows 11 ver. 22H2. They do not apply any known restrictions.
So, why are they present on the fresh-installed Windows 11, even if the user did not apply any AppLocker rules?

Post edited.

 

[Andy Ful]

After some research, I managed to find some helpful information about two nonstandard policies on Windows 11 (discussed in my previous posts).

The Internals of AppLocker - Part 3 - Access Tokens and Access Checking

This is part 3 in a short series on the internals of AppLocker (AL). Part 1 is here , part 2 here and part 4 here . In the last part I ou...

www.tiraniddo.dev

I followed the instructions from this article and used the Format-AppLockerSecurityDescriptor function to get some information about the standard and non-standard Exe.AppLocker files.

Here is the information about the standard "empty" Exe.AppLocker file on Windows 10:
<DACL>
- <EMPTY ACL>

Here is the information about the "nonstandard empty" Exe.AppLocker file on Windows 11 ver. 22H2:
<DACL>
- Type : Allowed
- Name : APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
- SID : S-1-15-2-1
- Mask : 0x001200A0
- Access: Execute|ReadAttributes|ReadControl|Synchronize
- Flags : None

It looks like the non-standard AppLocker policy does not apply any restrictions, but allows all application packages. So, switching off the AppLocker on Windows 11 ver. 22H2 does not lower the SAC protection. But, in theory, it can have some impact when running applications from Microsoft Store (or 3rd party resources with the packaged apps).

 

[Gandalf_The_Grey]

@Andy Ful What is your conclusion from all this? Do you consider setting RuleCount"=dword:00000000 a clever way to get SRP working again and use Simple Windows Hardening and/or Hard_Configurator on a fresh install of Windows aa 22H2? And do you recommend it?

 

[Andy Ful]

@Andy Ful What is your conclusion from all this? Do you consider setting RuleCount"=dword:00000000 a clever way to get SRP working again and use Simple Windows Hardening and/or Hard_Configurator on a fresh install of Windows aa 22H2? And do you recommend it?

Yes. But, I am going to wait a while to see the reaction of Microsoft.
I still do not fully understand, why Microsoft applied 2 "nonstandard empty" rules which are active in any SAC mode. In my tests (so far), I did not see any difference in installing/running/auditing packaged applications when RuleCount"=dword:00000000.

 

[oldschool]

Yes. But, I am going to wait a while to see the reaction of Microsoft.
I still do not fully understand, why Microsoft applied 2 "nonstandard empty" rules which are active in any SAC mode. In my tests (so far), I did not see any difference in installing/running/auditing packaged applications when RuleCount"=dword:00000000.

Any new info to share regarding this setting?

 

[Andy Ful]

Any new info to share regarding this setting?

No info from Microsoft. Anyway, H_C works flawlessly (with my correction) on Windows 11, also with enabled SAC.
I installed several packaged applications from Microsoft Store without any issues. SAC also accepts the unsigned H_C uninstaller (made by NSIS) after connecting with the cloud backend. I plan to publish the H_C ver. 6.1.1.1 in April.

 

[oldschool]

Anyway, H_C works flawlessly (with my correction) on Windows 11, also with enabled SAC.

Okay, that's good to know if I really want to lock my system down.

What is your experience with SAC with app installs, etc. so far?

 

[Andy Ful]

What is your experience with SAC with app installs, etc. so far?

I can live with it, so far.
It can take some time until many opensource unsigned DLLs will be properly whitelisted and more developers will submit their software to Microsoft.

 

[ForgottenSeer 98186]

It can take some time until many opensource unsigned DLLs will be properly whitelisted and more developers will submit their software to Microsoft.

This is the real issue with SAC.

It will be interesting to see how SAC behaves 1 year from now.