Hard_Configurator - Windows Hardening Configurator

[ForgottenSeer 85179]

Can I install it on an old version?

Yes

 

[shmu26]

Thanks to Andy.
This is good information that there is a new version.
Excellent work and thanks for maintaining this tool to work.
Can I install it on an old version?

We all installed on top of the old version without any problem.

 

[Gandalf_The_Grey]

And that is written in the announcement from @Andy Ful :

This beta version can be installed over the previous version (5.1.1.2).

 

[Andy Ful]

After installation, the new version does not change the settings from the previous one. The one exception is adding the whitelisting entry for device paths in the Windows\system32 folder (Windows 11 support).

If one uses settings with blocked sponsors, then I can suggest adding manually also finger.exe.
Similarly, in the FirewallHardening the executables csc, jsc, finger, and vbc can be added via the "Recommended H_C" option. Also, all new executables (csc, cvtres, CasPol, finger, ilasm, jsc, Microsoft.Workflow.Compiler, mscorsvw, ngen, ngentask, and vbc) are automatically added when using "LOLBins" option.

People who use Microsoft Office can add SLK file extension via <Designated File Types>. This file extension was already in "Paranoid" extensions. In the new version, It is automatically added to default extensions when applying predefined H_C profiles.

Users who want Defender to be more interactive can apply INTERACTIVE Protection Level in ConfigureDefender. It is worth using the INFO button to read some useful information about Defender (especially ASR rules). Similar information (with several screenshots) can be found in ConfigureDefenderHelp.pdf (in the H_C folder).

 

[Lenny_Fox]

@Andy Ful

Feature request, could you add an "restricted" update mode which only allows update from TMP and TEMP folders (allowing EXE, MSI, TMP)?

Alternatively you could add an option to the "add folder" whitelist to allow all, or only allow exe, msi and tmp in that folder, than I can set it myself by adding my TEMP folder to the whitelist for EXE, MSI and TMP files only

 

[Andy Ful]

@Andy Ful

Feature request, could you add an "restricted" update mode which only allows update from TMP and TEMP folders (allowing EXE, MSI, TMP)?

Alternatively you could add an option to the "add folder" whitelist to allow all, or only allow exe, msi and tmp in that folder, than I can set it myself by adding my TEMP folder to the whitelist for EXE, MSI and TMP files only

Thanks. It is an interesting and promising idea, although it will block applications from UserSpace (more whitelisting required). The applications from Program Files should auto-update without problems.

Anyway, I must think about it for some time. The H_C is already complex and I had to remove from it some good ideas to keep it coherent.

 

[Andy Ful]

Lenny_Fox,
I am not sure if such improvement could have an impact on the protection of Windows 10 machines. It can be probably relevant as a post-exploitation (post-infection) mitigation on Windows 7 machines.

 

[Lenny_Fox]

Lenny_Fox,
I am not sure if such improvement could have an impact on the protection of Windows 10 machines. It can be probably relevant as a post-exploitation (post-infection) mitigation on Windows 7 machines.

I agree for Windows 10 when people have Secure Folders enabled. For my older relatives I disabled Secure Folders because the warnings are to confusing for them. Restricting the "update hole" to only temp folder is a substantial attack surface reduction when secure folders is not enabled.

So please keep this in mind when deciding whether to use your scarce and valuable time for my request.

When you reject the idea I should have a closer look on Windows 10 version where people can only install Windows Store Apps (no desktop apps)

 

[ForgottenSeer 85179]

I don't think that will add any improvements, but increasing complexity.

I agree for Windows 10 when people have Secure Folders enabled. For my older relatives I disabled Secure Folders because the warnings are to confusing for them. Restricting the "update hole" to only temp folder is a substantial attack surface reduction when secure folders is not enabled.

Why not use restricted user account then? Easier and safer

When you reject the idea I should have a closer look on Windows 10 version where people can only install Windows Store Apps (no desktop apps)

Windows S mode is recommend and most secure solution

 

[Lenny_Fox]

1. I don't think that will add any improvements, but increasing complexity.


