Hard_Configurator - Windows Hardening Configurator

[Andy Ful]

Oops - I doubled the post.

 

[Andy Ful]

There is no need to use both AppGuard and Hard_Configurator. In fact, 'Hard_Configurator + vulnerable applications in App Container' is a similar philosophy as AppGuard + some system hardening.
The main difference is that AppGuard uses a custom driver and Hard_Configurator uses built-in Windows policies.
Also, I think that AppGuard is a more comprehensive solution, worth paying. The light sandboxing can be applied to any application, that is the clear advantage over security based on Hard_Configurator. Also, Hard_Configurator settings can be too restrictive in Enterprises.
From the home users point of view, Hard_Configurator can add the forced SmartScreen feature.

 

[ForgottenSeer 69673]

@shmu26 is right. I am a beta tester of AppGuard and I like the way it uses SRP with light sandboxing (guarded applications). This is a very efficient way to protect users in Windows. I test AppGuard in the VirtualBox, and use Hard_Configurator in the real system.
Sandboxie (paid) is great when one wants to isolate/restrict a vulnerable application. The custom sandbox can be highly restrictive, so for example, any other application cannot run, the Internet access is disabled, the application cannot read from folders but can write to them or can read but cannot write to them, etc.

Ahh ok they are not running on the same system at the same time. That makes sense.

 

[509322]

Ahh ok they are not running on the same system at the same time. That makes sense.

You do not want to run double SRP on a system. Pick either @Andy Ful 's Hard_Configurator or AppGuard.

It is like when I walk up to an endpoint and I find Group Policy, AppLocker and Windows Defender Application Guard being applied all at the same time - each doing the very same thing. It is stupid and makes usability a rigmarole. Redundancy like that is for Rockets, Space Shuttles and Space Stations - not PCs.

Quite frankly the same applies to combining AppGuard with some other security softs, but I don't want to create a drama here - so I won't go into detail.

 

[shmu26]

Hard_Configurator and AppGuard have an important difference in how they handle elevated processes.
Hard_Configurator does not apply restrictions to elevated processes, but AppGuard does.

 

[Andy Ful]

Hard_Configurator and AppGuard have an important difference in how they handle elevated processes.
Hard_Configurator does not apply restrictions to elevated processes, but AppGuard does.

