HotCakeX / Harden-Windows-Security

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
https://hotcakex.github.io
MIT License
1.87k stars 148 forks source link

WDACConfig module v0.2.9 #175

Closed HotCakeX closed 11 months ago

HotCakeX commented 11 months ago

What's Changed

  1. New feature: the ability to download the latest version of the SignTool.exe from official Microsoft servers. If the path for SignTool.exe was not specified in any of the relevant cmdlets, if it wasn't detected automatically on the system, or if it did not exist in the user configurations file, you will be offered this option automatically.
  2. New feature: the ability to generate certificates for signing WDAC policies. You no longer need to install Windows Server to generate a certificate for yourself, now you can use the new cmdlet Build-WDACCertificate to automate the entire process in just few seconds. The certificate's private πŸ— will be securely stored on the system using Virtualization based Security πŸ”.
  3. The WDACConfig module is almost completely self-sufficient and can handle all of the tasks required for Windows Defender Application Control management in an environment on its own. You can manage your computer's security without leaving the PowerShell window. Also, many of the module's features can be used non-interactively or in headless mode, meaning you can pre-configure the parameters and use the features at scale without the need for individual user inputs.
  4. New feature: the capability to create a deny policy based on a directory path with wildcard(s): New-DenyWDACConfig -PathWildCards. This unveils many new opportunities. One of them is deploying a deny policy that blocks anything from executing in the Downloads directory, so if you inadvertently download a malware that is programmed to autorun after downloading then it will fail because nothing will be executed in the Downloads directory. You will have to manually transfer a trustworthy file to another location and then execute it. Of course, you can diversify and use this special policy with other kinds of policies on the system. You can also use this kind of policy with guidelines from my other repository that is for Privacy, Anonymity and Compartmentalization, by creating wildcard block rules for directory paths that contain files that are only intended to run in their assigned Windows Sandboxes and shouldn't be permitted to run on the host.