New Update Application Control on Windows 10 Home

[Andy Ful]

Is it possible to use WD Application Control (WDAC) on Windows 10 Home, with disabled WD? The answer is somewhat surprising. Why?

WDAC is the Windows 10 security feature, which was introduced for Windows Enterprise editions. It can be used only on the computers with UEFI. The working WDAC (WD Application Control) code integrity policy cannot be created on WIndows Home and Windows Pro via registry tweaks or PowerShell, or GPO.
But, WDAC code integrity policy can be applied on any Windows 10 editions, if the user has the file SIPolicy.p7b, that was created on the machine with Windows Enterprise.

So, yes - WDAC can be used on Windows 10 Home and Pro. But, for the standard home user applying it, in the usual way (block applications), would be impractical.

Yet, WDAC can be used as a very practical diagnostic tool, to monitor the execution of processes, which are not whitelisted by WDAC.
The below events are logged in the Windows Event Log :

1. All user-mode code not built-in to the OS or originating from the Microsoft Store.
2. All kernel drivers except Windows, HAL, and ELAM-signed drivers.

The events are logged under Applications and Services Logs >> Microsoft >> Windows >> CodeIntegrity >> Operational, Event Id 3076. It is recommended to make a custom filter only for that event.

Applying it is very easy. Make a binary WDAC policy SIPolicy.p7b and copy it to C:\Windows\System32\CodeIntegrity (admin rights are required), and reboot.
The details are available in Matt Graeber's article:
Threat Detection using Windows Defender Application Control (Device Guard) in Audit Mode

Edit (September 2022).
Currently, the prebuild file SIPolicy.p7b is no longer available. One can use the Microsoft tool on Windows Pro to make the WDAC policy:

Microsoft App Control Wizard

 

[Andy Ful]

The advanced users could (with a little effort) use WDAC for protecting their computers with Windows Home. It would be necessary to make the VM with WIndows Enterprise trial and manage the main system via SIPolicy.p7b, that has been created in the VM. Yet, this could be done in practice only for a really locked system.

 

[Andy Ful]

The below was posted by me on another thread, but I think that it should be also posted here, for the further discussion.

Windows Defender Application Control (WDAC) is very different from HIPS.

"Windows Defender Application Control (WDAC) can help mitigate these types of security threats by restricting the applications that users are allowed to run and the code that runs in the System Core (kernel). WDAC policies also block unsigned scripts and MSIs, and Windows PowerShell runs in Constrained Language Mode."
Windows Defender Application Control (WDAC) (Windows 10)

So, WDAC is rather a kind of Software and Driver policy. It is very strong because it can block also .NET Dlls. I have been playing with it for some time, but it cannot be configured via GPO or PowerShell, or reg tweaks on Windows Home and Pro. WDAC can be deployed on any Windows 10 edition via SIPolicy.p7b file, or on Windows Pro (and higher ed.) via GPO if the user can have access to the custom policy .bin file. Both SIPolicy.p7b and the custom policy .bin file can be made from the .XML policy file when using PowerShell cmdlets on Windows Enterprise ed. On Windows Home and Pro the required cmdlets are not available, you get the error "ConvertFrom-CIPolicy : Device Guard is not available in this edition of Windows."

WDAC can be also optionally managed via Mobile Device Management (MDM), such as Microsoft Intune, but I did not try this.
I installed Windows 10 Enterprise, and then WDAC can be configured via PowerShell cmdlets.
I made the SIPolicy.p7b file that can be copied to C:\Windows\System32\CodeIntegrity, and then WDAC can work on Windows 10 Home and Pro.

In practice, WDAC restrictions can be applied on Windows Home and Pro via SIPolicy.p7b, as a default-allow setup with a blacklist for vulnerable applications (script interpreters, etc.) and DLLs - one can use the Bouncer blacklist for that.

The advanced users can apply WDAC restrictions as default deny setup for drivers and software, but it is not an easy solution, and can be dangerous to system stability on Windows Home.

 

[Andy Ful]

Q&A - What built-in HIPS functionality exists in Windows 10 ?

Very Interesting!!
So once you generated a SIP file on Enterprise, you can use it and manage it on Win10 Home and Pro?
What specifically would a home user want to do with WDAC that he can't already do with H_C?

You can manage it via Mobile Device Management (MDM), such as Microsoft Intune, but Intune requires subscription (not free).
There is no advantage for home users when using WDAC instead of H_C default-deny setup. But, it can be used as the blacklist for Interpreters and Sponsors in default-allow setup. The WDAC can protect against many Sponsors (Interpreters and vulnerable system tools) and is stronger than SysHardener in this area.

Post edited.
WDAG replaced by the correct acronym WDAC.

 

[shmu26]

Q&A - What built-in HIPS functionality exists in Windows 10 ?

You can manage it via Mobile Device Management (MDM), such as Microsoft Intune, but Intune requires subscription (not free).
There is no advantage for home users when using WDAG instead of H_C default-deny setup. But, it can be used as the blacklist for Interpreters and Sponsors in default-allow setup. The WDAG can protect against many Sponsors (Interpreters and vulnerable system tools) and is stronger than SysHardener in this area.

