Harden Windows Security v0.6.4 - 24H2 Update

[HotCakeX]

What's New

This release ensures that the Harden Windows Security module/app is compatible with the Windows 11 24H2 build. The latest Windows build introduces numerous new group policies for configurations that were previously accessible only through methods like CIM. Consequently, many of these configurations are now implemented via group policies, providing a more streamlined and unified process.

The Readme content and style have been updated for better readability. A reminder that the Readme document is the main source of all of the security measures that is applied by the Harden Windows Security module/app.

All of the registry keys, policies, process mitigations and so on have been verified to continue to be compatible with the latest build of Windows, which currently is 24H2.

More policies will be added in the next update after further testing and verification.

Updated the DLLs from Microsoft Nuget packages to the latest versions.

Microsoft Defender Category

• Intel TDT policy is now applied through Group Policy.
• Disabling Performance mode of Microsoft Defender (For Dev Drives) is now applied through Group Policy.
• Real-time protection and Security Intelligence Updates during OOBE policy is now applied through Group Policy.
• Brute-Force Protection policy is now applied through Group Policy.
• Brute-Force Protection aggressiveness policy is now applied through Group Policy.
• Remote Encryption Protection policy is now applied through Group Policy.
• Remote Encryption Protection aggressiveness policy is now applied through Group Policy.

---

• New policy: Enable Network Protection to be configured into block or audit mode on Windows Server.

---

Identified 2 issues with the group policies on build 26100.1742 and 26100.1882. Mentioned them in the Microsoft Tech Community as well.

The following group policies do not actually apply the policies on the system when they are enabled in the specified build.

Windows Components\Microsoft Defender Antivirus\Network Inspection System\
Turn on asynchronous inspection

And

Windows Components\Microsoft Defender Antivirus\Network Inspection System\
Convert warn verdict to block

After applying them and checking the output of the cmdlet/CIM via the Get-MpPreference, even after system restart, we can see that the values of EnableConvertWarnToBlock and AllowSwitchToAsyncInspection are still false.

That is why the Harden Windows Security module will continue to enforce and apply them through the CIM. The checks and balances in the module/app make sure everything stays compliant regardless of the method of enforcement.

---

• During Process mitigations compliance verification, if a process has more mitigations applied to it than the ones required by the Harden Windows Security application, it will be considered compliant. Previous behavior would only consider them compliant if they were exact match but that would miss the situations where currently applied mitigations were more than the required mitigations. The log messages have been improved to provide detailed info about each process.

BitLocker Category

• Added more logging messages during compliance checking of the BitLocker category to let user know why OS drive is not compliant.

• BitLocker group policies are completely self-sufficient and no longer depend on the Microsoft Security Baselines.

• Improved the BitLocker encryption for Non-OS Drives. The ExternalKey key protectors that belong to previous OS installations and are leftovers are now properly taken care of and renewed to be bound to the new OS Drive.

User Account Control (UAC) Category

• New Policy: Sets the behavior of the elevation prompt for Standard users to Prompt for Credentials on the Secure Desktop. Microsoft Security Baselines 23H2 would set this to Deny elevation requests but since Windows is moving towards the Adminless future, it is required to perform elevation from Standard users. This policy ensures that the elevation prompt is secure and the user is prompted to enter the credentials on the Secure Desktop.

• Added this only for compliance checking: UAC: Behavior of the elevation prompt for administrators in Enhanced Privilege Protection Mode. This policy is by default set to the most secure value, which is Prompt for Credentials on the Secure Desktop. Adding it to compliance checking in the UAC category provides easy verification for the user to ensure it is set to the correct value because it is an important policy.

• New policy: Configures the type of Admin Approval Mode to be Admin Approval Mode with enhanced privilege protection. This is another new policy added in the build 24H2.

Windows Update Category

There are no configuration changes. Only updated the group policy objects to match the new policies' locations in the 24H2 build. All of them are related to update auto-restart grace period and deadlines and how their locations are different between 23H2 and 24H2 builds.

• The SetComplianceDeadline policy is changed. In 24H2, it is broken down to 2 different policies. They are also Intune compatible which means unified compliance check between group policy or Intune deployments.

  • ConfigureDeadlineNoAutoRebootForFeatureUpdates

  • ConfigureDeadlineNoAutoRebootForQualityUpdates

Optional Windows Features

There is a bug in Windows 11 24H2 builds 26100.1742 and 26100.1882, related to the DISM module cmdlet, Get-WindowsCapability -Online and Internet Explorer mode! Watch the video:

https://github.com/user-attachments/assets/0ac4cabb-447c-4418-86bc-a690a5d422e2

As a workaround, Internet explorer mode removal was moved to the end of the Optional Windows Features category instead of being in the middle. This change makes sure the category will complete successfully.

The problem with the cmdlet will most likely be fixed after a system restart. That means when Internet explorer mode which is for the legacy rendering in the Edge browser and is totally unnecessary, is removed, you will have to perform a system restart before that cmdlet can be used again.

