What's Changed

Complete Redesign

Revamped the architecture of the Harden Windows Security script. The new versatile design enables a single file to function as an independent script and as a component of the Harden Windows Security module, at the same time.

The All New Hybrid Mode of Operation

The Harden Windows Security module now supports headless or silent mode of operation. This mode enables you to run the module without any interaction on the PowerShell console. You simply choose the categories you wish to apply automatically, and the module will perform them for you. If a selected category requires Administrator privileges and the module is running with Standard privileges, that category is skipped.

Facilitating Large-Scale Deployments

This modification, in conjunction with other improvements in this version, prepare the Harden Windows Security module for deployments at a large scale.

Available Parameters for Protect-WindowsSecurity Cmdlet

Protect-WindowsSecurity [[-Categories] <String[]>] [<CommonParameters>]

The following parameters are only for the headless/silent mode of operation.

• -Categories: Optional; Specify the hardening categories that you want to apply. This will tell the module to operate in non-interactive or headless/silent mode which won't ask for confirmation before running each selected categories. You can specify multiple categories by separating them with a comma. If you don't specify any category, the cmdlet will run in interactive mode. Use this parameter for deployments at a large scale. If a selected category requires Administrator privileges and the module is running with Standard privileges, that category is skipped.

  • This parameter has automatic tab completion. You can press the Tab key to see the available categories.

• -Verbose: Optional; Shows verbose messages on the console about what the cmdlet is doing.

[!NOTE]
You can further control the sub-categories of each category by using the following switch parameters. Pay attention to the naming convention of them. They are named after the category they belong to. For example, the switch parameter -MSFTDefender_SAC belongs to the MicrosoftDefender category. The switch parameters are dynamic and will only appear if you specify the corresponding category in the -Categories parameter. For example, if you don't specify the MicrosoftDefender category in the -Categories parameter, the switch parameters related to it won't appear. The following table shows the available switch parameters and their corresponding categories.

What if You Don’t Configure the Sub-Categories?

If you do not specify any sub-categories using the switch parameters above, the following sub-category configuration will be applied when the corresponding category exists in the -Categories parameter.

• Windows Boot Manager Revocations
• Microsoft Security Baselines
  • Yes, With the Optional Overrides (Recommended)
  • Yes
• Microsoft 365 Apps Security Baselines
• Microsoft Defender
  • Smart App Control enablement
  • Enable advanced diagnostic data if Smart App Control is on
  • Scheduled task creation for fast weekly MSFT driver block list update
  • Set engine and intelligence update channels to beta
• Attack Surface Reduction Rules
• BitLocker Settings
  • Normal: TPM + Startup PIN + Recovery Password
  • Enhanced: TPM + Startup PIN + Startup Key + Recovery Password
  • Skip encryptions altogether
• TLS Security
• Lock Screen
  • Don't display last signed-in
  • Require CTRL + ALT + DEL on lock screen
• User Account Control
  • Only elevate signed and validated executables
  • Hide the entry points for Fast User Switching
• Windows Firewall
• Optional Windows Features
• Windows Networking
• Miscellaneous Configurations
• Windows Update Configurations
• Edge Browser Configurations
• Certificate Checking Commands
• Country IP Blocking
  • Block State Sponsors of Terrorism IP blocks
  • Block OFAC Sanctioned Countries IP blocks
• Downloads Defense Measures
• Non-Admin Commands

[!IMPORTANT]
It is highly recommended to always include the Microsoft Security Baselines category and place it first as it forms the foundation of all subsequent categories.

Example 1

If you run the module like this without specifying any categories, the module will run in interactive mode and the usual beautiful prompts will be displayed to the user.

Protect-WindowsSecurity

Example 2

If you run the module like this, the 2 categories will be executed automatically without requiring any user input. The results will be displayed on the console.

Protect-WindowsSecurity -Categories MicrosoftDefender, AttackSurfaceReductionRules

Example 3

This example will apply the Microsoft Defender category with the Smart App Control sub-category, without the need for user interaction, and will show verbose messages.

Protect-WindowsSecurity -Categories MicrosoftDefender -MSFTDefender_SAC -Verbose

Example 4

This example will apply the Microsoft Security Baselines, BitLocker, User Account Control, Lock Screen and Downloads Defense Measures categories. It will also apply the "Only Elevate Signed and Validated Executables" sub-category of the User Account Control category, and the "Require CTRL + ALT + DEL on Lock Screen" sub-category of the Lock Screen category.