I see. So I guess if you have an Enterprise VM, you could manage it that way, too, although it doesn't sound very convenient. Or you could just convert your Windows 10 Home/Pro to Enterprise with a $5 eBay license, if your conscience allows.

Question about blocking sponsors etc with WDAC: can you set a certain integrity level, or can you go according to User? I mean, can you block process X, but still allow it to be run by SYSTEM?
Another question: can you block process X, but make exceptions for it, according to parent and/or command line?

 

[shmu26]

All in all, it sounds like a pretty inconvenient way to manage a system, unless somebody like Andy Ful creates a tool for it...

 

[Andy Ful]

I see. So I guess if you have an Enterprise VM, you could manage it that way, too, although it doesn't sound very convenient. Or you could just convert your Windows 10 Home/Pro to Enterprise with a $5 eBay license, if your conscience allows.

Question about blocking sponsors etc with WDAC: can you set a certain integrity level, or can you go according to User? I mean, can you block process X, but still allow it to be run by SYSTEM?
Another question: can you block process X, but make exceptions for it, according to parent and/or command line?

It allows a kind of very simple parent checking, but not advanced one as in Excubits Bouncer.
Furthermore, you cannot allow/block anything by path. For example:

    <Deny ID="ID_DENY_D_1_1" FriendlyName="scrobj.dll FileRule" FileName="scrobj.dll" MinimumFileVersion="65535.65535.65535.65535" AppIDs="REGSVR32.EXE" />
    <Deny ID="ID_DENY_WMIC" FriendlyName="wmic.exe" FileName="wmic.exe" MinimumFileVersion="65535.65535.65535.65535"/>

The first rule will block scrobj.dll when loaded by REGSVR32.EXE .
The second will block execution of wmic.exe.
The rules apply to all local users and can recognize the file name from the file properties (hardcoded during compilation). So, if you rename the file a.exe to b.exe then both files will be blocked.

 

[shmu26]

It allows a kind of very simple parent checking, but not advanced one as in Excubits Bouncer.
Furthermore, you cannot allow/block anything by path. For example:

    <Deny ID="ID_DENY_D_1_1" FriendlyName="scrobj.dll FileRule" FileName="scrobj.dll" MinimumFileVersion="65535.65535.65535.65535" AppIDs="REGSVR32.EXE" />
    <Deny ID="ID_DENY_WMIC" FriendlyName="wmic.exe" FileName="wmic.exe" MinimumFileVersion="65535.65535.65535.65535"/>

The first rule will block scrobj.dll when loaded by REGSVR32.EXE .
The second will block execution of wmic.exe.
The rules apply to all local users and can recognize the file name from the file properties (hardcoded during compilation). So, if you rename the file a.exe to b.exe then both files will be blocked.

Fascinating. So this can actually complement H_C in the places where you need more flexibility, for instance, if you have a program that depends on a certain sponsor, you can make an exception for it.

 

[Andy Ful]

Fascinating. So this can actually complement H_C in the places where you need more flexibility, for instance, if you have a program that depends on a certain sponsor, you can make an exception for it.

It could complement H_C, if the user wanted to blacklist some DLLs, especially .NET DLLs.

 

[shmu26]

It could complement H_C, if the user wanted to blacklist some DLLs, especially .NET DLLs.

But you can't make exceptions like I was talking about?

 

[Andy Ful]

But you can't make exceptions like I was talking about?

Not in the usual sense, but you can mix several kinds of allow and deny rules by the file name/hash, publisher, publisher rule combined with a version number, file publisher, and several kinds of certificate types.
As I said, the con of WDAC is the lack of the path rules and no wildcards support.

 

[shmu26]

Not in the usual sense, but you can mix several kinds of allow and deny rules by the file name/hash, publisher, publisher rule combined with a version number, file publisher, and several kinds of certificate types.
As I said, the cons of WDAC are the lack of the path rules and no wildcards support.

Still, it sounds very cool. Forgive my chutzpah and my ignorance, but I would be happy if you could educate us about which dlls are dangerous, and why, and how to block them without borking the system.

 

[Andy Ful]

Still, it sounds very cool. Forgive my chutzpah and my ignorance, but I would be happy if you could educate us about which dlls are dangerous, and why, and how to block them without borking the system.

First, I have to educate myself. It is not so hard, but time consuming. I should read/test the examples from:
api0cradle/LOLBAS

 

[Andy Ful]

I have tried WDAC on Windows 10 Pro ver. 2004. Everything works well.
Now, I can configure the WDAC policies via PowerShell and make the binary file policy.
I did not try it on Windows Home ver. 2004, yet (probably will not work).

 

[Andy Ful]

Windows Defender BabySitter for Windows Home.

It is my little project on joining WD with a simple WDAC policy. WDAC can restrict PE Executables (EXE, SCR, DLL, OCX, etc.) and non-PE files (Windows Script Host and PowerShell, or MSI files).

Here is what WD BabySitter can do:

