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

[Andy Ful]

There will be no stand-alone SWH, rather SWH-like settings are included in WHH if I understand correctly.

Yes. The SWH switch in WHH (Light or full version) is related to the default settings in the Simple Windows Hardening ver. 2.1.1.1 (published in July 2023).
When the user runs WHH for the first time, the application works as default SWH (other WHH switches are OFF).

 

[Andy Ful]

@Andy Ful
...
1. Allow Microsoft + ISG (ISG is sort of similar to SAC)
2. Explicit allow rules for
a) Program Files
b Program files (x86)
c) Users\Admin\Apdata
d) Users\Admin\AppData\Local\temp
3. Microsoft advised block Rules for User space and kernel
4. SWH (SRP blocking risky file extensions and allowing exe, msi. tmp)
5. fall back to Audit mode when a driver fails to load
6. Exclude dynamic code and scripts (I told you so )
...

Yes. This can be an interesting setup. Let's name it shortly as SWH + ISG. I will show that:

SWH + ISG ~ SWH + ConfigureDefender (Max settings).

• Both can be bypassed via DLL hijacking (files downloaded from the Internet).
• The first can block DLL hijacking via USB drives.
• The second can block EXE malware dropped to user Appdata (reputation-prevalence ASR rule).
• Both can be bypassed when the EXE or DLL is loaded dynamically.
• The first can block the post-exploitation attacks when DLLs are run via LOLBins, but most of these attacks can be prevented by SWH.
  The second config can prevent most such attacks by SWH, or ASR rules related to MS Office.
• The second will block the installation of malicious and vulnerable drivers via the ASR rule (the first can block vulnerable drivers).
• The first will block malware even without an Internet connection (can be important in businesses).
• Other differences are very rare in the wild. Many attacks will be prevented by SWH.

It is worth mentioning, that WDAC ISG and ConfigureDefender work when Defender is the main AV. Furthermore, two ASR rules (for USB and reputation-prevalence rule) use ISG for EXE files (without WDAC policy). The main advantage of ISG over ASR rules is that ISG can block also DLLs.

From the comparison, it follows that both configurations can cover mostly the same attack surface (with some advantage of the second in the home environment). If we remove the user AppData from the WDAC Whitelist, then there can be a small advantage of the first config.

As I noted in my earlier post, this kind of setup can be easily configured by running WHH without custom changes and setting ConfigureDefender to MAX.

Edit.
The SWH + ISG setup with the whitelisted user AppData folder will produce a smaller number of false positives, especially for software auto-updates.
This can be partially solved in the second setup by setting the reputation-prevalence ASR rule to WARN.

 

[ForgottenSeer 97327]

Andy I tried WHH but could you answer four questions below?

It does not, because WHHLight is not a default deny, but a smart-default deny similar to ISG.

1. What smart mechanism is similar to ISG?
2. As far as I can see you allow execution in folders often used used for installing software. Is that correct?

It is not true. The holes would be important while only using the WDAC restrictions. The WHHLight settings + tools included in the package make these holes negligible at home.

3. As far as I understand, users have to select "User space lock" to remove the allows for often used installation folders (to close the protection holes you leave open for ease of use). Is that correct?
4. Do you also close the 'allow dynamic code hole" when the user selects "User space lock"?

 

[Andy Ful]

Andy I tried WHH but could you answer four questions below?

1. What smart mechanism is similar to ISG?

EXE files from the Internet (MOTW attached) are checked by WDAC ISG only via SmartScreen. If the EXE file has no MOTW, then WDAC ISG uses AI in the cloud. So for EXE files downloaded from the Internet, the WDAC ISG works as RunBySmartscreen.
The ISG AI produces far more false positives compared to SmartScreen.

2. As far as I can see you allow execution in folders often used used for installing software. Is that correct?

Yes. These folders are the same as in your config, with the addition of %ProgramData%. I noticed that some game launchers can use it.

3. As far as I understand, users have to select "User space lock" to remove the allows for often used installation folders (to close the protection holes you leave open for ease of use). Is that correct?

To remove the folder from the WDAC Whitelist, the user must use the < Whitelist > (blue) button.

4. Do you also close the 'allow dynamic code hole" when the user selects "User space lock"?

I have forced this option, but it will be removed in the next version.

 

[ForgottenSeer 97327]

EXE files from the Internet (MOTW attached) are checked by WDAC ISG only via SmartScreen. If the EXE file has no MOTW, then WDAC ISG uses AI in the cloud. So for EXE files downloaded from the internet, the WDAC ISG works as RunBySmartscreen.
The ISG AI produces far more false positives compared to SmartScreen.

When something is dropped without the MOTW it will install without any protection of WDAC, is that correct?

Did you know that smartscreen also tells ISG and SAC to allow stuf when Smartscreen considers this safe? So how would ISG or SAC produce more false positives when an executable was installed using smartscreen compared with your smart solution using the same smartscreen approach?

I have forced this option, but it will be removed in the next version

