WDACConfig v0.4.6 - new milestone

[HotCakeX]

Introduction of the Modern GUI for WDACConfig

This update marks the release of the initial version of the graphical user interface (GUI) for the WDACConfig module. The application operates as a standalone tool, independent of PowerShell, offering the following key features:

• Built using WinUI3/XAML/C#.
• Powered by the WinAppSDK (formerly Project Reunion).
• Packaged with the modern MSIX format.
• Incorporates the Mica material design for backgrounds.
• Adopts the Windows 11 Fluent design system.
• Significantly faster execution and startup times.
• Very small size (uses trimming technology).
• 0 required dependency.
• 0 third-party library or file used.

Here is a very early and incomplete preview of the GUI, showcasing its design and layout:

As demonstrated in the preview, several features have already been implemented. The application leverages WebView2, which comes pre-installed with Windows, to facilitate web rendering. I've included two convenient menu items that provide direct access to both WDAC (Windows Defender Application Control) resources from this repository and official Microsoft documentation, ensuring guidance and support are always just two clicks or taps away.

My goal is to implement at least 20% of all of the features in the GUI in version 0.4.6 (current pull request), and more in the future versions.

Let's Talk Security and Threat Model

At this stage, security should be top of mind. Let’s delve into how the recent developments, particularly the introduction of compiled binaries for the GUI, impact the overall security and threat model.

First and foremost, the PowerShell module will always remain available in its uncompiled form. This ensures flexibility for users who prefer or require it.

Additionally, the source code for the new MSIX-packaged WDACConfig application is fully accessible in this repository. Anyone can review the code and explore the complete Visual Studio solution provided, allowing you to easily create the MSIX package on your own.

[!TIP]
Does this alter the threat model? Absolutely not. Here's why: When using the WDACConfig PowerShell module, you inherently grant it Administrator privileges. By doing so, you're already placing a level of trust in the module—demonstrated by running PowerShell as an Administrator and executing one of its cmdlets or commands in the terminal.

The same level of privilege applies to the new WDACConfig application packaged in MSIX format. It will still require Administrator privileges for its operations, as it performs the same functions as the PowerShell version. In fact, 90% of the codebase remains unchanged.

Is using the MSIX package mandatory? Absolutely not. You can continue using the WDACConfig PowerShell module exactly as before—nothing has changed in that regard. The GUI for WDACConfig is simply a part of the development roadmap, and as promised, I'm actively working on it. Personally, this interface will make managing application controls on my systems, and those I manage, much more streamlined and easier.

[!IMPORTANT]
If you are an enterprise or business, you can have your security team code review the WDACConfig application, and after fully verifying it, code sign it and use it in your environment.

[!NOTE]
Question: Is the MSIX package pre-signed? Answer: No.

Question: Can I (as a user) code sign it using my own certificate? Answer: It's up to you.

If users choose to install it, the process involves generating a self-signed certificate on their device, which is then used to sign the MSIX package before installation.

This approach ensures a high level of security, as the certificate is unique to each device, and no one else has access to it. Furthermore, the certificate contains no private keys, meaning it cannot be used to sign anything else, adding an additional layer of protection.

Here is a quick technical rundown of the Invoke-TacticalMSIXDeployment function that performs all of the required tasks automatically in a matter of seconds. No manual work is needed for the user to perform.

The script installs the WDACConfig MSIX package on the system.

It does so by securely generating a unique self-signed certificate on the user's system and then using it to sign the MSIX package.

Everything happens locally and no certificate comes from outside of the device.

The certificate is added to the Local Machine's Trust Root Certification Authorities Store with only public keys, ensuring no private key exists to be used to sign anything else.

Its existence with public key is needed so that you can use the WDACConfig app; without it the app will not launch as it will be considered untrusted by the system.

The 2 files, WDACConfig.dll and WDACConfig.exe inside of the MSIX app installation folder will be added to the Attack Surface Reduction rules exclusion list if they don't already exist in there, so the app will work properly.

The script creates a new directory in the TEMP directory for its operations and it will be deleted at the end of the script.

The script checks for the existence of any previous self-signed certificates generated by it and will remove them if it detects any, guaranteeing no unnecessary leftover remains on the user's system.

Summary

This is a new milestone in the development of the WDACConfig module. I'm personally learning a lot by doing it and the application I'm making is very useful for my needs and others I work with, by sharing it with the community, I'm hoping it will be useful for you too.

As I've thoroughly explained, the security model remains intact, decisions being made are based on logic and research with security in mind.

If you have any feedback or questions, feel free to share it. I'm always open to suggestions and improvements.