Protect-WindowsSecurity -Categories MicrosoftSecurityBaselines,BitLockerSettings,UserAccountControl,LockScreen,DownloadsDefenseMeasures -UAC_OnlyElevateSigned -LockScreen_CtrlAltDel

More Secure Than Ever

The previous design necessitated downloading the essential files from the GitHub repository regardless of the execution mode, either as a script or as a module's cmdlets. The current design optimizes this process by only fetching the vital payload files when the script is invoked from GitHub as follows:

irm 'https://raw.githubusercontent.com/HotCakeX/Harden-Windows-Security/main/Harden-Windows-Security.ps1' | iex

By installing and utilizing the Harden Windows Security module via the Protect-WindowsSecurity command, the essential files are pre-included in the module and thus eliminate the need for downloading them separately. This enhances the security level and offers more peace of mind to the users.

No Support for The Legacy Windows PowerShell

The new code excludes support for the old Windows PowerShell version 5.1, the default version installed with Windows. It was impeding the advancement and innovation in the code due to lack of compatibility with new features. Consequently, the new code base is more concise than before (despite offering more functionalities), more intelligent and more legible.

It is extremely easy to install the new modern PowerShell. The safest, fastest and best way to do so is through 🛍️ Microsoft Store.

By default, Windows Store packages run in an application sandbox that virtualizes access to some filesystem and registry locations. Changes to virtualized file and registry locations don't persist outside of the application sandbox.

This sandbox blocks all changes to the application's root folder. Any system-level configuration settings stored in $PSHOME can't be modified.

Alternatively, you can install PowerShell using Winget

Winget install Microsoft.PowerShell

PowerShell is modern and leverages the most recent .NET version and features. It is widely adopted in business and enterprise environments, and it eliminates the need and the rationale for relying on the archaic and old Windows PowerShell.

Downloads Defense Measures

To combat the threat of more sophisticated malware, a preemptive measure is taken by creating and deploying a WDAC policy on the system. This policy blocks the execution of executables and other potentially harmful file types in the Downloads folder, using the WDACConfig module.

This policy defends the system from malware that can launch itself automatically after being downloaded from the Internet. The user must ensure the file's safety and explicitly transfer it to a different folder before running it.

The WDAC policy employs a wildcard pattern to prevent any file from running in the Downloads folder. Additionally, it verifies that the system downloads folder in the user directory matches the downloads folder in the Edge browser's settings. If there is a discrepancy, a warning message is displayed on the console.

The policy can be removed by the Unprotect-WindowsSecurity or Remove-WDACConfig cmdlets.

It is an ongoing process so expect more WDAC integrations like this in the Harden Windows Security module.

Improved Auto Updating Experience

Whenever you execute any of the cmdlets, the Harden Windows Security module will verify if there is a newer version available and update itself automatically if needed. You no longer have to repeat your command after the update, as it will resume seamlessly.

[!NOTE]
When auto updating from version 0.2.7 to 0.2.8, you will see the message "Update successful, please run the cmdlet again.", instead of doing that, please close and reopen your PowerShell tab/window, otherwise you may encounter an error. It is totally harmless though and you won't see it anymore. This is due to a bug in version 0.2.7 that prevents it from properly disposing the secure constant variables. This bug is resolved in version 0.2.8.

Other Changes And Improvements

• Set the MDAG to be disabled instead of enabled: https://github.com/HotCakeX/Harden-Windows-Security/issues/170
• Added verbose messages to the module's cmdlets so you can take a peek at what's happening under the hood during the execution. Use the -Verbose parameter with each cmdlet.
• Removed Launch Renderer processes into an App Container policy from Edge category because it's now enabled by default in Edge browser since version 120.
• Added verifying the 3 built-in Firewall rules (for all 3 profiles) for Multicast DNS (mDNS) UDP-in are disabled, to the Confirm-SystemCompliance.

What's Next

• Total offline operation for air gapped computers.
• Generating detailed log file for the activities of the Protect-WindowsSecurity cmdlet
• Possible Windows Server support
• And more...

Feel free to open pull requests if you want to contribute by implementing any of the mentioned features.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/177

What's Changed

