MDAC or (the Unexpected Virtue of Ignorance)

MDAC or (the Unexpected Virtue of Ignorance)

This blog is the fourth part of the Endpoint Security Series and it will show you how to configure Windows/Microsoft Defender Application Control(WDAC/MDAC).  It could be a great addition to securing your environment. I will divide this blog into multiple parts.

  1. MDAC/WDAC/Device Guard Explained
  2. Choosing between MDAC and Applocker
  3. How to configure MDAC
  4. Automatically with an Endpoint Protection Policy
  5. Manually with a CSP
  6. Monitoring / Testing/ Troubleshooting it
  7. Creating a golden Image
  8. Adding and merging policies
  9. The Microsoft Store/Blocking Apps
  10. Removing MDAC
  11. Conclusion

1.MDAC/WDAC/Device Guard explained

Microsoft Defender Application Control (MDAC) formerly known as Windows Defender Application Guard or Device Guard will control if an application may or may not be executed on a Windows 10 device. MDAC will prevent the execution, running and loading of unwanted or malicious code, drivers and scripts. MDAC does not trust any software it does not know of.

If the application is allowed and trusted the application can run, otherwise the application will be blocked by a feature called configurable code integrity (CI).

CI will guarantee, only  trusted code may be executed from the boot loader onwards. CI will make sure you are protected before any OS code could run

Securing your environment by creating and maintaining MDAC policies will definitely take some time. The policies you have created at the beginning can be outdated within a few weeks. Implementing MDAC is not a set and forget solution, you will need to spend time on it to maintain it.

When you want to deploy MDAC, there is of course a requirement. Luckily it’s a simple one, you will only need to make sure the device has Windows 10 installed and nothing more. Luckily there are no restrictions about which Windows 10 version is required, but it’s best practice to use 1903+

When you want to know the MDAC differences between each Windows 10 build, go check out this file. It is the MDAC/WDAC code integrity policy schema.

%windir%\schemas\CodeIntegrity\cipolicy.xsd

Looking at this file… could anyone tell me what this policy does?

I can’t find it in the Microsoft Docs?

Understand Windows Defender Application Control (WDAC) policy rules and file rules (Windows 10) – Windows security | Microsoft Docs

2. Choosing between MDAC and Applocker

Of course, Microsoft is recommending using WDAC rather than Applocker when you need to implement application Control. The main reason could be the continual improvements and support you could get. Looking at Applocker, there is not going to be any feature update of Applocker.

But in my opinion…. just start with Applocker to make sure your devices are protected for 99% from malware and ransomware.  The only thing missing in Applocker is the possibility to block driver files.

When you know how it all works, start testing with MDAC. The idea is almost the same but with one big difference:

Applocker policies can be targeted to users and groups.

MDAC policies are targeted to devices.

A common misconception is that MDAC is the replacement of Applocker.  Applocker also controls the execution of applications and files, but it does not offer the security you will get with MDAC.  MDAC offers a chain of trust from when the device boots up to the kernel. But again it’s not the replacement of Applocker.

To resume, when you deny the execution of an application, it will also be blocked for the local admin. So the best practice would be to make sure you have configured MDAC and combine it with Applocker to perform some finetuning.

3.How to configure MDAC

There are multiple methods how you could deploy MDAC to your devices.

But as Intune is the way to go, I will only show you how to configure MDAC and deploy it with Intune.  But a lot of information in this blog can also be used when you are deploying it with PowerShell or Group policies.

4.Automatically with an Endpoint Protection Profile?

When we want to enable MDAC without any additional configuration, you can do so by creating a new device configuration profile and choosing an Endpoint Protection Profile.

That’s cool! We only need to configure the “Application Control Code Integrity policy” and the “Trust apps with good reputation” options. When configuring the first option, Windows Components, Microsoft Store Apps (more on this later) will be allowed.

But what does “trust apps with good reputation” mean?

The Microsoft Intelligent Security Graph (ISG) is the “data plane” that collects all the information /telemetry from every Microsoft application. When application files are executed and there are no specific allow or deny rules for this application, the data from the ISG is used by WDAC to determine if the file reputation is known to be good /know to be bad or unknown. This mechanism is also used by Microsoft Defender Antivirus and Microsoft Defender Smartscreen.

Please note, when you are not using MDM and you want to enable ISG, you also will need to enable a service by launching this command:

appidtel start

It will make sure the Appid ManagedInstaller and Smartscreen Telemetry file service is started.

Let’s take a look what happens when we configure this Intune setting.

Windows will boot and of course, all the trusted Microsoft Apps as Onedrive/Teams will work… but what about the rest? I guess a lot will be blocked when it tries to execute.

Also the event log is a little bit filled up with a lot of CodeIntegrity Errors!

For me personally … this is not the way to go!

When you want to configure additional settings, you must define another separate CSP, so why not putting it all in the CSP?

5.Manually with a CSP

When we want to specify some additional settings to make sure some applications are allowed, we could create a device configuration profile.

We need an XML to specify some settings but how do we create it? Could we use a template? Looking at the c:\windows\schemas\codeintegrity\examlepolicies folder, we notice these Templates:

Before we continue, we need to have some more information about which template we could use and why. Each of the template policies has its own set of policies. I will show you each policy in increasing order allowing from only allowing the basics to allowing a lot more. For instance, the Default Windows mode policy allows fewer application signers and publishers than the Signed and Reputable mode policy.

Default Windows Mode:

Default Windows mode will authorize the following components:

  • Windows operating components – any binary installed by a fresh install of Windows
  • Apps installed from the Microsoft Store
  • Microsoft Office365 apps, OneDrive, and Microsoft Teams
  • Third-party Windows Hardware compatible drivers

Allow Microsoft Mode

Allow mode will authorize the following components:

  • Windows operating components – any binary installed by a fresh install of Windows
  • Apps installed from the Microsoft Store
  • Microsoft Office365 apps, OneDrive, and Microsoft Teams
  • Third-party Windows Hardware compatible drivers
  • All Microsoft-signed software

Signed and Reputable Mode

Signed and Reputable mode will authorize the following components:

  • Windows operating components – any binary installed by a fresh install of Windows
  • Apps installed from the Microsoft Store
  • Microsoft Office365 apps, OneDrive, and Microsoft Teams
  • Third-party Windows Hardware compatible drivers
  • All Microsoft-signed software
  • Files with good reputation ISG

Now we know what templates we could use, we need to know how we are going to configure them. We can do so by using Microsoft PowerShell or a nice WDAC tool.  In this blog I chose to configure the XML with the tool, so let’s download it first.

Microsoft WDAC Wizard (webapp-wdac-wizard.azurewebsites.net)

After the package is installed we can start creating our first WDAC policy.

As this is the first policy we are going to create we are going to choose: Multiple Policy Format and a Base Policy

Next, we can choose the template which we discussed earlier. You have got 3 options here: Default Windows Mode, Allow Microsoft Mode and Signed and Reputable Mode.

I will choose the “Allow Signed and Reputable mode” because I really do trust Microsoft… otherwise, it would be a mad mad world and I also have Applocker in place.

*Unsigned System Integrity Policy  –>  When you disable this option, you must protect the MDAC policy by digitally signing the policy. When it’s signed even the local administrator can’t tamper with it!

*Managed installer –> PLEASE NOTE ONLY AVAILABLE WITH SCCM

When you want to use this feature with MEMCM, you also will need to create an additional Applocker rule

*Audit Mode

I guess you need to audit it first! Before enabling it. You just can’t enable it without testing!. You will need to define a circle of trust and start auditing. Monitor each block event and edit the allow or deny rules when necessary and start over again until you are satisfied with the outcome.

*Intelligent Security Graph

Earlier in this blog I explained what is feature is about and how it works.

Please click on next when you configured everything necessary.

Now we have the possibility to add additional policies as shown above… Please beware if you don’t specify anything, a lot of third-party tools could still be blocked even when you turned on ISG. Of course, it will only be blocked if you don’t have enabled Audit Mode.

And a kind reminder… when you block a process, it will be blocked for everyone!! Not only the normal user but also the local admin! We will skip this part for now and continue to deploy the WDAC policy.

Open the xml and note the ID, because we need it later on.

But having an XML is not enough we need to convert it to a bin file, otherwise we can’t use it in Intune. Even when they say it’s a Base64 you still need to have the bin file.

We have got 2 options to convert it to a BIN file: PowerShell or using the WDAC tool itself.

Powershell:

WDAC tool:

Or maybe a way better option, now we are doing everything with the tool itself. Select the “convert policy to binary after xml creation” option in the settings menu of the WDAC Tool.

Now we have everything we need we need to create a CSP. Go open Intune and start configuring a CSP with these values:

OMA-URI:

./Vendor/MSFT/ApplicationControl/Policies/[ID without brackets]/Policy

And select the bin file you just created.

6.Monitoring / Testing / Troubleshoot

1.Monitoring

We are going to start with some monitoring to make sure, MDAC is applied and if it’s enforced or only configured to Audit.

How to determine if MDAC is active? We have multiple methods to check if it’s working

  1. MSINFO
  2. CodeIntegrity Folder
  3. Event log
  4. PowerShell
  1. MSINFO

You only need to open MSINFO32.exe and start looking for the Windows defender application control status. As shown below, it’s enforced.

2. Codeintegrity Folder

Just like with Applocker, device guard has its own folder with the active policy in it.

Before we continue we need to take a look at this folder C:\Windows\System32\CodeIntegrity\ to understand when which file is created

If you have a SiPolicy file in this folder, that means you have selected the single policy format in the WDAC tool instead of the multiple policy format. If you have selected the multiple policy format, the policy is going to be created inside the cipolicies\active folder.

3. Event log

Please note only using the default template and rules is going to produce a lot of errors on the device. First, we need to know which kind of event’s can be triggered.

Don’t be mistaken by these kinds of warnings, because it’s a known problem.

4. Powershell

Open a new PowerShell session as admin and copy paste this command

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | FL *codeintegrity*

If WDAC is enfored the “UserModeCodeIntegrityPolicyEnforcementStatus” needs to have a value of “2”

2.Testing it

After some tests, I noticed a lot of apps that were trying to install from the company app portal just failed! So we have got 2 options here.

  1. Allowing
  2. Scanning
  1. Allowing

If you don’t want to go into the hassle to scan all folders on a golden device. (The same physical device with all the software installed which is necessary) you could just allow the folders needed. It’s just like Applocker where everything launched from the program files is allowed!

Please note, you can only use these 3 system variables when you are going to allow some folders.

2. Scanning

Just like with the allowing part, when you have selected one of the Microsoft Baseline Examples, you still need to scan the program files! Otherwise, a lot of apps will be blocked even when you have enabled ISG

New-CIPolicy -FilePath .\ProgramFiles.xml -ScanPath $env:ProgramFiles -Level Publisher –UserPEs -fallback hash

 New-CIPolicy -FilePath .\ProgramFiles86.xml -ScanPath ${env:ProgramFiles(x86)} -Level Publisher –UserPEs -fallback hash

Please beware,  there are a lot of files that can’t be added by a filepublisherrule.  So you need to specify the -fallback “hash” parameter. It will make sure if there are files that can’t meet the FilePubisher trust level, they will be trusted based on the Hash rule level.

When you have uploaded the new policy to Intune, you can check out the code integrity event log to determine if the new policy has arrived.

3.Troubleshooting

While testing it, I experienced some weird behaviour. A sort of delay in policy arrival. Normally you push the new bin file to Intune and press the sync button to make sure the devices are being synced but this time it wasn’t working. After waiting almost an hour, I decided to delete the cip file in the C:\Windows\System32\CodeIntegrity\CIPolicies\Active folder. After again syncing the device, within a couple of minutes the new policy applied.

But beware when MDAC is deployed and enforced, you should make sure you signed your MDAC policy. If the policy is not signed, you are able to just delete (or overwrite) the policy as I did above when my policy was not updating!

7. Creating a Golden Image?

In the fifth part of this blog, we chose to start with a Microsoft Baseline Example and added some additional publisher rules or allowed the program files folder. But what if you don’t want to use the Microsoft Baseline and create your own golden image?

Let’s start with creating a baseline from the same physical device your other users are going to work on.

Open Powershell and launch this command

$wdacPolicyfileXML = “C:\temp\wdacpolicybaseline.xml”

New-CIPolicy -MultiplePolicy -filePath $wdacPolicyfileXML -ScanPath C: -level FilePublisher -UserPEs -Fallback Hash

And now we wait… a long time

Glad It's Friday! | Funny gif, Sylvester the cat, Funny pictures

After it was finally done creating the XML, I started the WDAC tool again and chose to edit the file

In the next screen, change the settings you need and press Next.

What a large list of allowed publishers and a lot of duplicate items! I tried to remove all the duplicates

Let’s start building our WDAC policy…. Shall I add another Coffee gif?

After waiting a long time it was finally done. You could upload it to Intune and start testing with it… but In my opinion, choosing a Microsoft baseline to start with is way better and cleaner.

8. Adding an allow rule or merging two XML Files!

Best practice!! Make sure you have an additional VM enrolled to the company you want to allow an additional application. When you are making changes, please save each XML in its own folder with revisions and what you have changed!

1.Adding a rule

Again, we need to open the WDAC tool, but this time we are going to choose to edit a policy.

It’s very easy, just select the correct XML, add some allow or deny rules in it and save the policy. After you have made some changes and convert it again to a bin file, we need to open the CSP you have created earlier and select the new bin file. After you have selected the bin file, you also need to rename the OMA-URI to match the ID from the XML. When you are done, don’t forget to save the CSP.

2.Merging rules

Now we know how to add some rules, we are going to take a look at how we could possibly merge two rules. First, we are going to download, Microsoft list of recommended block rules and save the XML.

Microsoft recommended block rules (Windows 10) – Windows security | Microsoft Docs

It block some processes which could do harm.

Open the WDAC tool and select the policy merger and select both of the 2 policies.

It will combine the 2 xml in one new xml and cip/bin file you could upload.

9. The Microsoft Store / Blocking Apps

As mentioned earlier, when looking at Microsoft their WDAC baseline examples you will notice on each of them the Microsoft Store ApplicationS are allowed.

The first thing that would probably come to mind, is to Enforce store applications.

If this rule option is enabled, WDAC policies will also apply to Universal Windows applications.

Yeahhh!!! you might think….

But what happens when we just try to download spotify!

It just downloads the App and you can launch with no issues!

So we need to block specific Universal Store Apps when we have chosen the Microsoft Example baseline?

Blocking Packaged Apps

We could use New-CIPolicyRule -Package $Package -Deny to block packaged apps. Here is an example to block Netflix

After we have merged the rules, let’s take a look what happens when we want to launch the Netflix App

But beware, this only disables the Netflix App and all the other apps are still available!

So what happen when we block the Windows Store just like I did with Netflix, I did the same with the Windows Store app

And the Results! As shown below… when you are trying to launch the Windows Store…. It’s not going to open.

But this is definitely not what you want! You still want to have the Microsoft Store on your devices as it’s needed if you want to make sure the Company App is installed on your devices (If you don’t have a Win32 app with the offline version in it). It even still doesn’t prevent manually installations of App Packages!

Also removing this Publisher rule as shown below from the Microsoft example baseline… won’t help!

So what’s next? I tried to remove some more Publisher rules, but it instantly broke my virtual machine and it ended up in a non-bootable VM.

I guess as I said before… you could do some finetuning with Applocker or just use Applocker……..

10.Removing MDAC

First, we are going to take a look at what Microsoft tells us we must do when we want to remove the policy.

If you are done testing or using WDAC, please beware when you need to disable WDAC enforcement you will need to make sure you have replaced the existing policy with a new version of the %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml policy.  

When you are certain the policy has been replaced you can delete the policy from the Intune portal. So, you can be certain that all applications are allowed and on the next reboot the WDAC policy is removed.

To be sure I just removed the assignment from the device configuration policy to see if the policy is still tattooed to the device.

After the policy has applied watch the codeintegrity folder, it’s empty but still the process is blocked.

But after a reboot, it worked… even without specifying the allowall.xml first. I guess safety first and just push out the AllowALl.xml first… you can’t break anything by doing so.

I guess when you were still deploying WDAC with the applocker CSP you definitely need to make  sure everything is allowed before you remove the policy

Conclusion

It’s cool you could combine MDAC/WDAC with Applocker to block PowerShell only for the normal user.

So, MDAC is not a replacement for Applocker but a complement. In my opinion, I still prefer to use only Applocker for the SMB. Applocker is much easier to setup/maintain and deploy!.

Of course, everything can be more secure but it could also mean you can end up with a lot of people rebelling because nothing is working and you will end up questioning yourself if it was a good idea just to turn it on.

If you want to read more parts of the Endpoint Security Series:

Endpoint Security Series – Call4Cloud 

*The fifth part about Exploit Protection

Leave a Reply

Your email address will not be published. Required fields are marked *

59  +    =  64