Hard_Configurator - Windows Hardening Configurator

@Windows_Security,
I installed the Free Office. After the installation the MS Office documents were still directed to MS Office, so I changed this via Explorer context menu: Open with > Choose another application, with ticked option 'Always open...'.
 
Last edited:
For me the "windows vista at least" confused me more than win7,win 8,win 10( like on softpedia)
I think you are right. It would be clearer to say "Windows Vista or higher", or to list the options like you suggested. @askalan, please correct accordingly @Freki123 is right.
 
Quite nice. Now if I was just bold enough to try it o_O
Please, do not do it because the website is nice (joke).:giggle::emoji_innocent:
You can try it, if you are really disappointed by your actual setup (I doubt you are).(y)
 
Avast profile and 'UAC deny elevation of unsigned'

The UAC setting ValidateAdminCodeSignatures = 1, applies the policy to block elevation of applications (enforce cryptographic signatures on any interactive application that requests elevation of privilege).
This setting can probably block about 80% of malware on SUA (but not on Admin account because of UAC bypasses). It is not required when one uses H_C default-deny, but can be useful on H_C default allow setup. In the case of default-allow setup proposed by @Windows_Security, one can first apply H_C Avast profile (with any AV, not necessarily with Avast) and next, apply 'UAC deny elevation of unsigned' by registry tweak (ValidateAdminCodeSignatures = 1).
If running H_C or installing the new application is required, then first 'UAC deny elevation of unsigned' must be deactivated (ValidateAdminCodeSignatures = 0), and then H_C or application installer will be allowed to run with elevation. After this, the user can apply 'UAC deny elevation of unsigned' again (ValidateAdminCodeSignatures = 1).

The above is not the usual way of using H_C, because it is suited to default-deny setup.
 
Hardening SysHardener with SRP on SUA.

SysHardener is a very capable application, and I usually advise it to the users, because it is the simplest way to block/restrict VBScript, JScript, and PowerShell.
Other settings can be useful but not so important. SysHardener can also apply 'UAC deny elevation of unsigned' (Only Elevate Executables that are Signed and Validated). Yet, this feature is not especially popular, because it will block most application installers and can block some already installed applications. Several SysHardener settings are Windows defaults - that can be useful when they were changed accidentally or by malicious actions.

SysHardener with some additional (non-default) settings for: 'UAC deny elevation of unsigned', PowerShell, remote features, SMBv1, Linux subsystem, REG - JAR - BAT extensions, HomeGroup, BitsAdmin, Regsvr32.exe, and Rundll32.exe, can be a valuable and pretty usable hardening on SUA (fewer UAC bypasses as compared to Admin account). It will be also OK on Admin account, and there is a catch. The section 'Vulnerable Software Tweaks' works well only on Admin account - those tweaks do not work on SUA!
So, another tool has to be used for hardening those applications on SUA, especially for MS Office and Adobe Acrobat Reader.

If one wants to install the new application, then he/she can simply run SysHardener, untick the option 'Only Elevate Executables that are Signed and Validated', apply changes (reboot), make the installation, run SysHaredener again, tick 'Only Elevate Executables that are Signed and Validated', apply changes (reboot). It is simple, but not especially convenient when someone installs applications frequently.

But, where is the place for SRP?
  1. Add more entries for dangerous file extensions (CHM, CPL, several kinds of shortcuts, etc.). Shortcuts could be whitelisted in some predefined locations (like desktop, Start Menu) and blocked by default in other locations.
  2. Block files with double extensions, like: *.docx.exe, *.avi.exe, *.txt.exe, etc.
  3. Block powershell.exe and powershell_ise.exe to stop some PowerShell techniques that can bypass Constrained Language mode (this could be done also by non-SRP tweak).
  4. Whitelist by default, the script execution (VBScript, JScript) and dangerous file extensions in Windows and Program Files folders.
One can additionally disable Remote Registry and Remote Shell, like in H_C (non-SRP tweak).
Some users would like to block also several sponsors via SRP.
 
Last edited:
Hardening SysHardener with SRP on SUA.

SysHardener is a very capable application, and I usually advise it to the users, because it is the simplest way to block/restrict VBScript, JScript, and PowerShell.
Other settings can be useful but not so important. SysHardener can also apply 'UAC deny elevation of unsigned' (Only Elevate Executables that are Signed and Validated). Yet, this feature is not especially popular, because it will block most application installers and can block some already installed applications. Several SysHardener settings are Windows defaults - that can be useful when they were changed accidentally or by malicious actions.

SysHardener with some additional (non-default) settings for: 'UAC deny elevation of unsigned', PowerShell, remote features, SMBv1, Linux subsystem, REG - JAR - BAT extensions, HomeGroup, BitsAdmin, Regsvr32.exe, and Rundll32.exe, can be a valuable and pretty usable hardening on SUA (fewer UAC bypasses as compared to Admin account). It will be also OK on Admin account, and there is a catch. The section 'Vulnerable Software Tweaks' works well only on Admin account - those tweaks do not work on SUA!
So, another tool has to be used for hardening those applications on SUA, especially for MS Office and Adobe Acrobat Reader.

