Hot Take Applocker on Windows Home.

[wat0114]

I am not sure. You are using OSArmor which can possibly be tweaked to do similar things.

Okay, it's just that this news is rather exciting for me, so I have this irresistible urge to try out AppLocker again since not having it used it since my Windows 7 Ultimate days It's always been my all time favourite built-in Windows security feature

 

[Andy Ful]

It seems that the HomeAppLocker policies can block processes that require standard and administrative rights, but do not block processes with system privileges. So, it is possible to block PowerShell also for Administrators and still manage HomeAppLocker with PowerShell.
I updated one of my previous posts (removed the warning related to blocking PowerShell).

 

[Andy Ful]

I successfully managed to create the script that allows viewing the current policies:

$namespaceName = "root\cimv2\mdm\dmmap" #Do not change this
$GroupName = "AppLocker001" #Your own groupName
$parentID = "./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/$GroupName"

$className = "MDM_AppLocker_ApplicationLaunchRestrictions01_EXE03" #Do not change this
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID=`'$parentID`' and InstanceID='EXE'"
Get-CimInstance -CimInstance $obj

$className = "MDM_AppLocker_MSI03" #Do not change this
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID=`'$parentID`' and InstanceID='MSI'"
Get-CimInstance -CimInstance $obj

$className = "MDM_AppLocker_DLL03" #Do not change this
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID=`'$parentID`' and InstanceID='DLL'"
Get-CimInstance -CimInstance $obj

$className = "MDM_AppLocker_Script03" #Do not change this
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID=`'$parentID`' and InstanceID='Script'"
Get-CimInstance -CimInstance $obj

$className = "MDM_AppLocker_ApplicationLaunchRestrictions01_StoreApps03"
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID=`'$parentID`' and InstanceID='Storeapps'"
Get-CimInstance -CimInstance $obj

 

[Andy Ful]

Good news.
It is possible to get most of AaronLocker to create the XML policy file on Windows 10 Home. One must copy some folders from Windows Pro - they are absent on Windows Home:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.Security.ApplicationId.*
C:\Windows\security\ApplicationId
c:\Windows\System32\WindowsPowerShell\v1.0\Modules\Applocker

The result is the same as for Windows 10 Pro except for Deny rules for LOLBins. But these rules are well known and can be easily added (if necessary).
https://github.com/microsoft/AaronLocker

Edit
To avoid errors related to WDAC, it is necessary to change the default parameter in the script Create-Policies.ps1:
$AppLockerOrWDAC = "Both" ------> $AppLockerOrWDAC = "Applocker"

Post edited.

 

[ForgottenSeer 97327]

@Andy Ful two questions

1. Why do you use filepath *.* with MSI and filepath * with scripts?
2. Will your suggested workaround also work when copying the folders from Windows10 Pro to Windows11 Home?


Thanks for all the information and help I did not know about Aaronlocker, downloaded the Word file and reading it now.

I am playing with an idea at the moment which aims to implement SWH-like hardening for basic users with two levels of hardening

1. Creating SWH-like AppLocker policies for
A) Basic user blocking scripts in user space and blocking Microsoft Recommended (and all old obsolete scriptors like CMD, Wscript and Cscript)
B) Admin also allowing signed scripts

2. Creating crossover of SWH and H_C like AppLocker policies for
A) Basic user blocking in user space all scripts and unsigned programs in user space and blocking Microsoft Recommended (and all old obsolete scriptors like CMD, Wscript and Cscript)
B) Admin blocking in user space all, except (allowing) signed scripts, signed programs and signed DLL''s
C) Blocking execution of user writeable folders in Windows for everyone

From what I remember AppLocker differentiating Admin and Basic user rules, one needs to run as Basic User to apply them, but with UAC on default, blocking unsigned to elevate, I think this would be together with ConfigureDefender on Max a solid security setup for the average user. My wife's laptop came with Windows11, so all essential stuff is (Windows) signed.

 

[Andy Ful]

@Andy Ful two questions

1. Why do you use filepath *.* with MSI and filepath * with scripts?

By an accident. The recommended is "*". If I correctly recall there is no functional difference.

2. Will your suggested workaround also work when copying the folders from Windows10 Pro to Windows11 Home?

