Hard_Configurator - Windows Hardening Configurator

[Andy Ful]

Just as an additional security step, that's all.

The ability to blacklist specific files or folders should definitely be there, IMO, whether it's for new LOLBins that are not on the list yet, for admin/restrictive purposes or for some other reason.

The H_C is intended to work without producing serious incompatibilities. Blocking new LOLBins should be done with caution and "just in case" is not a sufficient reason to do it.
It is easy to block something, but it is usually not easy to find out later that it causes hidden incompatibilities. The H_C setup with the current list of well tested LOLBins is already too complex.
Anyway, If any LOLBin which is not included in H_C will become popular in the wild I will try to add it, except if this would produce some serious issues.​

 

[nadis]

I agree that blocking stuff can break things, but I don't think this is or should be your personal responsibility, at least not to such a great extent. I think it's good enough if you show users a warning when they're about to do these changes (frankly, they should already know this before installing H_C).
Besides, you released Simple Windows Hardening. Why not let H_C be a tool for power users? We're not talking about giving people nuclear weapons, at worst if something breaks they'll have to restore the system from a backup. So it's not the end of the world and I think some users would rather risk a temporary system malfunction than being exposed to potential vulnerabilities.
Right now, in case of LOLBins, a user has to wait for you to: 1)notice a new LOLBin 2)determine that it's popular enough in the wild 3)determine that blocking it doesn't cause issues and 4)release an update to H_C. A lot of time can pass while the user is potentially exposed.

But as I said, it's not just about LOLBins. A user might want to block a specific program or path for other reasons, like parental control or some other administrative reason, blocking a file/folder inside a whitelisted portable app folder and so on.
To me the main proposition of H_C was basically a nicer UI for SRP and Windows Firewall. The import/export features are a godsent, for example. But if it can't effectively be used for basic SRP functionality I might start looking elsewhere. The fact that it can't block dlls anymore is already a bit disappointing.

Anyway, just my thoughts. The fact that SWH exists is IMO the biggest argument for having more SRP options in H_C.

 

[Andy Ful]

@nadis,

I understand your point, because I thought so a few years ago before I was starting the H_C project. This way can be followed when using something like Simple Software Restriction Policies.
The problem is that H_C was not created to be "a nicer GUI for basic SRP functionality". It would be much easier for me to do such a GUI, but in fact, the H_C project was intended for something more ambitious. It tries to adopt some Windows built-in features to make consistent and safe security in the home environment. These features were made by Microsoft for enterprises, not for home users. So, the security model of H_C is different as compared to enterprises.

In enterprises, one has to assume that:

1. It is impossible to fully prevent malware and the security has to fight the malware executed in the system.
2. The system cannot be highly restricted because of remote administration, automation via scripts (macros), shortcuts, etc.
3. The software/system installations are not frequent and limited in number. The updates are usually made manually/remotely by Administrators.

The H_C security model in the home environment (Recommended Settings on Windows 8+) assumes that :

1. It is possible in practice to prevent malware by highly restricting users' actions on the user level (medium integrity processes), and restricting only some Windows features on the administrative level.
2. The remote administration can be disabled and automation via scripts (macros) can be highly restricted. The shortcuts can be blocked except for some typical locations (like Desktop or Start Menu).
   The malware cannot use the command-line in the usual way (no access to LOLBins)
3. The software/system auto-updates should be allowed without disabling the protection. The user should have the possibility to install safely popular (legal) applications without disabling the protection.
4. The security cannot be too complex, because the "home administrator" does not have much time. For the same reason, the security model should avoid producing hidden incompatibilities.
5. After applying the restrictions, the average user should use the computer without problems, with occasional help from "home administrator".

The above security model is actually a base for H_C. That is why I had to skip DLL protection and I am not eager to add any possible LOLBin. I added some other setting profiles which are more or less compatible with this security model, especially with points 4 and 5. Of course, when choosing a more restrictive profile one has to sacrifice more time to manage it or use fewer desktop applications.
I know well the complexity of Unrestricted/Disallowed SRP rules. Using such complex rules is often hard to understand - some combinations work in an unusual way and some are buggy. Furthermore, the rules can work differently with some other SRP settings (Enforcement, Default Security Level) - if one is not the SRP expert then it is easy to apply rules that do not work as intended. So, I use these combinations that work well and are easy to understand. The Unrestricted/Disallowed rules applied in H_C settings are very complex - if you would add your own Disallowed rule, then in many cases, it would be altered by the H_C rules (and would not work as intended).

 