1. New feature: the ability to download the latest version of the SignTool.exe from official Microsoft servers. If the path for SignTool.exe was not specified in any of the relevant cmdlets, if it wasn't detected automatically on the system, or if it did not exist in the user configurations file, you will be offered this option automatically.
2. New feature: the ability to generate certificates for signing WDAC policies. You no longer need to install Windows Server to generate a certificate for yourself, now you can use the new cmdlet Build-WDACCertificate to automate the entire process in just few seconds. The certificate's private 🗝 will be securely stored on the system using Virtualization based Security 🔐.
3. The WDACConfig module is almost completely self-sufficient and can handle all of the tasks required for Windows Defender Application Control management in an environment on its own. You can manage your computer's security without leaving the PowerShell window. Also, many of the module's features can be used non-interactively or in headless mode, meaning you can pre-configure the parameters and use the features at scale without the need for individual user inputs.
4. New feature: the capability to create a deny policy based on a directory path with wildcard(s): New-DenyWDACConfig -PathWildCards. This unveils many new opportunities. One of them is deploying a deny policy that blocks anything from executing in the Downloads directory, so if you inadvertently download a malware that is programmed to autorun after downloading then it will fail because nothing will be executed in the Downloads directory. You will have to manually transfer a trustworthy file to another location and then execute it. Of course, you can diversify and use this special policy with other kinds of policies on the system. You can also use this kind of policy with guidelines from my other repository that is for Privacy, Anonymity and Compartmentalization, by creating wildcard block rules for directory paths that contain files that are only intended to run in their assigned Windows Sandboxes and shouldn't be permitted to run on the host.

PRs:

• https://github.com/HotCakeX/Harden-Windows-Security/pull/176
• https://github.com/HotCakeX/Harden-Windows-Security/pull/175

What's Changed 🎄

• Further improvements to the code to follow the best practices.
• Added native prompt for confirmation to Deploy-SignedWDACConfig before deploying the signed policy on the system.
• Added native prompt for confirmation to New-DenyWDACConfig before deploying the deny base policy for Appx based apps. Shows the details of the select appx package based on the user input and allows for confirming or denying it before proceeding.
• Added native prompt for confirmation to New-SupplementalWDACConfig before deploying the supplemental policy for Appx based apps. Shows the details of the select appx package based on the user input and allows for confirming or denying it before proceeding.
• Added native prompt for confirmation to Remove-WDACConfig -SignedBase before deploying the signed policy in unsigned mode.
• All of the prompts for confirmations can be bypassed with the familiar -Force parameter. This allows the WDACConfig module to be used non-interactively for remote administration.
• Improved detection of PowerShell core, now when creating Default Windows base policies, PowerShell core files are only scanned if it's installed using MSI. PowerShell core installed from Microsoft Store doesn't need to be scanned and allowed in the Default Windows base policy because it's automatically allowed.
• Added progress bars to all of the parameters of the New-WDACConfig cmdlet.
• Completed adding verbose messages to every single component of the WDACConfig module.
• Added progress bars to all of the parameters of the Edit-WDACConfig cmdlet.
• Added progress bars to all of the parameters of the Edit-SignedWDACConfig cmdlet.
• Improved and added progress bars to Remove-WDACConfig -UnsignedOrSupplemental cmdlet and parameter.
• Improved input validations on the Set-CommonWDACConfig cmdlet.
• Added progress bars to all of the parameters of the New-SupplementalWDACConfig cmdlet.
• Added progress bars to all of the parameters of the New-DenyWDACConfig cmdlet.
• Added progress bars to the Deploy-SignedWDACConfig cmdlet.
• In Edit-SignedWDACConfig and Edit-WDACConfig cmdlets, changed the name of the -PolicyPaths parameter to -PolicyPath because those cmdlets only work on one base policy at a time and realistically there is no need for more than 1 base policy to allow files. The documentation also has been updated.
• Added progress bars to all of the parameters of the New-KernelModeWDACConfig cmdlet.
• Created a new cmdlet called Assert-WDACConfigIntegrity, used to verify the integrity of the WDACConfig module with the most secure available hashing algo: SHA2 512. Will switch to SHA3 hashes that are available in .NET 8 and later once they are available in stable builds Windows. They are currently available in insider channels. The documentation of this new cmdlet can be found here.
• Improved the self updating mechanism. The execution flow is no longer disrupted when the module auto updates to a new version despite using constant variables, they are properly recycled.

[!NOTE]
When the module automatically updates to version 0.2.8 there might be a one-time error because of a bug (that is fixed in this version but present in version 0.2.7). You can safely ignore it by closing the PowerShell tab and reopening it again to continue using the new version of the module. Alternatively you can manually update the WDACConfig module by running the following command:

Update-Module -Name WDACConfig -Force

The bug 🐛 is related to constant variables being used and the inability of the v0.2.7 to empty them when the module updates to a new version.