I do not know - it is probably better to copy folders from Windows 11 Pro.

I am playing with an idea at the moment which aims to implement SWH-like hardening for basic users with two levels of hardening

It is better to avoid the term "basic users". It is related to the classic SRP and does not have an equivalent in AppLocker. What do you mean by hardening "basic user"? Is it hardening on SUA or hardening any account to block unelevated processes?

1. Creating SWH-like AppLocker policies for
A) Basic user blocking scripts in user space and blocking Microsoft Recommended (and all old obsolete scriptors like CMD, Wscript and Cscript)
B) Admin also allowing signed scripts

Technically, the above protection is very different from SWH settings. For example, SWH settings can prevent many attacks with EXE or DLL executables (introduced as secondary payloads). Anyway, one can probably apply a comparable security level on a home computer, by blocking popular LOLBins, including powershell.exe and powershell_ise.exe. Blocking cscript.exe and wscript.exe is not necessary - these LOLBins cannot be run with Applocker Script protection. Still, the above Applocker settings can be easily bypassed by shortcuts using rundll32.exe (to run DLLs) and some other LOLBins which cannot be safely blocked.

2. Creating crossover of SWH and H_C like AppLocker policies for
A) Basic user blocking in user space all scripts and unsigned programs in user space and blocking Microsoft Recommended (and all old obsolete scriptors like CMD, Wscript and Cscript)
B) Admin blocking in user space all, except (allowing) signed scripts, signed programs and signed DLL''s
C) Blocking execution of user writeable folders in Windows for everyone

I am not sure. Are the unsigned DLLs blocked for Everyone? If so, then OK.

From what I remember AppLocker differentiating Admin and Basic user rules, one needs to run as Basic User to apply them, ...

Applocker uses the default rule "Allow for Administrators", for example:
<FilePathRule Id="64ad46ff-0d71-4fa0-a30b-3f3d30c5433d" Name="Allow for Administrators" Description="" UserOrGroupSid="S-1-5-32-544" Action="Allow">
<Conditions>
<FilePathCondition Path="*" />
</Conditions>
</FilePathRule>

This rule works on SUA in the same way for EXE, DLLs, MSI, and Scripts. But on the default Admin account, it works so, only for MSI, and Scripts. The EXE and DLL files will be allowed on any Administrator account including the default Admin account. The MSI files and Scripts will be still blocked on the default Admin account with the same rule (with a different GUID). That is why I removed this default rule from my scripts in the sections for EXE and DLL.

 

[ForgottenSeer 97327]

@Andy Ful

Thanks for the feedback. As you can see in my post, I am famliar with WDAC and SRP because I am on Windows10Pro. It seems that AppLocker does not work as I had expected. DO I understand you correctly, when the conclusion is that only the cross-over of H_C and SWH makes sense to add?

I need some further studying. Thanks for the feedback, it helps me to understand it better

 

[wat0114]

These Applocker scripts and policies being posted in this thread are so complicated and intimidating to follow

@Andy Ful, is there a tool you might be able to develop that would make applying Applocker rules and policies an easy, "no fuss no muss" process for anyone wanting to use them, similar to your excellent tools SWH, CF and H_C available now?

 

[Andy Ful]

@Andy Ful
DO I understand you correctly, when the conclusion is that only the cross-over of H_C and SWH makes sense to add?

Any Applocker hardening adds some important protection. But nowadays, the malware often uses CmdLine access to run DLLs. Unfortunately, the AVs (including Microsoft Defender with ASR rules) usually do not provide the same protection level for DLLs as for EXE files. So malicious DLLs can be a problem. One can use additional protection by:

1. Efficiently restricting CmdLine access (like H_C or SWH, without blocking DLLs).
2. Efficiently blocking DLLs in UserSpace.

WDAC and Applocker cannot protect several methods that allow CmdLine access (shortcuts and many file types with active content), so the recommended setup should rely on point 2.
One good example is allowing only signed DLLs in userSpace when using Applocker (not possible in WDAC). This can protect home users against many attacks (via unprotected file types) that end with running a DLL or DLL hijacking.

 

[Andy Ful]

These Applocker scripts and policies being posted in this thread are so complicated and intimidating to follow

