New Update Testing Windows Hybrid Hardening (new hardening application).

[ForgottenSeer 97327]

If you will send me the links to the tested installers, I can test them against my ISG policy.

That was some time ago I tested two backup (Macrium and Aomei), SyncBackFree, three cleaners (Auslogic, Wise and CCleaner) Hwinfo and another system info tool and the benchmark program used on MT in which members can compare the power of their computer, and three secundary scanners (norton, sophos and malware bytes)

I installed Avast and repeated the same test. It looks like Avast uses ISG API because the results were the same as with MS Defender (Cloud-delivered protection enabled). Installation of Avast did not stop the services required by ISG. I did not test other AVs.
After uninstalling Avast I noticed that the services required by ISG has been stopped.

Edit.
The ISG tests require using a Virtual Machine. Each test must be done on the fresh snapshot. This is required because when the file has been successfully executed in one test, the result is stored in the system and the file will be allowed also in another test (even if it would be normally blocked).

Ahh sorry yes I am using Avast Free with hardened mode, because then you have two cloud whitelist protections (ISG and Avast cloud).

This is the reason we got different results. Thanks very much solving this mystery.

Does this discovery slightly opens the door to an extra ISG option in your Hybrid Windows Hardening
(the current implementation with only an extra option to enable ISG when WDAC is chosen)?

 

[Andy Ful]

That was some time ago I tested two backup (Macrium and Aomei), SyncBackFree, three cleaners (Auslogic, Wise and CCleaner) Hwinfo and another system info tool and the benchmark program used on MT in which members can compare the power of their computer, and three secundary scanners (norton, sophos and malware bytes)

• Macrium Reflect Home - the downloader ReflectDLHT.exe is allowed by ISG even without MOTW. This downloader downloads and executes the offline installer v8.1.7638_reflect_home_setup_x64.exe which is blocked by ISG if the MOTW is removed.
• AOMEI Backuper - the installer AOMEIBackupperStd_20230920.6986790.exe is blocked by ISG if the MOTW is removed.
• SyncBack free - the installer SyncBack_Setup.exe is blocked by ISG if the MOTW is removed.
• Auslogics Registry Cleaner - the installer auslogics-registry-cleaner-setup.exe is allowed by ISG even without MOTW.
• Wise Care 365 - the installer WiseCare365_6.6.1.631.exe is blocked by ISG if the MOTW is removed.
• CCleaner - the installer ccsetup616.exe is blocked by ISG if the MOTW is removed.
• HWiNFO - the installer hwi_762.exe is allowed by ISG even without MOTW.

The tested installers are the newest versions.

I think that your test was done before I suggested removing the MOTW from installers (to simulate auto-update). If the MOTW is not removed after downloading then the installers mentioned above are allowed by ISG, because all of them are accepted by SmartScreen. Next, the system remembers the file paths of the allowed files and allows them even when they do not have MOTW. If the files are copied to another location, they are checked again, but now it does not have MOTW, so can be blocked.
You can have the same file in two different (non-whitelisted) locations. One can be allowed by ISG and the second can be blocked.
This works well when the user downloads and installs manually applications. But does not work well when the installed application auto-updates, because the auto-updates downloads the installer without MOTW into the user Temp folder and executes it from this location.

Post edited.

 

[Andy Ful]

Does this discovery slightly opens the door to an extra ISG option in your Hybrid Windows Hardening
(the current implementation with only an extra option to enable ISG when WDAC is chosen)?

I am thinking and testing ....

After our discussion, I did not change much my opinion about ISG, but you helped me to see how well SWH compensates the cons of ISG (nice combo).
I also noticed that the Microsoft improvements of SmartScreen from this year, made SWH + SmartScreen much stronger. Before those improvements, the attackers could easily skirt around SmartScreen to run EXE or MSI files without MOTW, by using archives and disk images. So, the user had to use the RunBySmartscreen tool. Now, it is not so easy and will be even harder when Microsoft implements native support for 7-zip, Gz, and Rar.

 

