github HotCakeX/Harden-Windows-Security WDACConfigv0.3.2
WDACConfig module update v0.3.2

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: #198


Don't miss a new Harden-Windows-Security release

NewReleases is sending notifications on new releases.