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 hidden (Show)
Published by HotCakeX 2 months ago
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/317
Published by HotCakeX 2 months ago
The ConvertTo-WDACPolicy command now shows blocked and audited events by default unless you use the -LogType
parameter to narrow it down. The previous default behavior was Audit logs only.
The ConvertTo-WDACPolicy now has a new optional parameter called -Level. The level determining rule generation can be one of the following: Auto, FilePublisher, Publisher, or Hash.
The fallback level is always Hash.
By default, which is the same as not using this parameter, the most secure levels are prioritized. If a log contains the requisite details for the FilePublisher level, it will be utilized. If not, the Publisher level will be attempted. Should this also fail, the Hash level will be employed.
Enterprises and organizations typically favor the Publisher level over FilePublisher for its streamlined maintenance, making this adjustment particularly advantageous for these user groups.
The Edit-SignedWDACConfig
and Edit-WDACConfig
commands now support the same levels that the ConvertTo-WDACPolicy
supports when creating policy based on the event logs.
Improved globalization to ensure compatibility with any culture.
Provided ready to use Visual Studio solution (.NET 9).
ConvertTo-WDACPolicy -PolicyToAddLogsTo
now supports policies that contain Macros.
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/312
Published by HotCakeX 3 months ago
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/314
Published by HotCakeX 3 months ago
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/311
Published by HotCakeX 3 months ago
🦄 Transitioning from conventional registry-based verifications to assessing the Effective Status of implemented security settings wherever feasible in a hybrid way. This approach engages deeply with the operating system, ensuring greater accuracy.
🔥Intune policies verification. The Compliance checking is no longer limited to only Group Policy/Registry settings. If your workstation is controlled using Intune (modern workplace management) then you can use the Harden Windows Security module to verify the implementation of the policies and see what security score you receive according to this repo's guidelines.
Over time, more policies will be added for auditing, especially those in the Microsoft Security Baselines that are available as group policy packages and in the Intune portal.
Currently, over 160 policies are supported to be verified when they are applied through Intune portal. This number will keep going up in future updates.
✅ Added title and custom icon to the Harden Windows Security GUI.
✅ Re-implemented the entire compliance checking logic natively in C# achieving enhanced execution speed, strictly typed code, and a more interoperable codebase.
✅ Adjusted some compliance checks to be more practical.
☁️ Updated many of the Intune policies.
✅ Implemented many of the remaining policies in Intune CSPs ready to be consumed.
✅ Removed the SpecialPollInterval
that would configure the Windows time sync interval. When you run the Miscellaneous category next time, its registry key will automatically be removed if it exists. The reason for the removal is that Windows now has an even lower time interval by default, so this policy is no longer necessary.
✅ Added a new policy to the Miscellaneous category: a policy that requests claims and compound authentication for Dynamic Access Control and Kerberos armoring.
♾️There is a new record for the execution speed of the Confirm-SystemCompliance
cmdlet. It now completes in only 7 seconds, all categories of it. This improved speed is despite the fact that so many new features were added and a lot more data sources are being processed.
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/308
Published by HotCakeX 3 months ago
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/307
Published by HotCakeX 3 months ago
Confirm-SystemCompliance
output.PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/302
Published by HotCakeX 3 months ago
Provided Intune policy files for the remaining categories.
Fixed compliance checking total displayed number. It would show an increased total number after the first run in the same session.
Updated the BitLocker wiki page with additional info regarding key protector setup using Intune and Group Policy.
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/300
Published by HotCakeX 3 months ago
Added Intune policies to the repository for enterprise folks who want to quickly and easily add the same policies described in the Readme page to their environment. They are clear-text JSON files supported natively in the Intune portal. In the future this can be automated by the Harden Windows Security module.
Added device compliance policy to the repository which can be used via Microsoft Graph API to import it to your Intune portal for secure device compliance policy for Windows OS devices.
Added preliminary code for support of compliance checking using the Confirm-SystemCompliance for enterprise systems that have Intune policies applied to them. So far only the Attack Surface Reduction category is fully supported.
Fixed a bug where if you used cd
to change the directory in PowerShell after loading the module, there would be an error in Confirm-SystemCompliance
cmdlet due to relative path usage. -> https://github.com/HotCakeX/Harden-Windows-Security/issues/298
Fixed a typo: Synching -> Syncing
The TLS Category items in the Confirm-SystemCompliance
results have more descriptive names.
Updated the Bitlocker group policy to disallow TPM-only encryption for the OS drive. The TPM-only encryption is insecure and needs to be coupled with Startup PIN, Startup key or both and the Harden Windows Security module offers them.
Before:
After:
[!important]
"Do not allow TPM" means "do not allow TPM-only encryption".
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/299
Published by HotCakeX 3 months ago
Just a small update with quality of life improvements
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/292
Published by HotCakeX 3 months ago
The Downloads Defense Measures category now has an optional sub-category that allows you to choose a new type of WDAC policy to deploy automatically. This policy blocks dangerous and very old components on Windows. Please read this post for all the info about them..
Some 3rd party programs might still attempt to use these. Remember that you can easily remove the policy using the Unprotect-WindowsSecurity command at any time.
The components blocked by this optional WDAC policy are:
Improved the overall performance and speed of the Harden Windows Security module through internal reconstruction.
Added a new Attack Surface Reduction rule: Block Webshell creation for Servers to the ASR Category.
Changed the Attack Surface reduction Rule Block executable files from running unless they meet a prevalence, age, or trusted list criterion from Block
to Bock and Warn
, which means it will allow the System Administrator to be able to allow the blocked file or app if they wish to without the need to use group policy editor. This should make it easier for developers or people that want to install newly released versions of programs before their reputation is determined by the system. This doesn't change the threat model whatsoever since you still need to have Administrator privileges to allow a blocked app, just like you need to have Administrator privileges to change the group policies.
Changed the Clipboard syncing in the Non-Admin category to be an optional sub-category instead of applying by default in that category.
The Confirm-SystemCompliance
now takes into account the type of the registry keys too when performing compliance checks. When the registry key path, name and value match but the type doesn't match, (E.g., the module expects a DWORD
but the value is QWORD
or String
), then that item will be shown as false. This further improves the accuracy and trustworthiness of the results.
The Microsoft Defender category now detects when GitHub Desktop or Git (standalone version) is installed and automatically adds their executables to the exceptions for mandatory ASLR as they are not compatible. More info here - Was also mentioned in this issue
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/289
Published by HotCakeX 4 months ago
Added support for WHQLFilePublisher, WHQLPublisher, WHQL and FilePath levels to the WDAC Simulation. If you want to read more about the levels check out this article.
Lots of performance improvements and optimizations in pretty much every component of the WDACConfig module to make it faster.
WDAC Simulation's logic has been substantially improved under the hood for faster and completely different mechanism that unlocks all Application Control levels to be verifiable through the simulation engine.
WDAC Simulation now supports parallelism. You can set the number of parallel threads between 1 which is minimum, and the number of your CPU cores which is the maximum. With this improvement, you can perform WDAC Simulation on the entire C drive in only a few minutes.
Laid the groundwork for the future GUI implementation in the WDACConfig module.
When deploying signed policies, before attempting to download the SignTool.exe from the official Microsoft Nuget repository, the module now checks whether Nuget exists as a package source on the system (which should be by default) and if it isn't, it will add it.
When using the New-KernelModeWDACConfig to deploy a strict kernel mode WDAC policy with no flight root signers (which is not the default behavior and you have to go out of your way to choose that option), the module now performs a WDAC simulation on the Windows Kernel to ensure your current OS version does not belong to Dev/Canary insider channels, to prevent from deploying a policy that could render the system unusable.
Lots of PowerShell code have been converted to native C# code for improved agility, future use-cases and being able to directly utilize Windows APIs.
Since Windows no longer has a cap on the number of the WDAC policies that can be deployed, many components of the module have been updated to handle large number of deployed policies.
The module's startup time has been substantially improved, now the parameter suggestions and arguments are loaded at least x3 times faster than before.
Removed the self-signed certificate details from the module files as most of them are converted to C# and .cs
files don't support Authenticode signature. The best way to verify the integrity of the WDACConfig module files is using the Assert-WDACConfigIntegrity which uses the strongest available hashing algorithms (SHA3 and SHA2).
All of the PowerShell native global variables have been switched to C# constants, this offers greater protection against tampering since reflection can no longer be used to overwrite them. To compromise C# constants you would need to directly modify their in-memory values which imposes more cost from an attacker's point of view. Read more about this method here
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/284
Published by HotCakeX 4 months ago
Lots of speed improvements for Confirm-SystemCompliance cmdlet. The entire system can now be audited in ~12 seconds. Previous it would take about ~38 seconds to complete. Everything has been parallelized for high performance output.
Below is an example of the type of recovery info that will be generated. As you can see, all of the required details are in one text file, easy to use and backup. If you have many drives, they all will be in this file, and you can use the size and their ID to identify and unlock them if you need to use recovery passwords.
PR : https://github.com/HotCakeX/Harden-Windows-Security/pull/275
Published by HotCakeX 4 months ago
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/273
Published by HotCakeX 4 months ago
Added new parameter to ConvertTo-WDACPolicy called -SuppPolicyName
which allows the user to define a custom name for the supplemental policy. If not defined, the module will continue to automatically generate a name based on the source type and date + time.
In Edit-WDACConfig and Edit-SignedWDACConfig cmdlets for the -AllowNewApps
parameter, the directory paths that the user selects are de-duplicated now so if you accidentally select the same directory multiple times using the GUI, the module only performs a single scan, saving time and reducing redundancy.
Again in Edit-WDACConfig and Edit-SignedWDACConfig cmdlets for the -AllowNewApps
parameter, a new parallel task has been added to check for files signed with ECC algorithms, the module will create hash level rules for those files. This is because WDAC only supports files signed with RSA algorithm and even though ECC signed files have Signature based rules created for them in the XML policy, they are still not authorized to run and generate VerificationError 23 in the Code Integrity Operational event logs.
Fixed AppLocker logs property alignments. Also the ConvertTo-WDACPolicy
cmdlet now shows the source of the log in extreme visibility mode, so you can know whether a file was logged in AppLocker logs or Code Integrity operational logs.
Improved the accuracy of the boosted security modes, also known as dependency sandboxing. They are now processed faster and also created for files that were run during installing or audit phase but are no longer on the disk.
Improved the speed of Code Integrity and AppLocker logs parsing yet again.
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/269
Published by HotCakeX 5 months ago
This is by far the biggest update to the WDACConfig module. It brings a lot of new features, improvements, and changes to the cmdlets. The main focus of this update is to make the workflow of the cmdlets more user-friendly, faster, and more efficient. There are some inevitable breaking changes along with new features and improvements that are all listed below.
The vast majority of programs incorporate Dynamic Link Libraries (DLLs) and additional dependencies such as .com
, .rll
, .ocx
, .msp
, .mst
, .bin
, .hxs
, .mui
, .lex
, .mof
etc., which are replicated into their designated installation directory throughout the setup phase. These critical files may harbor security flaws susceptible to exploitation by malware. To counteract this, the innovative feature establishes a sandbox-like perimeter encircling the application's dependencies. This ensures that solely the application's own executables have the privilege to interact with the DLLs and dependency files, effectively barring all other executables from accessing them.
This feature is available in the Edit-WDACConfig
and Edit-SignedWDACConfig
cmdlets. It can be activated using the -BoostedSecurity
parameter.
This feature might be added to other cmdlets as well after further evaluations.
Removed -AllowNewAppsAuditEvents
parameters from both cmdlets, its job has been merged with -AllowNewApps
parameter. This simplifies the workflow as you no longer have to make a decision between which parameter to use when you need to allow apps or files.
The -AllowNewApps
parameter now automatically detects the files run during audit mode from event logs and display them to you in a GUI, offering you the option to include them in the supplemental policy by providing comprehensive details about every detected file and empowering you to make informed decision about them. It also checks for kernel-protected files in the logs you select, such as the main executable of the Xbox games, and allows them in the supplemental policy based on PFN (Package Family Name).
The SnapBack security mechanism is triggered sooner, restoring the base policy that is in audit mode back to enforced mode as soon as possible.
Using parallel processing methods, the workflow of the cmdlet has been optimized for faster execution.
You can now use the -AllowNewApps
parameter either by selecting directories to scan, purely rely on audit event logs or both. Previously, the workflow would require you to select directories to scan and would fail otherwise. Now you can solely rely on audit event logs to allow new apps or files, or if you want to allow a new file but you don't know its exact location.
The -UpdateBasePolicy
parameter has been upgraded. It now intelligently increases the version number of the base policy, ensuring that the new version is always one version higher than the previous one. The version change considers all semantic versioning rules such as revision, build, minor and major numbers and their maximum allowed values.
It's a new cmdlet, consider it an improved version of the built-in cmdlet Set-RuleOption
. It offers more features and improvements such as removing or adding rules at the same time in bulk.
Completely internalized policy rule option modifications, no longer using built-in cmdlets. This change results in much faster policy creation.
All of this cmdlets's parameters have been replaced with more user-friendly and efficient ones. No functionality has been lost. The goal is to offer the end-user the ability to quickly and easily choose the desired settings with 0 ambiguity. As a result, the following changes have been made:
Removed the -MakePolicyFromAuditLogs
parameter from the cmdlet. Its job can now be done with the -AllowNewApps
parameter in the Edit-WDACConfig
and Edit-SignedWDACConfig
cmdlets, or by the New-SupplementalWDACConfig cmdlet.
New parameter -PolicyType
: Use it to create base policies, it offers 3 options: 'DefaultWindows', 'AllowMicrosoft', 'SignedAndReputable'.
New parameter -GetUserModeBlockRules
: Use it to download or deploy the latest User Mode Block rules from the Microsoft GitHub repository. The User Mode block rules are no longer coupled with the base policy, they are now deployed as a standalone policy separately, offering greater control over them and their life cycle. This is due to the fact that Windows no longer has a limit on how many WDAC policies can be deployed on the system. Previously the limit was 32 policies.
New parameter -GetDriverBlockRules
: Use it to download or deploy the latest Kernel Mode drivers Block rules from the Microsoft website.
New parameter -Audit
: Used to turn on audit mode in the base policy. Only available when -PolicyType
parameter is used.
New parameter -AutoUpdate
: Only available when -GetDriverBlockRules
parameter is used. It will automatically update the driver block rules when a new version is available using scheduled task.
Gets the secure settings value from the deployed CI policies using the Windows APIs.
Refer to the following documents for more info:
OnlySystemPolicies
: It will display only the system policies when used.The ConvertTo-WDACPolicy cmdlet when using local logs as the source, has become faster using high performance functions.
Kernel-protected files are now faster to detect and rules for them are created in better ways.
Sub-modules in each cmdlet are now loaded faster.
Cmdlet outputs are now more streamlined and consistent.
During the module preload phase, certain immutable global variables are established, remaining unalterable for the duration of the session. Previously, these variables were instantiated only if they did not already exist within the session's scope with the same name. Now, the values of these pre-existing variables are scrutinized against those defined within the module. Should a discrepancy arise, an error is triggered. This rigorous validation mechanism ensures the integrity of critical variables, safeguarding them from any potential malicious alterations prior to the module's loading.
Whenever using cmdlets that require interaction with Code Integrity and AppLocker event logs, such as Edit-WDACConfig
, Edit-SignedWDACConfig
or New-WDACConfig -Audit
, the Code Integrity Operational's event log size is evaluated. If the current free capacity is less than 1MB and its maximum size is less than 10MB, its size is increased by 1MB. This is a controlled automated workflow that is introduced in this version that aims to prevent the overwrite of the event logs. You can always use the -LogSize
parameter with the cmdlets that support it to set the desired max size for the Code Integrity Operational logs.
Increased the minimum required OS build version from 22621.2428
to 22621.3447
. In this build, the cap for the deployed WDAC policies was removed and the redesign of the module is based on that change.
Increased the update check interval from 10 minutes to 30 minutes.
PRs:
Published by HotCakeX 5 months ago
Protect-WindowsSecurity
cmdlet. Now if the system is detected to not have TPM, only the BitLocker category will become automatically unavailable to run.Get-MpComputerStatus
cmdlet is called, now saving the results to a variable and using it for subsequent queries.PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/262
Published by HotCakeX 5 months ago
-offline
parameter for the Confirm-SystemCompliance cmdlet, it will skip the online update check when used. => related issue
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/256
Published by HotCakeX 5 months ago
7.4.1
to 7.4.2
.As always, the module automatically updates when you run any of its cmdlets/commands and when there is a new version available on PowerShell Gallery, so you don't have to manually update it.
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/251
Published by HotCakeX 6 months ago
PR: https://github.com/HotCakeX/Harden-Windows-Security/pull/249