Hard_Configurator - Windows Hardening Configurator

[Andy Ful]

Yes please give the user always the choice to use SRP (maybe off be default).

On my win 11 MS decided to disable SAC. SAC was for me the reason to try 11 at all (so I'm quite disappointed).
So if there is no SRP and MS disables SAC for you you got "nothing" otherwise.

It is improbable that Microsoft will remove both SAC and SRP. But in such a case, one can use AppLocker (via LightWindowsHardening) instead of SRP:
https://malwaretips.com/threads/microsoft-defender-config-max-smart-app-control.120267/post-1021020

 

[Andy Ful]

It is worth remembering, that any H_C setup can significantly decrease the chances of infection when the malware can bypass the AV protection. So, there is no need to focus on maximal protection. Simply, adjust the setup to the level you can live with. Some people can live with the H_C on MAX settings. But, this does not follow from their extremal patience and security paranoia. They use a simple software setup and do not install new applications. My wife is a good example. I have to look at her computer once a few months (a few hours per year).
On the contrary, my son uses SWH because he installs many applications and games.

 

[Freki123]

It is improbable that Microsoft will remove both SAC and SRP.

I wasn't worried about MS removing SRP I was worried you might remove the SRP option (in HC) for Win 11 if SAC was on.
So if HC would offer no SRP (for noobs) and Win 11 later turns SAC off it would be no fun. Hope I expressed it better this time

 

[Andy Ful]

I wasn't worried about MS removing SRP I was worried you might remove the SRP option (in HC) for Win 11 if SAC was on.

 

[ForgottenSeer 98186]

using SRP is clearly beneficial at home. But this usually requires a home administrator.

SRP is particularly beneficial in a home with adults and children who do not practice safe digital behaviors.

there is no need to focus on maximal protection.

The maximum protection possible via hardening (includes SRP) is a proactive effort to prevent initial compromise at the user level and also to thwart further compromise and network pivoting (laterally [to other workstations] or vertically [to servers]).

I do not want to debate the following protection strategies as there are corner cases and exceptions where they would not be suitable. I only mention them generally.

The single most effective way to keep users safe (both home and enterprise) is to prevent them from downloading and executing files from the internet. Just blocking the downloaded.exe file type instantaneously provides an exponential increase in security. Home users can accomplish this on Windows 10\11 very simply by setting Windows to only permit installs from the Microsoft Store.

For "users that want to use stuff" the simple act of disabling the most commonly abused sponsors (top 10 or 15), again, instantaneously provides an exponential increase in user security. This protection model probabilistically breaks the kill-chain at the system level. This is as true for the home user as it is for the enterprise user.

When it comes to native Microsoft security there is one extremely important point that is almost never discussed - that it provides flexibility to conform to virtually ANY home use or enterprise use case. No other security provides as much flexibility and adaptability as Microsoft native security. Even the home user who is inclined to do so, can find a Microsoft security configuration that is suitable for their "digital personality" - their wants, needs, expectations, tolerances, temperament, habits, etc. These traits affect security more than anything else.

Security enthusiasts who lean towards the maximum protection end of the spectrum do it more "just because they can" or, in their mind, "if it is possible, then it should be defended against." They understand the differences between "What Ifs" and what is statistically likely to happen. I've seen this protection strategy work very well for users without any complaints about it causing a usability burden. This will not be the case most users who have a different level of understanding, and therefore, expectations.

It is improbable that Microsoft will remove both SAC and SRP

On the enterprise side SRP will definitely not be removed. SRP is too enmeshed into enterprise protection. Microsoft will likely keep SRP around for a lot longer than PowerShell version 2.0. Another factor against Microsoft removing or somehow permanently disabling it is the fact that Microsoft is not good at offering transition solutions. So if it gets rid of SRP, it is up to the client to figure out how to make the transition. Anybody that has worked in enterprise knows that just about any kind of transition is tough.

WDAC is effective security. There is no denying it. But WDAC adoption in the greater enterprise space has been a mixed-bag. Adoption by SMBs is even less. This is because WDAC development has been a serpentine and circuitous journey beginning almost 7+ years ago starting with Device Guard. For many years Microsoft was trying to figure out what its latest-and-greatest default-deny protections were going to be. WDAC evolved from Application Guard, which itself evolved from Device Guard, but the development has been inconsistent over those years. Only recently has Microsoft made a definitive commitment to WDAC. All of this has affected adoption for the time being.

Introducing Windows Defender Application Control - Microsoft Security Blog

Application control is a crucial line of defense for protecting enterprises given today’s threat landscape, and it has an inherent advantage over traditional antivirus solutions.

www.microsoft.com

Microsoft also has its own competing overarching agenda - which is to get as many enterprises and SMBs to adopt Azure. With Azure Microsoft can offer the latest-and-greatest security trend with is "adaptive security." "Adaptive Application Control" does not use WDAC. Not only that, Azure really is the "complete package" where commercial and government can pick-and-choose from antivirus to EDR to SIEM to network security to compliance. WDAC is possible within this infrastructure, but Microsoft does not market it in its cloud and adaptive security solutions.

These facts only provide a partial explanation as to why native Microsoft security is the way it is for them.

Security Control: Apply adaptive application control

As part of our recent Microsoft Defender for Cloud Blog Series, we are diving into the different controls within MDC’s Secure Score.  In this post we will be discussing the control of “Apply Adaptive Application control”.  This security control contains up to 7 recommendations, depending on...

techcommunity.microsoft.com

one can use AppLocker (via LightWindowsHardening) instead of SRP:
https://malwaretips.com/threads/microsoft-defender-config-max-smart-app-control.120267/post-1021020

This is a very good solution @Andy Ful .

They use a simple software setup and do not install new applications.

Users of this type will likely never be compromised, even if they run default Windows Home for decades.

 

[oldschool]

On my win 11 MS decided to disable SAC. SAC was for me the reason to try 11 at all (so I'm quite disappointed).

You could have enabled it manually when it was eval mode as I did at the suggestion of @SpyNetGirl

 

[ForgottenSeer 97327]

@Andy Ful

Maybe you could include in your enhanced setting of sponsor blocks Microsoft Recommended and Windows-S? So you keep the three levels of sponsor blocking (most common scriptors, enhanced and all LoLBins)?

Thx

max

 

[Andy Ful]

@Andy Ful

Maybe you could include in your enhanced setting of sponsor blocks Microsoft Recommended and Windows-S? So you keep the three levels of sponsor blocking (most common scriptors, enhanced and all LoLBins)?

Such a BlockList would be relatively long (over 60 entries):
AddInProcess, AddInProcess32, AddInUtil, Aspnet_Compiler, bash, bitsadmin, cdb, cmd, cmstp, csc, csi, dbghost, dbgsvd, dnx, finger, forfiles, fsi, FsiAnyCpu, hh, ieexec, iexplore, ilasm, InfDefaultInstall, InstallUtil, jsc, kd, kill, lxrun, Microsoft.Workflow.Compiler, msbuild, msdt, mshta, ntkd, ntsd, pnputil, powershell, PowerShellCustomHost, powershell_ise, PresentationHost, rcsi, reg, regasm, regini, regsvr32, RegSvcs, runas, rundll32, RunScriptHelper, sc, schtasks, SyncAppvPublishingServer, TextTransform, vbc, verclsid, VisualUiaVerifyNative, wfc, windbg, wmic, wsl, wslconfig, wslhost, xwizard.

The list is longer than for WDAC, because H_C does not block DLLs (but blocks the files that could contain the CmdLines to run DLLs via LOLBins). If you use a setup that does not prevent running CmdLines, then you must also add the LOLBins that can run DLLs.

I prefer the setup that can prevent access to CmdLine (as much as possible). This can be done via SRP in H_C and cannot be done via AppLocker or WDAC. That is why I included in enhanced settings only some popular LOLBins (probably unnecessary).
Anyway, I can put some info about the extended set of LOLBins in the H_C manual.

 

[ForgottenSeer 98186]

Such a BlockList would be relatively long (over 60 entries):


AddInProcess, AddInProcess32, AddInUtil, Aspnet_Compiler, bash, bitsadmin, cdb, cmd, cmstp, csc, csi, dbghost, dbgsvd, dnx, finger, forfiles, fsi, FsiAnyCpu, hh, ieexec, iexplore, ilasm, InfDefaultInstall, InstallUtil, jsc, kd, kill, lxrun, Microsoft.Workflow.Compiler, msbuild, msdt, mshta, ntkd, ntsd, pnputil, powershell, PowerShellCustomHost, powershell_ise, PresentationHost, rcsi, reg, regasm, regini, regsvr32, RegSvcs, runas, rundll32, RunScriptHelper, sc, schtasks, SyncAppvPublishingServer, TextTransform, vbc, verclsid, VisualUiaVerifyNative, wfc, windbg, wmic, wsl, wslconfig, wslhost, xwizard.

Blocking the entire list above will cause very few problems for a typical home user. For the type of person that is inclined to use H_C they should be able to resolve whatever issue they might run into. Actually, except for runonce to permit tray icons to launch, a person can block the entire 250+ extended LOLBin block list and have few sporadic issues.

On a typical home user setup of Windows, I can block that entire list you give above and not run into a problem for years. Only if I use some enterprise software do I have to enable something like the compiler csc.exe - and that is a rare allow exception.

If a user has to create allow exceptions for things such as wmic, cmstp, windbg, MSBuild, PowerShellCustomHost, ntkd, etc - then that user is definitely doing stuff at a level where they should be able to figure out any problems and create any needed allow exceptions with ease.

Not having access to Control Panel (rundll32 blocked) while protection is enabled is not a valid usability problem. An MT H_C user knows how to turn the block policy for rundll32 ON\OFF.

I'd say it is more important that a user running an Administrative privileged Windows account is best served by installing H_C with the -p switch. Afterall, the main point is to protect also against a post-exploit environment. The standard H_C install method might or might not provide sufficient protection if an exploit leads to localsystem RCE. It depends upon the post-exploit kill chain.

I could care less about users that want to install stuff without having to anything blocked or want to download and run game DLL cheats. Any user that is going to employ SRP will have to learn the procedure of ON\OFF and how to create allow exceptions from log block events. If they cannot master those very basic skills, then they should not use ANY default deny. They are much better served by depending upon a quality default allow solution.

Anyway, I can put some info about the extended set of LOLBins in the H_C manual.

Blocking typically downloaded file types and blocking the top 20 LOLBins provides much security - more or less along the concept of Simple Software Restriction Policy.

How far a user wants to take system lockdown is a matter of personal choice.

 

[ForgottenSeer 97327]

@Andy Ful

To overcome maintaining preset lists of sponsors/LoLBins, you could also add an option to add a block rule. You only need an extra switch (allow/block) in the current option to allow a program.

At the moment I use H_C to create SoftwRestrictionPolicies on Windows11 Home, Next I add allow rules for the LoLBins not in the block sponsor lists. I then export the registry key for SRP and move those added LoLBins from the allow subkey to the block subkey with a notepad. Then I deïnstall H_C and run the exported H_C registry file to re-create the H_C generated rules with extra LoLBins moved from allow to block.

I have not checked on H_C for a long time. As @Oerlink says a typical home user has little or no use cases for needing the blocked LolBins.

 

[Andy Ful]

@Andy Ful

To overcome maintaining preset lists of sponsors/LoLBins, you could also add an option to add a block rule. You only need an extra switch (allow/block) in the current option to allow a program.

There are more pros (for me and most users) when LOLBins are added by the developer.
Which of your LOLBins are not on the H_C blocklist?

 

[ForgottenSeer 98186]

I have not checked on H_C for a long time. As @Oerlink says a typical home user has little or no use cases for needing the blocked LolBins.

That's not what I said.

Unmanaged home users are the security group that need extensive LOLBin blocking and other system hardening by default. In fact, that group should get a heavily restricted version of Windows.

Unmanaged home users are substantially incapable of making sound security choices and then managing their security. The broad, sweeping generalization is true = most users just run with default Windows Defender on Windows, do not use AV on MacOS, do not use AV on their phone, and they don't know what Linux is.

A home user who lives on their phone and playing XBox 24/7, saying "I know I need to install AV" is not security literate. Tech knowledge is NOT security knowledge or savvy. Just look at how users cannot handle security alerts. When presented with an alert, their reaction or decision is to select "Allow" when they are busy, and a toss-of-the-coin when they actually read and try to understand what is said in the alert.

To put things into perspective, most users want to be entertained. They're very superficially aware of the need for security. They assume or falsely expect that they are protected on any device with any software installed or run.

 

[Andy Ful]

Here we can see a different approach to LOLBins between me and @Oerlink.
In my opinion, blocking LOLBins at home on Windows 10+ can add only a little more security, compared to other H_C features. My concern is that many LOLBins were never properly tested in the home environment. There are many people who use niche or old software/firmware. Microsoft still keeps these LOLBins, so it is reasonable to suspect that they can be (rarely) used by some software, diagnostic tools, etc.

So, blocking LOLBins at home with H_C on Windows 10+ can be used optionally by very experienced users, who want to maximize protection. The system is already well-protected without blocking LOLBins.
Blocking LOLBins in enterprises is another story (highly recommendable).

People who are not convinced can look at examples (taken from the SWH thread):

Nobelium: Q&A - Simple Windows Hardening
Zloader: Q&A - Simple Windows Hardening
Log4Shell: Q&A - Simple Windows Hardening
GootLoader: Q&A - Simple Windows Hardening
Emotet: Q&A - Simple Windows Hardening
Warzone and AgentTesla: Q&A - Simple Windows Hardening
AsyncRAT: Q&A - Simple Windows Hardening
Shuckworm RATS: Q&A - Simple Windows Hardening
Muddywater: Q&A - Simple Windows Hardening
SolarMarker: Q&A - Simple Windows Hardening
BazarLoader: Q&A - Simple Windows Hardening
PPAM attack: Q&A - Simple Windows Hardening
HTML ---> ISO ---> scripts: Q&A - Simple Windows Hardening
Hermetic Wiper: Q&A - Simple Windows Hardening
Asylum Ambuscade spear-phishing: Q&A - Simple Windows Hardening
Quakbot: Q&A - Simple Windows Hardening
Vidar infostealer: Q&A - Simple Windows Hardening (RunBySmartscreen) <----- attack blocked by H_C
Emotet: Q&A - Simple Windows Hardening
IceID (Cobalt Strike, Quantum ransomware): Q&A - Simple Windows Hardening
Fileless RAT (CHM file): Q&A - Simple Windows Hardening
SocGholish: Q&A - Simple Windows Hardening
TA551 phishing campaigns: Q&A - Simple Windows Hardening
GuLoader: Q&A - Simple Windows Hardening (RunBySmartscreen) <----- attack blocked by H_C
Follina exploit: Q&A - Simple Windows Hardening
AstraLocker 2.0: Q&A - Simple Windows Hardening
Raspberry Robin worm: Q&A - Simple Windows Hardening
Magniber (CPL variant): Q&A - Simple Windows Hardening
Batloader (MSI PowerShellScriptInline custom action): Question - Simple Windows Hardening

 

[ForgottenSeer 98186]

My concern is that many LOLBins were never properly tested in the home environment. There are many people who use niche or old software/firmware. Microsoft still keeps these LOLBins, so it is reasonable to suspect that they can be (rarely) used by some software, diagnostic tools, etc.

I am more or less in agreement with you except on the "dangers" of blocking LOLBins or creating block process policies generally.

My argument is that, Windows as Microsoft ships it, is completely unsuitable for unmanaged home users. A fully configured SRP along with other hardening will prevent users from doing all the stuff that gets them into trouble. That statement is conceptual and time-proven. However, it is all undone by the dinosaur thinking that any user should be able to do what they want on a system. In that paradigm, locked devices is a non-starter.

LOLBin blocking for home user systems has been tested by both Microsoft and for thousands of enterprises that issue take-home laptops and in-office devices. Enterprises use a lot more obscure, old, niche software. I know from managing literally tens of thousands of devices that breakages are rare. I have never encountered a situation where the breakage could not be fixed within a matter of minutes.

If a home user is using old or niche software, then it is assumed that they have the wherewithal to read logs and create allow exceptions. If they cannot perform these basic functions, then they should not be using SRP.

The main reason Microsoft does not implement more strict protections for unmanaged home users is clear - it does not want to deal with "users that want to use stuff" who will only complain when the protection Microsoft provides prevents them from doing what they want. It is very profitable for Microsoft to adopt this policy towards home users. Microsoft makes billions off of default allow because that is what most home users want.

For the vast majority of home users, simply blocking the execution of commonly downloaded file types (e.g. .exe and .msi, scripts, and known abused file types by malware campaigns) greatly increases their security) There is no absolute need to block LOLBins - however, blocking the most commonly abused LOLBins (top 5 or 10) is not going to create excessive problems. Blocking LOLBins is only to protect a post-exploit environment. What sense does it make to block PowerShell.exe if PowerShell scripts are blocked by policy? - It only matters if the system is exploited. What sense does it make to create a block firewall rule for PowerShell? - It matters if the system is exploited.

If a user downloads an undetected ransomware sample that is either, for example, an .exe or a .vbs file, what does it matter if LOLBins are blocked whenever the user cannot execute either the .exe or the .vbs file? The system is protected by simple targeted blocking of common malware file types or downloaders. Again, LOLBins blocking matters mostly in a post-exploit system.

The whole point of SRP is to prevent users from downloading and executing stuff - that includes installs. If the user does not understand, embrace and practice that protection model, then they should not be using SRP. SRP serves no purpose for a home user if they understand BLOCK\ALLOW but they disable SRP to allow installs as they desire. The protection model requires the user to assess the risks and apply appropriate decision making.

Most home users with a general understanding of Windows security ("I know I need to install AV."), should stay away from default deny or system hardening and instead use a quality antivirus or internet security suite. A certain temperament, motivation, perseverance, knowledge, experience and expectations are required for a user to be OK with default deny. So, in short, default deny requires some work on the part of the user. The amount of work varies with the type of default deny.

Microsoft should not be giving a generic OS image intended for enterprise from day 1 to unmanaged home users. In fact, for those users who do not need Windows, they should be using a Chromebook.

Full Transparency: I do not use SRP of any kind. I do not mess with WDAC. SAC is set to OFF. I do block wscript\cscript with the registry tweak intended by Microsoft. I allow PowerShell scripts (both local and remote) to execute. I do not harden my systems. I use Office without macros. Currently I use F-Secure and WIndows Defender. I set Windows to block installs from non-Microsoft Store sources. I am not paranoid and do not have doubts that some unknown, hidden nefarious things are happening on my system. I do not worry about protecting localhost. I don't worry that a file I downloaded is FUD ransomware or infostealer. Instead my efforts are directed to protecting my financial assets on the service provider side. Protecting authentication and authorization in various ways in another priority.

 

[oldschool]

People who are not convinced can look at examples (taken from the SWH thread):

And people, especially those who don't test malware and are convinced, may want to broaden their knowledge about malware vectors, etc.

 

[Andy Ful]

For the vast majority of home users, simply blocking the execution of commonly downloaded file types (e.g. .exe and .msi, scripts, and known abused file types by malware campaigns) greatly increases their security) There is no absolute need to block LOLBins - however, blocking the most commonly abused LOLBins (top 5 or 10) is not going to create excessive problems. Blocking LOLBins is only to protect a post-exploit environment.

