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
MIT License
Bot releases are visible (Hide)
Published by HotCakeX 6 months ago
Introduced functionality to create a Supplemental policy based on certificate files. This enhancement enables administrators to select .cer
certificate files and authorize them within a policy. Consequently, any files signed with these certificates will be permitted to execute. The primary motivation behind this feature is to streamline the deployment and utilization of Script Enforcement scenarios.
Developed comprehensive and user-friendly documentation aimed at system administrators seeking to leverage the Script Enforcement feature within Application Control policies (WDAC). This documentation provides clear guidelines for establishing stringent boundaries around script engines, including PowerShell and similar tools.
Improved the resiliency of log parsing functions.
Added new parameter called EnableScriptEnforcement
to the New-WDACConfig cmdlet which will enable script enforcement for the base policies it creates.
Enhanced the robustness of certificate details retrieval functions for WDAC Simulation.
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/245
Published by HotCakeX 6 months ago
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/244
Published by HotCakeX 6 months ago
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/241
Published by HotCakeX 6 months ago
You can now use the WDACConfig module to convert the Microsoft Defender for Endpoint (MDE) Advanced Hunting query results directly to Application Control policy (WDAC) policy in a matter of seconds with high precision and performance.
The systematic approach to converting the query results to WDAC policy is as follows:
These levels are selected based on their security. You can read more about the levels security comparison in this article.
DeviceEvents
| where ActionType startswith "AppControlCodeIntegrity"
or ActionType startswith "AppControlCIScriptBlocked"
or ActionType startswith "AppControlCIScriptAudited"
As you can see, the WDACConfig module encapsulates all requisite logic, enabling the employment of heightened security levels for files, notably the FilePublisher. It assimilates comprehensive data, utilizing the maximum extent of available information to formulate the most precise and tailored rule for each individual file.
Supported Features | WDACConfig | WDAC Wizard |
---|---|---|
Log types | Code Integrity + AppLocker | Code Integrity |
Generated Rules | File Publisher, Publisher, Leaf Certificate, Hash | Publisher, Hash |
Requires Custom CSV Formatting | No - Accepts RAW data | Yes |
Required Query Size | Small | Large |
[!IMPORTANT]
WDAC Wizard is a great tool, it offers a GUI and can be downloaded from here
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/218
Published by HotCakeX 6 months ago
-OnlyCountryIPBlockingFirewallRules
to the Unprotect-WindowsSecurity cmdlet. It allows you to only remove the country IP blocking firewall rules without removing anything else.PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/235
Published by HotCakeX 6 months ago
This update is in response to the changes made today to the Windows Boot Manager revocations for Secure Boot in this blog post.
You can find all of the necessary information in that post.
As always, make sure you're using the latest version of the OS to stay safe and secure with the latest patches.
Today's patch Tuesday update:
https://support.microsoft.com/en-gb/topic/april-9-2024-kb5036893-os-builds-22621-3447-and-22631-3447-a674a67b-85f5-4a40-8d74-5f8af8ead5bb
Related discussion announcement: https://github.com/HotCakeX/Harden-Windows-Security/discussions/230
Q: What about the old procedure?
A: If you applied the old procedure either manually by following the official article or using the Harden Windows Security module, then you're good to go and don't need to make any more changes. If you never applied the mitigations, you can read the article and see if you want to follow it and apply the new mitigations manually, or just wait until they are automatically applied to your device in the near future through Windows Update.
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/229
Published by HotCakeX 7 months ago
The Harden Windows Security Module (and script) now feature a user-friendly Graphical User Interface (GUI). This allows users the flexibility to apply security hardening measures through either the traditional Command Line Interface (CLI) or the intuitive new GUI, catering to both advanced users and those who prefer a more visual approach.
This version aims to be more informative and engaging, emphasizing the added convenience and user choice.
The GUI was created with accessibility in mind. It is responsive and does not need any dependency or additional files. You can even run it fileless by using the GitHub link from this repository and pasting it on your PowerShell console.
If you have any feedbacks, feel free to open new issues, I already have some improvements in mind that will be introduced in later versions of the module.
The GUI works for both offline and online modes
Protect-WindowsSecurity -GUI
LogPath
parameter of the Protect-WindowsSecurity
cmdlet.PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/221
Published by HotCakeX 7 months ago
Set Block use of copied or impersonated system tools Attack Surface Reduction rule to Warn and block instead of block. In this mode, it will block the action but display a notification toast allowing you to unblock the action if you want. It's in preview state so this change should allow you to have more control over its operation in case it inadvertently blocks a process. If you want to apply this new change just run the ASR category again.
Thanks to @agpt8 for the post about this.
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/220
Published by HotCakeX 7 months ago
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/211
Published by HotCakeX 8 months ago
VirtualMachinePlatform
from the Optional Windows Features category since WSA is deprecated.PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/212
Published by HotCakeX 8 months ago
Configures the Brute-Force Protection to use cloud aggregation to block IP addresses that are over 99% likely malicious CSP
Configures the Brute-Force Protection to detect and block attempts to forcibly sign in and initiate sessions CSP
Sets the internal feature logic to determine blocking time for the Brute-Force Protections CSP
Configures the Remote Encryption Protection to use cloud intel and context, and block when confidence level is above 90% CSP
Configures the Remote Encryption Protection to detect and block attempts to replace local files with encrypted versions from another device CSP
Sets the internal feature logic to determine blocking time for the Remote Encryption Protection CSP
To leverage the new features, the minimum required OS version has been increased from 22621.2428
to 22621.3155
. It was released on February 13 2024 and is a non-preview, stable build of Windows 11.
Added new parameter -OnlyDownloadsDefenseMeasures
to Unprotect-WindowsSecurity cmdlet which allows you to only remove the Downloads Defense Measures without changing anything else.
Removed certain built-in executables such as SystemSettings.exe, ngen.exe, LSASS.exe, RuntimeBroker.exe and ngentask.exe from the Unprotect-WindowsSecurity cmdlet because they have pre-existing mitigations applied to them and the cmdlet shouldn't remove them.
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/210
Published by HotCakeX 8 months ago
Some paths are accessible to any user, while others are restricted to Administrator-level privileges. These paths have different security levels and non-elevated processes cannot access them. Based on these facts, the WDACConfig module has been upgraded to utilize the more secure paths.
If the WDACConfig module is located in the Documents folder, which is the default setting, a malicious program without elevated privileges could manipulate its files and interfere with its functionality.
Therefore, it is strongly advised to install it with the AllUsers scope
Install-Module -name 'WDACConfig' -Scope AllUsers
Which will increase its protection against unauthorized access by installing it in the following path
C:\Program Files\PowerShell\Modules\WDACConfig
Which is guarded by Administrator privileges. When the module auto-updates, it will also be installed in that path.
Previously, the WDACConfig module saved user configurations in the following path
C:\Users\UserName\.WDACConfig\UserConfigurations.json
This directory is accessible to any user, and a malicious program or process without elevated privileges could manipulate its files. Therefore, the WDACConfig module has been upgraded to save user configurations in the following path
C:\Program Files\WDACConfig\UserConfigurations\UserConfigurations.json
[!NOTE]
In this release, the module automatically moves the user configuration file from the old location to the new one if it doesn't already exist in the new location. This feature is only added temporarily to smooth the transition and will be removed in the next version.
The module now uses a secure staging area located in
C:\Program Files\WDACConfig\StagingArea
for all of its operations, including but not limited to: creating, modifying, signing, generating, removing, and simulating WDAC policies. This directory is cleaned up after each operation unless the -Debug
parameter is used with the cmdlets that support it. No file operation is performed outside of this area.
Assigned WHQLFilePublisher
as the default value for -Level
and FilePublisher, Hash
as the default value for -Fallback
parameters in all of the cmdlets that support them. This increases security by taking into account the WHQL EKU of any possible drivers in the files being scanned. Read about the comparison of each level in this document.
FilePublisher
and the default fallback was Hash
.Added a new parameter called -CipFile
to the Test-CiPolicy cmdlet for displaying signer information in the signed .CIP
files. This is done because the normal Get-AuthenticodeSignature
cmdlet does not reveal a .CIP
file's signatures.
Enabled OS indicators during WDAC Simulation, this enables Windows Terminal and the taskbar to display little indicators about the progress of the simulation. Also made the progress bar fancier by showing dynamic colors.
Improved the speed of WDAC Simulation when calculating the Authenticode file hashes.
Added a new parameter called -CSVOutput
to Invoke-WDACSimulation cmdlet, indicating the cmdlet will create a CSV file containing the simulation results. Previously, this parameter didn't exist and the cmdlet would always create the CSV output. Now users have more options to control that behavior.
Added a confirmation check to the Remove-CommonWDACConfig cmdlet when invoking it without any additional parameters, because in that mode it deletes all of the saved user configurations for the WDACConfig so as a relatively high risk action it is now put behind an extra check. It can be bypassed with the familiar -Force
parameter.
Added file picker GUI to various parameters of the Edit-SignedWDACConfig and Edit-WDACConfig cmdlets.
Hardened more variable types.
Improved Certificate common name detection by using Windows APIs instead of custom regex patterns.
Refined the logic for both Edit-SignedWDACConfig -UpdateBasePolicy and Edit-WDACConfig -UpdateBasePolicy to handle the case where multiple policies with the same name are deployed and the user selects that name.
Simplified the parameters of the New-KernelModeWDACConfig cmdlet.
Added progress bars to ConvertTo-WDACPolicy.
Lots of code optimization and refactoring that led to reduced code base while adding more functionality at the same time. Thanks to @mklement0 for his help with parts of this.
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/206
Published by HotCakeX 8 months ago
Added 3 new policies to the Optional Overrides. These 3 policies alter the settings that are applied by Microsoft Security baselines.
in Computer Configuration -> Administrative Templates -> Windows Components -> Cloud Content
The reason is that in Windows 11 build 22635.3209, which is currently in the Windows insider Beta channel, new features are available in settings
If that policy was left in the enabled state, the settings page would look like this
Which is obviously not desired as the Harden Windows Security module should not create obstacles or cause difficulties for using built-in features.
Thanks @agpt8 for reporting it!
in Computer Configuration -> Administrative Templates -> System -> LAPS
Microsoft Security Baselines set it to this value
But since the Harden Windows Security module does not apply to computers managed by domain controllers or Entra ID, there is no need for this policy to be active. That is why the policy is now set to this state
in Computer Configuration -> Administrative Templates -> MS Security Guide
Microsoft Security baselines set it to Disabled state. Not sure why exactly, probably a legacy feature in domain controller environments rely on it.
Either way, it's a security feature that is enabled by default in Windows, so the Optional Overrides set it back to the enabled state.
You can learn more about that feature in here
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/207
Published by HotCakeX 8 months ago
-Level
and -Fallbacks
parameters from New-DenyWDACConfig -Drivers
and instead assigned WHQLFilePublisher to the level and None to the fallbacks. The created policies always enforce WHQL criteria and since the drivers are being scanned, WHQLFilePublisher is the best level to use..bat
and .ocx
file types do not support Authenticode signing, the simulation no longer checks for their signature, leading to overall performance improvements.PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/202
Published by HotCakeX 8 months ago
Updated all of the WDACConfig module documents to match the style of Microsoft Learn markdowns to offer a familiar experience when reading them.
Added validation against the Code Integrity schema for any XML file that is loaded into the WDACConfig module.
The Deploy-SignedWDACConfig
is now able to perform a WDAC simulation on the SignTool.exe
in order to find out whether the base policy that the user is trying to create/deploy will allow the SignTool.exe to run or not. This is important because if you deploy a policy that does not allow the SignTool.exe
to run then you cannot remove or modify that signed policy, (unless you use a VM or another computer to create a supplemental policy that allows the SignTool.exe
to run). This is the first time the Invoke-WDACSimulation
cmdlet is being used internally.
-SignToolPath
and -IncludeSignTool
parameters from the New-WDACConfig
cmdlet since they are no longer needed as their jobs have been automated.Hardened many variable types.
Properly distributed C# and WDAC Simulation resources.
No longer using regex to process and remove 'allow all' rules from Microsoft recommended block rules, instead using Xpath and other native robust methods to perform those tasks, the generated policy is fully compatible with the CI Policy Schema.
Added a new cmdlet named Test-CiPolicy, you can use it to validate XML files to make sure they are compliant with the CI Policy Schema, for example if you manually edited a WDAC policy XML file yourself and you want to make sure it will work properly.
Improved folder name when using New-WDACConfig -MakePolicyFromAuditLogs
to generate policy from audit logs. It no longer uses the generic 'WDAC' name and instead prepends the current time and date to it for better UX.
The Strict Kernel-mode (BYOVD protection) policy now uses WHQLFilePublisher
as level. Previously it used FilePublisher
. This adds extra protection by requiring the certificates of the kernel-mode drivers to have WHQL EKU.
Added support for WDAC simulation with individual files. Previously you'd only have the option to select a folder.
The Invoke-WDACSimulation
cmdlet now outputs objects and all the required informational strings are displayed in the verbose stream, allowing you to process its output in a more flexible way.
Added a new parameter to the Invoke-WDACSimulation
cmdlet called -BooleanOutput
. When this parameter is used, the cmdlet will return a boolean value instead of an object.
Added logic for handling template policies that don't reveal the TBS value of the signers. This improves the WDAC Simulation against those templates. More info here
The WDAC Simulation engine now supports the following levels: (Support for the remaining levels will be added in a future update)
To enhance the precision and reliability of the simulation outcomes, the engine now validates the EKUs of the signers against the EKUs of each file and if there is a mismatch, the file will be listed as Not Allowed - EKU requirements not met
The engine supports all of the SpecificFileNameLevel options when validating the FilePublisher level.
The Invoke-WDACSimulation
cmdlet now supports a new parameter, -Log
, which creates a text file with the complete console output. For optimal transparency into the process and the authorization status of each file, it is advisable to use the -Verbose parameter along with it.
[!IMPORTANT]
About Accuracies
- The engine can determine with 100% accuracy whether a file is authorized by a given policy or not as long as the file was scanned based on one of the supported levels mentioned above.
- The
SpecificFileNameLevel
is established with 99.99% accuracy. The only exception is when a file is damaged in a manner that impairs the detection of its additional attributes. However, this is a rare occurrence, as I have not encountered any such file in over 1 million tests.
Explicit Deny rules are not taken into account during simulation. Support for them will be added in a future update. The nature of the WDAC policies is whitelisting and anything not mentioned in them is automatically blocked/denied.
The cmdlet internally tags each signer in the policy file indicating its mode: Kernel, User, Update policy, or Supplemental policy. This information will be used in future enhancements to augment the engine’s intelligence.
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/198
Published by HotCakeX 9 months ago
Following empirical and logical evaluations, mitigations for Rundll32.exe and several Protected Process Light (PPL) processes have been implemented. These are Defense in Depth measures that augment the security of the PPL processes, which already necessitate Administrator privileges to be compromised with a zero-day vulnerability.
These mitigations are auditable and generate an event log when they prevent an intrusion. You can conveniently view the logs by running the Miscellaneous category in the Harden Windows Security module, which creates custom views in the Event Viewer. One of the custom views is Exploit Protection Events, which contains the logs for the exploit protection measures.
[!NOTE]
MsMpEng.exe can have the mitigation that prevents loading Non-Microsoft signed code into the process too, but due to tamper protection, it can't be programmatically configured, not even with SYSTEM privileges. The user would need to manually use the Windows Security GUI to add that mitigation for it. It is a component of Microsoft Defender called Microsoft Malware Protection Engine.
[!NOTE]
Other PPLs already enforce Microsoft signed code (Signature Code Integrity) by default, that's why the mitigation wasn't added to them.
[!NOTE]
rundll32.exe can't have Microsoft Signed code enforced on it because there are 3rd party software such as Nvidia shadow play (part of the GeForce Experience program) that inject non-Microsoft signed code into that process.
[!NOTE]
In a previous release note there was a mention of an unsigned file that was causing some problems with a policy that adds mitigations for Svchost.exe. That issue has been resolved as Microsoft has digitally signed the file.
Improved verbosity for when -Verbose
parameter is used with Confirm-SystemCompliance
and Protect-WindowsSecurity
cmdlets.
The Confirm-SystemCompliance
now verifies the applied process mitigations too and their results are included in the final security score. This happens in the Microsoft Defender category.
The Confirm-SystemCompliance
now verifies the status of Smart App Control and includes it in the final security score. Smart App Control is a great automated AI-based security feature.
Improved the nested data rendering in the CSV file output when using Confirm-SystemCompliance -ExportToCSV
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/193
Published by HotCakeX 9 months ago
New-KernelModeWDACConfig
cmdlet no longer needs to clear the Code Integrity Operational event logs to create a strict kernel-mode policy for BYOVD protection, it can now intelligently detect kernel-mode drivers that ran after the audit mode policy was deployed on the system. Its documentation has also been updated.PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/191
Published by HotCakeX 9 months ago
Full offline capability added. This mode operates independently of Microsoft servers or GitHub, without checking for updates or downloading any files. You must supply paths to the Microsoft Security baseline, the Microsoft 365 Enterprise apps security baseline, and the LGPO. These files should be in .zip
format, as they are when downloaded from the Microsoft Security Compliance Toolkit.
-Offline
parameter activates offline mode. This mode requires three additional parameters that specify the paths to the required files on your local system. The parameters validate the selected .zip
files to ensure they contain the right files and avoid accidental errors. You can also use the file picker GUI by pressing the Tab key to browse for the files graphically.Detailed logging, activated by the new -Log
parameter. When you use this parameter, another parameter will be available to you, called -LogPath
, you can use it to choose a name and path for the log file to be saved, otherwise the log file will be saved in the current working directory and will have a dynamically generated name that also contains the current time and date.
Added block remote image load exploit mitigations to the following PPL processes: Csrss.exe, Services.exe and Lsass.exe to prevent loading of DLLs from network locations such as SMB - WebDAV - etc. This is a proactive defense-in-depth strategy because to achieve exploits like that one needs to gain administrator privileges first. More PPLs will be added eventually once enough testing has been done.
Improved the verbose messages. Highly recommended to use the -Verbose
parameter when using the -Log
parameter to enable detailed logging.
Added execution time calculation to the log file so you will know how long it took to run the Protect-WindowsSecurity
cmdlet.
Updated the module documentation.
Bumped the minimum required PowerShell version to 7.4.1
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/184
Published by HotCakeX 9 months ago
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/181
Published by HotCakeX 9 months ago
New-WDACConfig -SetAutoUpdateDriverBlockRules
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/180