• Improved the way Certificate Common Names were detected from the local user certificates store by taking into account the CNs that have comma in them and as a result are wrapped around double quotes. Also implemented an additional check to make sure the certificate's algorithm uses RSA and not others such as ECDSA.
• The WDACConfig module comprises of .ps1 and .psm1 files that bear the cryptographic signature of my local certificate authority's (CA) certificate. The module incorporates mechanisms to automatically ascertain the integrity of the module files and prevent any unauthorized modifications. The module manifest, .psd1 file, on the other hand, lacks a signature due to the installation error that arises from the PowerShell gallery when it is signed with a self-signed certificate.
• The public key of the certificate used to sign the module files can be obtained from here.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/165

What's Changed

1. Improved best practices in the code.

2. Added progress bar to the Unprotect-WindowsSecurity cmdlet, now all the cmdlets of the module have progress bars!

3. The Unprotect-WindowsSecurity cmdlet now prompts for confirmation using native PowerShell methods. This prompt can be bypassed if you use the familiar -Force parameter, useful when not running this module interactively.

4. Removed untrusted font blocking which was an optional additional policy in the Miscellaneous category. The reason for its removal is mentioned here and its removal was suggested a while ago in this repo as well. The reason why it's finally being removed is that it can cause some blocked fonts logs to be generated for 1st party inbox apps such as OneDrive.

5. Removed the UAC: Behavior of the elevation prompt for standard users policy from the User Account Control (UAC) category because it's already being applied by Microsoft Security Baselines. The security baselines correctly prevent any elevation of request on Standard user accounts.

   • The compliance checking and verification for this policy continues to exist in Confirm-SystemCompliance cmdlet.

   • For highly secure scenarios, use Standard account for regular everyday tasks, and if you want to perform administrative tasks such as installing a program system-wide or changing system settings, completely log out of the Standard account and log into an Administrator account, perform the tasks, then completely log out and log back into the Standard account to continue your work. No fast user switching.

6. The module now supports environments where C is not the OS drive's label.

7. Made the policy that requires CTRL + ALT + DEL at lock screen optional for accessibility reasons. It's in lock screen category.

8. Added CSP links for the policies included in the compliance checking CSV file.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/161

What's Changed

1. Added VS Code workspace file to offer easy debugging of the module.
2. Implemented a lot of best practices in the code to make it safer, faster and better.
3. Invoke-WDACSimulation is now a lot faster and supports more file rules.
4. Added progress bar to Invoke-WDACSimulation. More cmdlets will have it in the future.
5. Added verbose messages all over the module. Use the common parameter -Verbose with each cmdlet to get extra messages about what's happening under the hood.
6. Changed a lot of messages that used be displayed with -Debug parameter to be displayed when -Verbose is used.
7. Improved Windows build number detection
8. Bumped required PowerShell version to 7.4.0 due to the new features implemented.
9. Completely restructured and reengineered the WDACConfig module
10. Increased the required version for SignTool.exe to 10.0.22621.2428 which is available in the latest SDK

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/160

What's Changed

1. Improved colored texts
2. Fixed an error related to flash drive selection in BitLocker category - https://github.com/HotCakeX/Harden-Windows-Security/pull/155
3. Improved visual spacing of Optional Windows Features category - https://github.com/HotCakeX/Harden-Windows-Security/pull/156
4. 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.
5. 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.
6. 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.
7. Improved execution speed by at least 8 seconds
8. 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.

PRs: https://github.com/HotCakeX/Harden-Windows-Security/pull/158 - https://github.com/HotCakeX/Harden-Windows-Security/pull/155 - https://github.com/HotCakeX/Harden-Windows-Security/pull/156

What's Changed

1. Added Multifactor Authentication to the BitLocker category. When you run the BitLocker category, you will be presented with the option to choose between Normal and Enhanced security levels. The Normal security level is the previous method where the OS drive (your device) needed TPM + Startup PIN to be unlocked. The Enhanced security level adds one more factor to the authentication, requiring an external flash drive containing a special encryption key to be inserted into your device prior to the authentication.

   • So, with Enhanced security level of the BitLocker, you will have to enter a Startup PIN And have a flash drive containing a special key, in order to unlock your device. The TPM also needs to attest to the authenticity of the BitLocker encryption key. These 3 factors result in multifactor authentication and make it nearly impossible for any unauthorized person to access your device. The Readme has also been updated with information regarding this additional feature.

