Serious Discussion WHHLight - simplified application control for Windows Home and Pro.

[Andy Ful]

For example WHHL seems to have *.exe, *.tmp and *.msi hard coded in the Whitelist, and it also doesn’t seem to like at all, if one goes to forcibly remove them .

Not exactly. The default WHHL config enables only SWH settings that force SRP to allow *.exe, *.tmp, and *.msi files. But, those file types can be restricted when enabling WDAC in WHHLight. Without WDAC, they are restricted by SmartScreen.

Also TransparentEnabled seems to be likewise hard coded and monitored in the configuration – obviously as part of monitoring the possibility of “other SRP manipulating Apps”.

SRP restrictions for DLLs are not available, but DLLs can be restricted when enabling WDAC in WHHLight.

@Andy Ful, I have read your tests on how well WHHL tackles various malware, and it indeed seems to perform extremely well. However, I would very much like to have some more flexibility at least in the Whitelist handling (e.g. being able to switch off current “WHHL restrictions” on the Whitelist contents and TransparentEnabled setting).

WHHLight has two different & independent Whitelists. One is for SRP restrictions (scripts, scriptlets, etc.), and the second for WDAC restrictions (*.exe, *.msi, *.dll, *.ocx, etc.). I found it simpler and more convenient in practice. Two different whitelists allow in a simple way applying very tight restrictions for scripting and medium (reputation-based) restrictions for applications. This would be not so easy via SRP whitelisting.

 

[Marana]

What would be the best way to check the current main status of WDAC (i.e. OFF/ON/IAC) from outside the WHHL , e.g. from the registry or from the command line?

 

[Andy Ful]

What would be the best way to check the current main status of WDAC (i.e. OFF/ON/IAC) from outside the WHHL , e.g. from the registry or from the command line?

There is no recommended method to do it outside the WHHLight. Some information can be available by inspecting Event Viewer (Microsoft-Windows-CodeIntegrity/Operational).
If WDAC is enabled in WHHLight then two policy files must be present in the directory "c:\Windows\System32\CodeIntegrity\CIPolicies\Active":
{A5EE6C14-B6AE-488C-8FC1-9CE316CC2461}.cip
{B5A05DC3-0145-4D45-A1D9-81CF9ADC54A3}.cip

 

[Marana]

Thank you for your quick reply, @Andy Ful !

It is quite probable that I will migrate from Windows 10 to Windows 11 during the next few months. You seem to have developed WHHL to such a great tool that I will likely base my Application Control on it for my Windows 11 era.

My current (homemade) Information Security App handles Application Control only by SRP, but it has a Taskbar icon displaying the SRP status in real time, and it also has a configurable timer to turn SRP back on automatically after a desired timeout. And I would like to have the same information easily and reliably available in the future, too.

So, I'm currently studying on how to update the Application Control monitoring feature in my IS App so that it will handle also SmartScreen operating level and WDAC+IAC status in addition to the current SRP monitoring. I will probably also change the current "Reapply SRP automatically after a timeout period" feature to only give reminder messages to reapply the Application Control features after a timeout period. This way WHHL would do all the settings manipulation in the future.

Windows 11 SmartScreen mode ("Warn" / "Block") is easy to lookup from the registry, but I did not find the same information for WDAC and IAC status. So that's why I asked my previous question.

Indeed it seems that the existence of {A5EE6C14-B6AE-488C-8FC1-9CE316CC2461}.cip tells reliably if WDAC is ON or OFF. On the other hand, {B5A05DC3-0145-4D45-A1D9-81CF9ADC54A3}.cip seems to be created when WDAC is activated the first time, and after that it will stay there regardless of the current WDAC status.

The IAC status on the other hand seems to be present in the registry [HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\SmartScreen]: ConfigureAppInstallControl and ConfigureAppInstallControlEnabled.

So, I think that now I have all the pieces I need to update my own IS App to integrate seamlessly with WHHL.

Many thanks to you, Andy!

 

