My personal opinion about the biggest risk of LoLBins is that they are Microsoft signed but not safe", so a default deny based on whitelist is useless, you will need some sort of AI (like
@danb offers) to analyse and analyze the commands. Next best is a blacklist based solution like OS Armor or simply using WHHLight or HardConfigirator to block execution og LoLBins for standard users.
@Bot do you have any additional advices?
You’re right about the core problem: many LoLBins are Microsoft-signed and legitimately present on almost every Windows system, so “allow only signed binaries” (or simplistic allowlisting) does not stop living-off-the-land abuse.
That said, “default deny / allowlisting is useless” is a bit too strong — it’s just that it must be done with the right granularity (what runs, from where, by whom, with what child-process behavior), and ideally combined with command-line visibility.
Biggest practical risk of Windows LoLBins
The biggest risk is not that LoLBins exist, but that attackers can:
- Blend into normal admin/tooling activity (harder detection/triage).
- Abuse trusted binaries to execute payloads, download content, run script, or proxy execution (often reducing reliance on dropping obvious “malware.exe”).
- Bypass weak controls (e.g., “block unknown EXEs” while PowerShell/mshta/rundll32/regsvr32 remain fully usable).
This is why LoLBins often show up after initial access (phish/macro/script/exposed service) as the attacker’s “toolchain.”
What actually works (layered controls)
1) Reduce script-driven initial execution paths (high ROI)
Most LoL abuse chains rely on script hosts or scripting features:
- Disable PowerShell v2 (legacy downgrade attacks).
- Use PowerShell Constrained Language Mode where feasible (especially for standard users).
- Disable or restrict Windows Script Host (wscript.exe/cscript.exe) if you don’t need it.
- Be strict about Office spawning child processes (common infection chain).
If you can only harden a few things, hardening scripting is often more impactful than chasing a long LoLBin blacklist.
2) Use Microsoft Defender ASR rules (this is “behavior control” without needing “AI”)
Attack Surface Reduction rules can block many common LoL patterns (Office child process creation, credential theft behaviors, suspicious script behaviors, etc.). This is one of the most practical “command/behavior aware” mitigations available to home/pro users without third-party EDR.
3) Do not only “block LoLBins” — block the dangerous ones, for the right users, with tight scope
Blanket-blocking lots of Windows binaries can cause breakage. A safer approach is:
- Restrict high-abuse LoLBins for standard users where possible (examples often include mshta.exe, wscript.exe/cscript.exe, regsvr32.exe, rundll32.exe, certutil.exe, bitsadmin.exe), but test carefully.
- Prefer rules that are user-scope aware (standard user vs admin) and/or context aware (allowed only for admins, allowed only from system locations, etc.).
Tools like Hard_Configurator / Simple Windows Hardening can be reasonable “policy wrappers” for this style of control, but the real win is understanding what they changed and validating it doesn’t break your workflows.
4) Logging/visibility: command-line is where LoL lives
Even without “AI,” you can make LoL activity much easier to spot by enabling:
- Process creation auditing with command line (Windows Security Event ID 4688 with command line enabled).
- Optional: Sysmon (if you’re comfortable with it) for richer process/network telemetry.
- Centralizing logs (even simple Windows Event Forwarding to one box) if you manage multiple PCs.
If you can’t see command-lines, you’re blind to the “how” of LoL.
5) WDAC/AppLocker note (important correction)
WDAC/allowlisting is not inherently useless against LoLBins. It becomes weak only when configured as “allow anything signed by Microsoft.” More robust approaches include:
- Explicitly controlling scripting engines and installers.
- Using carefully scoped allow rules (publisher + product + version ranges) rather than “all Microsoft.”
- Controlling what untrusted locations can execute (user-writable paths are a major issue).
It’s more work, but it’s not a dead end.
Practical “next best” for most users
If the goal is real risk reduction with minimal complexity:
- Turn on strong Microsoft Defender protections (including ASR where possible).
- Harden/limit scripting (PowerShell/WSH) for standard users.
- Add targeted blocks for the most abused LoLBins you do not need (test for breakage).
- Enable command-line process logging so LoL behavior is visible when something goes wrong.
Bottom line: the biggest risk is LoLBins being a stealthy, flexible post-compromise toolkit; the best defenses are script-chain hardening + ASR/behavior rules + command-line visibility, with selective LoLBin restrictions rather than broad “block everything” lists.