2. Fixed a problem with OneDrive's Personal Vault, it wouldn't be initialized if a certain policy related to BitLocker was active. The policy was "Full disk encryption for fixed data drives" and it's now removed in this update. The policy is used to enforce encryption of the full space of the disk rather than only the used space. The Microsoft Security Baselines don't enable this policy. After careful consideration, came to the conclusion that it should be removed to fix the OneDrive Personal Vault initialization problem, and also it's not necessary to be enabled because the Harden Windows Security Module and script already encrypt the drives with full disk space (Used space + free space) to ensure maximum protection and confidentiality of the data at rest.

   • Enable-BitLocker PowerShell cmdlet encrypts the entire disk by default unless the [-UsedSpaceOnly] optional parameter is used, which is not the case in the module/script.

3. The latest Microsoft Security Baselines 23H2 mentions to have added support for WinVerifyTrust Signature Validation policy (aka certificate padding) but they haven't implemented it properly. More info in the comments section of this Microsoft Tech Community article. This is why this update uses registry keys to apply the Certificate padding check until that problem is officially resolved.

4. When using Unprotect-WindowsSecurity cmdlet, during the restoration of security group policies, the cmdlet now only restores settings that were changed by the Protect-WindowsSecurity cmdlet, excluding the ones applied by the Microsoft Security Baselines. This allows for a more surgical and careful restoration of the settings and will prevent any accidental changes to the settings.

5. The BitLocker category now saves the recovery password in the same format as Windows does when using the GUI to encrypt a drive.

6. The BitLocker category now has a much better UX and logic.

7. Fixed hibernate file size detection logic.

8. The Scheduled task for updating Microsoft recommended driver block rules now only runs if there is a network connection, which makes sense because it needs to download the latest block list from the official MSFT servers and apply them on the system. It also restarts itself if it fails, every 6 hours, up to 4 tries.

9. Improved variable types to be more explicit and safe. Using full variable type names instead of their aliases.

10. Using 'Unrestricted' instead of 'Bypass' when setting the execution policy for the current process. Unrestricted is more secure than Bypass because if a script is code signed then tampered, you will see an error, but in bypass mode, no code sign tamper detection happens. The execution policy is also saved prior to running the script and is restored at the end.

11. Improved Hyper-V group member detection by using SIDs instead of account names. This makes it more robust and the comparison logic has also been improved. This change makes everything more inclusive by working in situations where the usernames contain non-English alphabets, lots of spaces and such. Or when the username is the same as the computer name.

12. The required PowerShell Core version is now the latest version which is 7.4.0. It has many new features, one of which is having -ProgressAction common parameter. Using this new common parameter and setting it to SilentlyContinue for Invoke-WebRequest and Invoke-restMethod cmdlets allows for the removal of the customInvoke-WithoutProgress function since it renders it unnecessary.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/154

What's Changed

1. The Compliance Checking Confirm-SystemCompliance cmdlet now verifies and shows the encryption status of the non-OS drives as well to ensure they are properly encrypted with BitLocker.
2. Improved the performance of the Confirm-SystemCompliance cmdlet by reducing the number of times Get-MpComputerStatus and Get-MpPreference cmdlets were called.
3. When applying the hardening measures, you will see a much better and detailed progress bar.
4. In BitLocker category, the hibernation won't be set to full if it's in that state already, reducing the execution time of that category.
5. Removed PrintDialog.exe that was a placeholder for the script and module to remove its process mitigations. It was a graceful removal. Reminder that you can run the "Unprotect-WindowsSecurity -OnlyProcessMitigations" to remove only the process mitigations.
6. Required PowerShell core version is now 7.3.8

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/153

What's Changed

