Using Hard_Configurator in HARDENEDmode with ConfigureDefender in HIGHEST protection on Windows10

[Windows_Security]

NOTE: THIS SETUP IS FOR PEOPLE RUNNING ON ADMIN ACCOUNT

Getting the most out of Windows 10 build-in security features without reducing functionality or compatibility.

USE CONFIGURE DEFENDER to set Windows Defender at HIGHEST settings (well not really the highest settings, because CLOUD protection has a higher level called block, but this setup is the highest while keeping the user in full control).

Hard Configurator enabling Windows BASIC USER Software Restriction Policy on Windows Home versions (it is a PRO feature for free) easy to use compared to Window's group policy editor which requires detailed knowledge to configurate (so you alse get the knowledge for free because Hard Configurator has predefines profiles).

Why is it an EASY SRP?

1. Allowing admins to overrule in case something might not work (safety net RUN AS ADMIN). Note that I apply this setup since 2007 for older relatives and every day PC users (the type of person which uses PC for surfing, social media and streaming media like songs, youtube, Netflix etc) without problems on at least 10 PC's of relatives. So it is a proven solution over 300.000 hours and counting of problem free computing
   
   
2. SRP excludes (means allows) EXE, MSI, MST, MSU, TMP and DLL files, so every executable is allowed to run.
   
   
3. SRP Basic User meaning you can use all programs as a normal user, only scripts and other risky file types are blocked in user folders. Normally Program install in UAC protected folders. Running shady executable formats is a way to trick users into running malware and infecting themselves.

 

[oldschool]

Very nice thread. Your offering gives Hard_Configurator users another great, simple-to-use profile option.

 

[Ink]

Where can I find the specs (link)?

Look at the specs of my ASUS Transformer, they are humble.

 

[Windows_Security]

Where can I find the specs (link)?

I have filled it in the form edit fields above, but here they are

 

[Windows_Security]

Bonus for people using Microsoft Software (like Office or Browser). The Windows Aps products all run in AppContainer, so they are safe.

Desktop applications (Like Microsoft Office or Edge Browser) can get extra protection using Exploit Protection feature of Windows Defender.

Go to Windows Security (Windows Defender), choose APP & Browser control, scroll down until you see EXPLOIT PROTECTION
Click the Exploit Protection Settings, Choose the (second) tab Program Settings, choose ADD program (by name or path).
Add this feature (example of Edge-chromium).