[Moonhorse]

As non geek user, should i give this a go? Or just stick to configure defehder?

 

[ForgottenSeer 97327]

I am thinking and testing ....

After our discussion, I did not change much my opinion about ISG, but you helped me to see how well SWH compensates the cons of ISG (nice combo).
I also noticed that the Microsoft improvements of SmartScreen from this year, made SWH + SmartScreen much stronger. Before those improvements, the attackers could easily skirt around SmartScreen to run EXE or MSI files without MOTW, by using archives and disk images. So, the user had to use the RunBySmartscreen tool. Now, it is not so easy and will be even harder when Microsoft implements native support for 7-zip, Gz, and Rar.

 

[ForgottenSeer 97327]

As non geek user, should i give this a go? Or just stick to configure defehder?

First try Hard_Configurator in default mode with blocking scripters + enhanced and Configure defender on MAX (and Firewall hardening blocking all LoLbins), you got simular protection as discussed above. When that runs well (wait for a Patch Tuesday update), you could give HybridWindowsHardening a try to lock it completely

 

[Andy Ful]

As non geek user, should i give this a go? Or just stick to configure defehder?

This is a testing phase. As a "non-geek user", you can try it on a Virtual Machine.

 

[ForgottenSeer 97327]

I think that your test was done before I suggested removing the MOTW from installers (to simulate auto-update). If the MOTW is not removed after downloading then the installers mentioned above are allowed by ISG, because all of them are accepted by SmartScreen. Next, the system remembers the file paths of the allowed files and allows them even when they do not have MOTW. If the files are copied to another location, they are checked again, but now it does not have MOTW, so can be blocked.
You can have the same file in two different (non-whitelisted) locations. One can be allowed by ISG and the second can be blocked.
This works well when the user downloads and installs manually applications. But does not work well when the installed application auto-updates, because the auto-updates downloads the installer without MOTW into the user Temp folder and executes it from this location.

Andy,

Thanks for explaining this. Seems we are close to 99,99% understanding and agreement on this topic
I understand your second thoughts on ISG much better now. I have a question.

Which are the ISG services needed to be launched by an AV to enable ISG (what are their names / ID)?

Regards Max

 

[ErzCrz]

Liking the look of WHH, might have a try with it at some point. Weirdly, I find H_C which is bundled with CD and FWH at recommended as a simple set and forget unless there's issues. Anyway, can't wait to try this one out as it develops!

 

[Andy Ful]

Andy,
Which are the ISG services needed to be launched by an AV to enable ISG (what are their names / ID)?

WDAC + ISG requires:

These services can be started by using the command:
appidtel start

Authorize reputable apps with the Intelligent Security Graph (ISG) - Windows Security

Automatically authorize applications that Microsoft’s ISG recognizes as having known good reputation.

learn.microsoft.com

 

[ForgottenSeer 97327]

@Andy Ful

Thanks. Yes that were the services I was hinting at. I had enabled them manually. I had set them to autostart.

Because you posted that Avast enabled them I thought there were more which I did not know of.

According to M$ these services have to be enabled to get ISG, that is why I thought these services can be autostart enabled with any third-party AV.

 

[Andy Ful]

@Andy Ful

Because you posted that Avast enabled them I thought there were more which I did not know of.

I am not sure if Avast enables/disables these services. But, I noticed that after uninstalling Avast, these services were stopped. This happened on Windows 11 with SAC OFF. I did not do comprehensive tests. My post should be considered a warning, that some user actions can accidentally tamper with ISG. This does not decrease security, because not-working ISG = block execution.

 

[Andy Ful]

When experimenting with WHHLight policies, I noticed the possibility of using a "Partial Whitelist".
It means that one can use the setup where UserSpace is blocked by default (Full block), selected locations can be restricted by ISG (Partial Whitelist), and some other locations can be whitelisted (Whitelist).