What sense does it make to block PowerShell.exe if PowerShell scripts are blocked by policy? - It only matters if the system is exploited. What sense does it make to create a block firewall rule for PowerShell? - It matters if the system is exploited.

It is mostly true when using H_C.

 

[oldschool]

What effect does configuring powershell.exe and powershell_ise.exe with Code Integrity Guard in Exploit Protection? I believe @Max90 uses this in his config.

 

[Zero Knowledge]

What effect does configuring powershell.exe and powershell_ise.exe with Code Integrity Guard in Exploit Protection? I believe @Max90 uses this in his config.

Good question. Not sure with integrity guard but I know in Group Policy you can configure PowerShell to only run signed PowerShell scripts and you can turn on logging of PowerShell events.

H_C user here. Not sure I need any further protection than H_C and Group Policy?

 

[ForgottenSeer 98186]

What effect does configuring powershell.exe and powershell_ise.exe with Code Integrity Guard in Exploit Protection? I believe @Max90 uses this in his config.

Nothing.

 

[ForgottenSeer 97327]

That's not what I said.

Unmanaged home users are the security group that need extensive LOLBin blocking and other system hardening by default.

Fun fact 1: from a behavioral viewpoint home users are always unmanaged (when you refer to home user as the people using it at home), it is like saying a strainer leaks (a strainer which does not leak by definition is not a strainer anymore).

Fun fact 2: from a technical viewpoint when you refer to the PC of a home user (in your quote above), a PC which would have extensive LoLBin blocking and system hardening, technically that PC would not be unmanaged anymore.

Fun fact 3: using grandiloquent language while trying to convince (other) people that your 'best practice' is the best 'best practice', actually is not a best practice itself

"a typical home user has little or no use cases for needing the blocked LolBins".

I know you like to disagree with people, so we, your friends at MT, give you the attention and importance you deserve, but read again: little or no use cases for needing the blocked LilBins in other words 95% of the home users don't need the programs in the LoLBin list. It is true that it is not exactly your quote. I added "little or no use", because there might be some corner cases where people need them.