New Update Simple Windows Hardening

[EASTER]

Late to the party but so far caught on quickly SWH- If i missed it someplace feel free to say so but how do we clear the Blocked Files Log- I mean is there a Clear Logs button i missed or is it safe to do it manually. Thanks You for fantastic programs.

 

[Andy Ful]

Late to the party but so far caught on quickly SWH- If i missed it someplace feel free to say so but how do we clear the Blocked Files Log- I mean is there a Clear Logs button i missed or is it safe to do it manually. Thanks You for fantastic programs.

It is not necessary, because the blocked events are sorted by time.
Anyway, SWH uses the events from Windows Event Log, so they can be cleared by using Event Viewer or Wevtutil tool. For example, open the CMD with Administrator privileges and use the below CmdLines:

wevtutil.exe cl "Microsoft-Windows-PowerShell/Operational"
wevtutil.exe cl "Application"

The first will clear the PowerShell events and the second SRP events. But, also many other events will be cleared in these channels, so I think that it would be better to avoid clearing the blocked events.

 

[EASTER]

It is not necessary, because the blocked events are sorted by time.
Anyway, SWH uses the events from Windows Event Log, so they can be cleared by using Event Viewer or Wevtutil tool. For example, open the CMD with Administrator privileges and use the below CmdLines:

wevtutil.exe cl "Microsoft-Windows-PowerShell/Operational"
wevtutil.exe cl "Application"

The first will clear the PowerShell events and the second SRP events. But, also many other events will be cleared in these channels, so I think that it would be better to avoid clearing the blocked events.

Thanks Andy Ful and it's always a pleasure to read your replies and posts. Awesome program(s) of course. Likely there won't be any heavy collection of records of blocks but that one minor detail was of interest in any event.

 

[Andy Ful]

The current build of Windows 11 Insider ver. 22H2 is incompatible with SWH (SRP does not work).

Hard_Configurator - Windows Hardening Configurator

Hi, wouldn't it be a good idea to block exe's and derivatives from running in powershell or cmd? Edit: Or at least have that option for those who want to activate it. It is only possible to block CMD or PowerShell, so they cannot be used to run anything.

malwaretips.com

 

[Pixel_]

Hi to everyone. I have a question or few of them.

I''m using Sys_Hardener V 1.5. Last time I checked it was updated in 2018. So I decided to switch to SWH and FirewallHardening.
I'm using ESET IS and VoodooShiled 7.05 (one of the last free versions).

My question is, is it wise to add SWH and FirewallHardening to ESET and VS?

 

[Andy Ful]

Hi to everyone. I have a question or few of them.

I''m using Sys_Hardener V 1.5. Last time I checked it was updated in 2018. So I decided to switch to SWH and FirewallHardening.
I'm using ESET IS and VoodooShiled 7.05 (one of the last free versions).

My question is, is it wise to add SWH and FirewallHardening to ESET and VS?

Some people use such a setup, but it may be too complex for most users. Eset + VS should be OK.

 

[Pixel_]

Some people use such a setup, but it may be too complex for most users. Eset + VS should be OK.

Do you know if Firewall Hardening affects EIS firewall in any way?

 

[Kongo]

Do you know if Firewall Hardening affects EIS firewall in any way?

ESET's firewall disables the Windows Firewall as far as I know. So Firewall Hardening is useless for this config.

 

[ForgottenSeer 95367]

SRP has absolutely zero context... no parent, no command line, nothing.

This point of view shows a lack of understanding of how SRP is designed and deployed.

The whole context of SRP has always heen, and remains, active threat intelligence used to craft the policies (Microsoft itself has an entire workgroup devoted to this task). The source of that context is exactly what you fallaciously claim that SRP does not rely upon:

1. kill chain
2. source
3. command lines
4. parent-child
5. etc

Threat intelligence (context) for SRP [and other products in the same vein - even Splunk, Snort] is available everywhere. From the open SecOps community to privately purchased Threat Analytics & Intelligence.

What did you think - that an ape is put into a cage and made to pick just process names and file types out of a hat randomly to create SRP policies?

All SRP does is blindly block by path or globally by extension.

On the face of it, but that point of view is misleading. Highly effective security policies are distilled from hyper-detailed context down to their simplest operational form needed to protect on the endpoint. Because of this simplicity and reliability, hundreds of millions of systems running SRP function flawlessly while remaining uninfected with a very low probability of becoming infected.

 

[Andy Ful]

Although I agree with @Furyo, the discussion about the SRP in this thread including the Enterprise environment, would be out of topic. Simple Windows Hardening is intended for home users.

SWH has got the context without SRP, so we do not have to discuss contextual features related to SRP. We should remember that EXE and MSI files are allowed in SWH (no need to think about the context for them). The context is that it is very suspicious when scripts, scriptlets, shortcuts, and other potentially dangerous files are dropped on the home computer. There is no such context in the Enterprise environment, where these files are commonly used by administrators.

 

[ForgottenSeer 95367]

SWH has got the context without SRP, so we do not have to discuss contextual features related to SRP. We should remember that EXE and MSI files are allowed in SWH (no need to think about the context for them).

System-wide events, including SWH actions, can be collected and analyzed using any of a vast array of threat intelligence tools and methods to obtain all the "context" anyone could possibly need. Whether or not the typical user needs (or wants) all of that is a question best answered by each individual themselves.

The context is that it is very suspicious when scripts, scriptlets, shortcuts, and other potentially dangerous files are dropped on the home computer.

