Andy Ful

Level 63
Content Creator
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.​


New Member
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.
  • Like
Reactions: Protomartyr

Andy Ful

Level 63
Content Creator

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).
Last edited:

Andy Ful

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

thanks (y)
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.:)

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

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})."
Last edited: