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

[Andy Ful]

...
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.

 

[Digmor Crusher]

Looking forward to the finished product.

 

[Andy Ful]

I plan to publish the new version in November (together with some videos) and test it for one or two months.

 

[Azazel]

RunBySmartscreen still appears on old windows 10 menu but not the new windows 11 menu.

 

[Andy Ful]

RunBySmartscreen still appears on old windows 10 menu but not the new windows 11 menu.

Use "Show more options" or SHIFT + right-click.

 

[tidyloop]

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]

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:

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

... 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...

malwaretips.com

 

[tidyloop]

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]

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:

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).

 

[Andy Ful]

This method and its variation (based on DLL search order) discouraged me from enabling ISG in WDAC. ISG could have stopped the attack before Microsoft added MOTW support for ISO files. Fortunately, the issue has been recently corrected by Microsoft.

https://malwaretips.com/threads/qua...ng-to-fly-under-the-radar.126597/post-1062144
https://www.uptycs.com/blog/quasar-rat

 

[ForgottenSeer 97327]

that is why I have SWH-like SRP with all sponsors blocked combined with WDAC-ISG and Avast free hardened on my wife's laptop

 

[Andy Ful]

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.

What do you think about such a setup?

 

[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)

 

[Andy Ful]

@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]

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.

 

[Andy Ful]

WHHLight ver. 1.0.0.4

https://github.com/AndyFul/Hard_Configurator/raw/master/WindowsHybridHardening/WHHLight_Package_1004.exe

This version uses a different WDAC policy with enabled ISG, so the application will show < WDAC > = OFF.
If the user wants WDAC enabled, it is necessary to switch ON the < WDAC > option.
If the user wants WDAC disabled, it is recommended to switch the < WDAC > option ON, and next switch it OFF.

I prepared four short videos to show how WHHLight works:

 

[Digmor Crusher]

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

 

[Digmor Crusher]

Cyberlock blocks it as well.

 

[Andy Ful]

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).

 

[Digmor Crusher]

Tried again, no detection this time, I sent them the file, I wonder if they fixed the false positive this fast?

Cyberlock still complains,I suppose because its not signed?

Thanks.