Harden Windows Safely, Securely using Official Supported Microsoft methods and proper explanation | Always up-to-date and works with the latest build of Windows | Provides tools and Guides for Personal, Enterprise, Government and Military security levels | Read The Rationale https://github.com/HotCakeX/Harden-Windows-Security/blob/main/Rationale.md
Improved BCD NX bit setting and detection: Instead of using the Bcdedit, using the new PowerShell cmdlets. This allows the NX bit value detection to work with any locale and system language. Previously this detection only worked with EN-US locales.
Added workaround for Controlled Folder Access: The controlled folder access is now properly navigated when using Confirm-SystemCompliance cmdlet. The new method of BCD NX value verification and detection causes Controlled Folder Access to show notification about pwsh.exe getting blocked so the new change prevents this from happening by dynamically adding pwsh.exe exe to the exclusion list before running the function and then restoring the exclusion list back to exactly how it was at the end of the operation. This is safely done to ensure that even if user pressed ctrl + c to prematurely exit the operation or if there is an error, the exclusion list restoration will still happen.
Added Svchost.exe security mitigation removal to the Unprotect-WindowsSecurity cmdlet. It's a tattooed policy so simply setting it to not configured won't revert it.
Added warning for insecure encryption method: When running BitLocker category, the encryption method of each drive will be checked and if it's not XTSAES256 which is currently the most secure type, a warning will be displayed. The module/script doesn't do anything else, but if you like to fix that, you will need to manually decrypt each drive, wait for it to be fully decrypted, and then run the BitLocker category again to encrypt them with the most secure algorithm. Your OS or non-OS drive that is BitLocker encrypted might be using a less secure encryption method if you didn't encrypt it properly. Another potential cause is if your SSD is SED (Self Encrypting Drive) and uses Opal 2, in this case it might automatically pick a different algorithm such as XTSAES128. The Harden Windows Security module always uses XTSAES256 until a more secure encryption method becomes available.
Important Notes
I'm going to explain 2 known issues in Windows that are not related to the Harden Windows Security module or script, nevertheless, I want to make you aware of them because they can cause complications. You might not be affected by them at all. I've found these issues through long debugging sessions.
Svchost.exe security mitigations policy
In the Miscellaneous category, there is a policy called svchost.exe mitigations., it applies process mitigations for Svchost.exe process, you can read more about what it does in the linked page but the most important thing is that it requires all binaries loaded in Svchost.exe process to be signed by Microsoft.
So far so good, right? so where is the problem?
There is a file located at:
C:\Windows\System32\gameplatformservices.dll
It's part of the Windows OS but it hasn't been digitally signed for about 2 months now. It was signed before but since about 2 months ago it was released as an unsigned dll.
When you use the Miscellaneous category and you have at least Windows 11 pro for workstation edition, that security policy prevents gameplatformservices.dll from loading and as a result of that, Code Integrity Operational logs begin to generate in an unprecedented rate, sometimes up to 500 logs every 10 seconds. They essentially pollute that important event category and also cause high CPU usage. Microsoft Store is one of the triggers of this problem. When it checks for app updates or if you manually check for app updates, the problem starts happening, CPU usage goes up and Microsoft Store gets stuck at checking for updates forever. Using Xbox apps and services can potentially help this problem manifest itself better or faster.
Smart App Control also detects this file as unsigned and blocks it. I've reported this in Feedback hub multiple times (1 - 2 - 3) but so far no changes have been made.
As a workaround, you can manually turn off this policy if you are affected by this issue. It's a tattooed policy, meaning it's not enough to simply set it to "Not Configured" state, you need to change or delete the registry key related to that policy too.
BitLocker encryption, OneDrive Personal Vault and ReFS volumes, an interesting trio
Based on my findings, there is a potential issue when you try to use BitLocker, OneDrive Personal Vault and ReFS volume at the same time.
If your OS volume is BitLocker encrypted and you have at least one ReFS volume that is also BitLocker encrypted then OneDrive's Personal Vault fails when you try to unlock or initialize it.
It fails by getting stuck at step 12 and when that happens, some normal operations of the OS get stuck and stop functioning.
This only happens if the ReFS volume is unlocked. If the ReFS volume is BitLocker encrypted but locked when you try to unlock OneDrive's personal vault, then this problem won't happen.
It doesn't matter how many other BitLocker encrypted ReFS, NTFS or non-BitLocker encrypted volumes are available on the system.
The ReFS volume can have recovery password, auto unlock or password key protector, either way this problem is reproducible.
What's Changed
Bcdedit, using the new PowerShell cmdlets. This allows the NX bit value detection to work with any locale and system language. Previously this detection only worked with EN-US locales.Confirm-SystemCompliancecmdlet. The new method of BCD NX value verification and detection causes Controlled Folder Access to show notification about pwsh.exe getting blocked so the new change prevents this from happening by dynamically adding pwsh.exe exe to the exclusion list before running the function and then restoring the exclusion list back to exactly how it was at the end of the operation. This is safely done to ensure that even if user pressedctrl + cto prematurely exit the operation or if there is an error, the exclusion list restoration will still happen.Svchost.exesecurity mitigation removal to theUnprotect-WindowsSecuritycmdlet. It's a tattooed policy so simply setting it to not configured won't revert it.XTSAES256which is currently the most secure type, a warning will be displayed. The module/script doesn't do anything else, but if you like to fix that, you will need to manually decrypt each drive, wait for it to be fully decrypted, and then run the BitLocker category again to encrypt them with the most secure algorithm. Your OS or non-OS drive that is BitLocker encrypted might be using a less secure encryption method if you didn't encrypt it properly. Another potential cause is if your SSD is SED (Self Encrypting Drive) and uses Opal 2, in this case it might automatically pick a different algorithm such asXTSAES128. The Harden Windows Security module always usesXTSAES256until a more secure encryption method becomes available.Important Notes
I'm going to explain 2 known issues in Windows that are not related to the Harden Windows Security module or script, nevertheless, I want to make you aware of them because they can cause complications. You might not be affected by them at all. I've found these issues through long debugging sessions.
Svchost.exe security mitigations policy
In the Miscellaneous category, there is a policy called svchost.exe mitigations., it applies process mitigations for
Svchost.exeprocess, you can read more about what it does in the linked page but the most important thing is that it requires all binaries loaded inSvchost.exeprocess to be signed by Microsoft.So far so good, right? so where is the problem?
There is a file located at:
It's part of the Windows OS but it hasn't been digitally signed for about 2 months now. It was signed before but since about 2 months ago it was released as an unsigned dll.
When you use the Miscellaneous category and you have at least Windows 11 pro for workstation edition, that security policy prevents
gameplatformservices.dllfrom loading and as a result of that, Code Integrity Operational logs begin to generate in an unprecedented rate, sometimes up to 500 logs every 10 seconds. They essentially pollute that important event category and also cause high CPU usage. Microsoft Store is one of the triggers of this problem. When it checks for app updates or if you manually check for app updates, the problem starts happening, CPU usage goes up and Microsoft Store gets stuck at checking for updates forever. Using Xbox apps and services can potentially help this problem manifest itself better or faster.Smart App Control also detects this file as unsigned and blocks it. I've reported this in Feedback hub multiple times (1 - 2 - 3) but so far no changes have been made.
As a workaround, you can manually turn off this policy if you are affected by this issue. It's a tattooed policy, meaning it's not enough to simply set it to "Not Configured" state, you need to change or delete the registry key related to that policy too.
Screenshots 📸
 
BitLocker encryption, OneDrive Personal Vault and ReFS volumes, an interesting trio
Based on my findings, there is a potential issue when you try to use BitLocker, OneDrive Personal Vault and ReFS volume at the same time.
If your OS volume is BitLocker encrypted and you have at least one ReFS volume that is also BitLocker encrypted then OneDrive's Personal Vault fails when you try to unlock or initialize it.
It fails by getting stuck at step 12 and when that happens, some normal operations of the OS get stuck and stop functioning.
This only happens if the ReFS volume is unlocked. If the ReFS volume is BitLocker encrypted but locked when you try to unlock OneDrive's personal vault, then this problem won't happen.
It doesn't matter how many other BitLocker encrypted ReFS, NTFS or non-BitLocker encrypted volumes are available on the system.
The ReFS volume can have recovery password, auto unlock or password key protector, either way this problem is reproducible.
Screenshots 📸