2. Why not use restricted user account then? Easier and safer


3. Windows S mode is recommend and most secure solution

1. I explained the use case. Just asking for an extra option for update mode (do you know where to find it?)

2. Still leaves user space wide open. So not safer IMO,. With H_C I can copy and load my profile, that is easy enough for me.

3. Yes, that is why I have to look into it. Do you use it?

 

[Andy Ful]

Restricting the "update hole" to only temp folder is a substantial attack surface reduction when secure folders is not enabled.

What do you mean by "secure folders"? If these are folders that can be protected by Controlled Folder Access (CFA), then Update Mode already blocks execution in all folders that can be protected by CFA (like Documents, Pictures, Videos, etc). Normally, you cannot add the AppData subfolders to the folders protected by CFA (except when unhiding the hidden folders in Explorer). The AppData subfolders are not intended to store users' data, but only the user-dependent settings of applications. Normally, these settings are available to users only via installed applications.

The situation is slightly different when the system/software has got popular vulnerabilities and can be exploited. Such a situation is probable on Windows 7 and unsupported Windows versions. That is why in the Recommended_Settings on Windows 7 (Vista), the <Update Mode> = OFF.

I must consider all cons and pros of unblocking only a temporary folder in the User Profile. As I have already said, it can be useful on Windows 7 (or vulnerable machine). The idea of using it is rather for releasing the restrictions on Windows 7 than restricting Update Mode on Windows 10.

 

[Andy Ful]

When you reject the idea I should have a closer look on Windows 10 version where people can only install Windows Store Apps (no desktop apps)

A similar type of protection is possible on any Windows version. One can simply use H_C (SUA + Windows_10_NoElevationSUA). It is also possible to further restrict these Apps by SmartScreen.

 

[Lenny_Fox]

What do you mean by "secure folders"? If these are folders that can be protected by Controlled Folder Access (CFA), then Update Mode already blocks execution in all folders that can be protected by CFA (like Documents, Pictures, Videos, etc). Normally, you cannot add the AppData subfolders to the folders protected by CFA (except when unhiding the hidden folders in Explorer). The AppData subfolders are not intended to store users' data, but only the user-dependent settings of applications. Normally, these settings are available to users only via installed applications.

The situation is slightly different when the system/software has got popular vulnerabilities and can be exploited. Such a situation is probable on Windows 7 and unsupported Windows versions. That is why in the Recommended_Settings on Windows 7 (Vista), the <Update Mode> = OFF.

I must consider all cons and pros of blocking only a temporary folder in the User Profile. As I have already said, it can be useful on Windows 7 (or vulnerable machine). The idea of using it is rather for releasing the restrictions on Windows 7 than restricting Update Mode on Windows 10.

Sorry I mean CFA. When always allowing exe, msi and tmp on user folders. CFA will add some protection, because only trusted applications are allowed to store data.

 

[Andy Ful]

Sorry I mean CFA. When always allowing exe, msi and tmp on user folders. CFA will add some protection, because only trusted applications are allowed to store data.

Yes. But, <Update Mode> does not allow execution in user folders (understood as folders visible by users in Explorer on default settings). The AppData folder is hidden, so users cannot normally access it via Explorer or CFA. Even if an exploit could drop the executable into the AppData subfolder, the user could not execute it directly. The exploit has to drop the executable (EXE or MSI) there and execute it without user interaction.

 

[ForgottenSeer 85179]

1. I explained the use case. Just asking for an extra option for update mode (do you know where to find it?)

Sure:

2. Still leaves user space wide open. So not safer IMO,. With H_C I can copy and load my profile, that is easy enough for me.

user space is restricted.

3. Yes, that is why I have to look into it. Do you use it?

No i don't use it as i need Win32 programs and my setup is secure anyway.

 

[South Park]

