H_C - Hard_Configurator
AV - Antivirus application
SRP - Software Restriction Policies (Windows built-in security feature)
UAC - User Account Control
SUA - Standard User Account
AA - Administrator Account; not to be confused with 'Built-in Administrator Account' (disabled by default), that can be used to boot Windows to 'Audit mode'.
These are standard (default) rights granted by the Windows system to processes initiated by the user on AA or SUA. Access to higher rights is controlled by User Account Control (UAC). This feature was introduced with Windows Vista.
An Administrator Account (AA) created during a fresh installation of Windows, or any account created manually by the user (AA or SUA), is limited to standard rights by UAC.
A process initiated by the user on AA or SUA may be elevated to Administrator rights and access important, new privileges. Process elevation is controlled by User Account Control (UAC). If the elevated process is initiated on AA (with standard rights), then process creation and elevation take place on AA, and the process continues to run on AA (account change not required). If it is initiated on SUA, then process creation and elevation also take place on AA, except the process no longer runs on SUA (account change SUA ---> AA, admin password required).
Selected Windows built-in security features can restrict Windows, MS Office, and Adobe Acrobat Reader with smart default-deny protection. These features are normally disabled in Windows. H_C allows the user to enable them, make configuration changes, and displays the user's chosen settings. After configuration, real-time protection comes only from Windows' built-in security features.
The following file locations (folders and subfolders) are defined as SystemSpace and are whitelisted by default in H_C:
C:\Program Files (x86) - only on Windows 64-bit
All locations on the user's local drives (also USB external drives) which are not included in SystemSpace, are defined as UserSpace. Network locations are excluded either from UserSpace or SystemSpace. UserSpace locations are writable by processes running with standard rights. All executables in the UserSpace are blocked by default with H_C's default-deny setup, except when whitelisted or initiated by the user via "Run As SmartScreen" (see also the Elevated Shell).
Normally, the user on AA or SUA may initiate applications only with standard rights. However, this can be changed by accessing an elevated shell: PowerShell (Administrator), Command Prompt (Administrator), etc. An alternative solution is to run Total Commander via "Run As SmartScreen". The user who wants to access the elevated shell must first accept the UAC prompt. As long as the applications are initiated from the elevated shell, SRP and UAC will ignore them (i.e., no UAC alerts or SRP restrictions). This can be useful when doing administrative tasks on the computer.
It allows all installed applications and system processes but blocks by default all new executables, except those which are whitelisted. Some executables may be whitelisted automatically, e.g. by certificate or path rules. Others must first be whitelisted by the user in order to run. It is the user's responsibility to whitelist clean files.
Smart default-deny makes the computer more usable, while maintaining a high level of protection in the home environment. Hard_Configurator includes three smart features:
They are very safe in the home environment, against malware in the wild. Smart features can be bypassed in Enterprises because of targeted attacks. Also, certain H_C restrictions, e.g. "Block remote access", are not practical in enterprises.
No. System processes, Windows Updates, and system scheduled tasks are not started directly by the user. These are initiated with higher than standard rights and automatically bypass SRP restrictions configured with H_C.
Occasionally. Some applications download the updater and run it from the Temp folder in user profile with standard rights. In this case, the update will be blocked by the H_C default-deny settings.
If the update is blocked, then the application or updater should be run with Administrator rights by using "Run As SmartScreen" (on Windows 8, 8.1, 10) or "Run as administrator" (on Windows Vista or Windows 7).
There may be a problem if the application is installed in the user profile, because then an update should not be performed with Administrator rights. Why? If it is run with Administrator rights, then it will usually search the application files in the administrator profile and not in the SUA profile. The update will thus fail, or will be installed in the wrong user profile.
H_C users should check as follows:
Generally, it is safe in smart default-deny setup. SystemSpace locations are usually not writable with standard rights. There are known exceptions, but they are covered by H_C's <Protect Windows Folder> setting. The exploit or malware cannot silently drop payloads to SystemSpace when running with standard rights.
Usually they are, and this is recommended by Microsoft. However, some legal applications still install in UserSpace. These applications have to be whitelisted manually. For users who frequently install such applications, default-deny protection may be inconvenient.
Processes initiated by the user cannot run with Administrator rights on SUA. If a process running on SUA requires Administrator rights, then the UAC prompt appears, and the user must provide an Administrator password to log on to the AA. After accepting the UAC, the process is no longer running on SUA, but on AA (user account is switched for that process only: SUA ---> AA).
This behavior is quite different when a process is initiated on AA, because the user is not obliged to provide the Administrator password. Instead, the UAC prompt asks for a simple "Yes" or "No". After accepting the UAC prompt, the process continues running on the same AA (user account is not switched for that process).
Yes, most definitely. On SUA, unelevated processes (running with standard rights or lower) do not share the same user account as elevated processes. This is not true on AA. It is much easier to exploit something when both unelevated and elevated processes are running on the same AA account. Malware or exploits cannot run with Administrator rights on SUA - they must first escape to an Administrator account. This is hardly possible, because Microsoft usually patches any system vulnerabilities which might allow malware to escape from SUA. H_C's smart default-deny setup relies on blocking unelevated programs (running with standard rights), so SUA is an ideal companion to H_C.
SUA should be considered a vital part of any security solution when using a vulnerable system, or popular & vulnerable software. However, it is not necessary to use SUA with H_C's smart default-deny when Windows 10 and all installed software are updated regularly. A well maintained system which includes H_C is a dead end for malware/exploits in the home environment.
Yes, if the application installs in SystemSpace (usually in C:\Program Files). There can be a problem if it installs in user profile, which lies in UserSpace. Why? Because with H_C smart default-deny, Forced SmartScreen uses Administrator rights. Applications which are intended to install in SUA profile, are installed in Administrator profile - even when the installation is initiated from SUA. The user on SUA cannot run applications from Administrator profile, since Windows isolates user profiles from one another. In this case, the user must disable default-deny protection temporarily, and install the application without using "Run As SmartScreen".
New users of default-deny protection should be aware that it requires more skill than using an AV alone. Please use only the Recommended H_C settings along with your AV, until you are comfortable and familiar with H_C. Prematurely adding advanced H_C settings or more security software to this configuration may lead to complications, and user discouragement, with default-deny protection.
Recommended H_C settings provide strong preventive protection against running malware in the system.
Advanced H_C settings can mitigate the malware or an exploit which is already running in the system. When using well-patched software on updated Windows 10, advanced settings are not required.
On most computers, even maximum H_C settings cannot break anything important in the system, but some applications may be not fully functional. Enabling advanced settings will usually require more whitelisting, more researching of logs, etc., and may be annoying for most users. If so, then the user should restore Recommended settings.
Restoring the Recommended settings preserves the user's whitelisted entries and blocked file extensions.
Advanced settings can be activated by turning ON additional individual H_C options, or by loading the setting profile (<Load Profile> button).
It is advisable to begin with the Recommended_Enhanced profile. This may be done by loading the file: Windows_*_Recommended_Enhanced.hdc, where the asterisk replaces the Windows version (7, 8, or 10). This will enable the Recommended settings, and some well known Sponsors will be blocked (including Script Interpreters).
A Sponsor is an executable from the SystemSpace (usually from C:\Windows), that can be used by an attacker to bypass default-deny protection. Sponsors are frequently used in targeted attacks on organizations and businesses, especially via exploits. Blocking some Sponsors in the home environment can be important for people who use a vulnerable system or software. In H_C's Recommended settings, Windows Script Host Sponsors (wscript.exe and cscript.exe) are blocked by SRP. Furthermore, PowerShell Sponsors (powershell.exe and powershell_ise.exe) are restricted by Constrained Language mode in Windows 10 and blocked by SRP in Windows Vista, 7, 8, 8.1. These Sponsors are the most popular Script Interpreters. Some other Interpreters (mshta.exe, hh.exe, wmic.exe, scrcons.exe) can be blocked in H_C by <Block Sponsors> option. Unfortunately, a few of them can be used occasionally by older software, usually those related to peripherals. Applications and web browser plugins may also use Interpreters for some actions, though most applications and plugins do not use them at all.
In H_C, Sponsors are blocked for processes running with standard rights, but allowed for administrative processes running with higher rights.
Yes, they can. Here are some examples, where the random characters are replaced by wildcards to whitelist the particular EXE file: