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
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.
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-SignedWDACConfigis now able to perform a WDAC simulation on theSignTool.exein 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 theSignTool.exeto 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 theSignTool.exeto run). This is the first time theInvoke-WDACSimulationcmdlet is being used internally.-SignToolPathand-IncludeSignToolparameters from theNew-WDACConfigcmdlet 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 -MakePolicyFromAuditLogsto 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
WHQLFilePublisheras level. Previously it usedFilePublisher. 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-WDACSimulationcmdlet 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-WDACSimulationcmdlet 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 metThe engine supports all of the SpecificFileNameLevel options when validating the FilePublisher level.
The
Invoke-WDACSimulationcmdlet 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.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.