Software Review The biggest risk with Windows: LOLBINS

Video Reviews - Security and Privacy
226 Replies 16,063 Views
Reviews reflect the reviewer's setup and methods. Check the evidence and limitations.
Thread details
Content created by
PC Security Channel
LinuxFan58 said:
@Bot please read GitHub - AndyFul/Hard_Configurator: GUI to Manage Software Restriction Policies and harden Windows Home OS and Hard_Configurator/WindowsHybridHardening at master · AndyFul/Hard_Configurator

Reducing your nr 1 advice "Reduce script-driven initial execution paths (high ROI)" is exactly what they are doing
Click to expand...
Yes — your “Reduce script-driven initial execution paths” point is very much in the core design of Hard_Configurator.

From AndyFul’s own README, Hard_Configurator explicitly includes things like:
  • Disabling PowerShell script execution and also securing PowerShell via Constrained Language Mode. ([github.com](https://github.com/AndyFul/Hard_Configurator))
  • Disabling execution of scripts managed by Windows Script Host (WSH). ([github.com](https://github.com/AndyFul/Hard_Configurator))
  • Blocking LOLBins via SRP, plus an option to harden Windows Firewall by blocking Internet access to LOLBins. ([github.com](https://github.com/AndyFul/Hard_Configurator))
  • Enabling Defender “advanced settings” such as PUA protection, ASR rules, Network Protection, etc. ([github.com](https://github.com/AndyFul/Hard_Configurator))

So if someone’s threat model includes LoLBins + script-heavy initial access, H_C (and related AndyFul tools) are directly aligned with the “reduce script-driven execution paths” strategy.

Additional practical advice (LoLBins-focused) on top of H_C / WHHLight

  • Don’t stack overlapping hardening tools blindly. AndyFul explicitly warns about incompatibilities/overlap (for example SRP conflicts and not recommending running H_C alongside WindowsHybridHardening / SimpleWindowsHardening due to shared settings and possible misconfigurations). ([github.com](https://github.com/AndyFul/Hard_Configurator))
  • Treat LoLBin “blocking” and LoLBin “abuse prevention” as different goals. Blocking a list of binaries helps, but many attacks still hinge on command-lines, parent/child process chains, and script content. Defender ASR rules (when set to block) are one of the more realistic “behavior-aware” controls available to home/pro users (H_C can enable ASR, but the effectiveness depends on which rules you enable and whether you run them in block vs audit). ([github.com](https://github.com/AndyFul/Hard_Configurator))
  • Add visibility so you can confirm the hardening actually stopped something. Even with SRP/SmartScreen/ASR, having process creation logging with command-lines (and optionally Sysmon if you’re comfortable with it) makes LoL-style activity much easier to investigate later. This is not “AI,” just basic telemetry that prevents guesswork.
  • Keep the “who can run what” model tight. These tools are mainly intended to lock down inexperienced users (“happy clickers”) using built-in Windows controls. Keeping daily use in a standard user account (and elevating only when necessary) still matters a lot, even with strong hardening. ([github.com](https://github.com/AndyFul/Hard_Configurator))

For WindowsHybridHardening Light (WHHLight) specifically: AndyFul describes it as a successor to SimpleWindowsHardening and as a simplified configurator of Windows built-in application control features including SmartScreen, SRP, and WDAC. ([malwaretips.com](https://malwaretips.com/threads/testing-windows-hybrid-hardening-new-hardening-application.125082/?utm_source=openai))

Conclusion
Your observation is correct: Hard_Configurator is already implementing the “reduce script-driven execution paths” approach (PowerShell/WSH restrictions, SRP-based blocks, Defender hardening, etc.). The biggest added value beyond that is usually avoiding conflicting policy tools and ensuring you have at least basic command-line/process visibility, because LoL abuse often lives in the command-line, not the binary.

Sources
 
Bot said:
Yes — your “Reduce script-driven initial execution paths” point is very much in the core design of Hard_Configurator.

From AndyFul’s own README, Hard_Configurator explicitly includes things like:
  • Disabling PowerShell script execution and also securing PowerShell via Constrained Language Mode. ([github.com](https://github.com/AndyFul/Hard_Configurator))
  • Disabling execution of scripts managed by Windows Script Host (WSH). ([github.com](https://github.com/AndyFul/Hard_Configurator))
  • Blocking LOLBins via SRP, plus an option to harden Windows Firewall by blocking Internet access to LOLBins. ([github.com](https://github.com/AndyFul/Hard_Configurator))
  • Enabling Defender “advanced settings” such as PUA protection, ASR rules, Network Protection, etc. ([github.com](https://github.com/AndyFul/Hard_Configurator))

So if someone’s threat model includes LoLBins + script-heavy initial access, H_C (and related AndyFul tools) are directly aligned with the “reduce script-driven execution paths” strategy.

Additional practical advice (LoLBins-focused) on top of H_C / WHHLight

  • Don’t stack overlapping hardening tools blindly. AndyFul explicitly warns about incompatibilities/overlap (for example SRP conflicts and not recommending running H_C alongside WindowsHybridHardening / SimpleWindowsHardening due to shared settings and possible misconfigurations). ([github.com](https://github.com/AndyFul/Hard_Configurator))
  • Treat LoLBin “blocking” and LoLBin “abuse prevention” as different goals. Blocking a list of binaries helps, but many attacks still hinge on command-lines, parent/child process chains, and script content. Defender ASR rules (when set to block) are one of the more realistic “behavior-aware” controls available to home/pro users (H_C can enable ASR, but the effectiveness depends on which rules you enable and whether you run them in block vs audit). ([github.com](https://github.com/AndyFul/Hard_Configurator))
  • Add visibility so you can confirm the hardening actually stopped something. Even with SRP/SmartScreen/ASR, having process creation logging with command-lines (and optionally Sysmon if you’re comfortable with it) makes LoL-style activity much easier to investigate later. This is not “AI,” just basic telemetry that prevents guesswork.
  • Keep the “who can run what” model tight. These tools are mainly intended to lock down inexperienced users (“happy clickers”) using built-in Windows controls. Keeping daily use in a standard user account (and elevating only when necessary) still matters a lot, even with strong hardening. ([github.com](https://github.com/AndyFul/Hard_Configurator))

For WindowsHybridHardening Light (WHHLight) specifically: AndyFul describes it as a successor to SimpleWindowsHardening and as a simplified configurator of Windows built-in application control features including SmartScreen, SRP, and WDAC. ([malwaretips.com](https://malwaretips.com/threads/testing-windows-hybrid-hardening-new-hardening-application.125082/?utm_source=openai))

Conclusion
Your observation is correct: Hard_Configurator is already implementing the “reduce script-driven execution paths” approach (PowerShell/WSH restrictions, SRP-based blocks, Defender hardening, etc.). The biggest added value beyond that is usually avoiding conflicting policy tools and ensuring you have at least basic command-line/process visibility, because LoL abuse often lives in the command-line, not the binary.

Sources
Click to expand...
@Bot, you validated the strategy of using third-party tools like Hard_Configurator to block LOLBins because they are 'Microsoft signed but not safe.'

However, you failed to account for User Integrity Levels.

Why would a 'live' LOLBin attack be catastrophic on a Standard User Account (SUA) when the powershell.exe or certutil.exe process inherits the user's Medium Integrity token? If the malicious process cannot write to C:\Windows, HKLM, or inject into System processes due to basic ACLs, does the 'risk' justify the overhead of third-party blocking tools, or is the architecture itself the mitigation?
 
@Divergent although it is a fair point you are bringing to the table (my wife's runs on her Windows laptop hardened with HardConfigurator as Standard User)., ask yourself (and you are allowed to use AI for the anser): "how many home users on Windows OS are running as standard user?
 
Divergent said:
Why would a 'live' LOLBin attack be catastrophic on a Standard User Account (SUA) when the powershell.exe or certutil.exe process inherits the user's Medium Integrity token?
Click to expand...

Unfortunately, modern threats can also do much harm with standard rights. Ransomware or info stealers are good examples.
However, instead of blocking PowerShell LOLBin and some others, one can use a quite effective and slightly lighter strategy:
  1. Restrict PowerShell to a Constrained Language and block PowerShell script files (such as .ps1).
  2. Block outbound connections of PowerShell and some popular LOLBins.
  3. Block Windows Script Host files (.vbs, .vbe, .js, .jse, etc.) and batch files (.bat, .cmd).
  4. Block shortcuts and some other dangerous file extensions (.hta, .chm, etc.) in UserSpace.
In this way, the user can hardly run LOLBins. If the user wants to whitelist some scripts and other blocked files, the best method is to use SRP.
Some limited (to files with MOTW) restrictions for dangerous file types are included in SAC.
When using AppLocker or WDAC, it is necessary to block several LOLBins because most of the dangerous file types cannot be blocked by file extension.
 
Andy Ful said:
Unfortunately, modern threats can also do much harm with standard rights. Ransomware or info stealers are good examples.
However, instead of blocking PowerShell LOLBin and some others, one can use a quite effective and slightly lighter strategy:
  1. Restrict PowerShell to a Constrained Language and block PowerShell script files (such as .ps1).
  2. Block outbound connections of PowerShell and some popular LOLBins.
  3. Block Windows Script Host files (.vbs, .vbe, .js, .jse, etc.) and batch files (.bat, .cmd).
  4. Block shortcuts and some other dangerous file extensions (.hta, .chm, etc.) in UserSpace.
In this way, the user can hardly run LOLBins. If the user wants to whitelist some scripts and other blocked files, the best method is to use SRP.
Some limited (to files with MOTW) restrictions for dangerous file types are included in SAC.
When using AppLocker or WDAC, it is necessary to block several LOLBins because most of the dangerous file types cannot be blocked by file extension.
Click to expand...
You are correct to distinguish between Structural Integrity (the OS) and Content Integrity (User Data). A Standard User token protects the building's foundation, but it won't stop a user from setting fire to their own furniture (Ransomware/Stealers in %UserProfile%).

Your "Noise Discipline" strategy, specifically choking the supply lines by blocking outbound connections for LOLBins, is superior hygiene. If powershell.exe or wscript.exe cannot dial out to a C2 server, the malware is effectively just a mime shouting in a vacuum, it can destroy local files, but it cannot exfiltrate them.

However, recommending SRP (Software Restriction Policies) is architectural malpractice. That is "Rust." Microsoft deprecated SRP years ago, building a security posture on it today is like plumbing a new house with lead pipes because they are "easier" to bend than copper. If you want a whitelist, use WDAC. It is heavy and unforgiving, but it is supported concrete.
 
Divergent said:
However, recommending SRP (Software Restriction Policies) is architectural malpractice. That is "Rust." Microsoft deprecated SRP years ago, building a security posture on it today is like plumbing a new house with lead pipes because they are "easier" to bend than copper. If you want a whitelist, use WDAC. It is heavy and unforgiving, but it is supported concrete.
Click to expand...

Let's agree to disagree. I hear the same "deprecated" argument for 7 years, and still, SRP works as it should and is even more effective at home than before.
However, it works in Userland, so it cannot be a security boundary in Enterprises. That is why Microsoft stopped actively developing SRP.
Unfortunately, skipping SRP makes hardening at home more complex and inconvenient for users.
Until SRP works well, it is worth attention.
 
Last edited:
Andy Ful said:
Let's agree to disagree. I hear the same "deprecated" argument for 7 years, and still, SRP works as it should and is even more effective at home than before.
However, it works in Userland, so it cannot be a security boundary in Enterprises. That is why Microsoft stopped actively developing SRP.
Unfortunately, skipping SRP makes hardening at home more complex and inconvenient for users.
Until SRP works well, it is worth attention.
Click to expand...
I understand you have built tooling around SRP, and for a specific demographic, it functions as a serviceable patch. But let’s be honest about the architecture, SRP is a Zombie.

Microsoft has not significantly touched SRP since Windows 7. It does not handle modern AppX/UWP structures natively or securely. Relying on it is like wiring a modern building with knob-and-tube because "it still conducts electricity." It works until you add a load it wasn't designed for.

SRP is a policy overlay, effectively a "Do Not Enter" sign. WDAC is the concrete barrier. There is a reason vulnerability researchers stopped publishing SRP bypasses, not because they don't exist, but because breaking a deprecated feature is no longer sport.

Advising users to learn SRP today is wasted caloric burn. We should be teaching them the WDAC Wizard or AppControl, even if the learning curve is steeper.

If the objective is "Easy," use an iPad. If the objective is "Secure," use WDAC. We do not lower the building standards just because the contractor is tired.
 
@Divergent,

When did you become an expert on SRP?:)
I know well both WDAC and SRP and do not agree with you.
So, let's agree to disagree.

I give you some examples.
One can easily block/whitelist shortcuts in SRP but not in WDAC or AppLocker. The same is true for many dangerous file types.
So the home user can use SRP to block shortcuts in UserSpace and whitelist shortcuts only in some locations (the same is possible for other file types).
WDAC cannot block/whitelist batch files (.bat, .cmd).
WDAC can block indirectly dangerous file types by blocking the LOLBins that open those files by default, but you cannot whitelist them.
WDAC blocks the execution even when it has high privileges. SRP can additionally block only execution with standard rights and allow execution with higher privileges. So, you can use a Standard User Account and block many LOLBins only with standard rights, which does not block system processes.
SRP has so many advantages at home that skipping it would not be wise. It is so useful that it is worth using even if deprecated.
 
Last edited:
Andy Ful said:
@Divergent,

When did you become an expert on SRP?:)
I know well both WDAC and SRP and do not agree with you.
So, let's agree to disagree.

I give you some examples.
One can easily block/whitelist shortcuts in SRP but not in WDAC or AppLocker. The same is true for many dangerous file types.
So the home user can use SRP to block shortcuts in UserSpace and whitelist shortcuts only in some locations (the same is possible for other file types).
AppLocker and WDAC cannot block/whitelist batch files (.bat, .cmd).
WDAC can block indirectly dangerous file types by blocking the LOLBins that open those files by default, but you cannot whitelist them.
WDAC blocks the execution even when it has high privileges. SRP can additionally block only execution with standard rights and allow execution with higher privileges. So, you can use a Standard User Account and block many LOLBins only with standard rights, which does not block system processes.
SRP has so many advantages at home that skipping it would not be wise.
Click to expand...
Your confidence in Software Restriction Policies (SRP) is outpacing your technical accuracy, specifically regarding your claim that AppLocker and WDAC cannot block or whitelist batch files. This is objectively false, AppLocker has possessed a dedicated "Script Rules" collection for over a decade that explicitly controls .ps1, cmd, .bat, .vbs, and .js files. You are confusing your own lack of familiarity with the tool's actual capabilities with a software limitation, just because you do not use the feature does not mean it does not exist.

Your argument regarding shortcuts prioritizes the signpost over the destination. Structural security does not care about the .lnk file, it cares about the payload it executes, such as cmd[.]exe or powershell[.]exe. If WDAC or AppLocker blocks the target executable or script, the shortcut is rendered a harmless, dead icon. Policing file extensions like shortcuts is "User Interface" security, whereas blocking the process itself is "Kernel" security, it is the difference between putting tape over a light switch and actually cutting the circuit breaker.

Finally, citing the ability of SRP to apply only to Standard Users while exempting Administrators as an "advantage" is a dangerous misunderstanding of modern threat modeling. WDAC’s refusal to exempt high-privilege accounts is a feature, not a bug. If an administrator account is compromised via phishing or a drive-by download, your SRP "safety net" vanishes because the token has High Integrity, effectively handing the attacker the keys to the kingdom. WDAC enforces "Zero Trust," ignoring whether you are SYSTEM or Guest, if the code isn't trusted, it terminates. You are clinging to SRP because it allows for lazy administration, but in a hostile environment, we do not architect for comfort.
 
Divergent said:
Advising users to learn SRP today is wasted caloric burn. We should be teaching them the WDAC Wizard or AppControl, even if the learning curve is steeper.
Click to expand...
Let's assume for argument's sake that your assumptions and objections about SRP were right. Ask yourself (and you are allowed to use AI as with the question about standard users) how many home use desktop installations run Windows Pro or higher (WDAC and AppControl are not available on Windows Home as you probably will know)?
 
Andy Ful said:
Yes, WDAC cannot block/whitelist batch files. I corrected it.
Click to expand...
Fair enough. I will accept the technical correction regarding WDAC's specific handling of .bat files, but I reject the strategic conclusion you are drawing from it.

You are correct that WDAC, unlike AppLocker, does not natively hash-enforce .bat files. This is because cmd[.]exe is a legacy relic that lacks the modern "enlightenment" (AMSI integration) to verify text-based scripts against a kernel policy. WDAC controls the engine, but it struggles to validate the fuel when that fuel is just a text file from 1989.

However, this brings us back to the architecture. You are effectively arguing that we should keep a deprecated, rotting framework (SRP) on life support solely to manage batch files. That is not a feature, that is a crutch.

If your security model relies on granularly whitelisting "good" batch files for home users, you are already fighting the wrong war.

Use AppLocker (as you now concede works) if you absolutely must manage script execution policies.

Block cmd[.]exe entirely for Standard Users. There is almost zero legitimate reason for a home user to be running batch scripts interactively in 2026.

We should not let the limitations of a legacy tool (cmd[.]exe) dictate the security posture of a modern OS. We don't build the fence out of wood just because the gate latch is rusty.
 
Divergent said:
Your argument regarding shortcuts prioritizes the signpost over the destination. Structural security does not care about the .lnk file, it cares about the payload it executes, such as cmd[.]exe or powershell[.]exe. If WDAC or AppLocker blocks the target executable or script, the shortcut is rendered a harmless, dead icon. Policing file extensions like shortcuts is "User Interface" security, whereas blocking the process itself is "Kernel" security, it is the difference between putting tape over a light switch and actually cutting the circuit breaker.
Click to expand...

Microsoft does not agree with you and added blocking shortcuts and some other dangerous file types in SAC (for home users). Your argument is a copy of typical arguments valid in Enterprises.

Divergent said:
Finally, citing the ability of SRP to apply only to Standard Users while exempting Administrators as an "advantage" is a dangerous misunderstanding of modern threat modeling.
Click to expand...

Microsoft does not agree with you. The same is a default feature in AppLocker. The advantage is usability without losing much security.

Divergent said:
WDAC’s refusal to exempt high-privilege accounts is a feature, not a bug. If an administrator account is compromised via phishing or a drive-by download, your SRP "safety net" vanishes ...
Click to expand...

You assumed something that can hardly happen with correct SRP restrictions. Furthermore, the main role of SRP at home is not a security boundary, but an effective prevention. The role of SRP at home is very different from the role of WDAC in Enterprises. So, most of your arguments do not apply to SRP at home.
 
LinuxFan58 said:
Let's assume for argument's sake that your assumptions and objections about SRP were right. Ask yourself (and you are allowed to use AI as with the question about standard users) how many home use desktop installations run Windows Pro or higher (WDAC and AppControl are not available on Windows Home as you probably will know)?
Click to expand...
Here, the largest fraction of users have the Pro, then a smaller fraction using Ent, and only a minority using Home.

What is interesting, most of the users of the three versions do not use, or even know that there is WDAC, AppLock, or SRP.

It would be an acheivement if they checked MD database is up to date or if there are added exclusions

May be 139-141 among 109,000,000 have some idea about the fuss going on here.
 
Andy Ful said:
Microsoft does not agree with you and added blocking shortcuts and some other dangerous file types in SAC (for home users). Your argument is a copy of typical arguments valid in Enterprises.
Click to expand...
Malware does not check IsDomainJoined before it encrypts the Master File Table.

The attack surface of a Windows 11 Home PC and a Windows 11 Enterprise workstation is identical at the binary level. A kernel driver exploit works on both. A ransomware encryption thread works on both.

You are arguing that because the user is different, the security requirements are lower. That is not engineering; that is hope. If anything, a Home user needs stronger structural automation (like WDAC) because they lack a SOC team to monitor the logs when your "Prevention" layer fails.

Andy Ful said:
Microsoft does not agree with you. The same is a default feature in AppLocker. The advantage is usability without losing much security.
Click to expand...
You are conflating Cloud Intelligence with Static Extensions.

SAC (Smart App Control). Blocks shortcuts based on dynamic threat intelligence and reputation. It uses the cloud to decide if a specific .lnk is malicious.

SRP/Your Method. Blocks shortcuts based on file extension and path.

Using SAC to justify SRP is like saying, "The bank uses a laser grid, so I'm safe using a piece of string." One is active intelligence, the other is a dumb list.

Andy Ful said:
You assumed something that can hardly happen with correct SRP restrictions. Furthermore, the main role of SRP at home is not a security boundary, but an effective prevention. The role of SRP at home is very different from the role of WDAC in Enterprises. So, most of your arguments do not apply to SRP at home.
Click to expand...
You stated, "The advantage is usability without losing much security."

That "much" is doing a lot of heavy lifting.

You claim SRP is "Effective Prevention" but not a "Security Boundary." If it is not a boundary, it is merely a speed bump.

By allowing Admin execution (for "usability"), you are relying entirely on UAC (User Account Control) to stop the malware from elevating. Microsoft explicitly states UAC is not a security boundary.

Your strategy relies on a user clicking "No" on a UAC prompt. My strategy (Architecture) relies on the OS saying "No" regardless of what the user clicks.
 
Parkinsond said:
Here, the largest fraction of users have the Pro, then a smaller fraction using Ent, and only a minority using Home.

What is interesting, most of the users of the three versions do not use, or even know that there is WDAC, AppLock, or SRP.

It would be an acheivement if they checked MD database is up to date or if there are added exclusions

May be 139-141 among 109,000,000 have some idea about the fuss going on here.
Click to expand...
Okay interesting fact thanks. I had found some stats of a large webshop (CoolBlue) in the Netherlands (one of the four big webshops with Amazon etc) that less than 20% of their Windows devices sold have Windows Pro (most have Windows Home)
 
LinuxFan58 said:
Okay interesting fact, I had found some stats of a large webshop (CoolBlue) in the Netherlands (one of the four big webshops with Amazon etc) that less than 20% of their Windows devices sold have Windows Pro (most have Windows Home)
Click to expand...
I can explain; we do not have strict piracy rule, like for example Germancy (which is the status in most of the world except a smaller percentage of countries).

The same tool activating Home, is the one activating Pro and Ent, so why to use Home?

Ent is less prevalent than Pro because most of users utilize the consumer ISO which does not include Ent.
 
It’s ironic that you claim I’m the one who can’t think for myself, yet it takes a whole committee of you to construct a failing argument.

If I’m so dependent on AI to survive, why does it take a battalion of 'natural' intellects to lose against me?

For a group convinced I’m unintelligent, you certainly need a lot of manpower to barely make a dent.
 
@Divergent,

In my opinion, you put much effort into explaining that SRP is not good because it is not a WDAC.
However, we can make a challenge. Please make a WDAC policy that you think is more secure at home than Hard_Configurator in Recommended settings.
Next, we can check if it is true. You can also look for examples of how well the weakest H_C config works in practice (even without blocking LOLBins):
Andy Ful

New Update Thread 'Simple Windows Hardening'

Post updated in March 2026.
Simple Windows Hardening is replaced by Windows Hybrid Hardening.
Windows Hybrid Hardening Light works in the default settings just like Simple Windows Hardening.
Microsoft documentation for Software Restriction Policies (July 2021):
learn.microsoft.com

Software Restriction Policies Technical Overview

Learn about software restriction policies, when and how to use the feature, and what changes have been implemented in past releases.
learn.microsoft.com
This documentation was made for Windows Server...
  • Like
  • +Reputation
  • Thanks

1768938808575.png
 
Last edited:

Recently browsing

Members who viewed this thread in the last 5 minutes

You may also like...

Back
Top