Forum Discussion
WDAC and file attributes filename not working
Hey all,
We have some dll files that exist under our users profile that we want to whitelist in WDAC.
- I can't use the hash method as it updates reasonably regularly and some users have a different version of the file, so that would be onerous to maintain.
- The dll's aren't signed so can't use that method.
- We are running Win10 so can't use wildcards to point to the path.
I have tried a simple filename rule as below but it doesn't work.
<Allow ID="ID_ALLOW_A_0_0_1_1_0_0" FriendlyName="Allow files based on file attributes: dllfile.dll" FileName="dllfile.DLL" />
Am I missing something with the filename rule?
cheers
j
Hi Deleted,
The <Allow> rule you've provided seems correct at first glance, but there might be some issues with the casing and file attributes.
Here are a few things to check:
Check Filename Matching: WDAC is case-sensitive, so ensure that the filename in your rule exactly matches the DLL file's name in the user's profile, including the correct casing.
Use Wildcards: If there are different versions of the file, you can use wildcards in the filename itself. For example, "*dllfile.DLL" will allow any DLL file with "dllfile.DLL" in its name.
WDAC Version: Verify if your Windows 10 version supports filename-based rules. Different Windows versions may have varying levels of support for different rule types.
Test the Policy: After updating your WDAC policy, test it on a test machine to see if the rule is applied correctly. Check the event logs for WDAC-related events to spot any issues.
Policy Enforcement: Make sure that WDAC is enabled and enforcing policies on the target machines. Sometimes, policies aren't enforced as expected.
Here are some additional tips for troubleshooting WDAC filename rules:
- Make sure that the DLL file is not blocked by any other WDAC rules.
- Try restarting the computer after deploying the WDAC policy.
Please click Mark as Best Response & Like if my post helped you to solve your issue.
This will help others to find the correct solution easily. It also closes the item.If the post was useful in other ways, please consider giving it Like.
Kindest regards,
Leon Pavesic
(LinkedIn)
2 Replies
Hi Deleted,
The <Allow> rule you've provided seems correct at first glance, but there might be some issues with the casing and file attributes.
Here are a few things to check:
Check Filename Matching: WDAC is case-sensitive, so ensure that the filename in your rule exactly matches the DLL file's name in the user's profile, including the correct casing.
Use Wildcards: If there are different versions of the file, you can use wildcards in the filename itself. For example, "*dllfile.DLL" will allow any DLL file with "dllfile.DLL" in its name.
WDAC Version: Verify if your Windows 10 version supports filename-based rules. Different Windows versions may have varying levels of support for different rule types.
Test the Policy: After updating your WDAC policy, test it on a test machine to see if the rule is applied correctly. Check the event logs for WDAC-related events to spot any issues.
Policy Enforcement: Make sure that WDAC is enabled and enforcing policies on the target machines. Sometimes, policies aren't enforced as expected.
Here are some additional tips for troubleshooting WDAC filename rules:
- Make sure that the DLL file is not blocked by any other WDAC rules.
- Try restarting the computer after deploying the WDAC policy.
Please click Mark as Best Response & Like if my post helped you to solve your issue.
This will help others to find the correct solution easily. It also closes the item.If the post was useful in other ways, please consider giving it Like.
Kindest regards,
Leon Pavesic
(LinkedIn)Thanks for the replyLeonPavesic
I didn't know about the case sensitivity so will take that into account. That did affect one dll where the file under Program Files had a lower case extension .dll, but when it was compiled (under %localappdata%\assembly) it had an uppercase .DLL
I found the main issue to be the Dynamic Code Security option. Once I disabled that, the dll's in question were loaded by their respective programs fine.
https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/wdac-and-dotnet