As you can see in the video, this is not related to the Harden Windows Security.

Non-Admin Category

• Removed the 2 policies that were used to enable Clipboard syncing for the current user. They were an optional sub-category of the Non-Admin category.

[agpt8]

• Does this version also include security baseline overrides mentioned in this comment? The docs does not seem to show this and I also dont see these in the release notes or the code...? Is this still coming?

• The baseline suggests enabling performance mode in Defender, yet the module turns it off. Should it remain disabled?

• Also, in the overrides wiki, I think point 8 is now handled already in the baseline and can be removed.

On a sidenote, the horizontal rules added in the readme introduce a lot of noise and make it harder to read. The previous simple point-based text looks perfect! Just a thought :)

[HotCakeX]

Hi @agpt8 There are no changes other than those mentioned in the release notes. This update which took few days to complete was just to make sure the module is compatible with 24H2 Asap. More policies changes will be included in the next version.

I'll add re-enabling sudo in the next update very soon.

performance mode for dev drives is enabled by default, Harden Windows Security disables it in the Defender category. The reason is mentioned here: https://learn.microsoft.com/en-us/windows/dev-drive/#understanding-security-risks-and-trust-in-relation-to-dev-drive

If that override isn't necessary anymore i'll remove it in the next version.

I added the horizontal lines because there were no borders between each item, but i can remove it if it's making it hard to read.

[agpt8]

performance mode for dev drives is enabled by default, Harden Windows Security disables it in the Defender category. The reason is mentioned here: https://learn.microsoft.com/en-us/windows/dev-drive/#understanding-security-risks-and-trust-in-relation-to-dev-drive

Well, the page does mention "Microsoft recommends using the default performance mode setting when using a trusted Dev Drive."

[HotCakeX]

performance mode for dev drives is enabled by default, Harden Windows Security disables it in the Defender category. The reason is mentioned here: https://learn.microsoft.com/en-us/windows/dev-drive/#understanding-security-risks-and-trust-in-relation-to-dev-drive

Well, the page does mention "Microsoft recommends using the default performance mode setting when using a trusted Dev Drive."

It's all written on their docs. Microsoft recommends it because it's something they built for developers, to be faster while lowering security, it's exclusion alternative. I chose security over performance that's why it's disabled. You can flip the policy and turn it on again if you need to. I use ReFS drives with real time protection (performance mode disabled) and it's alright. But for a fast dev environment, a bunch of other things would need to be disabled, such as ASR rules that prevent unknown files from loading, or the Defender features that enable zero tolerance level.

Ultimately, i can add a preset for developers only to provide a balance between security and speed.

btw i removed the horizontal lines from readme.

[agpt8]

Understood. Thanks for clarifying!

[HotCakeX]

@agpt8 I checked the policy that's related to showing exclusions in Microsoft Defender to the local admins. The 24H2 baselines still hide them from the local admins, so there is no need for policy changes in the optional overrides.

These screenshots are taken after applying the Microsoft security baselines 24H2 without the optional overrides.

[agpt8]

Intresting! This seems like a bug? Similar to the other two policies that had no effect. Or am I wrong here?

[HotCakeX]

Intresting! This seems like a bug? Similar to the other two policies that had no effect. Or am I wrong here?

The policy they added in 24H2 baselines controls whether exclusions are visible to the local users, aka Standard users, and they hide it from the Standard users now which is fine and we can leave it like that.

The number 8 item in the optional overrides refer to showing the exclusions to the local admins, but since there is no change in that area i'm gonna leave it be so local admins can see exclusions.

The 2 policies have very similar titles, but it's all good, no bugs :)

[AaronMargosis]

The SCT's baseline recommendation for UAC elevation prompts for standard users hasn't changed. It's still "automatically deny elevation requests." UAC same-desktop elevation has never been a security boundary, and should be avoided on standard user desktops.

[HotCakeX]

The SCT's baseline recommendation for UAC elevation prompts for standard users hasn't changed. It's still "automatically deny elevation requests." UAC same-desktop elevation has never been a security boundary, and should be avoided on standard user desktops.

Hi, please take a look at this discussion post. I made that change because it appears that Windows is moving towards adminless where standard user elevation is necessary, there are 2 new policies available in 24H2 that aren't talked about in details but from what i've seen looks like they are related to the adminless mode. Another comment in the discussion post points to an insider build notes that also talks about adminless. At this year's Ignite we should see more news about adminless. I made that change to give users a chance to try out the new policies but if it's still not secure enough to elevate from Standard to Admin i can change that.

• https://x.com/dwizzzleMSFT/status/1841138426298417235
• https://x.com/mearjunsha/status/1843616498088124780

[AaronMargosis]

I don't see anything in those links that suggests that UAC same-desktop elevation from a standard user desktop is any less dangerous than it was before, nor that it will be in a future update.

[AaronMargosis]

I would stick with what the SCT baseline recommends (and the CIS benchmarks and DISA STIGs for Windows as well).

[AaronMargosis]

