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

[ForgottenSeer 97327]

Hi @Andy Ful

or anyone who might know, is it possible, or will it be possible in the future, to use wildcards for Paths under WDAC-> Whitelist option? I wasn't able to add a Path rule with wildcards.

View attachment 279421

When I remember correctly (now also on Linux) when I used WDAC on Windows10 PRO, your are only allowed 1 wildcard in a folder path and it has to be placed at the lowest hierarchical level. The wildcard is only used to iterate its subfolders. More important you also have to disable the Runtime FilePath Rule Protection option. When Andy has not enabled the latter it will be impossible to use wildcards.

 

[Andy Ful]

Just playing around with the new WHHLight ver. 1.0.0.4
WDAC enabled ON. I see no longer blocks for some legit applications what are blocked with the previous version WWH_Light 1.00.4 (Whitelisted folders are the same)
@Andy Ful My question what is the difference compared to when WDAC off ? Guess it's misunderstanding from me

If < WDAC > = ON, then any file (EXE, DLL, MSI) executed in UserSpace is blocked if it is not recognized as safe by ISG.
ISG ignores files from SystemSpace and files in whitelisted folders.

ISG can get the file reputation from three sources:

1. For files with MOTW, the file reputation comes from SmartScreen. If the file is an installer (drops other files) the installed files get the reputation from that installer.
2. For files installed via point 1, the reputation comes from the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) written to the file. This attribute is lost when you copy the file to another location, but is kept when the file is moved to another location (but it must be on NTFS drive).
3. For other files, ISG uses AI (and probably some AllowList). Microsoft does not share any useful information about it.

 

[Andy Ful]

Hi @Andy Ful

or anyone who might know, is it possible, or will it be possible in the future, to use wildcards for Paths under WDAC-> Whitelist option? I wasn't able to add a Path rule with wildcards.

View attachment 279421

Microsoft does not allow wildcards inside paths on Windows 10. But, Wildcards can be fully implemented on Windows 11. I did not do it (for now), because I want to keep one application for both Windows 10 and 11.

 

[wat0114]

Microsoft does not allow wildcards inside paths on Windows 10. But, Wildcards can be fully implemented on Windows 11. I did not do it (for now), because I want to keep one application for both Windows 10 and 11.

Okay thanks Andy!

 

[Digmor Crusher]

There is no WHH folder on the Desktop (and never been). The posts made by NormanF in this thread and on Wilders Security thread are incorrect.
The "icon" on the Desktop is a shortcut. If you click on it then the real folder "C:\ProgramData\WindowsHybridHardening_Tools" is opened in Explorer. If you remove the "icon", only the shortcut will be deleted, and not the real folder in %ProgramData%.

I am not sure why you would want to keep the WHH Light executable on the Desktop instead of a shortcut.
Anyway, If you drag the WHH application from the default folder to the desktop, then the file will be moved from the WHH folder to the Desktop, and allowed by WDAC.
But, do not copy the file. Microsoft made ISG in a way that the copy does not inherit the positive reputation (only moving the file does).

Thanks Andy, I don't really need to keep the executable on the desktop. In that folder or icon as you call it, there are other tools I don't use such as Configure Defender, so I just want something on the desktop for easy access to the program that I am using which is WHH. I just deleted the folder (icon) on the desktop and dragged the icon from Program Data to my desktop. I suppose I could have just as easily used the shortcut icon from the desktop icon as well.

 

[Andy Ful]

... I just want something on the desktop for easy access to the program that I am using which is WHH.

Understand. The best method would be to make a shortcut of WHHLight (in the WHHLight folder) and drag that shortcut to the Desktop.

 

[Digmor Crusher]

Understand. The best method would be to make a shortcut of WHHLight (in the WHHLight folder) and drag that shortcut to the Desktop.

Will do.

 

[wat0114]

Hi @Andy Ful

is this a Windows limitation or a limitation of WHH-Light?



It happened when I tried to add the following userspace folder to WDAC Whitelist:

C:\Users\myname\AppData\Roaming\Mozilla\Firefox\Profiles\fvdukp8y.default-release-1662297472611\gmp-widevinecdm

Resolved with truncating it to:

C:\Users\myname\AppData\Roaming\Mozilla\Firefox

If it's the latter mentioned limitation, can it be fixed? Thanks!
Btw, yes I'm running as Standard user, thus I don't have AppData folders whitelisted for the account.

 

[Andy Ful]

Hi @Andy Ful

is this a Windows limitation or a limitation of WHH-Light?

View attachment 279447

Yes. You can also see this limitation on the WDAC Whitelist window

In that particular case, the available folder path can be "C:\Users\myname\AppData\Roaming\Mozilla\Firefox\Profiles" (or shorter).

 

[wat0114]

Yes. You can also see this limitation on the WDAC Whitelist window

View attachment 279448

In that particular case, the available folder path can be "C:\Users\myname\AppData\Roaming\Mozilla\Firefox\Profiles" (or shorter).

I had not even noticed the limitation on the WDAC whitelist window Thanks again, Andy!

 

[ForgottenSeer 97327]

@Andy Ful

Two user WHH-light setup (explained by you) is running flawlessly on my wife's laptop. An update of a signed program which installed in users folders went well.

 

[Back3]

Just installed W11 23H2. Checked WHHL. It asked me to restart the computer. It runs OK.

 

[ForgottenSeer 97327]

Just installed W11 23H2. Checked WHHL. It asked me to restart the computer. It runs OK.

Same on wife's laptop with super solid WHH light two user setup

 

[Andy Ful]