Problem report: I installed the new version over 5.1.1.2 on 21H1, fully patched and with current Intel WiFi drivers. I used recommended settings for HC, firewall, and CD. A few min. after installing the beta, the WiFi shut off and couldn't be restarted. I reinstalled 6.0 beta, restarted the computer several times, eventually got the WiFi to turn back on, but then the computer crashed on shutdown. Crystal Disk Info, CHKDSK and SFC /SCANNOW showed no problems. I uninstalled the beta and reinstalled 5.1.1.2 and observed no further problems. The only error message generated was when the WiFi shut off, attached below.

 

[Andy Ful]

Problem report: I installed the new version over 5.1.1.2 on 21H1, fully patched and with current Intel WiFi drivers. I used recommended settings for HC, firewall, and CD. A few min. after installing the beta, the WiFi shut off and couldn't be restarted. I reinstalled 6.0 beta, restarted the computer several times, eventually got the WiFi to turn back on, but then the computer crashed on shutdown. Crystal Disk Info, CHKDSK and SFC /SCANNOW showed no problems. I uninstalled the beta and reinstalled 5.1.1.2 and observed no further problems. The only error message generated was when the WiFi shut off, attached below.

It seems that this issue is not related to the H_C settings. Such issues are probably related to WiFi drivers (the Log shows the issue in the Windows kernel). The H_C settings have no direct impact on kernel events.
The installation of H_C 6 beta over 5.1.1.2 does not change the restrictions in any way. The installer simply copies the new files to the H_C folder.
Did you look in the FirewallHardening Log? If you used the Recommended H_C block list the outbound connections of some new LOLBins were blocked (csc.exe, finger.exe, jsc.exe, and vbc.exe). But, this should not cause such errors. If so, then the computer would also crash every time when the user disconnects the computer from the Internet.

Did you change any settings (not necessarily related to H_C), make any updates or software installations? When you rebooted several times the faulty update could be removed automatically via the System Restore point.

 

[South Park]

@Andy Ful , the only software I had recently updated was Edge a few days earlier. There were no events logged in Defender or the Firewall for the date/time of the kernel error. The last event blocked by the Firewall was 17 July.

I manually disconnected from the Internet, turned WiFi off and back on, and reconnected today with no problems and no events logged using H_C 5.1.1.2 and all default settings. The only other error recently logged was a MS Edge PWA Proxy Host error on 17 July. (This error is logged about once every 4 days for no apparent reason.)

 

[Andy Ful]

@Andy Ful , the only software I had recently updated was Edge a few days earlier. There were no events logged in Defender or the Firewall for the date/time of the kernel error. The last event blocked by the Firewall was 17 July.

I manually disconnected from the Internet, turned WiFi off and back on, and reconnected today with no problems and no events logged using H_C 5.1.1.2 and all default settings. The only other error recently logged was a MS Edge PWA Proxy Host error on 17 July. (This error is logged about once every 4 days for no apparent reason.)

Is this your real system or a Virtual Machine?
In the virtual machine, you could repeat installing H_C 6 beta 1 when disconnected from the Internet (disconnect > reboot > install H_C 6 beta when disconnected > reboot). This would exclude the possibility of a silent driver update.
But, there is no need to do it in the real system. If the issue is related to some driver instability, it will probably happen again with or without H_C (please report such an event). If it is related to the H_C, it will be reported by someone else, too. Thanks for testing.

 

[South Park]

Is this your real system or a Virtual Machine?
In the virtual machine, you could repeat installing H_C 6 beta 1 when disconnected from the Internet (disconnect > reboot > install H_C 6 beta when disconnected > reboot). This would exclude the possibility of a silent driver update.
But, there is no need to do it in the real system. If the issue is related to some driver instability, it will probably happen again with or without H_C (please report such an event). If it is related to the H_C, it will be reported by someone else, too. Thanks for testing.

It's a real (non-VM) system, a 2016 laptop with Intel WiFi, with the latest driver being from 2018 and Windows showing nothing newer available. (Edit: I eventually found a newer driver from 2021 on Intel's site. Is it possible the C_D setting to warn on vulnerable signed drivers could have interacted with the old driver?)

I hope the event was a one-off and that if anyone else has a problem with H_C 6 beta, they'll report it here.

Thanks for all your work on this project!