Are you aware that amateur red hackers often used GitHub and Visual Studio binaries to evade the MOTW? Most really nasty malware does not use regular software to evade MOTW detection anyway. Are you sure you are not underestimating the achilles heel holes (by relying on MOTW and excluding dynamic code)?

 

[Andy Ful]

When something is dropped without the MOTW it will install without any protection of WDAC, is that correct?

No. It will be blocked, except for whitelisted folders.

Did you know that smartscreen also tells ISG and SAC to allow stuf when Smartscreen considers this safe? So how would ISG or SAC produce more false positives when an executable was installed using smartscreen compared with your smart solution using the same smartscreen approach?

When the user runs the EXE file, WDAC ISG does not use SmartScreen for all files, but only for some of them (files with MOTW). The "Run By SmartScreen" always uses SmartScreen.
For example, if you run the file from the (FAT32) USB drive, then WDAC ISG will not use SmartScreen but AI (more false positives). If you do the same in WHHLight (WDAC ON), you must use "Run By SmartScreen" and the file will be checked by SmartScreen.
SAC works differently - it can produce fewer false positives than SmartScreen.

Are you aware that in amateur red hackers often used GitHub and Visual Studio binaries to evade the MOTW. Most really nasty malware does not use regular software to evade MOTW detection anyway. Are you sure you are not underestimating the achilles heel (relying on MOTW and excluding dynamic code)?

Yes, I noticed this 7 years ago. That is why I implemented "Install By SmartScreen" and "Run By SmartScreen" in my applications. They automatically add the MOTW to EXE, MSI, and some other file types. In WHHLight (WDAC ON) the user is forced to run files from not-whitelisted locations via "Run By SmartScreen". The software auto-updates and exploits will run EXE files without "Run By SmartScreen" and will be blocked (except for whitelisted folders).

 

[ForgottenSeer 97327]

1. No. It will be blocked, except for whitelisted folders.



2. When the user runs the EXE file, WDAC ISG does not use SmartScreen for all files, but only for some of them (files with MOTW). The "Run By SmartScreen" always uses SmartScreen.
For example, if you run the file from the (FAT32) USB drive, then WDAC ISG will not use SmartScreen but AI (more false positives). If you do the same in WHHLight (WDAC ON), you must use "Run By SmartScreen" and the file will be checked by SmartScreen.
SAC works differently - it can produce fewer false positives than SmartScreen.



3. Yes, I noticed this 7 years ago. That is why I implemented "Install By SmartScreen" and "Run By SmartScreen" in my applications. They automatically add the MOTW to EXE, MSI, and some other file types. In WHHLight (WDAC ON) the user is forced to run files from not-whitelisted locations via "Run By SmartScreen". The software auto-updates and exploits will run EXE files without "Run By SmartScreen" and will be blocked (except for whitelisted folders).

These answers trigger questions, because you seem to evade direct answers:

1. NO except except for whitelisted folders means YES it allows everything in whitelisted folders, correct?

2. Do I understand you correctly that using Run by Smartscreen with WHH-version of WDAC and Run by Smartscreen using WDAC-ISG, the smartscreen works the same (trying to compare apples with apples)?

3. Yes, I got a YES

___________

About your comment on using Run By Smartscreen. I have three additional questions:
4. How do you force to use "Run By Smartscreen"?
5. I have read some posts about side loading using mising DLLs in the known DLL list which even Smartscreen missed. So I am unsure whether that Run By smartScreen is a fool proof solution for 'normal' DLLs. How Does Smartscreen protecs from side loading DLL's when you exclude dotNet DLL's from WDAC blocking?
6. In case of dropped DLL's, I fail to understand how run by smartscreen would protect the user when software updates from whitelisted folders using the dropped DLL's? That is the whole point of DLL side loading and hijacking, let regular (whitelisted) software run it?

 

[Andy Ful]

These answers trigger questions, because you seem to evade direct answers:

1. NO except except for whitelisted folders means YES it allows everything in whitelisted folders, correct?

Yes.

2. Do I understand you correctly that using Run by Smartscreen with WHH-vrsion of WDAC and Run by Smartscreen using WDAC-ISG, the smartscreen works the same (comparing apples with apples)?

"Run By SmartScreen" works the same, but in WDAC-ISG the user is not forced to use it.

About your comment on using Run By Smartscreen. I have three additional questions:
4. How do you force to use "Run By Smartscreen"?

By applying WDAC which blocks EXE and MSI files by default. If the user wants to run them, this can be safely done via the right-click Explorer context menu by choosing "Run By SmartScreen".

5. I have read some posts about side loading using mising DLLs in the known DLL list which even Smartscreen missed. So I am unsure whether that Run By smartScreen is a fool proof solution for 'normal' DLLs. How Does Smartscreen protecs from side loading DLL's when you exclude dotNet DLL's from WDAC blocking?

Before executing the EXE or MSI file, RunBySmartscreen copies the file to another location, so the EXE cannot find the DLLs.

That is the whole point of DLL side loading and hijacking, let regular (whitelisted) software run it?