Currently, I am testing ISG against real malware. I have learned something new. I downloaded/executed several malicious & signed samples (EXE files). SmartScreen blocked them. So, I manually bypassed the SmartScreen alerts via "Run anyway" option. I suspected ISG could allow some samples, but they were blocked anyway.

There were also some signed samples (from MalwareBazaar) that were benign and were allowed by SmartScreen. I inspected them, and it turned out that those samples were used in the DLL hijacking attacks (via search order or side loading). For example:

Analysis 99a2352694fa6b96e7a1baf1112cc53a3d7b9c52aa0a1571c08b89f88544b4e5.exe (MD5: 95382D214090471F770C4420C8E45912) No threats detected - Interactive analysis ANY.RUN

Interactive malware hunting service. Live testing of most type of threats in any environments. No installation and no waiting necessary.

app.any.run

Edit.
Fortunately, the current version of ISG is not vulnerable to DLL hijacking.

 

[Digmor Crusher]

Hi Andy, any reason you can see why SWH is blocking Windscribe? I did whitelist it and it still shows some kind of block. Before I whitelisted it Windscribe was taking 15 -20 seconds to connect to a server, after whitelisting it was back to normal and connecting almost immediately.

 

[Back3]

Hi Andy, any reason you can see why SWH is blocking Windscribe? I did whitelist it and it still shows some kind of block. Before I whitelisted it Windscribe was taking 15 -20 seconds to connect to a server, after whitelisting it was back to normal and connecting almost immediately.
View attachment 279677

I was also having connection issues with Windscribe. I used WireGuard protocol. Furthermore, I checked SWH and no block. I changed to IKEV2 protocol and solved my problems. From 20 seconds to 2 seconds.

 

[Andy Ful]

Hi Andy, any reason you can see why SWH is blocking Windscribe? I did whitelist it and it still shows some kind of block. Before I whitelisted it Windscribe was taking 15 -20 seconds to connect to a server, after whitelisting it was back to normal and connecting almost immediately.
View attachment 279677

In the log, we can see: "WDAC blocked events for EXE and DLL files". So it is not the SWH Log but the WDAC Log.
The WDAC Log in WHHLight can show events blocked by Windows native policies and events blocked by WHHLight WDAC policy. In the second case we can see the entry:
PolicyName = UserSpace Lock
The example posted by you is related to the WHHLight WDAC policy (UserSpace Lock).

The block is caused by Microsoft's recommendations, for LOLBins that can bypass WDAC. Those LOLBins are blocked in WHHLight WDAC policy.
One of the blocked LOLBins is WMIC.exe.
Windscribe whitelisting is not necessary and cannot remove this block.

I think that the long time needed to connect the server was unrelated to your whitelisting. You can check it by removing from the WDAC Whitelist any of the possible paths:
C:\Windows\System32\wbem\WMIC.exe
C::\Program Files\Windscribe\WindscribeService.exe

 

[Andy Ful]

After some inspection of the windscribeservice.log it turned out that the below command is blocked:
AA_COMMAND_WMIC_GET_CONFIG_ERROR_CODE, cmd=C:\Windows\system32\wbem\wmic.exe path win32_networkadapter where description="Windscribe VPN" get ConfigManagerErrorCode

Except for this diagnostic CmdLine, the Windscribe works as usual. Anyway, it would be OK to ask the developer if blocking WMIC.exe can impact Windscribe in daily work.
I am not sure if Windscribe is used in businesses. If so, then the developer should consider the possibility of using WMI without WMIC.exe.

 

[Andy Ful]

Currently, I am testing ISG against real malware. I have learned something new. I downloaded/executed several malicious & signed samples (EXE files). SmartScreen blocked them. So, I manually bypassed the SmartScreen alerts via "Run anyway" option. I suspected ISG could allow some samples, but they were blocked anyway.

I should add some comments related to "Run By SmartScreen" because it works differently as compared to normal file execution. It is implemented in WHHLight to allow bypassing WDAC ISG by the user, when installing standalone installers. There are some cases when SmartScreen is not triggered and the benign installer is blocked by ISG.
In the default WHHLight settings, after running the installer (or any EXE/MSI file) that is blocked by ISG and SmartScreen, the user can still choose "Run anyway" in the SmartScreen alert, and then the installer will be ignored by ISG. This behavior is not recommended for happy clickers and children. One can prevent bypassing ISG via "Run By SmartScreen" by setting:
< SmartScreen Block > = ON

 

[Digmor Crusher]

In the log, we can see: "WDAC blocked events for EXE and DLL files". So it is not the SWH Log but the WDAC Log.
The WDAC Log in WHHLight can show events blocked by Windows native policies and events blocked by WHHLight WDAC policy. In the second case we can see the entry:
PolicyName = UserSpace Lock
The example posted by you is related to the WHHLight WDAC policy (UserSpace Lock).

The block is caused by Microsoft's recommendations, for LOLBins that can bypass WDAC. Those LOLBins are blocked in WHHLight WDAC policy.
One of the blocked LOLBins is WMIC.exe.
Windscribe whitelisting is not necessary and cannot remove this block.

I think that the long time needed to connect the server was unrelated to your whitelisting. You can check it by removing from the WDAC Whitelist any of the possible paths:
C:\Windows\System32\wbem\WMIC.exe
C::\Program Files\Windscribe\WindscribeService.exe

Yes, sorry I misspoke, it wasn't a SWH block. Also, it seems that after removing it from the whitelist that it connects just as fast as before, so not sure why it was so slow connecting before. I'll keep an eye on it to see if I can figure anything out. Thanks.