[mkoundo]

Hi Andy, i'd be interested to hear your opinion on H_C blocking the abuse of windows update as per this article:

Windows Update can be abused to execute malicious programs

The Windows Update client has just been added to the list of living-off-the-land binaries (LoLBins) attackers can use to execute malicious code on Windows systems.

www.bleepingcomputer.com

thanks

 

[Andy Ful]

Hi Andy, i'd be interested to hear your opinion on H_C blocking the abuse of windows update as per this article:

Windows Update can be abused to execute malicious programs

The Windows Update client has just been added to the list of living-off-the-land binaries (LoLBins) attackers can use to execute malicious code on Windows systems.

www.bleepingcomputer.com

thanks

Such LOLBins are used by scripting, shortcuts, or when the attacker uses a file with active content (like .chm). So, it is not a problem for H_C settings. These methods and generally LOLBins can be a problem for AVs on default settings that allow running scripts, shortcuts, and files with active content. They have to block the malware on the second or later infection chain. This is much harder, because there are many more things to consider.
It is similar to the fight against the virus (like COVID-19). If you can quickly isolate the first infected person, then you will avoid much effort to recognize and quarantine tenths of other people on the infection tree.
Of course, the H_C setup is not magic, but only a smart-default-deny. One has to sacrifice some convenience for security.

Edit1.
As it was mentioned in the article, this LOLBin can be used to bypass such strong enterprise security as WD Application Control (WDAC), if not properly configured. Unfortunately, WDAC (and Applocker) cannot block shortcuts and files with active content (like .chm, etc.). So, one has to can block LOLBins by adding custom rules.
The same is true for most setups based on SRP, because users commonly allow shortcuts (and DLLs).

Edit2.
I tested this LOLBin against WDAC. Although it can be bypassed in some WDAC settings, this will not happen if WDAC is properly configured even without blocking any LOLBin. Simply, WDAC default-deny setup will block the malicious DLL (Id 3077) like in the below example:

"Code Integrity determined that a process (\Device\HarddiskVolume2\Windows\System32\wuauclt.exe) attempted to load \Device\HarddiskVolume4\Users\reflective_dll.x64.dll that did not meet the Enterprise signing level requirements or violated code integrity policy (Policy ID:{a244370e-44c9-4c06-b551-f6016e563076})."

 

[Andy Ful]

I have made an update to Windows 10 20H2 on MAX settings (H_C Windows_10_All_ON profile, ConfigureDefender MAX, FirewallHardening all LOLBins). The update has been installed without a problem.
The restrictions are still here after the update and work as usual.
Also, the Windows Defender Application Control policies survived the update.

 

[SeriousHoax]

Hi @Andy Ful, do you know anything about this types of blocks? There are a lot of this every single day. All LOLBins are blocked by Firewall Hardening.

 

[Andy Ful]

Hi @Andy Ful, do you know anything about this types of blocks? There are a lot of this every single day. All LOLBins are blocked by Firewall Hardening.
View attachment 247912

They are not blocked by FirewallHardening, except when you have manually added svchost.exe to the Blocklist.
Do you have svchost.exe on the FirewallHardening Blocklist?

 

[ForgottenSeer 85179]

They are not blocked by FirewallHardening, except when you have manually added svchost.exe to the Blocklist.
Do you have svchost.exe on the FirewallHardening Blocklist?

I also get the same blocked entries but i don't block LOLBins nor add svchost.exe to blacklist.

 

[Andy Ful]

I also get the same blocked entries but i don't block LOLBins nor add svchost.exe to blacklist.

So, they are not related to FirewallHardening. Do you use some network filtering applications or extensions?

 

[ForgottenSeer 85179]

So, they are not related to FirewallHardening. Do you use some network filtering applications?

Nope. Only your recommend Firewall rules. Windows firewall is otherwise not modified and run on default mode.

 

[Andy Ful]

