What's New

• 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.

  • This capability has been added to the New-SupplementalWDACConfig cmdlet.

• 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

What's New

• Added support for Windows Home edition, this means the module and script can run on Windows home editions but the categories are applied in best effort fashion and not all of them are available since many features such as group policy or attack surface reduction rules are simply not available in the home edition. More features might be specialized and implemented for home editions only, in the future.
• You can now choose which categories to check compliance for using the Confirm-SystemCompliance cmdlet. Previously it would check all categories. If no category is selected, all categories are checked.
• Overall code improvements and refactoring.

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

What's New

• Added support for EVTX logs file parsing. Now, you can quickly create Application Control (WDAC) policies using EVTX logs from any computer. Just export the Code Integrity and/or AppLocker logs and use the WDACConfig module to turn them into WDAC policies. This feature provides a consistent and user-friendly experience similar to what’s available for MDE Advanced Hunting logs and Local logs, utilizing the ConvertTo-WDACPolicy cmdlet for streamlined policy creation.
• Overall code improvements

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

What's New

Microsoft Defender for Endpoint - Advanced Hunting

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.

Demo Video

The systematic approach to converting the query results to WDAC policy is as follows:

• If a file is unsigned then a hash rule will be created for it.
• If a file is signed then there are multiple possibilities:
  • If the file is signed and the MDE AH results contain the file's version as well as at least one of the following file attributes (Original Name, Internal Name, Description, Product Name), then a File Publisher rule will be created for it.
  • If the file is signed but the file attributes are not present in the results, Publisher level rule will be created for it.

These levels are selected based on their security. You can read more about the levels security comparison in this article.

Simple Yet Comprehensive

What WDACConfig requires for MDE Advanced Hunting

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.

Comparison

[!IMPORTANT]
WDAC Wizard is a great tool, it offers a GUI and can be downloaded from here

Other Changes

• Significantly Improved the performance when parsing the Code Integrity related event logs.
• In addition to the Code Integrity logs, now AppLocker logs are also processed by the WDACConfig module. This allows it to capture and create rules for blocked/audited MSI files as well.
• Bumped the required PowerShell version from 7.4.1 to 7.4.2 because it has WDAC related improvements.
• Fixed this issue: https://github.com/HotCakeX/Harden-Windows-Security/issues/225

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

What's New

• Toast Notification is now displayed upon completion of operation when using the GUI to operate the Harden Windows Security module and script.
• Improved the logging style when using the GUI, both in the log file and the displayed logs on the GUI.
• Added a new parameter -OnlyCountryIPBlockingFirewallRules to the Unprotect-WindowsSecurity cmdlet. It allows you to only remove the country IP blocking firewall rules without removing anything else.
• Overall code improvements

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

What's Changed

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.

To Summarize:

1. The procedures required to apply the Windows Boot Manager revocations for Secure Boot changes have changed significantly and the current category that applies them has been removed.
2. The new procedures are very extensive and require lots of work that might have adverse effect if automated at this point in time. According to the post, it requires new updated bootable media which haven't been released yet by Microsoft. It would also trigger BitLocker's recovery screen so user would need to keep the 48-digit recovery code accessible during the procedure.
3. Microsoft is planning to apply these changes automatically in the future through Windows Update.
4. Once updated bootable media (ISO files) have been released by Microsoft on July 9, 2024, I'll re-evaluate the procedures as to whether add automation for them in the Harden Windows Security Module or not.

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

FAQ

• 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

What's New

GUI (Graphical User Interface)

• 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

YouTube Video & Demo

Link: https://youtu.be/a8YbihowTVg

How To Launch The GUI

Protect-WindowsSecurity -GUI

Other Changes

• Added a file picker GUI for the LogPath parameter of the Protect-WindowsSecurity cmdlet.

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

What's Changed

• 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.

  • The compliance checking marks this ASR rule as compliant if it's either in warn & block or block mode.

Thanks to @agpt8 for the post about this.

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

What's Changed

• Improved SignTool.exe path acquisition logic.
• Fixed a bug where multiple deployed policies triggered the same event log to be generated multiple times and one of the internal functions couldn't properly find the correct one.
• Removed the temporary measure introduced in the previous release where the user configurations file would automatically be moved to the new location. More info in the previous release note.

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