Most of the attacks at home are of a different kind. They use a single EXE file vulnerable to DLL hijacking and a hidden DLL - the files are contained in an archive or disk image (ISO, IMG, VHD, VHDX) downloaded from the Internet or USB drive. The DLL is usually a modified system DLL (like version.dll) - it is unrelated to the installation files. The EXE can be often seen in Explorer as a document or picture. When the user opens the file, the hidden DLL is loaded and executed.
For example:

Need Advice - Testing DLL Search Order Hijacking against security features.

The DLL Search Order Hijacking is a well known (but not common) vector of attack. It is often performed via a vulnerable Microsoft EXE file or EXE signed by the well known reputable vendor. A popular way of exploiting this vulnerability is based on loading by the vulnerable EXE, one of the...

malwaretips.com

Need Advice - Testing DLL Search Order Hijacking against security features.

The DLL Search Order Hijacking is a well known (but not common) vector of attack. It is often performed via a vulnerable Microsoft EXE file or EXE signed by the well known reputable vendor. A popular way of exploiting this vulnerability is based on loading by the vulnerable EXE, one of the...

malwaretips.com

 

[ForgottenSeer 97327]

@Andy Ful We are getting there

YES

Second one

Run By SmartScreen" works the same, but in WDAC-ISG the user is not forced to use it.

I count that as YES number three

By applying WDAC which blocks EXE and MSI files by default. If the user wants to run them, this can be safely done via the right-click Explorer context menu by choosing "Run By SmartScreen".

My last three questions:
How do you run MSI elevated? Is that through "Install by Smartscreen"? (I remember seeing both Run by Smartscreen and Install by Smartscreen)
Does Run By Admin have the same effect (installing it in whitelisted Admin AppData Temp)?
Are you removing the "Run By Admin"?

 

[Andy Ful]

@Andy Ful

My last three questions:
How do you run MSI elevated?

MSI will ask for the elevation via UAC prompt.

Is that through "Install by Smartscreen"? (I remember seeing both Run by Smartscreen and Install by Smartscreen)
Does Run By Admin have the same effect (installing it in whitelisted Admin AppData Temp)?
Are you removing the "Run By Admin"?

Is "Run By Admin" = "Run as administrator" from the Explorer context menu?
If so then using "Run as administrator" gives the same effect in WHHLight as running the file normally via the left mouse-click.
SWH in WHHLight works with SRP PolicyScope = High (all users are blocked including Administrators).
WDAC in WHHLight also blocks all users, including Administrators.

 

[ForgottenSeer 97327]

If so then using "Run as administrator" gives the same effect in WHHLight as running the file normally via the left mouse-click.

Meaning it will be blocked?

 

[Andy Ful]

Meaning it will be blocked?

If it is blocked normally then it will be blocked also with "Run as administrator", otherwise it is allowed.

 

[ForgottenSeer 97327]

it took some time to pinpoint a yes from a no, but thanks for the answers

 

[Andy Ful]

it took some time to pinpoint a yes from a no, but thanks for the answers

You cannot count it as a simple "Yes". In WHHLight (WDAC ON), the files in UserSpace can be allowed by adding them to SystemSpace (ACL file permissions are changed) or by whitelisting. My post only confirmed that executing via "Run as administrator" cannot help to run the file.

 

[Victor M]

Hi @Andy Ful ,

I have trouble with WHH WDAC ON and making whitelist for NordVPN. Can you help?

 

[Andy Ful]

Hi @Andy Ful ,

I have trouble with WHH WDAC ON and making whitelist for NordVPN. Can you help?

NordVPN loads dynamically the Nord.Wrapper.dll, which is blocked by WDAC dynamic code trust verification. For this moment, nothing can be done except for switching OFF the WDAC. I plan to publish the new WHHLight version at the end of September, which will solve the problem of blocking dynamic code.

 

[silversurfer]

NordVPN loads dynamically the Nord.Wrapper.dll, which is blocked by WDAC dynamic code trust verification. For this moment, nothing can be done except for switching OFF the WDAC. I plan to publish the new WHHLight version at the end of September, which will solve the problem of blocking dynamic code.

You may could tell us how does your WHHL work to solve blocks by WDAC dynamic code trust verification, just a simple option to disable? whitelisting doesn't help in this case?

 

[Andy Ful]

You may could tell us how does your WHHL work to solve blocks by WDAC dynamic code trust verification, just a simple option to disable? whitelisting doesn't help in this case?

Currently, only disabling WDAC can help. In the new version, I will skip the WDAC option that forces dynamic trust verification.

 

[Andy Ful]

WindowsHybridHardeningLight ver. 1.0.0.2:

https://github.com/AndyFul/Hard_Configurator/raw/master/Simple%20Windows%20Hardening/WHHLight_Package_1002.exe

Removed the blocks related to the name collision with blocked LOLBins and dynamic code trust.

 

[silversurfer]

Just to inform, all my reported "blocks" are solved now since new WHHL version 1.0.0.2