Hard_Configurator - Windows Hardening Configurator

Did you enable logging?

1729766063065.png
 

So the issue is unrelated to FirewallHardening. If it was then the package could not be downloaded (but it could).

1729766886243.png


The issue is related to insufficient privileges. PowerShell thinks that the module does not have Administrator rights.
 
DId you try to install this module via the PowerShell CmdLine (PowerShell 7.4+ must be used):

Code:
 (irm 'https://raw.githubusercontent.com/HotCakeX/Harden-Windows-Security/main/Harden-Windows-Security.ps1')+'P'|iex
 
  • Like
Reactions: dronefox1166
Did you uninstall H_C via Tools >> Uninstall H_C?
is not installed, I have made an clean install without H_C. Only I use FirewallHardening and ConfigureDefender (independently of H_C.).

I did a reset instead exactly... but in program i have H_C but not installed, when I click it beg to suppress the shortcut...

So how I check if SRP or H_C rules are active ? I guess that not because of I have made an hard reset... of the system.
 
Last edited:
is not installed, I have made an clean install without H_C. Only I use FirewallHardening and ConfigureDefender (independently of H_C.).

If you did so, then there is no H_C restrictions.


No idea. Maybe this module does not work on your Windows version. Do you use any application that can block/restrict execution in some folders?
 
Last edited:
Did you manually add pwsh.exe to the anti-ransomware protection block list? Are there any blocked events in the Microsoft Defender protection history related to blocking pwsh.exe? Those events should also be visible in the CondfigureDefender Log.

Edit.
I think that PowerShell (pwsh.exe) used one of your protected folders when installing the Harden Windows Security Module. The modifications in that folder were blocked because pwsh.exe was not on the allowlist of Ransomware Protection. That is why PowerShell alerted that it did not have sufficient privileges to install the module.
 
Last edited:
I have a question that is closely related to H_C, although I'm not currently running H_C (but instead a home made SRP tool) in the PC where I came across to a new situation recently. I hope it's still ok to ask my question here, since the question is SRP specific, and I think that most people using SRP nowadays do use H_C (as I also use in some other PCs), so I think that the question can easily be answered here.

I have run SRP for years in all of my Windows computers in default deny mode, enforcement for all files (including dlls). Several years ago I have included a "jscript*.dll" entry in my Disallow list, since I have had no need for Javascript.

Recently I installed an USB connected HP printer to one of our workstations and noticed that to be able to print I had to create a custom allow policy for C:\Windows\System32\jscript.dll, which is now required by the printer. It took a while to find out since to my surprise no Event Log entries were generated. Luckily Process Monitor revealed the guilty dll which blocked printing.

I have not been actively following the threat developments for various Windows components, so I'm somewhat unsure what are nowadays the risks for allowing the access to jscript.dll for standard user accounts (I mean from technical point of view, e.g. if there are known unpatched vulnerabilities in jscript.dll that I failed to find, or what kind of scenarios an adversary could probably try to exploit in late October 2024 by using jscript.dll, etc...).

I'd be grateful if someone knowledgeable could shed some light on this.

I did try to use Google and MS copilot to answer the question, but after some trials I came to the conclusion that I'd rather prefer some real intelligence than plain AI stories here... :)

Windows 10 Pro 22H2.
 
  • Like
Reactions: oldschool