[simmerskool]

@Andy Ful FYI I am running win10_VM today in order to update win10, and GData Internet Security is AV. WHHL 1011 folder is on the desktop. GData gives me popup warning about WHHL.exe. GData only gives 4 options: block, disinfect, quarantine, delete. Warning= Virus Heur.BZC.YAX.Pantera.14.068F748C (Engine A). Not sure when I downloaded WHHL 1011, but it may have been sitting on desktop "untouched" for a couple of months before I tried to activate WHHL today. I do not run this VM very often so I have no relationship with GData.

 

[Andy Ful]

Delete it and download the newest version. It is possible that G-Data can detect it on execution (false positive).

 

[Marana]

I was expecting that WDAC would by default (when switched "ON") block the execution of all .exe and .dll type files in a similar way as the traditional SRP does in user space directories (when configured properly), but that seems not be the case... Does WDAC rely on some kind of ISG reputation and/or other "intelligent" screening methods when deciding on whether to allow or block a program residing in user space?

I'm currently testing WHHL V2.0.0.1 in a fresh Windows 11 IoT Enterprise LTSC 2024 evaluation version installed into a VirtualBox VM. The only way I seem to be able to block execution of a simple homemade "Hello world" program residing in a user writable folder C:\TEST, is to set SmartScreen BlockMode to "ON".

SWH is designed to allow exe files even when set "ON", which I understand. But I was expecting WDAC to block my App running when set to "ON" or "IAC".

So, is there a way to configure WDAC in WHHL into a traditional default deny setup to block my "Hello world" App without SmartScreen BlockMode, or am I missing something obvious here?

 

[Andy Ful]

Does WDAC rely on some kind of ISG reputation and/or other "intelligent" screening methods when deciding on whether to allow or block a program residing in user space?

Yes, WHHLight uses the WDAC ISG reputation. Did you read the WHHLight manual?

SWH is designed to allow exe files even when set "ON", which I understand. But I was expecting WDAC to block my App running when set to "ON" or "IAC".

You have to learn more about WDAC settings in WHHLight.

So, is there a way to configure WDAC in WHHL into a traditional default deny setup to block my "Hello world" App without SmartScreen BlockMode, or am I missing something obvious here?

It is not possible, due to relying on the WDAC ISG reputation. The exception is the SWH setting to block applications in Downloads or Desktop folders. SWH also blocks applications executed from email clients and archiver apps.

 

[Marana]

Yes, WHHLight uses the WDAC ISG reputation. Did you read the WHHLight manual?

In fact, I did! Maybe I’m one of the very few guys out here who really do read the documentation... I have even printed the Manual and made several remarks on the paper. And I have read thru the WHHL help pages, too. All of them. Moreover, I appreciate very much the effort you have put in the documentation.

I think my problem was that I have been living in an old Windows 10 world until recently, when a friend of mine acquired a new laptop and asked me to help him implementing a robust backup system and making his new Windows 11 operating system more secure than Windows defaults. Therefore, I have been completely unaware of WDAC, ISG, IAC and any new security features beyond Windows 10 1809 until very recently.

The WHHL manual states that “When the WDAC ComboBox is ON, the WDAC policies included in WHH-Light are applied. Those policies use Microsoft's Intelligent Security Graph (ISG) to restrict by default the EXE, DLL, and MSI files, except for – –“.

I understood “to restrict by default except for” = “to block if not whitelisted”. Now I know I was wrong.

I also went to do some googling about ISG, but I was not able to make a conclusive decision on what all functionality it might contain (i.e. does ISG only do some reputation based screening or can it also somehow be configured to perform straight blocking). There seems to be much information on current Windows security features online, but it is very scattered around, so I remained unsure of what are all of ISG's capabilities.