Nope. Only your recommend Firewall rules. Windows firewall is otherwise not modified and run on default mode.

Something (probably a service) blocks the outbound Internet connection to these entries.

 

[oldschool]

Regardless of the (eventually known) cause, it's like untangling a ball of spaghettini. These types of issues convinced me to stick with a simple security setup and leave WF as is, with manually-input rules as needed.

 

[Andy Ful]

Anyway, it is easy to check if FirewallHardening is involved. Just remove all entries from the Blocklist and restart the computer. Next, use the FirewallHardening Log to see if these svchost related blocks disappeared. FirewallHardening does not do anything else than adding/removing firewall rules. No rules, no blocking by FirewallHardening.
The Log shows all blocked outbound connections visible to Windows Firewall, no matter if FirewallHardening blocks something or not.

Edit.
I think that some outbound connections can be blocked without Windows Firewall rules, for example by the router. Such events will be also visible in the Log, because the packets are not sent.

 

[SeriousHoax]

except when you have manually added svchost.exe to the Blocklist

No, svchost is not added. I think internet connection won't work properly if svchost is blocked.

Do you use some network filtering applications or extensions?

I'm not using any either.
I do have some telemetry related and other stuff disabled via O&O shutup10 but none are Windows Firewall related. Since even @security123 having this blocks who doesn't use O&O shutup10, surely it's not to be blamed.

I think that some outbound connections can be blocked without Windows Firewall rules, for example by the router. Such events will be also visible in the Log, because the packets are not sent.

Maybe you're right. It's not Firewall hardening rather Windows Firewall itself probably. I have 5-6 smartphones connected on the same network via wifi, is it possible that it's something related to that? My firewall is currently set to Public network mode. Can this have any impact too?
Btw, if I use ESET then I get some blocks like this but I these are all inbound blocks not outbound.

I forgot to check the DNS Clinet block details before uninstalling ESET but others are inbound blocks.
Btw, no problem whatsoever with any internet connectivity. Everything works fine.

 

[Andy Ful]

Something blocks Adguard DNS, so maybe it is worth inspecting.

 

[SeriousHoax]

Something blocks Adguard DNS, so maybe it is worth inspecting.

Hmm that part is weird. But like I said, everything works without any problem. Anyway, I have now removed all Firewall hardening rules, restarted the system. Let's see what happens.

 

[ForgottenSeer 85179]

Anyway, it is easy to check if FirewallHardening is involved. Just remove all entries from the Blocklist and restart the computer. Next, use the FirewallHardening Log to see if these svchost related blocks disappeared.

I do this now and will check if new entries are added or not. As written in your manual

The Event Log can store the entries from several hours (usually 24 hours).

so i need to wait as turn off/ on the log feature doesn't clean old entries. Maybe this can be implemated ?

 

[Andy Ful]

I do this now and will check if new entries are added or not. As written in your manual

so i need to wait as turn off/ on the log feature doesn't clean old entries. Maybe this can be implemated ?

You do not need to turn off the Log (it will not help). The 24 hours limitation follows from the fact that on Windows 10 there are many inbound connection events that can wipe out other events in the Windows Security Log.

5152(F) The Windows Filtering Platform blocked a packet. - Windows 10

Describes security event 5152(F) The Windows Filtering Platform blocked a packet.

docs.microsoft.com

FirewallHardening makes the Security Log twice as bigger as the default Log (MaxSize = 0x01400000) and this is usually OK for surviving the events related to outbound connections for about 24 hours. If you want you can tweak the MaxSize of the log:
HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security
MaxSize = 0x02800000 (change to a bigger value)

When you turn Off Logging, the value is automatically changed to Windows default (MaxSize = 0x01400000).
When you turn ON logging, the value is twice bigger (MaxSize = 0x02800000). So, do not turn OFF/ON Logging if you tweaked MaxSize.

Anyway, you should look at the time moments in the Log when the AdGuard connections were blocked to find the possible correlation with the process which blocks AdGuard.

 

[ForgottenSeer 85179]

Anyway, you should look at the time moments in the Log when the AdGuard connections were blocked to find the possible correlation with the process which blocks AdGuard.

This is only related to SeriousHoax
I don't use AdGuard

Thanks for your great help (again)!