1. The whole system drive (usually c is whitelisted in WDAC for PE Executables, but all other drives (also flash drives) are restricted by WDAC.
2. WDAC restricts non-PE files on all drives (also on system drive). The restrictions for PowerShell follows from applying the Constrained Language Mode. Similar restrictions are applied for Windows Script Host. So, scripts can be run but advanced functions are disabled.
3. The restrictions for non-PE files can be turned OFF separately from PE Executables.
4. Turning OFF/ON the restrictions for PE Executables and non-PE files do not require to log off the account.
5. If the user wants to protect the "Desktop, Documents, Pictures, Videos" user folders, then these folders have to be moved to a non-system drive (right-click >> Properties >> Location >> Move ...).
6. It is possible to whitelist PE Executables in the predefined folders (Games, Programs), but the user cannot whitelist anything by himself.
7. All files (also non-PE files) accepted by Microsoft ISG are allowed to run (requires WD).
8. If the Portable Executable is not accepted by ISG but has been checked by SmartScreen Application Reputation, then it is allowed to run. One can use RunBySmartScreen for files without MOTW. This does not work for non-PE files.
9. Some protection for BAT, JAR, CHM, ... files can be done in the similar way as in SysHardener (no whitelisting).
10. It is probably also possible to block some LOLBins (via WDAC or Image File Execution Options).

In theory, the Microsoft ISG feature looks good. But in fact, it is very restrictive and different from SmartScreen. All applications have to be installed on system drive or in whitelisted folders (Games or Programs) on other drives. The installations/updates based on the standalone EXE installers can be done safely and without problems (also from the protected folders).
The software installations/updates based on MSI installers can be performed without problems only for very popular applications accepted by ISG, but otherwise, they will require turning OFF temporarily the protection for non-PE files.

Some info about Microsoft ISG:
"The Microsoft Intelligent Security Graph relies on the same vast security intelligence and machine learning analytics which power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having known good, known bad, or unknown reputation. When an unevaluated file is run on a system with WDAC enabled with the Microsoft Intelligent Security Graph authorization option specified, WDAC queries the file's reputation by sending its hash and signing information to the cloud. If the Microsoft Intelligent Security Graph determines that the file has a known good reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file. Every time the file tries to execute, if there are no explicit deny rules present for the file, it will be allowed to run based on its positive reputation. Conversely, a file that has unknown or known bad reputation will still be allowed to run in the presence of a rule that explicitly allows the file.

Additionally, an application installer which is determined to have known good reputation will pass along that positive reputation to any files that it writes. This way, all the files needed to install and run an app are granted positive reputation data."

 

[Andy Ful]

WD BabySitter protection can be extended by adding some hardening features similar to Simple Windows Hardening. The main difference will be unprotected shortcuts so the malware based on shortcuts will be fought by PowerShell or Windows Script Host restrictions - this is slightly weaker than blocking shortcuts. Also, the execution of PE Executables from archives is not blocked in BabySitter (can be blocked by Exploit Protection on Windows 10). On the other side, BabySitter has additional protection for MSI files (all drives) and for PE Executables on non-system drives (including user folders "Desktop, Downloads, etc.").
So, the protection of BabySitter can be comparable to Simple Windows Hardening. The second is probably more customizable due to applying SRP and whitelisting.

 

[ErzCrz]

Your epic @Andy Ful

 

[Andy Ful]

Your epic @Andy Ful

Ha, ha. I know - the post about BabySitter is rather long.

 

[Andy Ful]

Avast companion.

It is another little project on joining Avast with a simple WDAC policy. WDAC is here much simpler because it will protect only non-PE files (Windows Script Host + PowerShell, and MSI files).

Here is what Avast companion can do:

1. WDAC restricts non-PE files on all drives. The restrictions for PowerShell follows from applying the Constrained Language Mode. Similar restrictions are applied for Windows Script Host. So, scripts can be run but advanced functions are disabled.
2. Turning OFF/ON the restrictions do not require to log off the account.
3. Some protection for BAT, JAR, CHM, ... files can be done in a similar way as in SysHardener (no whitelisting).
4. It is probably also possible to block some LOLBins (via WDAC or Image File Execution Options).
5. The EXE files can be protected by Avast Hardened Mode + Cyber Capture.
6. The MSI installations/updates are blocked, but the user can easily switch OFF/ON temporarily the protection to make installations/updates.

Yes, I like this little project. It is similar (slightly weaker but also simpler) to the H_C Avast_Hardened_Mode_Aggressive setting profile.

 

[Vasudev]

I see. So I guess if you have an Enterprise VM, you could manage it that way, too, although it doesn't sound very convenient. Or you could just convert your Windows 10 Home/Pro to Enterprise with a INR 375 eBay license, if your conscience allows.

Question about blocking sponsors etc with WDAC: can you set a certain integrity level, or can you go according to User? I mean, can you block process X, but still allow it to be run by SYSTEM?
Another question: can you block process X, but make exceptions for it, according to parent and/or command line?

My home edition is almost Pro version since I apply regtweaks and gpedit tools during slipstreaming Win 10 ISO and I will be migrating to LSTC/B version.
@Andy Ful Do you think Silicon of Trust is valid these days? I have disabled mine Intel TPM. I'd rather use discrete XTS security chip or none at all!