New Update Testing Windows Hybrid Hardening (new hardening application).

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
...
You can really be proud on the end result and I hope I have not offended you in our sharp discussions 😉.

I tested ISG for a few years. Without our discussion, I would probably noticed in the year 2024 that it improved in the year 2023. :)
It is still not perfect, but now it is very close to the idea of forced SmartScreen I had several years ago when starting the Hard_Configurator project.
It is nice, that by changing the WDAC Whitelist, the setup can be adjusted to different users.
 
Last edited:

tidyloop

Level 1
Oct 14, 2023
17
I installed WHH for the first time and enabled SWH and WDAC. After doing so I can't load ConfigureDefender, FirewallHardening or Documents Anti-Exploit. I receive an event like the below:

Event[0]:
Event Id = 3077
Local Time: 2023/10/15 07:20:49
Attempted Path = C:\Windows\Temp\022219240259022212\0\FirewallHardening(x64).exe
Parent Process = C:\ProgramData\WindowsHybridHardening_Tools\FirewallHardening_3000.exe
PolicyName = UserSpace Lock
UserWriteable = true

I was trying to run them from C:\ProgramData and confirmed that is one of the whitelisted directories for WDAC.
 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
I installed WHH for the first time and enabled SWH and WDAC. After doing so I can't load ConfigureDefender, FirewallHardening or Documents Anti-Exploit. I receive an event like the below:

Event[0]:
Event Id = 3077
Local Time: 2023/10/15 07:20:49
Attempted Path = C:\Windows\Temp\022219240259022212\0\FirewallHardening(x64).exe
Parent Process = C:\ProgramData\WindowsHybridHardening_Tools\FirewallHardening_3000.exe
PolicyName = UserSpace Lock
UserWriteable = true

I was trying to run them from C:\ProgramData and confirmed that is one of the whitelisted directories for WDAC.
The FirewallHardening child process is blocked in the "C:\Windows\Temp" folder, because this folder on your computer is writable with standard rights.
Normally, it is not writable and applications can run from "C:\Windows\Temp" with WHHLight restrictions.
In your case there are two solutions:
  1. Add the path "C:\Windows\Temp" to the WDAC Whitelist.
  2. Switch OFF the WDAC temporarily (recommended if other applications are not blocked in "C:\Windows\Temp").
Edit1.
The untypical ACL restrictions for "C:\Windows\Temp" can happen when you have forced access to the "c:\Windows\Temp" folder from Standard User Account.

Edit2
More info can be found in the post:
 
Last edited:

tidyloop

Level 1
Oct 14, 2023
17
The FirewallHardening child process is blocked in the "C:\Windows\Temp" folder, because this folder on your computer is writable with standard rights.
Normally, it is not writable and applications can run from "C:\Windows\Temp" with WHHLight restrictions.
In your case there are two solutions:
  1. Add the path "C:\Windows\Temp" to the WDAC Whitelist.
  2. Switch OFF the WDAC temporarily (recommended if other applications are not blocked in "C:\Windows\Temp").
Edit.
The untypical ACL restrictions for "C:\Windows\Temp" can happen when you have forced access to the "c:\Windows" folder from Standard User Account.
Thank you so much! I suspect you're right with your edit too. I don't recall doing that but may have done some time ago for whatever reason.
 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
I investigated the ACL permissions of C:\Windows\Temp folder. It looks like they are kinda special and similar to the permissions of the %ProgramData% folder.
  1. If one copies the file to C:\Windows\Temp with standard rights, the file location is writable.
  2. If one copies the file with higher privileges the file location is not writable (the file cannot be replaced or modified with standard rights).
The difference is that files in %ProgramData% can be seen in the Explorer with standard rights, but not files in C:\Windows\Temp.
If the user wants to open C:\Windows\Temp, the alert is triggered:

1697676162470.png


After pressing the <Continue> button the user permanently gets access to that folder!!! But then, all locations in C:\Windows\Temp become writable (can be replaced or modified with standard rights).
 
Last edited:

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
Two Accounts Setup.

The idea of using two or more accounts for security reasons is as old as Windows Vista. Microsoft still recommends a Standard User account (SUA) for daily work. But, most home users do not like SUA:
  1. It requires writing an Admin password when something wants to elevate.
  2. Some applications do not install properly from SUA.
Anyway, SUA has many security advantages over an Admin account, so it is worth consideration when the computer is used:
  • in school,
  • by you and your children,
  • occasionally by guests,
  • when traveling.
In such scenarios, the user can simply sign in to SUA for more security. A similar configuration can be applied by using WHHLight with enabled WDAC.

1698274271217.png


What do you think about such a setup?
 
F

ForgottenSeer 97327

@Andy Ful

It is a great and super solid setup. To make it perfect add blocking common scriptors for SUA with SRP.

I think the post of @Ultimate Vision explains why people would be reluctant to use it. Rationally everyone should implement this, but laziness and trust in easy to use blacklist solutions probably will be the reason why not many people will implement this. For MT members wanting to cut down on their security addiction it is the the best build-in security solution one can find (and it is free) (y)
 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
@Andy Ful

It is a great and super solid setup. To make it perfect add blocking common scriptors for SUA with SRP.
...

It is already as strong as the strongest free setups, like for example tweaked H_C or tweaked Comodo Firewall. It is also stronger than SAC.
The advantage is, that the user can choose between usable and Super_Safe setup by simply signing into the proper user account.

Blocking many LOLBins would be only a little of little bit safer. :)
The attacks via LOLBins can hardly do any harm. Even if something can be exploited, the LOLBins can be used to download/drop the payload (EXE, DLL, script, etc.) and execute it. But, the execution will mostly fail due to SWH / WDAC restrictions. The dangerous LOLBins are those that could bypass WDAC, but these LOLBins are already blocked in WHHLight.

I could add the < Block LOLBins > option similar to that from H_C. I could even block LOLBins only on the account chosen by the user and only with standard rights (it is easy). It would be perfect from the security viewpoint, but many users could use this option to create overkill without sufficient reason.
Anyway, the threat landscape is evolving, so I do not exclude such a possibility in the future.
 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
The Two Accounts Setup is kinda similar to the idea of Sandboxie or ReHIPS. The second account can be understood as the "light sandbox" which requires a password.

Edit.
There are some differences, though.
The classic sandboxes have strong isolation and virtualization but allow running malware. So, the user can be spied on, except if the Internet connection is disabled in the sandbox. In theory, the malware can escape from the sandbox when a highly privileged exploit is applied, but I never heard about such malware in the wild - probably no one bothered to bypass Sandboxie or ReHIPS in that way.

The WHHLight 'sandbox' is a light sandbox. The isolation and "virtualization" is limited (in theory) to processes running with standard rights, but the user can run only safe files. In practice, WHHLight "sandbox" can prevent UAC bypasses, so the problem can arise only with rare (highly privileged) exploits.

There are some other differences like the amount of folders shared with a "non-sandboxed" account (default Admin account), etc.
But, from the viewpoint of the default Admin account, we have the isolation and virtualization expected when using a sandbox.
 
Last edited:

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
Last edited:

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
FSecure detects latest version as this:

Classification​

Category :

Malware
Type :

Other
Platform :

W32
Aliases :

HEUR/APC, Heuristic, Gen:Heur, Gen:Trojan.Heur, Memscan:[variant], Deepscan:generic.malware
Thanks. Could you retest the executables?
I have just installed F-Secure Internet Security ver. 19.1 and it allowed WHHLight 1.0.0.4 (no detection). :unsure:
 
Last edited:

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top