1. Fixed a bug that could happen in rare cases where a user's PC name and username are the same, for example your PC name is admin and your username is admin as well. This would throw an error when creating the scheduled task to automatically update the Microsoft recommended driver block rules in Microsoft Defender category. I also made improvements to this process. The scheduled task now registers (using SID) and runs under the SYSTEM account, and is no longer bound to the current Administrator account or its name. This gives the task resiliency so if you delete your current Admin account or change it, the scheduled task will remain intact and continue to function properly. While fixing this bug, I also found an issue and submitted a feedback for it in Feedback hub.
2. Improved the overall verbosity of the module by reducing items shown on the PowerShell console. Any errors or unexpected behaviors are clearly shown to the user.
3. Increased the required build number to 22621.2428, in preparation for 23H2 features infusion. That build was released almost a month ago so users have had ample time to keep their OS up to date.
4. Fixed the following issues: https://github.com/HotCakeX/Harden-Windows-Security/issues/151 and https://github.com/HotCakeX/Harden-Windows-Security/issues/152 by adding a new override here.
5. Certificate Padding Check or WinVerifyTrust that used to be applied using registry (In the Miscellaneous category) is now applied by group policy. Microsoft Security Baselines 23H2 added templates for this.
6. Removed the optional policy from Lock Screen Category that would offer to set Windows Hello PIN as the default credential provider and would also disable Password and WLID (Windows Live ID) credential providers. The reason for this removal is that it's no longer necessary to apply it.
   • Windows 11 23H2 now automatically can hide the password option when using Windows Hello for Business, more technical details here
   • If your personal device has fingerprint scanner and/or camera used with Windows Hello and you're using the Don't display last signed-in from the Lock screen category, you will be able to easily use your face or fingerprint to sign into Windows, even though the lock screen doesn't reveal which user accounts exist on the computer and asks you to supply both username + password.
   • The removal of password credential provider would prevent you from using RDP to connect to Azure VMs.
   • This optional policy was not reliable enough because it set PIN as the credential provider whereas maybe the user preferred to use face or fingerprint as the default authentication method.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/150

What's Changed

• Improved displayed output of the LGPO.exe on the PowerShell console; It no longer displays the same message over and over again when applying policies because using Quiet mode now. This doesn't suppress errors or anything else.
• Improved BitLocker category's displayed messages for non-OS drives.
• Fixed constant variables options.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/148

What's New

• Microsoft Security Baselines updated to version 2023 (23H2) which was released an hour ago, another link. The time is relative to the creation of the PR release note.
• Improved the Readme with the new changes described in this release notes.

Changes in Microsoft Defender Category

• Improved Process Mitigations (More about them below). Simply running the Microsoft Defender category will remove old mitigations and will apply the new ones automatically. Some mitigations such as Hardware Enforced Shadow Stack Protection (a.k.a Kernel CFG or KCFG) that are very powerful features against exploits, are only available on new CPUs, starting with Intel 12th gen CPUs. On older CPUs they simply do not have any effects.
• Reduced the number of days the quarantined items will be kept to 1 day from the previous 3 days.
• In Microsoft Defender category, Enhanced phishing protection, removed Notify password reuse, Notify malicious, Service enabled and Notify unsafe app, because they are already applied by Microsoft Security baselines. The only option that is applied by Harden Windows Security module for Enhanced Phishing Protection is Automatic data collection (formerly known as Capture Threat Windows), it's for security analysis from a suspicious website or app.
• Removed PUA blocking (Potentially Unwanted App) from Microsoft Defender because it's already applied by Microsoft Security Baselines.

Changes in Device Guard Category

• The entire Device Guard category is removed. Microsoft Security Baseline 23H2 implements the entire feature set of Device Guard in the most secure state just like the Harden Windows Security module did, so it's no longer necessary to have it as a separate and/or duplicate category. The documents related to Device Guard and Virtualization Based Security in Windows is available in the wiki.

Changes in BitLocker Category

• Improved BitLocker related code, specifically the BitLocker category for non-OS drives now has a more elaborate and slightly faster performing code. Also Improved the messages displayed on the console for non-OS drives when they are already encrypted.
• Removed Enhanced PIN for BitLocker policy because Microsoft Security baselines already apply it.
• Removed disabling power states S1-S3 policies because Microsoft Security Baselines already apply it.
• Added new policy for ensuring network connectivity in standby state on modern standby capable devices. This allows Security updates for Microsoft Defender and Windows to be downloaded and installed automatically.

Changes in Windows Networking Category

• Removed the policy that disables the LLMNR protocol (Link Local Multicast Name Resolution) because it's already applied by Microsoft Security Baselines.
  • That feature was only useful for networks that do not have a Domain Name System (DNS) server and Microsoft started ramping down NetBIOS name resolution and LLMNR. over a year ago.
• Removed the Turn off downloading of print drivers over HTTP policy because it's already applied by Microsoft Security Baselines.
  • For reference, this is the recommended and secure way of downloading printer drivers in Windows 11

Note

• It's more important than ever to apply the Microsoft Security Baselines category now that it applies many of the security measures.
• Nothing from compliance checking is removed. The policies that are removed because Microsoft Security Baselines already implement them, can be all verified using the Confirm-SystemCompliance cmdlet.

What's New in Process Mitigations / Exploit Protections

Added thorough explanations to each process mitigation in the CSV file, that will explain why they are used.