I mention that because I have never seen such a setup on the web. All known WDAC + ISG setups use ISG to restrict UserSpace by default (ISG block), selected locations can be blocked (BlockList), and some other locations can be whitelisted (Whitelist).
For example, @Max90 uses this well-known setup, which can be written as:
ISG block + Whitelist
WHHLight also uses another well-known setup:
Full block + Whitelist

The new possibility can be written as:
Full block + Partial Whitelist + Whitelist

Edit.
The setup with "Partial Whitelist" requires two slightly different WDAC base policies (one with ISG enabled and the second with ISG disabled) and two supplemental policies.

 

[ForgottenSeer 97327]

When experimenting with WHHLight policies, I noticed the possibility of using a "Partial Whitelist".
It means that one can use the setup where UserSpace is blocked by default (Full block), selected locations can be restricted by ISG (Partial Whitelist), and some other locations can be whitelisted (Whitelist).

I mention that because I have never seen such a setup on the web.

To me above post equals a cliff hanger of a next season of house of cards, turning bad or true detectives .... please release first episode

 

[ForgottenSeer 97327]

@AndyFul

Microsoft says SAC is based on WDAC (link) But SAC does not block (Infdefaultinstall.exe, Microsoft.Build.dll, Microsoft.Build.Framework.dll, Wslhost.dll) for compatibility/ease of use reasons.

Would it be an idea to NOT use the Microsoft recommended blocklist, but in stead create your own recommended blocklist excluding the ones above?

 

[Andy Ful]

@AndyFul

Would it be an idea to NOT use the Microsoft recommended blocklist, but in stead create your own recommended blocklist excluding the ones above?

Of course, it would be possible. But Microsoft did it for a reason, so it would be risky for such an application like WHHLight.
But, it is possible to create a custom WDAC base policy that allows everything (also drivers) except some LOLBins explicitly blocked by Deny rules. This policy will work well with WHHLight, except that it cannot be switched OFF/ON via WHHLight. But, the blocks will be seen in WHHLight.

 

[Andy Ful]

@Max90,

I finished the tests with ISG.
This week I made two 3 final tests.
The first test was done on Windows 10 (updates stopped in June 2023). ISG was vulnerable to DLL hijacking.
The second test was done on Windows 11 (with fresh updates) - ISG blocked DLL hijacking.
In the third test, I updated Windows 10 - ISG blocked DLL hijacking.

So, I can follow your suggestion to replace the current WDAC policy with WDAC + ISG policy.

 

[Andy Ful]

Introducing the new WHHLight policy will require some changes in the help files:

Please let me know if something is unclear or written in poor English.

 

[Andy Ful]

The current WDAC + ISG policy works exceptionally well when the users:

1. Use Windows native applications, Microsoft signed, or Microsoft Store applications.
2. Install new applications with standalone application installers downloaded via web browsers.
3. Choose standard installation locations.

In the above scenario, most users will not see WDAC working. Why?

• The applications from point 1 are allowed by digital certificates.
• The applications from point 2 trigger the SmartScreen check. If SmartScreen accepts the installer or the user chooses to bypass the SmartScreen alert, then the installation is allowed (just like without WDAC).
• The software auto-updates will work without problems due to whitelisted standard installation locations.

The standard installation locations are not writable (with standard rights) or hidden in Explorer, so users will not use those locations to open/run executables.
Finally, if the user is fooled to open something malicious (EXE or MSI file) without a SmartScreen check, then it is still checked by ISG and blocked.

There is one thing that users must respect = SMARTSCREEN.
If the user is a happy clicker, then WHHLight offers the option < SmartScreen Block > = ON.
It will prevent the user from bypassing the SmartScreen alert.

 

[ForgottenSeer 97327]

@Andy Ful

Thank you for all the work, knowledge and testing you put in to WHH.

In Dutch we say "geen glans zonder frictie", meaning you need some friction to really let something shine (possibly also the reason people from other countries say the Dutch are direct and blunt).

You can really be proud on the end result and I hope I have not offended you in our sharp discussions .

Thanks again