New Update Application Control on Windows 10 Home

[ForgottenSeer 85179]

have disabled mine Intel TPM. I'd rather use discrete XTS security chip or none at all!

TPM is a important security feature which you shouldn't disable. You can e.g. protect your Windows Hello or Bitlocker credentials with it
If you don't trust Intel, then switch to AMD.

 

[Andy Ful]

...
@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!

The well known TPM-FAIL vulnerability was patched by Intel, so it should be OK now.
I do not think that it is bulletproof, but it is improbable to encounter the malware in the wild which could exploit TPM (except rare targetted attacks).

 

[plat]

For some, the Trusted Platform Module is sold separately from the mainboard. It's pretty cheap for me: 13 USD or so but it's inconvenient to order, wait and then try to install and provision it. So it was a toss-up whether to bother with it. If/when any exploit of it becomes more visible in the wild, I'll spring for one.

I'd posted questions about the TPM on another forum but got very little info on it from other users. This info is more like it, Andy Ful! Should have posted here instead.

 

[Vasudev]

The well known TPM-FAIL vulnerability was patched by Intel, so it should be OK now.
I do not think that it is bulletproof, but it is improbable to encounter the malware in the wild which could exploit TPM (except rare targetted attacks).

On Linux TPM was causing longer boot times 3-10 minutes on NVMe/SATA SSDs and black screens. Tried updating MEI FW and BIOS to latest available. Earlier, TPM always needed re-keying after rebooting. Disabling it brought me a sense of relief that I won't be stuck at grub2-efi with blank screen w/o backlight.

 