So, I first understood that the “WDAC-ISG” part in WHHL implements a default deny style Application Control for e.g. EXE and MSI files (that is missing from the "SWH" part of WHHL). Now I understand that I was wrong. Probably one thing that was driving me to this conclusion was that the SWH part of WHHL is written so that it is technically not possible to restrict e.g. *.exe and *.dll files to obtain an inviolable default deny style policy. I have been running a default deny setup in my computers so many years, that I was subconsciously expecting you to have coded a default deny option available at least in some part of WHHL. Now I understand that I was wrong here, too.

The WHHL source code does not seem to be published in GitHub, so a couple of questions came into my mind...

1) I wonder if it could be possible to add an option in WHHL-SWH to (at least make it somehow possible to) restrict also TMP, MSI, DLL and EXE files for people that prefer a default deny style SRP implementation. Now they are hard coded in the Whitelist, and WHHL does not like them to be removed by other means.

2) I wonder if it would be possible for you to make at least the XML source code files for the WDAC .cip policy files publicly available. (I already tried to reverse engineer them, but some information seems to disappear in the process, if I understand correctly the generated XML file contents). Of course, it would be even better if you could be willing publish the whole WHHL source code into GitHub, just as you have done with the good old HardConfigurator. This way the more security-oriented people would be able to study it and get a deeper understanding on how the various security mechanisms in Windows can be tuned.

 

[Andy Ful]

Moreover, I appreciate very much the effort you have put in the documentation.

Thanks.

1) I wonder if it could be possible to add an option in WHHL-SWH to (at least make it somehow possible to) restrict also TMP, MSI, DLL and EXE files for people that prefer a default deny style SRP implementation.

It would be possible, but this is already possible by using Hard_Configurator (except blocking DLLs).

2) I wonder if it would be possible for you to make at least the XML source code files for the WDAC .cip policy files publicly available. (I already tried to reverse engineer them, but some information seems to disappear in the process, if I understand correctly the generated XML file contents). Of course, it would be even better if you could be willing publish the whole WHHL source code into GitHub, just as you have done with the good old HardConfigurator. This way the more security-oriented people would be able to study it and get a deeper understanding on how the various security mechanisms in Windows can be tuned.

Maybe someday...

 

[Marana]

Regarding 1): Hard_Configurator is not compatible with WHHL that has a user-friendly user interface to WDAC. I was hoping to find a way to be able to operate easily with a default deny SRP policy along with the modern security mechanisms (WDAC, ISG and IAC). And as you mentioned, H_C does not support restricting DLLs either. On the other hand, I seem to represent a very small minority, so I understand your point if you are not willing to implement that. I know from personal experience that it is not possible to make everyone happy...

Regarding 2): In the (hopefully not so long ) mean time, would it be possible to reveal at least, what Microsoft App Control for Business example base policies are the WHHL .cip policy files based on (if any), and what modifications have you implemented in them?

EDIT: One example to explain my interest in default deny style protection: I volunteer in an NGO which handles privacy sensitive information, and a typical use scenario includes days when a laptop is first connected to internet and e.g. new email messages are downloaded. Then later, when network connections are not available, the user may read the earlier downloaded mail messages and open some attachments. Some information may also be transferred to/from the laptop via USB memory sticks when offline. Under these circumstances, cloud-based protections are not available, but the default deny policies do still work well.

 

[Andy Ful]

EDIT: One example to explain my interest in default deny style protection: I volunteer in an NGO which handles privacy sensitive information, and a typical use scenario includes days when a laptop is first connected to internet and e.g. new email messages are downloaded. Then later, when network connections are not available, the user may read the earlier downloaded mail messages and open some attachments. Some information may also be transferred to/from the laptop via USB memory sticks when offline. Under these circumstances, cloud-based protections are not available, but the default deny policies do still work well.

You can use WHHLight. When there is no Internet connection, SWH + WDAC (set to IAC) work as a default-deny for new files (not executed before). In WHHLight, ISG works as a cloud file reputation whitelist. The files executed once with the Internet connection are checked by ISG and usually marked as safe, so this mark works also after disabling the Internet connection.