[Bug]: Starting with Version 0.5.9 hardening module stucks

[kamellemann]

Tools category

Harden Windows Security Module

Does Your System Meet The Requirements?

• [X] Yes, I acknowledge that I've read the requirements and my system meets them. 👍

Is your Windows Installation Genuine?

• [X] Yes, I acknowledge that the installation media of the Windows OS I used the tool on was downloaded from the official Microsoft website and I didn't tamper or modify it. 💯

Did You Read The Frequently Asked Questions?

• [X] Yes, I've referred to the FAQs and my issue is not covered/explained in there.

Please Explain The Bug

When renunning the script via task or manual, the module seems to stuck and powershell session and concole host did not close. Next time running the script we got "access denied" when the module tries to update as the files are still in use by the previous run. We do not see any errors

---

PowerShell transcript start Start time: 20240904053955 Configuration Name: Host Application: C:\Program Files\PowerShell\7\pwsh.dll -WindowStyle Hidden -ExecutionPolicy Bypass -File c:\hardening\hardening.ps1 Process ID: 8464 PSVersion: 7.4.5 PSEdition: Core GitCommitId: 7.4.5 OS: Microsoft Windows 10.0.22631 Platform: Win32NT PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1, 6.0, 7.0 PSRemotingProtocolVersion: 2.3 SerializationVersion: 1.1.0.1 WSManStackVersion: 3.0

---

Transcript started, output file is c:\hardening\hardeninglog.txt

---

PowerShell transcript end End time: 20240904054027

---

Error Details

No response

[HotCakeX]

What is the "script" that you're referring to?

Try using this command to install the latest version as shown on the readme, and then run it

Install-Module -Name 'Harden-Windows-Security-Module' -Force

[kamellemann]

We run this script each night. Starting with version 0.5.9 the script stucks

function harden{ Protect-WindowsSecurity -Categories MicrosoftDefender,AttackSurfaceReductionRules,TLSSecurity,UserAccountControl,WindowsFirewall,WindowsNetworking,MiscellaneousConfigurations,EdgeBrowserConfigurations,CountryIPBlocking,NonAdminCommands -UAC_NoFastSwitching -UAC_OnlyElevateSigned -MSFTDefender_BetaChannels -MSFTDefender_SAC -MSFTDefender_NoDiagData -MSFTDefender_NoScheduledTask -CountryIPBlocking_OFA -Log -Verbose -LogPath c:\hardening\hardeninglog.txt }

Save-Module -Name 'Harden-Windows-Security-Module' -Path 'C:\Hardening' -Force Import-Module -Name 'C:\Hardening\Harden-Windows-Security-Module' -Force

harden

[HotCakeX]

That's a clever way of running the module without it saving in the default directories. Do you use it in a scheduled task?

it doesn't get stuck for me, i tried reproducing it multiple times. In the version 0.6.0 i improved it so that you can completely delete the module's directory after it's finished, without the need to close the PowerShell first. The auto updating mechanism was improved in 0.5.9 so that you won't see those errors about files in use (or access denied).

Can you show me any errors you see next time? I need more info to reproduce the problem you're facing.

[HotCakeX]

By the way, this is the auto-updating experience, it transitions to the new version automatically without the need for any extra actions.

[kamellemann]

Thanks for the update. Works like a charm now and all problems are fixed! Once again: great job1 You are crazy!

[HotCakeX]

Hehe, glad to hear that and you're very welcome! 🙏

[HotCakeX]

Hi, just wanted to give you a quick update related to this issue.

It appeared that your workflow involves a recurring scheduled task where the Harden Windows Security module is installed, executed with predefined commands, and then removed.

The problem seems to arise during the removal stage, as it is being attempted within the same PowerShell session. Specifically, your script includes a command that tries to delete the module’s folder at the end of its execution.

Here’s the issue with that approach: The module relies on certain Microsoft-signed DLLs that are loaded into the PowerShell session when the module's commands are executed. These DLLs remain loaded as long as the PowerShell process is running, and because they’re still in use, they can’t be deleted while the session is active. This is the root cause of the problem.

PowerShell modules shipping with and using DLLs is a common practice, as many popular modules adopt this method to provide additional features.

I attempted to address the issue by ensuring that the previous PowerShell process closes at the end of the execution. However, this introduced a small side effect in an edge case, which I reverted in version 0.6.3.

Here is my proposed solution:

1)

Use an environment variable or a text file to store the currently running process ID of the PowerShell so that you can read it from the new PowerShell process and close it via Stop-Process.

Here is an example:

# Set an environment variable
[System.Environment]::SetEnvironmentVariable('HardenWindowsSecurity-PID', $PID, 'User')

# Recycle the current PowerShell session, read the previously set environment variable that includes the process ID of the previous PowerShell session and then use that to close/stop it 
pwsh.exe -NoProfile -NoLogo -NoExit -Command "Stop-Process -Id ([System.Environment]::GetEnvironmentVariable('HardenWindowsSecurity-PID', 'User')) -Force -ErrorAction Stop"

2)

My 2nd proposed solution is to remove the module removal commands from your script. Since it's a recurring task, let the module stay installed and just run it on your desired intervals.

[kamellemann]

Hi, once again thanks for your great work and support. Will try that.