What's Changed

New ASR Rules - Attack Surface Reduction

• Block use of copied or impersonated system tools
• Block rebooting machine in Safe Mode

Other Changes

• Removed enablement of VirtualMachinePlatform from the Optional Windows Features category since WSA is deprecated.

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

What's Changed

New Microsoft Defender Features

• Configures the Brute-Force Protection to use cloud aggregation to block IP addresses that are over 99% likely malicious CSP

  • This setting has a higher level protection level that will be added in a next version after more testing.

• 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

Other Changes

• 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

What's Changed

Threat Model Upgrade

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.

Install Directory

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.

User Configurations Directory

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.

Staging Areas

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.
 

Other Changes

• 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.

  • Previously, the default level was 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

What's Changed

Added 3 new policies to the Optional Overrides. These 3 policies alter the settings that are applied by Microsoft Security baselines.

Disabled "Turn off Microsoft Consumer Experiences"

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!

Disabled "Configure password backup directory"

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

Enabled "Apply UAC restrictions to local accounts on network logons"

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

Other Changes

• Improved the progress bars in the module

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

What's Changed

General Improvements

• Changed -LogSize parameter types to unsigned integers since they do not accept negative values. Made the same change internally to a few variables.
• Removed -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.
• Improved event logs collection and processing by making it more resilient and to prevent repetitive codes in the module. Now only one function is used whenever event logs need to be collected anywhere in the module.
  • This new function collects every piece of available information about each event, groups similar correlated events together and processes them properly for extreme visibility.
• New cmdlet 🧁 Get-CiFileHashes 🧁 calculates SHA1 and SHA2-256 Authenticode and first Page hash of the PE files. For non-conformant files, it calculates the Flat file hashes. All calculations happen according to the WDAC and Code Integrity requirements in Windows.
• New cmdlet 🧁 ConvertTo-WDACPolicy 🧁 presents the Code Integrity logs in a graphical interface (GUI) and enables the user to choose the logs. The logs can be filtered in various ways, such as Date, Type, Policy that generated them, and so on.

WDAC Simulation

• Since .bat and .ocx file types do not support Authenticode signing, the simulation no longer checks for their signature, leading to overall performance improvements.
• Improved performance of the simulation by handling non-conformant files faster using WDACConfig module itself.

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

What's New

General Improvements

• 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.

  • As a result of this improvement and automation, removed the -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.

WDAC Simulation Improvements

• 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)

  • FilePublisher
  • Publisher
  • SignedVersion
  • PCA Certificate
  • Root Certificate
  • Leaf Certificate
  • Hash

• 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.

  • FileDescription
  • InternalName
  • OriginalFileName
  • PackageFamilyName
  • ProductName
  • Filepath

• 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

What's Changed

New Process Mitigations / Exploit Protections

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.

• rundll32.exe: Prevent loading of DLLs from network locations such as SMB - WebDAV - etc.
• rundll32.exe: Prevent loading of files that are untrusted typically because they've been downloaded from the Internet from a sandboxed browser - Some malware use rundll32.exe to load malicious file that was just downloaded from the Internet.
• SMSS.exe: Prevent loading of DLLs from network locations such as SMB - WebDAV - etc. - It's called Session Manager SubSystem
• Wininit.exe: Prevent loading of DLLs from network locations such as SMB - WebDAV - etc. - It stands for Windows Initialization and is a process that is responsible for starting and terminating system services and processes during startup and shutdown
• NisSrv.exe: Prevent loading Non-Microsoft signed code into the process - This is a component of Microsoft Defender called Network Inspection Service

[!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.

Other Improvements

• 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

What's Changed

1. Implemented JSON schema as extra validation for the user configurations.
2. The 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.
3. Bumped the required PowerShell version to 7.4.1, a bunch of WDAC related issues were fixed in this version.

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

What's Changed

• 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.

  • The new -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

What's Changed

• Fixed a misplaced double quotes in the scheduled task code. It was a regression introduced in v0.2.8.

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

What's Changed

1. Fixed an edge case with emojis and code signature validation: https://github.com/HotCakeX/Harden-Windows-Security/issues/179 - Thanks @agpt8
2. Small improvement to the New-WDACConfig -SetAutoUpdateDriverBlockRules

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