[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."

Windows Defender BabySitter for Windows Home - part 2.
(post updated in October 2021)

I am thinking about changing the BabySitter model of protecting EXE files. In the older version, the protection comes from SmartScreen and from Microsoft ISG (non-system drives). Now I am inclined to use the WD ASR prevalence rule "Block executable files from running unless they meet a prevalence, age, or trusted list criteria", instead. So, EXE files (also COM and SCR) will be globally whitelisted in WDAC and globally protected by this ASR rule.

Here is what the current WD BabySitter can do:

1. The protection schema is based on WD ASR rules and WD Application Control (WDAC). The WD ASR exceptions are independent of WDAC whitelisting.
2. All files accepted by Microsoft ISG are allowed to run. This is true both for WD ASR rules and WDAC restrictions.
3. The EXE, COM, and SCR files on all disks are protected by the WD ASR prevalence rule. These executables are totally whitelisted in WDAC.
4. The binary libraries (DLL, OCX) are restricted by WDAC on the non-system disks except for whitelisted locations. On the system disk, the binary libraries have only standard WD protection. One can apply additional WD ASR rules for additional protection on the system disk.
5. The scripts (Windows Script Host, PowerShell) and MSI files are restricted by WDAC on all disks except for whitelisted locations. files (by hash). One can add some other script restrictions via WD ASR rules.
6. The WDAC restrictions for PowerShell follow from applying the Constrained Language Mode. Similar restrictions are applied for Windows Script Host. So, scripts can be still run but advanced functions are disabled.
7. The restrictions can be turned OFF/ON without logging off the user account.
8. If the user wants to protect the "Desktop, Documents, Downloads, Pictures, Videos" user folders against DLL hijacking, then these folders have to be moved to the non-system disk (right-click >> Properties >> Location >> Move ...).
9. Some protection for BAT, JAR, CHM, ... files can be done in a similar way as in SysHardener (no whitelisting).

Points 4 and 9 can prevent most DLL hijacking methods. From my tests, it follows that ASR rules and SmartScreen do not prevent such attacks (especially via USB drives or archives).
In the current version, the WD BabySitter is a kind of smart-default-deny that uses WD features introduced in Windows 10. I made the AutoIt program which can extend the necessary WDAC configuration features (like whitelisting) to Windows Home. It can create the WDAC policy files identical to those created by PowerShell on Windows Pro. For now, I test it without GUI - the tests will be continued for about one year.

Post edited.
Normally, the ASR prevalence rule for EXE, COM, and SCR files can overlap with WDAC default-deny restrictions. In BabySitter, these files are whitelisted globally in WDAC (by file rule) to avoid overlapping.
Additionally, I use the WDAC path rule to whitelist all Portable Executable files on the system disk, so also DLL and OCX files are allowed on the system disk (but restricted on other disks). This is crucial to avoid problems when installing/updating/uninstalling/running applications.
Still, the installations/updates made via MSI installers are inconvenient (require turning off the script/MSI protection or whitelisting by hash).

 

[eonline]

Hi Andy, I wanted to ask a question, could you develop an application to configure the native protection against Windows exploits?

I found these Microsoft settings on Github, perhaps it will help.

GitHub - microsoft/ExploitProtectionConfiguration: Common configurations for Exploit Protection settings in Windows 10.

Common configurations for Exploit Protection settings in Windows 10. - microsoft/ExploitProtectionConfiguration

github.com

 

[ForgottenSeer 85179]

GitHub - microsoft/ExploitProtectionConfiguration: Common configurations for Exploit Protection settings in Windows 10.

Common configurations for Exploit Protection settings in Windows 10. - microsoft/ExploitProtectionConfiguration

github.com

The project is inactive. Last commit:
on 15 Feb 2018

 

[Andy Ful]

Hi Andy, I wanted to ask a question, could you develop an application to configure the native protection against Windows exploits?

I found these Microsoft settings on Github, perhaps it will help.

GitHub - microsoft/ExploitProtectionConfiguration: Common configurations for Exploit Protection settings in Windows 10.

Common configurations for Exploit Protection settings in Windows 10. - microsoft/ExploitProtectionConfiguration

github.com

I had in mind such a project two years ago, but now I am busy with testing & researching the WD Application Control. Anyway, such a project would require the collective work of many MT members. Some mitigations will not be a problem on several machines and can cause issues on others. Some mitigations may cause problems after the software update.

The project from your link shows mitigations for the below applications:
7z.exe, 7zFM.exe, 7zG.exe, Acrobat.exe, AcroRd32.exe, communicator.exe, EXCEL.EXE, Foxit Reader.exe, googletalk.exe, iexplore.exe, INFOPATH.EXE, iTunes.exe, java.exe, javaw.exe, javaws.exe, LYNC.EXE, mirc.exe, MSACCESS.EXE, MSPUB.EXE, OIS.EXE, OUTLOOK.EXE, Photoshop.exe, pidgin.exe, plugin-container.exe, POWERPNT.EXE, PPTVIEW.EXE, QuickTimePlayer.exe, rar.exe, realconverter.exe, realplay.exe, Safari.exe, SkyDrive.exe, Skype.exe, thunderbird.exe, unrar.exe, VISIO.EXE, vlc.exe, VPREVIEW.EXE, winamp.exe, WindowsLiveWriter.exe, winrar.exe, WINWORD.EXE, winzip32.exe, winzip64.exe, WLXPhotoGallery.exe, wlmail.exe, wmplayer.exe, wordpad.exe.

 

[eonline]

The project is inactive. Last commit:
on 15 Feb 2018

I think that because these are static rules, I don't know if I'm wrong.

 

[ForgottenSeer 85179]

@Andy Ful take a look at microsoft/AaronLocker

 

[Andy Ful]

@Andy Ful take a look at microsoft/AaronLocker

It is a well known PowerShell front-end for AppLocker and WDAC. For AppLocker it will work on Windows Enterprise editions. For WDAC it will work on Windows Pro (at least). I can make a front end for WDAC on Windows Home (somewhat limited), but the current WDAC options are not adjusted for Home users.

 

[ForgottenSeer 85179]

It is a well known PowerShell front-end for AppLocker and WDAC. For AppLocker it will work on Windows Enterprise editions. For WDAC it will work on Windows Pro (at least). I can make a front end for WDAC on Windows Home (somewhat limited), but the current WDAC options are not adjusted for Home users.

In my opinion such isn’t needed for home edition.
I would like to see your front end

 

[Lenny_Fox]

@Andy Ful

Is Windows Defender BabySitter for Windows Home already available to try it out?

/L

 

[Andy Ful]

@Andy Ful

Is Windows Defender BabySitter for Windows Home already available to try it out?

/L

Not soon. It works in a limited way without a GUI for now.

 

[Andy Ful]

From another thread:

Would you please be a bit more clear or detailed in sharing infos?

Which policy files are you talking about? (Are you referring to the raw XML WDAC policy file or after it has been converted to a WDAC policy binary using)?:

ConvertFrom-CIPolicy [-XmlFilePath] <String> [-BinaryFilePath] <String> [<CommonParameters>]
The WDAC policy needs to be converted to a binary file, and that is the operational policy file that is "dropped" into CodeIntegrity per the official WDAC documentation.

Is there a different way using different policy files? (outside the official documentation?) The way you phrase your previous reply, in English it can be taken as meaning there are multiple ways to activate the WDAC policy on an endpoint using a WDAC policy file other than the binary.

There are a few ways to create WDAC policies:

1. Using the example policies (XML) from the folder:
   %Windir%\schemas\CodeIntegrity\ExamplePolicies
   The XML policy examples can be edited manually if one knows what to do.
2. Using PowerShell to change the example policy from point 1 and create a binary policy file.
3. Using tools like WDAC Wizard:
   
   Microsoft WDAC Wizard
   

   GitHub - MicrosoftDocs/WDAC-Toolkit: Documentation and tools to access Windows Defender Application Control (WDAC) technology.

   Documentation and tools to access Windows Defender Application Control (WDAC) technology. - GitHub - MicrosoftDocs/WDAC-Toolkit: Documentation and tools to access Windows Defender Application Cont...

   github.com

One can create a single base policy, multiple base policy, or supplemental policies.

When deploying a single base policy it can work in the directory:
%Windir%\System32\CodeIntegrity\
The binary policy has to be renamed to SIPolicy.p7b

The binary policy can be deployed via GPO. In this case, the file extension is usually .bin or .cip (probably any file name and extension will work too). The location of the binary policy file can be chosen by the user.

When deploying multiple policies or supplemental policies, they are located in the directory:
%Windir%\System32\CodeIntegrity\CiPolicies\Active\
One can use this location also for a single base policy.
The name of the binary policy file must be in the form of a proper GUID with the extension .cip

A few useful resources:
https://techcommunity.microsoft.com...ws-10-application-control-policy/ba-p/2486267
https://learn.microsoft.com/en-us/w...tection/windows-defender-application-control/
https://mattifestation.medium.com/windows-defender-application-control-wdac-resources-9cad7026a943

 

[ForgottenSeer 95367]

From another thread:



There are a few ways to create WDAC policies:

1. Using the example policies (XML) from the folder:
   %Windir%\schemas\CodeIntegrity\ExamplePolicies
   The XML policy examples can be edited manually if one knows what to do.
2. Using PowerShell to change the example policy from point 1 and create a binary policy file.
3. Using tools like WDAC Wizard:
   
   Microsoft WDAC Wizard
   

   GitHub - MicrosoftDocs/WDAC-Toolkit: Documentation and tools to access Windows Defender Application Control (WDAC) technology.

   Documentation and tools to access Windows Defender Application Control (WDAC) technology. - GitHub - MicrosoftDocs/WDAC-Toolkit: Documentation and tools to access Windows Defender Application Cont...

   github.com

One can create a single base policy, multiple base policy, or supplemental policies.

When deploying a single base policy it can work in the directory:
%Windir%\System32\CodeIntegrity\
The binary policy has to be renamed to SIPolicy.p7b

The binary policy can be deployed via GPO. In this case, the file extension is usually .bin or .cip (probably any extension will work too).

When deploying multiple policies or supplemental policies, they are located in the directory:
%Windir%\System32\CodeIntegrity\CiPolicies\Active\
The binary policy is then deployed with the extension .cip
One can use this location also for a single base policy.

A few useful resources:
https://techcommunity.microsoft.com...ws-10-application-control-policy/ba-p/2486267
https://learn.microsoft.com/en-us/w...tection/windows-defender-application-control/
https://mattifestation.medium.com/windows-defender-application-control-wdac-resources-9cad7026a943

Thanks. I was already aware of the documented methods of WDAC.

Reading your prior posts, I thought you discovered new and exciting undocumented WDAC tricks.

 

[Andy Ful]

Thanks. I was already aware of the documented methods of WDAC.

Reading your prior posts, I thought you discovered new and exciting undocumented WDAC tricks.

If so, then I would mention this for sure.

 

[ForgottenSeer 95367]

WDAC can create rules directly from Windows Audit Event.

Public Service Announcement

 

[ForgottenSeer 95367]

A primary problem with WDAC is management of the policy files:

1. Create the policy files
2. Test in Audit Mode
3. Tweak the policy files
4. Repeat Steps 2 and 3 until policy is ready for production
5. Acceptance test for production
6. Back-up the policy files

Steps 1 thru 4 will be tedious, even if you are only managing a single policy file. However, once you have the policies tweaked to where you want them it will be easy enough to deploy.

 

[Andy Ful]

Steps 1 thru 4 will be tedious, even if you are only managing a single policy file. However, once you have the policies tweaked to where you want them it will be easy enough to deploy.

This thread is the experimental one, because I check the possibility of using at home the security layer used in Enterprises. Your comments are probably true for Windows Pro, but not for Windows Home, except for some very special WDAC policies (like BabySitter).
My conclusion is that generally, it would be hard to deploy WDAC at home. Anyway, it is possible in some cases:
https://mattifestation.medium.com/w...20h2-and-building-a-simple-secure-4fd4ee86de4