Block remote support/assist applications using Windows Defender App Control & MEM
If you’re concerned about your users falling for a scam that gives someone control over their keyboard and mouse, one way to mitigate that risk is by blocking those remote assistance applications from running. Windows calls this functionality Application Control and provides two ways to implement it: AppLocker and Windows Defender Application Control (WDAC). There is an article describing the differences, but the short summary is that WDAC was designed as a security feature and provides additional functionality. So in this case we’ll be using WDAC!
Let’s throw in a caveat – WDAC provides an immense amount of control and security over your Windows devices. To be successful with WDAC, read through the official Design guidance and do not deploy broadly without significant testing.
The easiest way to get this WDAC policy created is leverage the Microsoft WDAC Wizard and edit a default template to block the Remote Assistance applications. Download and install from the link above:
In the Defender App Control Policy Wizard, we’ll create a new policy. Select Policy Creator:
Select Multiple Policy Format and Base Policy:
There are three templates we can choose by default. The Signed & Reputable Mode policy is the least restrictive, allowing files with a good reputation to also be ran on the system. Select that base template:
Then we can leave the default options. For detailed information on each slider, review the Windows Defender Application Control Wizard Base Policy Creation Docs article. Note that I turned off Audit Mode – do not turn off Audit Mode until you have properly validated the policy.
Finally, on the Policy Signing Rules pane, we can create custom rules to block remote support applications. Click + Add Custom Rule:
In the Custom Rule Conditions, select Deny and then the File Attributes Rule Type. Then we’ll need to browse for a Reference File that prefills the conditions that will be used. For this test, I will deny AnyDesk, TeamViewer, and LogMeInRescue (of course, there are many different Remote Support applications (including Microsoft’s own), and you will need to determine which to block during this step):
And then verify that the Deny rules are in the Policy Signing Rules list:
Then click Next, and the policy will be built!
Now that we have the policy, we just need to deploy it!
In Microsoft Endpoint Manager > Devices > Configuration profiles, create a new Custom Profile:
Add a new OMA-URI setting with the following details:
- OMA-URI: ./Vendor/MSFT/ApplicationControl/Policies/Policy GUID/Policy
- Policy GUID is found in the XML exported from WDAC Policy Wizard, towards the bottom
- Data type: Base64
- Certificate file: upload the binary format policy file
- Intune will convert the bin file to Base64
And then assign and deploy the custom policy!
In a few moments, the policy will be ingested and if the user tries to open one of the denied applications they will see:
Just like that – the applications we targeted are blocked! No more running remote assistance applications.
In an enterprise setting, there are many things we’d want to consider before deploying such a policy. For example, since we used the default policy we are blocking many potential applications/scripts that some users may need for their work – such as developers with unsigned test apps. Again – getting Application Control done correctly takes a lot of testing and validation. Blog posts like these can be a stepping stone in investigating how to secure your environment or maybe inspiration for starting to leverage a cool feature.
To that end – happy testing! 🧪