WHAT THIS SETTING DOES? ==> Only allows microsoft signed images (like DLL's) to load. This prevents injecting DLL's into that program. so ensures nobody can mess with it (no need for HPMA or MBAE etc). Free TOP-tier EXPLOIT protection

USE THIS ONLY FOR MICROSOFT APPLICATION PROGRAMS (NOT PART OF THE WINDOWS OS)!!!

 

[Andy Ful]

Thanks for a nice review.
Although I have to add some corrections.

1. On Windows 7 and higher versions, the EXE and MSI files will be still blocked by SRP in UserSpace. So, some applications will require manual updates from Admin account by using "Run as administrator" option from the right-click Explorer context menu.
2. <Disable Elevation on SUA> is set to ON, so any application which require to elevate is blocked (also Hard_Configurator) on any SUA type of account. it is not possible to install new applications in SystemSpace (for example in C:\Program Files) on Standard User type of account (SUA). So, most applications have to be installed/update on Admin account by using "Run as administrator" option from the right-click Explorer context menu. This will not be a problem for most users, because most users do not use SUA at all.
3. If the user wants to allow EXE files, then it is possible via <Whitelist By Path> by pressing <ADD> button under the "Allow Exe and TMP". But on SUA type of account the EXE files (started by user) which require elevation will be still blocked by the setting from point 2.
4. In the proposed setup, the remote access is allowed to the computer. It is much safer to disable it (<Block Remote Access> = ON). Most home users do not use remote features at all.
5. On Windows 8, 8.1 and 10, I suggest the setting <Run As SmartScreen> = 'Standard User'. This allows using SmartScreen for Explorer as on-demand scanner, and informs about many dangerous files.

The closest to @Windows_Security proposition with allowed EXE files, would be the profile in attachment, which I named: Windows_Security_hardening.hdc.txt (download - delete .txt - load to H_C - enjoy).

Edit.
Thanks @oldschool for pointing out the potential problem for users on SUA. The SUA is much more restricted than with 'UAC deny elevation of unsigned'. The applied protection on SUA blocks elevation both signed and unsigned files.
The advantage of using such protected SUA is blocking also signed malware which requires elevation (which is true for most signed malware).

 

[shmu26]

Hard Configurator enabling Windows BASIC USER

Just curious why you prefer Basic User over Disallowed? (And what exactly is the difference, anyway)

 

[Windows_Security]

@Andy Ful THX

Changed attached file I am using this since Vista until you made H_C with all the tweaks I used to painfully make through registry hacks. Reason for not using Run As Smartscreen was that I always set UAC to deny elevation of unsigned after I have installed H_C. I also thought (supposingly wrong) that Run As Smartscreen required elevation. So good to know it also runs as standard user.


@shmu26

On VIsta when you set default level to basic user and ran a program as basic user. It could not elevate to Admin. So all user programs with a seperate updater could be run in an extra "basic user' container. With Windows 7 this was impossible for programs started through file association (like word, poewerpointand excel), but for programs which you would start from taskbar and windows menu (like browser, mail and media player) that could still be achieved with a shortcut trick. In Windows 8 Microsoft made further changes to SRP to make this impossible.

Disallowed is more secure, because Basic User allows execution from user space folders (taskbar and start I believe). But Andty has provided some options to help close that gap. I close them through Access Control Lists. By simply adding a deny "Traverse folder/execute file" for everyone on Documents, Music, Pictures, Videos and Internet facing folders (and Startup folders).

Reason for (keeping) using Basic User is that (that is true) at least 10 relatives run this setup for years is that I have not been called (average users use they PC's, they don't install software for fun and when they are used to a program they dislike learning another program). I always install Office with cheap digital keys and (used to) copy some registry hacks of Group Policy to set Office trustcenter. Now with Windows Defender ASR rules that is not even necessary anymore.

Bottom line: I don't want to be called in the evening because their PC is not working. It worked on Vista, so I kept using it (don't fix something what is not broken). The more than 300.000 hours problem free usage is exaggerated, assuming on average 4 hours PC usage per day (most of them are retired) it is probably closer to 150.000 hours. A MTBF of over 150.000 hours what else do you want as a support guy?

Regards

 

[shmu26]

@Andy Ful THX

Changed attached file I am using this since Vista until you made H_C with all the tweaks I used to painfully make through registry hacks. Reason for not using Run As Smartscreen was that I always set UAC to deny elevation of unsigned after I have installed H_C. I also thought (supposingly wrong) that Run As Smartscreen required elevation. So good to know it also runs as standard user.


@shmu26

On VIsta when you set default level to basic user and ran a program as basic user. It could not elevate to Admin. So all user programs with a seperate updater could be run in an extra "basic user' container. With Windows 7 this was impossible for programs started through file association (like word, poewerpointand excel), but for programs which you would start from taskbar and windows menu (like browser, mail and media player) that could still be achieved with a shortcut trick. In Windows 8 Microsoft made further changes to SRP to make this impossible.

Disallowed is more secure, because Basic User allows execution from user space folders (taskbar and start I believe). But Andty has provided some options to help close that gap. I close them through Access Control Lists. By simply adding a deny "Traverse folder/execute file" for everyone on Documents, Music, Pictures, Videos and Internet facing folders (and Startup folders).