That is right. That is also a basis for forced SmartScreen. The user can choose 'Run As SmartScreen' option from Explorer context menu to safely execute EXE or MSI application installers. The application installer is first checked by SmartScreen Application Reputation and if it passes the check then it is allowed to run with Administrative Rights. The installation is ignored by default-deny protection. Forced Smartscreen feature can throw to SmartScreen, files which normally are ignored by SmartScreen, like files from: compressed archives, FAT 32 pendrives, ISO images or files downloaded via file downloaders outside web browsers, etc.
One can say that Hard_Configurator protection can be easily bypassed via any UAC bypass, but the problem will be to execute such bypass - it will be blocked first by default-deny protection. When the user will insist to 'Run As SmartScreen', the exploit/malware will be blocked by SmartScreen reputation filter.
There is only one little hole in the above security, when something legal is exploited. Even then, it is not easy to harm the system, because an exploit usually runs as standard user and scripts are highly restricted (payload's download & execution will be blocked).
But, some more sophisticated exploits can in theory bypass all those protective layers. So, the user can close the hole by using vulnerable applications in App Container (Word Mobile, Excel Mobile, PowerPoint Mobile, Adobe Touch, etc.) or by applying advanced Hard_Configurator restrictions via <Blocked Sponsors> or blocking DLLs in the Userspace. The users on Windows 10 FCU can also apply Exploit Guard mitigations or use ConfigureDefender to apply ASR.

 

[shmu26]

That is right. That is also a basis for forced SmartScreen. The user can choose 'Run As SmartScreen' option from Explorer context menu to safely execute EXE or MSI application installers. The application installer is first checked by SmartScreen Application Reputation and if it passes the check then it is allowed to run with Administrative Rigths. The installation is ignored by default-deny protection. Forced Smartscreen feature, can throw to SmartScreen files which normally are ignored by SmartScreen like files from: compressed archives, FAT 32 pendrives, ISO images or files downloaded via file downloaders outside web browsers, etc.

Yeah, I like it.
"Ignore elevated processes" allows the system to do what it needs to do.

 

[Andy Ful]

There is a known fact that Windows Defender can cause irritating issues on some computers. In the next version of Hard_Configurator, I will prepare a special profile to work with Avast Free AV. That will be just Recommended settings profile with whitelisted EXE files. The user should set Avast to Hardened Aggressive mode, so all EXE files will be first checked by Avast reputation service in the cloud.
With those Avast + Hard_Configurator settings, the user can get both strong Avast protection + Windows built-in default-deny security. Furthermore, the default-deny protection will be almost invisible to the home users, because they mostly run EXE files. Additionally (on Windows 8+), the users can still use 'Run As SmartScreen' to check the file installers by SmartScreen Application Reputation cloud.
That will be a much more usable, set and forget solution for home users, than Defender + Hard_Configurator, without losing much security.
The only cons will follow from the fact that Avast on Windows 10 is not as stable as Windows Defender.

 

[shmu26]

There is a known fact that Windows Defender can cause irritating issues on some computers.

But SRP and other HC functions work with any AV, or no AV, is this not so?

 

[Andy Ful]

But SRP and other HC functions work with any AV, or no AV, is this not so?

Yes, but whitelisting EXE files without using a good reputation cloud for them, weakens default-deny protection for EXE files. Hard_Configurator + Avast Hardened Aggressive mode is still a kind of smart default-deny protection. Hard_Configurator + any AV is not.

 

[shmu26]

Yes, but whitelisting EXE files without using a good reputation cloud for them, weakens default-deny protection for EXE files. Hard_Configurator + Avast Hardened Aggressive mode is still a kind of smart default-deny protection. Hard_Configurator + any AV is not.

Got it. You are talking about a special setup for Avast hardened:
SRP default/allow for exe files + Avast cloud reputation.
But the recommended SRP default/deny setup can be used with any AV, or without AV.

 

[Andy Ful]

Got it. You are talking about a special setup for Avast hardened:
SRP default/allow for exe files + Avast cloud reputation.
But the recommended SRP default/deny setup can be used with any AV, or without AV.

That is right. I will have to send my executables to Avast for manual analysis and whitelisting, because it will kill them in the quarantine.

 

[Sunshine-boy]

I used it with Eset and it worked great!

 

[Andy Ful]

I used it with Eset and it worked great!

Did you have to exclude Hard_Configurator executables in Eset?

 

[Sunshine-boy]

No.why would I?Eset cloud shows your tool as unknown(Brown Color)!i submit it to Eset more than 5 times but they never whitelist it(green mark).Eset won't bother to Exe(allow by default) even if it has 0 reputations.

 

[Sunshine-boy]

Andy do you know about Structured Exception Handling Overwrite Protection/ Address Space Layout Randomization (ASLR) and this policy: Administrative Templates\System\Mitigation Options\Process Mitigation ?!
can you pls add this protection to your tool?
Honestly, I don't understand the Microsoft documentation for this policy

 

[Andy Ful]

Those mitigations are turned ON by default on Windows 10. There is no need to disable any of them. You have to remember that in Windows many settings are already configured even when in GPO the setting is 'Not configured'

 

[shmu26]

So I have a process that runs every once in a while
C:\ProgramData\Logishrd\LogiOptions\Unifying\DJCUHost.exe
It is associated with my logitech mouse software.
When it runs, and I have dll protection enabled, I get a Windows error message that it was blocked by my administrator settings. I don't know what this process actually does. Maybe it runs an updater or something, don't know. It does not show in the log.

I tried enabling advanced logging, and manually running it elevated, but it did not do the usual thing that way.

I am guessing that it uses a dll in a temp folder somewhere.

Do you maybe know some tool that logs dlls?
I could disable dll protection, wait until it runs, and then check the log?

EDIT: I found this about the process, not that it helps very much troubleshooting my issue:

The unifying software is a program that lets you configure the devices. It will automatically scan for wireless keyboards and mice and add them onto the list. We can enable or disable a certain device using the program.

 

[WildByDesign]

Those mitigations are turned ON by default on Windows 10. There is no need to disable any of them. You have to remember that in Windows many settings are already configured even when in GPO the setting is 'Not configured'

Most of these great mitigations are enabled by default for all 64-bit processes on modern Windows 10 machines which is absolutely great to see. Although some of these mitigations are not applied (system-wide) on 32-bit processes. Using 32-bit processes on 64-bit systems these days is never the greatest idea but sometimes we don't have an alternative.

So in the case of anyone wanting to further protect their 32-bit processes, they can use WDEG to apply per-process mitigations but also the new draft is out for Security baseline for Windows 10 v1803 “Redstone 4” – DRAFT (Security baseline for Windows 10 v1803 “Redstone 4” – DRAFT) for RS4 users. In that package, there are policy files to drop in C:\Windows\PolicyDefinitions which are some quite valuable security policies to manage in gpedit.msc manually. In particular, it contains a policy to enable which forces SEHOP specifically on all 32-bit processes as well so that you don't have to do it per-process. This covers system-wide.

I apologize if these details had already been covered here at MalwareTips since I haven't followed as closely here. I would really like to get myself more familiar with MT forum soon.

BTW, thank you for this great tool. I am always a big fan of tiny portable apps which contain a big punch as far as the security impact that they can provide in a light, efficient and portable way. Keep up the great work!

EDIT: The FINAL version of the security baseline for 1803 will be out shortly after RS4 goes public.

 

[shmu26]

Most of these great mitigations are enabled by default for all 64-bit processes on modern Windows 10 machines which is absolutely great to see. Although some of these mitigations are not applied (system-wide) on 32-bit processes. Using 32-bit processes on 64-bit systems these days is never the greatest idea but sometimes we don't have an alternative.

So in the case of anyone wanting to further protect their 32-bit processes, they can use WDEG to apply per-process mitigations but also the new draft is out for Security baseline for Windows 10 v1803 “Redstone 4” – DRAFT (Security baseline for Windows 10 v1803 “Redstone 4” – DRAFT) for RS4 users. In that package, there are policy files to drop in C:\Windows\PolicyDefinitions which are some quite valuable security policies to manage in gpedit.msc manually. In particular, it contains a policy to enable which forces SEHOP specifically on all 32-bit processes as well so that you don't have to do it per-process. This covers system-wide.

I apologize if these details had already been covered here at MalwareTips since I haven't followed as closely here. I would really like to get myself more familiar with MT forum soon.

BTW, thank you for this great tool. I am always a big fan of tiny portable apps which contain a big punch as far as the security impact that they can provide in a light, efficient and portable way. Keep up the great work!

EDIT: The FINAL version of the security baseline for 1803 will be out shortly after RS4 goes public.

I assume there is some reason why SEHOP is not applied by default to 32 bit processes. Do you maybe know what issues it could cause, or which processes are high risk for SEHOP?