If one wants to install the new application, then he/she can simply run SysHardener, untick the option 'Only Elevate Executables that are Signed and Validated', apply changes (reboot), make the installation, run SysHaredener again, tick 'Only Elevate Executables that are Signed and Validated', apply changes (reboot). It is simple, but not especially convenient when someone installs applications frequently.

But, where is the place for SRP?
  1. Add more entries for dangerous file extensions (CHM, CPL, several kinds of shortcuts, etc.). Shortcuts could be whitelisted in some predefined locations (like desktop, Start Menu) and blocked by default in other locations.
  2. Block files with double extensions, like: *.docx.exe, *.avi.exe, *.txt.exe, etc.
  3. Block powershell.exe and powershell_ise.exe to stop some PowerShell techniques that can bypass Constrained Language mode (this could be done also by non-SRP tweak).
  4. Whitelist by default, the script execution (VBScript, JScript) and dangerous file extensions in Windows and Program Files folders.
One can additionally disable Remote Registry and Remote Shell, like in H_C (non-SRP tweak).
Some users would like to block also several sponsors via SRP.

Whew, this sounds exhausting!
 
It seems that the Blocked Events viewer is user-account dependent. I had a block in a certain standard user account, and I could only see it in the log when running the viewer from there.
Is there maybe a way for it to show events from all user accounts?
 
It seems that the Blocked Events viewer is user-account dependent. I had a block in a certain standard user account, and I could only see it in the log when running the viewer from there.
Is there maybe a way for it to show events from all user accounts?
No problem on my computer. I have run some applications and scripts on SUA. All blocked events were visible on Admin account. What events were not visible on your computer?
 
  • Like
Reactions: oldschool
Umm, now I see it from my main user account. I don't know why I didn't see it before. I will ping you again if it happens another time.
I noticed that some blocked files can give 2 alerts, like SRP and ASR alerts for the blocked VBScript files, but only the ASR event is logged. Probably, the file is really blocked only by ASR.
 
  • Like
Reactions: oldschool
I noticed that some blocked files can give 2 alerts, like SRP and ASR alerts for the blocked VBScript files, but only the ASR event is logged. Probably, the file is really blocked only by ASR.
This was a LNK file in user space that was blocked.
 
  • Like
Reactions: oldschool
Where concretely?
I was experimenting with ReHIPS, and I opened a Word doc in the other user account. Then, when I went back to that user account, I got the block posted below.

Windows Defender Antivirus has blocked an operation that is not allowed by your IT administrator.
For more information please contact your IT administrator.
ID: 3B576869-A4EC-4529-8536-B80A7769E899
Detection time: 2019-02-03T16:28:48.260Z
User: DESKTOP-111\ReHIPSUser7
Path: C:\Users\ReHIPSUser7\AppData\Roaming\Microsoft\Office\Recent\111 resume general.LNK
Process Name: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
Signature Version: 1.285.776.0
Engine Version: 1.1.15600.4
Product Version: 4.18.1901.7
 
I was experimenting with ReHIPS, and I opened a Word doc in the other user account. Then, when I went back to that user account, I got the block posted below.

Windows Defender Antivirus has blocked an operation that is not allowed by your IT administrator.
For more information please contact your IT administrator.
ID: 3B576869-A4EC-4529-8536-B80A7769E899
Detection time: 2019-02-03T16:28:48.260Z
User: DESKTOP-111\ReHIPSUser7
Path: C:\Users\ReHIPSUser7\AppData\Roaming\Microsoft\Office\Recent\111 resume general.LNK
Process Name: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
Signature Version: 1.285.776.0
Engine Version: 1.1.15600.4
Product Version: 4.18.1901.7
Windows Defender blocked a shortcut in ReHIPS sandbox. It is not SRP event, but ASR or some policy. The info comes from H_C or Event Viewer? What is the event Id for it?
 
Windows Defender blocked a shortcut in ReHIPS sandbox. It is not SRP event, but ASR or some policy. The info comes from H_C or Event Viewer? What is the event Id for it?
The info is from H_C, the event ID is 1121.
Several of the ASR rules rebel against MS Word running in ReHIPS isolation. They don't actually cause any breakage, but they generate a lot of alerts. Also Documents Anti-Exploit makes more alerts with MS Word running in ReHIPS isolation.
 
The info is from H_C, the event ID is 1121.
Several of the ASR rules rebel against MS Word running in ReHIPS isolation. They don't actually cause any breakage, but they generate a lot of alerts. Also Documents Anti-Exploit makes more alerts with MS Word running in ReHIPS isolation.
It is an ASR block. The rule 3B576869-A4EC-4529-8536-B80A7769E899 is related to 'Block Office applications from creating executable content'. It should be seen from H_C on every account.
 
It is an ASR block. The rule 3B576869-A4EC-4529-8536-B80A7769E899 is related to 'Block Office applications from creating executable content'. It should be seen from H_C on every account.
I have that rule disabled, because I already know it doesn't like ReHIPS. Weird.