@Andy Ful, is there a tool you might be able to develop that would make applying Applocker rules and policies an easy, "no fuss no muss" process for anyone wanting to use them, similar to your excellent tools SWH, CF and H_C available now?

Using Aaron Locker is not more complicated than using OSA, because one has to run only one script (Create-Policies.ps1). The problem is of another kind - the AaronLocker policies can be useful at home mostly with a semi-static setup.

I am not convinced that creating a dedicated application for HomeAppLocker (like H_C or SWH) is worth my time, because of the possible development of Smart App Control. But I do not exclude such a possibility in the future. For now, I am thinking about a simple loader that could work as follows:

1. All needed files are copied into the folder Windows\HomeApplocker.
2. The 3rd party explorer is executed with system privileges.
3. The PowerShell execution policy is temporarily changed to Remotely signed (and set to the previous setting after closing the loader).
4. The content of Windows\HomeApplocker is displayed in the file explorer.

Now the user can use the file explorer right-click context menu and choose "Run with PowerShell" to create/display/delete policies. So, using HomeApplocker can be very easy.

 

[wat0114]

U For now, I am thinking about a simple loader that could work as follows:

1. All needed files are copied into ......

Well that doesn't seem too painful to follow

 

[ForgottenSeer 97327]

Any Applocker hardening adds some important protection. But nowadays, the malware often uses CmdLine access to run DLLs. Unfortunately, the AVs (including Microsoft Defender with ASR rules) usually do not provide the same protection level for DLLs as for EXE files. So malicious DLLs can be a problem. One can use additional protection by:

1. Efficiently restricting CmdLine access (like H_C or SWH, without blocking DLLs).
2. Efficiently blocking DLLs in UserSpace.

WDAC and Applocker cannot protect several methods that allow CmdLine access (shortcuts and many file types with active content), so the recommended setup should rely on point 2.
One good example is allowing only signed DLLs in userSpace when using Applocker (not possible in WDAC). This can protect home users against many attacks (via unprotected file types) that end with running a DLL or DLL hijacking.

Now you are confusing me (assuming Andy-san is right and I am making wrong rookie assumptions )

1. This is the reason I am looking at AppLocker: Blockrules for sponsors with an allow rule for Admins (to allow updates and legitemate use of scriptors).

2. WDAC with SmartAppControl policy (link) and path allow rules for Windows and Program Files should do the trick.

So by combining AppLocker and WDAC I had hoped to achieve both, but you made me start doubting now

 

[Andy Ful]

Now you are confusing me (assuming Andy-san is right and I am making wrong rookie assumptions )

1. This is the reason I am looking at AppLocker: Blockrules for sponsors with an allow rule for Admins (to allow updates and legitemate use of scriptors).

Yes, it is possible on SUA.
Not possible on Admin account (for EXE and DLL) - only possible for Scripts and MSI files.
On Admin, the block rules for LOLBins will work only if you remove the "Allow Admin" rule in EXE section.

2. WDAC with SmartAppControl policy (link) and path allow rules for Windows and Program Files should do the trick.

I tested SmartAppControl WDAC policy a few weeks ago. It did not block LNK files and disk images. WDAC with SmartAppControl policy worked differently from SAC. You can test it by yourself, maybe now Microsoft managed to do it.

So by combining AppLocker and WDAC I had hoped to achieve both, but you made me start doubting now

That was my intention. Anyway, you have enough skills to check it. Things are changing, so my experience can be sometimes outdated.

 

[eonline]

Could you create an applocker management application with the possibility of whitelisting? Or this is technically impossible. Thank you very much.

 

[Andy Ful]

Could you create an applocker management application with the possibility of whitelisting? Or this is technically impossible. Thank you very much.

It is possible. But, whitelisting in the Applocker settings is not my favorite idea. I accepted whitelisting in the properly configured SRP (like H_C or SWH), but Applocker is a different problem. We will see.

 

[eonline]

I know it will be difficult but if you create another application to handle applocker restrictions a lot of users would be grateful and I think that is priceless. Thank you very much as always. Best regards.

 

[ForgottenSeer 97327]

Yes, it is possible on SUA.
Not possible on Admin account (for EXE and DLL) - only possible for Scripts and MSI files.
On Admin, the block rules for LOLBins will work only if you remove the "Allow Admin" rule in EXE section.

