WDAC Implementation Help & Any Gotchas You're Aware of? (original) (raw)

Hi Everyone,

I’m looking to implement WDAC for our environment and reading through a lot of MS fluff it doesn’t really tell me certain questions that I have regarding “what if” situations, so I’m hoping you guys have done the hard yards and are willing to share your experiences.

I have implemented Applocker on many occasions historically and find it works brilliantly, and WDAC looks like it uses the great things about Applocker, but makes them a hell of a lot more convoluted and complex.

I’m sure there is a reason for this and it looks as though WDAC takes hard line approach to any app not included in the whitelist whether it’s installed in the “Program Files” folder or not, which I find a little weird because only an admin can install apps to the Program Files folders.

FYI, I plan on using the Windows Defender App Control Policy Wizard to setup the policy.

Anyway, to my queries which I hope someone can help with:

• Upon implementation can additional path, file hash or publisher rules be added after the initial implementation?
• I know you have to reboot the PC after WDAC policy has been implemented, but does the PC need to be rebooted each time an additional exception is added?
• Can you include the Program Files and Program File (x86) folders as as path rules? Is that recommended?
• We use Connectwise Control as our remote support tool. Do you have to add this as an exception even if it’s installed prior to the implementation of the policy?
• Any other gotchas that you’re aware of that you’d like to share?

Thanks

Duke

azrifmf (azrifmf) June 14, 2023, 8:48am 2

Hello Duke,

Implementing WDAC (Windows Defender Application Control) can indeed introduce some complexities compared to AppLocker. I’ll do my best to address your queries based on the information available.

1. Upon implementation, additional path, file hash, or publisher rules can be added to the WDAC policy. You can modify and update the policy as needed to accommodate new applications or changes in your environment. However, keep in mind that any changes made to the policy will require the affected devices to apply the updated policy, which usually involves a reboot.
2. Yes, after making changes to the WDAC policy, such as adding additional exceptions, the affected devices will need to apply the updated policy. Rebooting the device ensures that the new policy is enforced. Without a reboot, the changes may not take effect immediately.
3. Including the Program Files and Program Files (x86) folders as path rules is possible with WDAC. However, it is generally recommended to be cautious when creating broad path rules, as they can potentially allow unauthorized applications to be executed from those directories. It’s recommended to create more specific rules based on your trusted applications rather than relying solely on folder-based rules.
4. When implementing WDAC, you may need to add Connectwise Control as an exception if it is not already included in the WDAC policy rules. Even if the application was installed prior to the policy implementation, if it is not explicitly allowed by the policy rules, it may be blocked. Review the rules and ensure that any necessary exceptions are included for your remote support tool.
5. Here are a few additional considerations and potential gotchas:

• Carefully test the WDAC policy in a controlled environment before implementing it across your entire organization.
• Ensure that all required applications are included in the policy rules to prevent unintended blocking.
• Regularly review and update the WDAC policy as your environment evolves and new applications are introduced.
• Pay attention to the enforcement level (Audit, Enforce, Audit Mode with Enforcement) you choose for the policy, as it determines the action taken when an unauthorized application is encountered.
• Be prepared for some initial tuning and troubleshooting as you fine-tune the policy to work effectively in your environment.

It’s always a good practice to thoroughly test and evaluate the impact of WDAC in your specific environment before deploying it widely.

Thanks Azlan, Fantastic reply. Thanks for taking the time to elaborate so extensively! Just awesome…

@azrifmf

Hi Everyone,

OK, I’ve been playing with this for the past two weeks and have a good grip on the way it differs from AppLocker. I have come across an issue during testing with Connectwise Control when an on-demand support session is created and a PC with WDAC implemented, the support exe file is allowed to run because of the exceptions I’ve implemented, but half way through the execution process it fails.

Looking through the event logs I see:

Code Integrity determined that a process (\Device\HarddiskVolume3\Windows\Microsoft.NET\Framework64\v4.0.30319\dfsvc.exe) attempted to load \Device\HarddiskVolume3\Users\AppData\Local\Temp\Deployment\72TG2L8V.2QY\JRAY8RDK.535\ScreenConnect.Client.dll that did not meet the Enterprise signing level requirements or violated code integrity policy (Policy ID:{23251f30-d915-4ec2-b436-9c5aefa1e1ea}).