Reason for (keeping) using Basic User is that (that is true) at least 10 relatives run this setup for years is that I have not been called (average users use they PC's, they don't install software for fun and when they are used to a program they dislike learning another program). I always install Office with cheap digital keys and (used to) copy some registry hacks of Group Policy to set Office trustcenter. Now with Windows Defender ASR rules that is not even necessary anymore.

Bottom line: I don't want to be called in the evening because their PC is not working. It worked on Vista, so I kept using it (don't fix something what is not broken). The more than 300.000 hours problem free usage is exaggerated, assuming on average 4 hours PC usage per day (most of them are retired) it is probably closer to 150.000 hours. A MTBF of over 150.000 hours what else do you want as a support guy?

Regards

They probably don't even realize that they should thank you

 

[Andy Ful]

@Windows_Security gave a nice explanation. In the first versions of H_C, I also used <Default Security Level> = 'Basic User'. After some time I solved the shortcut problem when using <Default Security Level> = 'Disallowed', so this setting is recommended.
@Windows_Security can use 'Basic User' + ACL, which is also OK.

If someone uses 'UAC set to deny elevation of unsigned' then <Run As SmartScreen> has to be set to "Standard User". This will trigger RunBySmartScreen tool which runs with standard rights. On the contrary, the <Run As SmartScreen> = "Administrator" would normally try to trigger RunAsSmartScreen tool with elevation, and this would be blocked by 'UAC set to deny elevation of unsigned' (H_C executables are not digitally signed).

The profile from my previous post is @Windows_Security idea without the necessity of using ACL. I am not sure if ACL settings can survive Windows upgrades (never tried). All these settings (except <Run As SmartScreen> options) were presented by him even before H_C was created.

 

[foasolution]

There is a reason for not using Run As Smartscreen was that I always set UAC to deny elevation of unsigned after I have installed H_C

 

[Andy Ful]

There is a reason for not using Run As Smartscreen was that I always set UAC to deny elevation of unsigned after I have installed H_C

In H_C's recommended settings (default-deny setup) the EXE files are not allowed in UserSpace so they cannot run. It is a much stronger restriction than UAC set to deny elevation of unsigned.

In the setup proposed by @Windows_Security (with my corrections), the EXE files are allowed (default-allow setup for EXE) so this UAC setting can be useful. But If one uses Standard User Account (SUA) for daily work, then 'UAC set to deny elevation of unsigned' is ignored. Windows_Security profile applies a stronger restriction <No Elevation on SUA>, which deny elevation of signed & unsigned (it is limited only to SUA type of account).
All will work if one use <Run As SmartScreen> = "Standard User". Yet, the user on Admin account has to remember to unlock the UAC before running H_C, because otherwise H_C executable will be blocked (it is not signed and requires elevation). After finishing H_C configuration, the UAC has to be set to block elevation of unsigned, again. This works, because after closing H_C, the restrictions are applied in the real-time by Windows built-in policies.

The above is not especially convenient so it is better to apply the below Windows Defender settings via ConfigureDefender, instead of UAC set to deny elevation of unsigned:

1. HIGH Profile + 'Cloud Protection Level' = 'Block'.
2. ASR rule: "Block executable files from running unless they meet a prevalence, age, or trusted list criteria".

Those WD settings can be a good replacement for UAC deny elevation of unsigned, because they are fully compatible with H_C and can also block unsigned suspicious programs (with or without elevation).

Warning.
The user should realize that both UAC set to deny elevation of unsigned and the above WD settings will produce more false positives than in standard setup based on typical AV only.
Furthermore, on SUA, the user can use only applications which do not require elevation. All computer management, installing/uninstalling applications, and running H_C, etc., have to be done on Admin account. The advantage for the user is that on SUA, any malware (signed or unsigned) cannot elevate too.

Post edited.
Thank @oldschool for pointing out the potential difficulties for users on SUA related to the setting <No elevation on SUA>.

 

[Windows_Security]

And when using microsoft programs like chromium-edge, set exploit protection as shown in post #5 in this thread to only allow Microsoft signed to load, this is really strong especially againts dotNet DLL's (which SRP, AppLocker, NVT Exe Radar, OS Armor, Bouncer etc can't block).