• This approach logically considers each use case of the mitigations and only implements them if there is enough information about that process that guarantees it will work 100% with the mitigation and also it makes sense to apply that mitigation in terms of security while also considering usability.

• You can always find more info about them in here: https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/exploit-protection-reference

• Removed ForceRelocateImages and RequireInfo from all 1st party executables in the process mitigations list.

  • The reason is because the former is already enabled by default system-wide and the latter is only applicable to older programs. RequireInfo still exist for 3rd party programs such as Adobe Acrobat but for 1st party programs released by Microsoft it's removed, because 1st party programs do not need it and even if hypothetically some 1st party program was missing RequireInfo, it still would do more harm than good by crashing that 1st party program.

• Removed EnableExportAddressFilter and EnableExportAddressFilterPlus from some processes that might not be compatible with it.

  • This mitigation is primarily an issue for applications such as debuggers, sandboxed applications, applications using DRM, or applications that implement anti-debugging technology.

  • Those processes that used them are likely to fall in the categories mentioned above, so to prevent any possible issues or crashes in the future, removed them from the process mitigations as a pre-emptive measure.

  • Import Address Filtering should ideally be used in conjunction with Export Address filtering in order for it to be effective. If an attacker knows you are using Import Address Filtering without Export Address Filtering, they "could" use the export method to get the address(s) for their shellcode, and vice versa.

• Removed DisableNonSystemFonts from Edge browser process mitigations because it uses DirectWrite instead of GDI and this mitigation is not required for it.

• Removed EnableRopSimExec as it only applies to 32-bit applications. Quick Assist and Adobe Acrobat that were using it are 64-bit.

• Added Hardware Enforced Shadow Stack Protection Strict mode to Edge browser and Quick Assist.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/146

What's Changed

1. Added Async feature to the downloads, significantly improves the download speeds, sometimes even x3 times in my tests (with modern PowerShell 7.3), by downloading the required files simultaneously instead of one by one.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/143

What's Changed

1. Added -OnlyProcessMitigations optional parameter to the Unprotect-WindowsSecurity cmdlet. When used, it will only remove process mitigations applied by the Protect-WindowsSecurity cmdlet. You can read more about it in the module document.
2. When applying the hardening measures, the prompt that asks you whether you want to set MSFT Defender Platform and Engine update channels to Beta will no longer be displayed if they are already set to Beta channel.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/140

What's Changed

1. Added WordPad removal to the Optional Windows Features category: Old and deprecated. None of the new features of Word documents are supported in it. Recommended to use Word Online, Notepad or M365 Word.
2. Added PowerShell ISE removal to the Optional Windows Features category: Old PowerShell environment that doesn't support versions above 5.1. Highly recommended to use Visual Studio Code for PowerShell usage and learning. You can even replicate the ISE experience in Visual Studio Code. You can access Visual Studio Code online in your browser without the need to install anything. You can also access this repository's files using GitHub CodeSpace right in your browser.
3. Improved Windows Media Player (Legacy) removal process.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/135

What's Changed

Significantly improved the Invoke-WDACSimulation cmdlet. The WDAC policy simulation is now out of the beta phase and is working very well. I've run it on more than 100k unique files belonging to multiple programs, the results have all been correct.

Some Use Cases of the Invoke-WDACSimulation cmdlet

• Have a WDAC policy and you want to test whether all of the files of a program will be allowed by the policy without running the program first? Use this WDAC simulation to find out.

• Employ this simulation method to discover files that are not explicitly specified in the WDAC policy but are still authorized to run by it. When you scan a folder to create a Supplemental policy for the files inside it, some files might not require to be mentioned in the xml policy file because they are already sanctioned using their certificate details by other files, so it would not be possible to check their availability merely by examining the XML file. Using this simulation, you will be able to confirm their eligibility and whether or not they are permitted by the WDAC policy, using robust automated methods of verification.

• Identify files that have hash mismatch and will not be permitted by WDAC engine using signature. These files are typically found in questionable software because they are tampered with. They are still incorporated into the WDAC policy based on their certificate signature but when you execute them you will receive a blocked message. Use this WDAC simulation feature to detect them without running them first.

• And more.

Continue reading about this cmdlet in this document

Related PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/134

What's Changed