When running Standard User (SUA), I don't want sponsors blocked on Admin account. The border between SUA and ADMIN is considered by specialists as a security protection (UAC is not according to Microsoft). For average users (like me and my wife) there is no reason running ADMIN.

Your info has changed my initial idea. When my wife's laptop updates to Windows11H2, I will use the SmartAppControl policy as a starting point, with path allow rules for UAC protected folders and enabling the option to exclude DLL's and dotNet protection. Next I will adopt your powershell scripts for AppLocker blocking sponsors and unsigned DLL's for SUA with exe ALLOW for admin and an exception for the folder containing PhotoBook Application in regard to signed DLL's.

To deal with the unsigned DLL-folder hole, I will remove access write permissions for that folder except for Admin (that folder will also be protected by Controlled Folder Access). As mentioned earlier adding Code Integrity Guard to all Microsoft user programs (and Windows processes running as SUA) and Denying non Micorosft programs to launch other programs (also with MD Exploit Protection) AND blocking sponsors for SUA only (iclucing RunDLL32 etcera) will provide sufficient protection against staged DLL-injection attacks (I also use your Configure Defender at MAX on my wife's laptop).

Thanks for all your feedback and efforts to bring AppLocker to Home users.

 

[Andy Ful]

When my wife's laptop updates to Windows11H2, I will use the SmartAppControl policy as a starting point, with path allow rules for UAC protected folders and enabling the option to exclude DLL's and dotNet protection. Next I will adopt your powershell scripts for AppLocker blocking sponsors and unsigned DLL's for SUA with exe ALLOW for admin and an exception for the folder containing PhotoBook Application in regard to signed DLL's.

I wonder how this idea will work in practice. It would be interesting to share your experience after implementing this setup on the computer.

To deal with the unsigned DLL-folder hole, I will remove access write permissions for that folder except for Admin (that folder will also be protected by Controlled Folder Access).

This must be thoroughly tested, because there can be a reason that developer added write permissions for that folder. Some application functionality can be dysfunctional.

Generally, I like your setup and wish you to apply it successfully.

 

[Andy Ful]

Updated ApplockerHome policy file.

Added some block rules for LOLBins and Windows writable folders. The policy includes:
cipher.exe, hh.exe, installutil.exe, jsc.exe, microsoft.workflow.compiler.exe, msbuild.exe, mshta.exe, powershell.exe, powershell_ise.exe, presentationhost.exe, regsvcs.exe, runas.exe, wmic.exe.
The LOLBins are blocked by a publisher rule, so they cannot be executed after copying to another location or changing the file name.

Three LOLBins are configured to be allowed (hh.exe, powershell.exe, powershell_ise.exe) due to a trick. I intentionally put the fake publisher name (for example HomeApplocker:HH.EXE). The LOLBin (like hh.exe) is going to be blocked after replacing the fake publisher name with an asterisk, for example:
HomeApplocker:HH.EXE -----> *

Blocked execution (for EXE, DLL, Script) in Windows folders:
%WINDIR%\debug\wia
%WINDIR%\registration\crmlog
%SYSTEM32%\com\dmp
%SYSTEM32%\config\systemprofile\appdata\local\packages\wdagrdpclientappcontainer\ac\
%SYSTEM32%\drivers\driverdata
%SYSTEM32%\fxstmp
%SYSTEM32%\microsoft\crypto\rsa\machinekeys
%SYSTEM32%\spool\drivers\color
%SYSTEM32%\spool\printers
%SYSTEM32%\spool\servers
%SYSTEM32%\tasks
%SYSTEM32%\tasks_migrated
%WINDIR%\tasks
%WINDIR%\temp
%WINDIR%\tracing

The policy code:

<#
.SYNOPSIS
    This function creates new AppLocker settings using MDM WMI Bridge.
    All previous rules will be deleted.
    ** EXE and DLL rules block also Administrators. Allow rules:
    Allow all files in the Program Files folder
    Allow all files in the Windows folder (with some exceptions)
    Allow all signed
    Block some LOLBins
    ** MSI rules do not block Administrators. Allow rules:
    All files in the folder %systemdrive%\Windows\Installer
    Allow all signed
    ** Script rules do not block Administrators. Allow rules:
    Allow all files in the Program Files folder
    Allow all files in the Windows folder (with some exceptions)
    ** StoreApps rule blocks also Administrators. Allow rule:
    Allow all signed
  

.CREDITS
    These scripts are based on the script for EXE files made by Sandy Zeng (Sandy Tsang).
    https://github.com/sandytsang/MSIntune/tree/master/Intune-PowerShell/AppLocker
#>

$namespaceName = "root\cimv2\mdm\dmmap" #Do not change this
$GroupName = "AppLocker001" #Your own groupName
$parentID = "./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/$GroupName"

$classNameDLL = "MDM_AppLocker_DLL03" #Do not change this
Get-CimInstance -Namespace $namespaceName -ClassName $classNameDLL -Filter "ParentID=`'$parentID`' and InstanceID='DLL'"  | Remove-CimInstance

$classNameEXE = "MDM_AppLocker_ApplicationLaunchRestrictions01_EXE03" #Do not change this
Get-CimInstance -Namespace $namespaceName -ClassName $classNameEXE -Filter "ParentID=`'$parentID`' and InstanceID='EXE'"  | Remove-CimInstance

$classNameMSI = "MDM_AppLocker_MSI03" #Do not change this
Get-CimInstance -Namespace $namespaceName -ClassName $classNameMSI -Filter "ParentID=`'$parentID`' and InstanceID='MSI'"  | Remove-CimInstance

$classNameScript = "MDM_AppLocker_Script03" #Do not change this
Get-CimInstance -Namespace $namespaceName -ClassName $classNameScript -Filter "ParentID=`'$parentID`' and InstanceID='Script'"  | Remove-CimInstance

$classNameStoreApps = "MDM_AppLocker_ApplicationLaunchRestrictions01_StoreApps03"
Get-CimInstance -Namespace $namespaceName -ClassName $classNameStoreApps -Filter "ParentID=`'$parentID`' and InstanceID='Storeapps'"  | Remove-CimInstance

Add-Type -AssemblyName System.Web

#This is example Rule Collection for EXE
$obj = [System.Net.WebUtility]::HtmlEncode(@"
  <RuleCollection Type="Exe" EnforcementMode="Enabled">
    <FilePathRule Id="dcff703a-6dbd-48f5-8ce3-94f8228b6ac4" Name="Wszystkie pliki znajdujące się w folderze Windows" Description="Umożliwia członkom grupy Wszyscy wykonywanie aplikacji znajdujących się w folderze Windows." UserOrGroupSid="S-1-1-0" Action="Allow">
     <Conditions>
       <FilePathCondition Path="%WINDIR%\*"/>
     </Conditions>
     <Exceptions>
        <FilePathCondition Path="%WINDIR%\debug\wia\*" />
        <FilePathCondition Path="%WINDIR%\registration\crmlog\*" />
        <FilePathCondition Path="%SYSTEM32%\com\dmp\*" />
        <FilePathCondition Path="%SYSTEM32%\config\systemprofile\appdata\local\packages\wdagrdpclientappcontainer\ac\*" />
        <FilePathCondition Path="%SYSTEM32%\drivers\driverdata\*" />
        <FilePathCondition Path="%SYSTEM32%\fxstmp\*" />
        <FilePathCondition Path="%SYSTEM32%\microsoft\crypto\rsa\machinekeys\*" />
        <FilePathCondition Path="%SYSTEM32%\spool\drivers\color\*" />
        <FilePathCondition Path="%SYSTEM32%\spool\printers\*" />
        <FilePathCondition Path="%SYSTEM32%\spool\servers\*" />
        <FilePathCondition Path="%SYSTEM32%\tasks\*" />
        <FilePathCondition Path="%SYSTEM32%\tasks_migrated\*" />
        <FilePathCondition Path="%WINDIR%\tasks\*" />
        <FilePathCondition Path="%WINDIR%\temp\*" />
        <FilePathCondition Path="%WINDIR%\tracing\*" />
     </Exceptions>
   </FilePathRule>
   <FilePathRule Id="921cc481-6e17-4653-8f75-050b80acca20" Name="Allow files in the Program Files folder" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%PROGRAMFILES%\*" />
      </Conditions>
   </FilePathRule>
    <FilePublisherRule Id="9ab086ea-40a8-4b05-875b-f9fdf9962ba8" Name="Allow signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a96000" Name="POWERSHELL.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="HomeApplocker:POWERSHELL.EXE" BinaryName="POWERSHELL.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a96001" Name="POWERSHELL_ISE.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="HomeApplocker:POWERSHELL_ISE.EXE" BinaryName="POWERSHELL_ISE.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a96003" Name="RUNAS.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="RUNAS.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a96004" Name="CIPHER.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CIPHER.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a96005" Name="MSBUILD.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MSBUILD.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a96006" Name="InstallUtil.exe" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="InstallUtil.exe">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a96007" Name="REGSVCS.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="REGSVCS.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a96008" Name="WMIC.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="WMIC.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a96009" Name="PRESENTATIONHOST.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="PRESENTATIONHOST.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a9600a" Name="JSC.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="JSC.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a9600b" Name="MSHTA.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MSHTA.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a9600c" Name="MICROSOFT.WORKFLOW.COMPILER.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.WORKFLOW.COMPILER.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="f493e22c-63a9-4811-ab94-c5d8a8a9600d" Name="HH.EXE" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="HomeApplocker:HH.EXE" BinaryName="HH.EXE">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>

  </RuleCollection>
"@)
New-CimInstance -Namespace $namespaceName -ClassName $classNameEXE -Property @{ParentID=$parentID;InstanceID="EXE";Policy=$obj}


#This is example Rule Collection for MSI
$obj = [System.Net.WebUtility]::HtmlEncode(@"
  <RuleCollection Type="Msi" EnforcementMode="Enabled">
    <FilePublisherRule Id="b7af7102-efde-4369-8a89-7a6a392d1473" Name="Allow all signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*">
          <BinaryVersionRange LowSection="0.0.0.0" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePathRule Id="5b290184-345a-4453-b184-45305f6d9a54" Name="Allow files in the folder %systemdrive%\Windows\Installer." Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%WINDIR%\Installer\*" />
      </Conditions>
    </FilePathRule>
    <FilePathRule Id="64ad46ff-0d71-4fa0-a30b-3f3d30c5433d" Name="Allow for Administrators" Description="" UserOrGroupSid="S-1-5-32-544" Action="Allow">
      <Conditions>
        <FilePathCondition Path="*" />
      </Conditions>
    </FilePathRule>
  </RuleCollection>
"@)
New-CimInstance -Namespace $namespaceName -ClassName $classNameMSI -Property @{ParentID=$parentID;InstanceID="MSI";Policy=$obj}


$obj = [System.Net.WebUtility]::HtmlEncode(@"
  <RuleCollection Type="Script" EnforcementMode="Enabled">
    <FilePathRule Id="06dce67b-934c-454f-a263-2515c8796a5d" Name="Allow scripts in Program Files folder" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%PROGRAMFILES%\*" />
      </Conditions>
    </FilePathRule>
    <FilePathRule Id="9428c672-5fc3-47f4-808a-a0011f36dd2c" Name="Allow scripts in Windows folder" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%WINDIR%\*" />
      </Conditions>
     <Exceptions>
        <FilePathCondition Path="%WINDIR%\debug\wia\*" />
        <FilePathCondition Path="%WINDIR%\registration\crmlog\*" />
        <FilePathCondition Path="%SYSTEM32%\com\dmp\*" />
        <FilePathCondition Path="%SYSTEM32%\config\systemprofile\appdata\local\packages\wdagrdpclientappcontainer\ac\*" />
        <FilePathCondition Path="%SYSTEM32%\drivers\driverdata\*" />
        <FilePathCondition Path="%SYSTEM32%\fxstmp\*" />
        <FilePathCondition Path="%SYSTEM32%\microsoft\crypto\rsa\machinekeys\*" />
        <FilePathCondition Path="%SYSTEM32%\spool\drivers\color\*" />
        <FilePathCondition Path="%SYSTEM32%\spool\printers\*" />
        <FilePathCondition Path="%SYSTEM32%\spool\servers\*" />
        <FilePathCondition Path="%SYSTEM32%\tasks\*" />
        <FilePathCondition Path="%SYSTEM32%\tasks_migrated\*" />
        <FilePathCondition Path="%WINDIR%\tasks\*" />
        <FilePathCondition Path="%WINDIR%\temp\*" />
        <FilePathCondition Path="%WINDIR%\tracing\*" />
     </Exceptions>
    </FilePathRule>
    <FilePathRule Id="ed97d0cb-15ff-430f-b82c-8d7832957725" Name="Allow for Administrators" Description="" UserOrGroupSid="S-1-5-32-544" Action="Allow">
      <Conditions>
        <FilePathCondition Path="*" />
      </Conditions>
    </FilePathRule>
  </RuleCollection>
"@)
New-CimInstance -Namespace $namespaceName -ClassName $classNameScript -Property @{ParentID=$parentID;InstanceID="Script";Policy=$obj}


$obj = [System.Net.WebUtility]::HtmlEncode(@"
  <RuleCollection Type="Dll" EnforcementMode="Enabled">
    <FilePathRule Id="bac4b0bf-6f1b-40e8-8627-8545fa89c8b6" Name="Allow DLLs in Windows folder" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%WINDIR%\*" />
      </Conditions>
     <Exceptions>
        <FilePathCondition Path="%WINDIR%\debug\wia\*" />
        <FilePathCondition Path="%WINDIR%\registration\crmlog\*" />
        <FilePathCondition Path="%SYSTEM32%\com\dmp\*" />
        <FilePathCondition Path="%SYSTEM32%\config\systemprofile\appdata\local\packages\wdagrdpclientappcontainer\ac\*" />
        <FilePathCondition Path="%SYSTEM32%\drivers\driverdata\*" />
        <FilePathCondition Path="%SYSTEM32%\fxstmp\*" />
        <FilePathCondition Path="%SYSTEM32%\microsoft\crypto\rsa\machinekeys\*" />
        <FilePathCondition Path="%SYSTEM32%\spool\drivers\color\*" />
        <FilePathCondition Path="%SYSTEM32%\spool\printers\*" />
        <FilePathCondition Path="%SYSTEM32%\spool\servers\*" />
        <FilePathCondition Path="%SYSTEM32%\tasks\*" />
        <FilePathCondition Path="%SYSTEM32%\tasks_migrated\*" />
        <FilePathCondition Path="%WINDIR%\tasks\*" />
        <FilePathCondition Path="%WINDIR%\temp\*" />
        <FilePathCondition Path="%WINDIR%\tracing\*" />
     </Exceptions>
    </FilePathRule>
    <FilePathRule Id="3737732c-99b7-41d4-9037-9cddfb0de0d0" Name="Allow DLLs in Program Files folder" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%PROGRAMFILES%\*" />
      </Conditions>
    </FilePathRule>
    <FilePublisherRule Id="1f0d0ec5-8523-4aa0-976a-ad2d2c21eed7" Name="Allow all Signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection>
"@)
New-CimInstance -Namespace $namespaceName -ClassName $classNameDLL -Property @{ParentID=$parentID;InstanceID="DLL";Policy=$obj}


$obj = [System.Net.WebUtility]::HtmlEncode(@"
  <RuleCollection Type="Appx" EnforcementMode="Enabled">
    <FilePublisherRule Id="a9e18c21-ff8f-43cf-b9fc-db40eed693ba" Name="All signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*">
          <BinaryVersionRange LowSection="0.0.0.0" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection>
"@)
New-CimInstance -Namespace $namespaceName -ClassName $classNameStoreApps -Property @{ParentID=$parentID;InstanceID="Storeapps";Policy=$obj}

Warning!!!
I strongly recommend making a System Restore Point before applying the Applocker rules.

 

[ForgottenSeer 97327]

@Andy Ful THANKS really appreciate this, this helps me a lot I called you Andy-san with a smile to express my appreciation of your efforts to bring really complex and advanced security features to the average skilled home users.

I remembered when I applied the 2019 hardening guidelines that there is also a registry setting somewhere that you can limit (block) which programs hh.exe is allowed to start. Blocking hh.exe to start other sponsors should minimize the options to misuse hh.exe as lolbin (or is that a wrong assumption?). Could this also be achieved by adding MD Exploit protection for hh.exe (e.g; only allow signed Microsoft DLL's and Block starting other programs).