I would also stick with the baseline's recommendation to keep the new sudo feature disabled.

[HotCakeX]

I would also stick with the baseline's recommendation to keep the new sudo feature disabled.

It's not enabled by the Harden Windows Security policies. By default it is disabled in Windows and we let it be like that. However, user can enable it if they want to, which requires Admin privileges.

[HotCakeX]

I would stick with what the SCT baseline recommends (and the CIS benchmarks and DISA STIGs for Windows as well).

I'm not sure about the other benchmarks, they aren't too secure, take a look at this article i wrote a while back https://github.com/HotCakeX/Harden-Windows-Security/wiki/Comparison-of-security-benchmarks

[HotCakeX]

I don't see anything in those links that suggests that UAC same-desktop elevation from a standard user desktop is any less dangerous than it was before, nor that it will be in a future update.

How will the Adminless work then?

[AaronMargosis]

I would also stick with the baseline's recommendation to keep the new sudo feature disabled.

It's not enabled by the Harden Windows Security policies. By default it is disabled in Windows and we let it be like that. However, user can enable it if they want to, which requires Admin privileges.

I interpreted a comment you had made on this PR that you planned to recommend enabling sudo in the near future.

[AaronMargosis]

I'm not sure about the other benchmarks, they aren't too secure, take a look at this article i wrote a while back https://github.com/HotCakeX/Harden-Windows-Security/wiki/Comparison-of-security-benchmarks

Thanks for pointing me to that. I've been heavily (and directly) involved in the development of the MS baselines, the CIS benchmarks, and the DISA STIGs. I would like to provide some feedback on that wiki -- what would be your preferred way for me to do that?

[AaronMargosis]

How will the Adminless work then?

I don't know and I'm looking forward to hearing their details. I imagine that it will involve significant changes to Windows and ways to prevent same-desktop elevation of privilege, which is a significant risk with admin elevation in a non-admin desktop. There's a lot of shared surface within a desktop session. If the desktop user is a member of admins, EoP from non-elevated to elevated isn't considered to cross a security boundary. If the desktop user is not a member of a privileged group and has not been assigned any admin-equivalent privileges, a process in that session being able to perform or cause admin actions does cross a security boundary (and thus is an MSRC-class bug) -- but not if UAC same-desktop elevation was invoked.

[HotCakeX]

I would also stick with the baseline's recommendation to keep the new sudo feature disabled.

It's not enabled by the Harden Windows Security policies. By default it is disabled in Windows and we let it be like that. However, user can enable it if they want to, which requires Admin privileges.

I interpreted a comment you had made on this PR that you planned to recommend enabling sudo in the near future.

Oh i see it

"I'll add re-enabling sudo in the next update very soon."

sorry, what i meant was that i would enable the ability to enable sudo in the next update.

[HotCakeX]

I'm not sure about the other benchmarks, they aren't too secure, take a look at this article i wrote a while back https://github.com/HotCakeX/Harden-Windows-Security/wiki/Comparison-of-security-benchmarks

Thanks for pointing me to that. I've been heavily (and directly) involved in the development of the MS baselines, the CIS benchmarks, and the DISA STIGs. I would like to provide some feedback on that wiki -- what would be your preferred way for me to do that?

I'd prefer email: spynetgirl@outlook.com But if you prefer GitHub discussions that's okay too. Thank you!

[AaronMargosis]

sorry, what i meant was that i would enable the ability to enable sudo in the next update.

I would think the more secure choice would be to go with the SCT's recommendation to explicitly disable it. It opens EoP paths unnecessarily. If one wants to run elevated processes, just open an elevated cmd.exe or powershell.exe and run the commands from there. Fewer elevation prompts that way; and the sudo.exe elevation prompt is often misleading -- the prompt says the verified publisher is Microsoft Windows, but the target process could be anything.

[HotCakeX]

sorry, what i meant was that i would enable the ability to enable sudo in the next update.

I would think the more secure choice would be to go with the SCT's recommendation to explicitly disable it. It opens EoP paths unnecessarily. If one wants to run elevated processes, just open an elevated cmd.exe or powershell.exe and run the commands from there. Fewer elevation prompts that way; and the sudo.exe elevation prompt is often misleading -- the prompt says the verified publisher is Microsoft Windows, but the target process could be anything.

You're right, i'll implement more granular control for security baselines overrides in the future. For now it's up to the user to enable it. Unfortunately disabling it by the security baselines would completely make it disappear from the settings page and search, and i didn't want users who heard about the new Sudo feature and installed the new 24H2 build complain or wonder about where it has gone after using the module.

[AaronMargosis]

I'd prefer email: spynetgirl@outlook.com But if you prefer GitHub discussions that's okay too. Thank you!

Did you receive my email?

[HotCakeX]

I'd prefer email: spynetgirl@outlook.com But if you prefer GitHub discussions that's okay too. Thank you!

Did you receive my email?

yes i did, thank you, it seems like it's thorough and detailed, i'll answer it as soon as i can