1. Added a new cmdlet named Remove-CommonWDACConfig, used for removing individual items from the user configurations Json file. You can read more about this new cmdlet here.
2. Improved the parameters of the Confirm-WDACConfig cmdlet by incorporating dynamic parameters.
3. The WDACConfig module now only checks for updates if at least 10 minutes have passed since the last update check.
4. Substantially improved the workflow of the Deploy-SignedWDACConfig cmdlet. It's smarter now when dealing with signing and deploying the strict kernel mode policies.
5. To prevent infinite nested looping for update checks, the 3 cmdlets that are also internally used, Get-commonWDACConfig, Set-CommonWDACConfig and Remove-CommonWDACConfig do not perform module update checks.
6. Improved New-KernelModeWDACConfig cmdlet, specially for when you just want to create a Strict kernel mode policy and then use the Deploy-SignedWDACConfig cmdlet to sign and deploy it. Lots of automation and abstractions have been added to make the process as automated and smooth as possible.
7. Changed some of the displayed messages in Remove-WDACConfig cmdlet to be only shown if -Debug parameter is used.
8. Removed -DeleteUserConfig parameter from Set-CommonWDACConfig cmdlet, because all deletion/removal operations related to User Config file is now handled by Remove-CommonWDACConfig cmdlet.
9. Updated all of the WDACConfig module's documents, check them out here.

Related PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/133

What's Changed

An Edge browser policy named WebRtcRespectOsRoutingTableEnabled is being removed. Its value in the registry changes to Delete, so that when you run the Edge category next time, it will be removed from your Edge policies.

Why

It causes problem when using Discord voice chat (WebRTC) in Edge browser while using a VPN such as Mullvad that has tight kill switch and anti-leak functionality.

You can read more about that policy here: https://learn.microsoft.com/en-us/deployedge/microsoft-edge-vpn-split-tunneling

The problem is mainly caused by 3rd party VPN software and their features. As you can see in the official article linked above, the policy is used to allow split tunneling using corporate VPNs, the ones built in Windows such as SSTP or IKEv2.

What's Next

You can use Protect-WindowsSecurity cmdlet and run the Edge browser category to apply the change if you are using a VPN + Discord in Edge browser + Voice chat and getting "no route" error.

If you aren't experiencing that issue then there is nothing you need to do.

This change doesn't decrease security whatsoever.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/132

What's Changed

1. Fixed an issue that is actually related to a Windows PowerShell module: https://github.com/HotCakeX/Harden-Windows-Security/issues/127 - Thanks @Ainatar
2. Compliance checking now skips items that are not applicable to the system, such as checking for hibernation on virtual machines; Adjusts the final score accordingly.

PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/128

TL/TR

This update improves the overall experience of the WDACConfig module, makes it easier to work with and implements various new checks to ensure user error is minimal. The goal is to minimize accidental user errors as much as possible by implementing useful and intelligent checks in multiple parts of the module.

What's Changed

1. When using Deploy-SignedWDACConfig to sign and deploy a WDAC policy, you will only see the prompt asking to add the signed policy to the user configurations, if the policy you are signing and deploying is a base policy.
2. Improved Temp folder path detection to be more secure and resilient.
3. Improved User profile directory detection to be more secure.
4. In New-SupplementalWDACConfig cmdlet, changed the parameter name -FilePathWildCards to PathWildCards to better reflect its purpose.
5. In New-SupplementalWDACConfig cmdlet, changed the parameter name -WildCardPath to FolderPath to better reflect its purpose.
6. Added GUI for New-SupplementalWDACConfig -PathWildCards -Path, it automatically adds a * wildcard at the end of the path and you can add extra wildcards to anywhere in the selected folder path too.
7. Made the generated policy file names and policy names consistent across all WDACConfig module's cmdlets.
8. When using -Deploy parameter with New-SupplementalWDACConfig cmdlet, if the selected base policy is a Signed policy, you will see an error stating that you should use Deploy-SignedWDACConfig cmdlet to deploy Signed policies.
9. Removed the manual MDAV scan of the UserConfigurations.json file since Defender already scans all of the files on access.
10. Relocated some of the parameters of the Set-CommonWDACConfig cmdlet to be easier to work with.
11. Improved some console output spacing for New-WDACConfig cmdlet.

What's Changed

1. Updated the Temp folder path detection by using a more robust and secure method that doesn't rely on pattern matching when the path is long and has spaces. Fixed this issue https://github.com/HotCakeX/Harden-Windows-Security/issues/123 - Thanks @drazenmilovanovic
2. Improved the ASR rule detection by using cmdlet instead of registry/group policy, this checks the effective state of the ASR rules even if you didn't use the Protect-WindowsSecurity cmdlet to apply them, Fixing this issue: https://github.com/HotCakeX/Harden-Windows-Security/issues/121 - Thanks @mbcomptech