Most home users at the security enthusiast level quickly grasp this.

There is no such context in the Enterprise environment, where these files are commonly used by administrators.

With regard to scripts only, these would provide "context" of a particular kind that an admin can leverage:

• There can be such context dependent upon how the sec admins have implemented security:
• The use of signed (or unsigned) scripts which are permitted to execute only from explicitly defined local or remote directories.
• Admin sets the runtime permission rights for the scripts intended to be run from the script directory.
• The calling of sponsors from scripts from any other locations is blocked system-wide.
• Units on the network that do not need to run scripts have script policies set to blocked. (Script launches would be a red flag for this designated segment of systems.)
• Surely other things not listed here (for example, login and other management scripts run via GPO - which is the way Microsoft preferred it be done at one point in time).

Scripts are deployed via, for example, Microsoft SCCM.

 

[Andy Ful]

It is true that a lot of the context can follow from the SRP rules. But, SWH uses simple rules, so the contextual information is also simple. Despite this fact, SWH can be both useful and very efficient protection against fileless attacks. This does not follow from the amount of contextual information, but from the specific attack surface of the home environment and usual/daily actions of home users. Furthermore, SWH is intended for semi-advanced users who do not have the knowledge of administrators and do not act/think like administrators.
Shortly, the discussion about the context in SRP is not important for SWH.

 

[ForgottenSeer 95367]

But, SWH uses simple rules, so the contextual information is also simple.

• Too much context represents a manageability problem. The industry wrestles with this problem daily.
• Simplicity, in the form of very limited context, is highly efficient and efficient for the right use-case.
• Users can figure it out and create rules with limited context. Any claims to the otherwise just ain't true.

Shortly, the discussion about the context in SRP is not important for SWH.

• The simple blocking by SWH is sufficient.
• The claim that SWH cannot deliver a user-friendly experience for a user because it does not incorporate "context" is a controversy deliberately created here by someone else.

Furthermore, SWH is intended for semi-advanced users who do not have the knowledge of administrators and do not act/think like administrators.

The things I mention are just general discussion points. I think readers can figure that out. They can benefit from a little bit of discussion of the security and operation in the enterprise space. Plus there are SOC employees, administrators, analysts that are members here. We're not all home users. I have a 33 cm laptop on which I run SWH.

Do you want the language and scope of your thread discussions limited only to the "context" of a typical user running Windows Pro, capable of making a few tweaks?

 

[Andy Ful]

Do you want the language and scope of your thread discussions limited only to the "context" of a typical user running Windows Pro, capable of making a few tweaks?

Yes.
Simple Windows Hardening uses predefined and simple SRP adjusted to the typical home user (on Windows Home and Pro). The information in the SWH log is mainly for helping users to whitelist the blocked files and paths. The SRP tweaks are usually limited to path/hash whitelisting, which can happen rarely.

The SRP used in SWH is stronger if it uses less context (as any default deny). So more context is needed in SWH for usability and not for more precise detection. That differs SWH from most security applications focused on malware detection.

 

[silversurfer]

Understandable. For me SRP was always the most simplistic and most effective way to support my AV without having to install another program, that has to run in the background all the time. But yeah, I think there is no other proper solution except using either OS Armor, Comodo Firewall or VoodooShield.

I don't know it would be enough for your config. I have changed (disabled) my settings in SWH due to "issues" of SRP on Windows 11. I chosen restrictions for:

• "Admin Windows Script Host"
• "Admin Powershell Scripts"

At least, malware variants like .js/vbs (even other common file script type) are blocked automatically due to restriction of Windows Script Host.

 

[Kongo]

I don't know it would be enough for your config. I have changed (disabled) my settings in SWH due to "issues" of SRP on Windows 11. I chosen restrictions for:

• "Admin Windows Script Host"
• "Admin Powershell Scripts"

At least, malware variants like .js/vbs (even other common file script type) are blocked automatically due to restriction of Windows Script Host.

So you only have enabled those two restrictions?

 

[silversurfer]

So you only have enabled those two restrictions?

Nope, I mentioned only two for purpose similar like SRP against malware as script variants...
I have enabled even other restrictions like "Remote Access" or "AppInstaller" and others... except for "Attachments and Archives" that doesn't work with disabled SRP.

 

[Kongo]

Nope, I mentioned only two for purpose similar like SRP against malware as script variants...
I have enabled even other restrictions like "Remote Access" or "AppInstaller" and others... except for "Attachments and Archives" that doesn't work with disabled SRP.

Alright, then I'll just keep on using SWH for now and disable SRP. Do you know how those restrictions are actually applied if not by SRP?

 

[silversurfer]

Alright, then I'll just keep on using SWH for now and disable SRP. Do you know how those restrictions are actually applied if not by SRP?

Regarding "Windows Script Host" I found again one bookmarked link from F-Secure, it's just a tweak in Windows registry:

How-To Disable Windows Script Host - F-Secure Blog

Numerous spam campaigns are pushing various crypto-ransomware families (and backdoors) via .zip file attachments. And such .zip files typically contain a JScript (.js/.jse) file that, if clicked, will be run via Windows Script Host. Do yourself a favor and edit your Windows Registry to disable...

blog.f-secure.com

 

[oldschool]

Do you know how those restrictions are actually applied if not by SRP?

Most of them are applied via Windows policy and do not allow for whitelisting. See the Help files in SWH for more info.