This happens for 2 DLLs and no matter what I do to exclude the following files:

screenconnect.client.dll
screenconnect.windows.dll

They are never allowed to run because none of the files are signed. I’ve tried file hash and path exceptions, and still the problem persists. How can I work around this? How can you get these files that are unsigned to run given the exceptions?

Filepath: *\screenconnect.client.dll
Filepath: *\screenconnect.windows.dll

I am using WDAC Polcicy Wizard to create my policies which works brilliantly and am using the “Allow Microsoft Mode”, rather than the more loose “Signed and Reputable Mode”.

The hash file is empty because there is no file signature, or at least that’s my understanding.

Thanks

Duke

@azrifmf

Hi Duke, Did you manage to get your WDAC policies deployed in the end?
I came across the exact same issue when trying to allowlist those dll files. I ended up using file attribute to whitelist them, its probabably the least secure way to do it… but at least it works.

Did you enable the UMCI mode? I feel like this is what contributes to the blocking of many DLL files, when I turned it off, I find that applicaitons are that explicitly run can still be run…

I am to a point where I constantly doubt my self if I am in the right industry…

I would be very grateful if you could share a bit more about your journey. Thank you

vladomamic0307 (DukeOfAwesome) January 24, 2025, 8:26pm 6

Hi Chris,

I wasted so much time on this and could never get it to work properly. I ended up giving up on it because it was blocking our remote support software (ScreenConnect) because of the DLLs I mentioned in my previous post which was a major deal breaker.

No matter what I tried and the sheer amount of time this issue was consuming we decided it was not worth it given the headaches it was causing. We also have clients with some very unusual software and we thought if we couldn’t get it to work in our test environment, what chance does it have in the wild.

To be honest, Microsoft’s implementation and documentation for WDAC is a disgrace and I’m of the opinion now that alot of these “security” product MS is rolling out are essentially BETA products that have no business being sold as solutions let alone be charged actual money for. Also, the coders implementing these solutions have either never worked in the “real world” or basically just don’t care. The implementation and work flow in alot of cases just doesn’t make sense and reasoning behind some of the decisions made is mind boggling to say the least. Was this even tested by MS before release or is it another case of close enough is good enough results be damned. The admins can figure it out. MS’s thought here was, BLOCK everything and whitelist what you want to allow, but if the whitelist doesn’t work, what have you got? Yes, a system that is essentially a hindrance rather than a productivity tool.

We ended up reverting to AppLocker which does mostly what we need and is a tested and tried solution that we’ve used for many years and it work and makes sense and exclusions actually work.

If you need a hand with AppLocker, get back to me.

Duke

We got it working using allow by Publisher after parsing the Advanced Hunting logs.

For many apps that run, you need to allow %AppData% in User Profiles via file path. DLL files often run from here.
If you are following the Essential 8, you will likely have to have a block rule on AppData\Local\Temp, i.e. %OSDRIVE%\Users*\AppData\Local\Temp though this potentially presents it’s own set of issues.
Your devices need to be on Windows 11 to allow Wildcards in the middle of the path.
This supplemental policy for %AppData% won’t work on a Windows 10 device, so it will still be blocked on Win10 with the policy applied.

vladomamic0307 (DukeOfAwesome) February 4, 2025, 3:09am 9

Thanks Wonko. That probably explains why we had so many issues. We were testing on Win 10 devices.

Again, you have to ask, why would Microsoft do that? It doesn’t make sense. They were pushing everyone to use WDAC, but then decided environmental variables wouldn’t be supported in Win 10.

This is precisely what I was talking about. This feature was deliberately not included with Win 10 so causing angst needlessly.

Because this wasn’t included with Win 10, it would force so many sys admins to not use WDAC because their environments are still predominantly Win 10.

Just a dumb short sighted decision more than likely based on greed.

WonkoTheSane (WonkoTheSane) February 4, 2025, 3:22am 10

(post deleted by author)