@Andy Ful even on my Windows10 Pro desktoop I am using H_C, because it is easier to use than secpol.msc

 

[Andy Ful]

The H_C tweaks safely several tenths of policies with one mouse click, so it is much easier than GPO.
Some of those policies are not known even by many administrators who use SRP.
Hardening Windows Edge by Exploit Guard as a browser for banking is a very good idea.
One can also use Chrome, Chromium Edge or another safe browser for daily work.

 

[oldschool]

I couldn't find a priest to hear my confession so I must admit my transgression here. I tried @Windows_Security profile and as you said, H_C exe. was blocked, which left me in an untenable situation. I should know from experience to wait for further posts like this:

Yet, the user has to remember to unlock the UAC before running H_C, because otherwise H_C executable will be blocked (it is not signed and requires elevation).

.:notworthy::notworthy::notworthy: Be warned! I had an image so not the worst thing, but you don't need to know the bloody details of what happened with my image. :devil::devil::devil: So am I now cleaning up the mess I caused. Lessons are being learned -> my skill level increases.

 

[Andy Ful]

I couldn't find a priest to hear my confession so I must admit my transgression here. I tried @Windows_Security profile and as you said, H_C exe. was blocked, which left me in an untenable situation.
...
.:notworthy::notworthy::notworthy: Be warned! I had an image so not the worst thing, but you don't need to know the bloody details of what happened with my image. :devil::devil::devil: So am I now cleaning up the mess I caused. Lessons are being learned -> my skill level increases.

WOW!!!
That is why I warned several times on MT to avoid using SysHardener or OSArmor with H_C. Many security solutions together always make a headache in the end.
Anyway, you could just unblock the UAC setting by using regedit, or SysHardener, or OSArmor.
There is no need to act hastily when configuring security.

Edit.
I was misdirected by the notion about UAC, so I assumed that the problem was with UAC set to deny elevation of unsigned. But it seems that @oldschool probably uses Standard User Account (SUA), and then the behavior he noted is quite normal and intended just by Windows_Security profile. It follows directly from the setting:
<More ...> <No Elevation on SUA> = ON.
This setting blocks elevation of any application started by the user on SUA (but is ignored on Admin account). It is a stronger version of 'UAC deny elevation of unsigned', but it restricts only SUA type of account and is ignored on Admin type of account. So, on Admin account the user can run H_C, but not on SUA. The H_C and all signed/unsigned applications which try to elevate will be blocked on SUA. Other applications which run with standard rights will be run normally.
Such protected SUA account is very secure, much more than with UAC deny elevation of unsigned. But, computer management, installing/updating applications, running H_C, etc., have to be done on Admin account. Furthermore, the user on SUA can run only applications which do not require elevation. Windows Updates and System tasks can still run without a problem, because they do not use SUA.
If the user can use such protected SUA, then the protection is much stronger than with 'UAC deny elevation of unsigned', because the elevation of all programs (also signed) will be denied, so signed malware will be blocked too.

 

[oldschool]

There is no need to act hastily when configuring security.

That's was my mistake in the end.

Edit: I did not use SH or OSA. Most of the damage has been cleaned up except for importing some stuff from backup.

 

[Andy Ful]

That's was my mistake in the end.

You are not alone, I have an interesting history too.
Fortunately, I use Shadow Defender when testing the new configurations.

 

[Windows_Security]

@oldschool

Sorry to hear from your problems. Should have said it was for people running as admin. :emoji_flushed:

 

[Andy Ful]

That's was my mistake in the end.

Edit: I did not use SH or OSA. Most of the damage has been cleaned up except for importing some stuff from backup.

If you use SUA that was not a mistake. Although, restoring the system was unnecessary. See my edited post:
https://malwaretips.com/threads/usi...est-protection-on-windows10.92678/post-816173