Tag: Microsoft Defender Application Control

Smart App Control vs Application Control in a cloud-native world

Smart App Control is a new feature in Windows 11 22H2 that allows only certain trusted, verified and reputable executables, DLL files and MSI installers to run. Anything not trusted will be blocked from running. This leaves us with a very high security posture.

Microsoft says this feature is intended for consumers and small businesses – and recommends larger organizations and enterprises to use Defender Application Control, which uses the same technology in the background, and has been available since the launch of Windows 10.

This blog post covers Smart App Control versus Defender Application Control in a cloud-native world, where Windows devices are connected only to Azure AD and Intune.

Background

One thing to start with – forget AppLocker as it is too weak and has too many flaws. We need something more secure that also includes anything running on the machine, regardless of user space vs kernel space and also applies to local administrators. At the same time, it must be hard to circumvent which is true for both Smart App Control and Application Control. AppLocker is too easy to circumvent, for instance by using a trusted process by AppLocker to load a malicious DLL file. See a number of examples on AppLocker bypasses here.

High-level overview

Smart App ControlApplication Control
Target audienceConsumers and small businesses.Organizations and enterprises.
ModesOn (Block), Evaluation (Audit), Off.Audit or Block mode.
ExceptionsNo exceptions possible – you are 100% in hands of Microsoft control and deciding what is trusted and reputable.You can create exceptions; however, it involves a certain amount of administration and manual work.
EnablementOnly for fresh deployment/installations, or resets of Windows 11 22H2.Any given time – whenever you choose to deploy it.

Goal is to set On (Block) mode, but first Evaluation (Audit) mode

Whenever enabling a technology that will effectively block stuff, it is highly recommended to first assess the situation obtaining intel about what would happen if we set a feature like this in On or Block mode.

So, our goal is without a doubt to first audit and collect information that we can use to evaluate how enabling either Smart App Control or Application Control in block would work. This is the focus to come, when we look at options on enabling audit/evaluation mode.

At the same time, we need to weigh in that running in audit mode gives us no raised security, it will only collect information. The sooner we can enable Block or On mode, the better.

Options to enable via Intune

Smart App ControlApplication Control (AppLocker CSP)Application Control (ApplicationControl CSP)
TechnologyRegistry value1.Endpoint Protection configuration profile (uses AppLocker CSP in background).Using Custom OMA-URI configuration profile using ApplicationControl CSP.
Mode of allow control featuresDefault Allow Microsoft binaries + Intelligent Security Graph (reputable binaries) + Microsoft recommended driver block rules + Microsoft recommended block rules (with exception of what is noted here)Default Allow policy in Audit or Block mode. “Optional” to use Intelligent Security Graph (reputable binaries), but if you want it to work and not block you from working you MUST use Intelligent Security Graph. Custom policy which might contain any number and type of rules, including Intelligent Security Graph.
Managed installerNo, not available.No, not available.Yes, this is possible. You can set Intune agent as Managed Installer to trust everything that comes through Intune. However, Managed Installer can only be applied via a custom created AppLocker XML file which must be applied with an AppLocker PowerShell command, plus the Application Control must use option 13 which is the “Managed Installer” enable switch.
RebootNo, not when applied but requires a reboot to take effect.When applied it forces a reboot of the computer, both in audit and block mode. This breaks ESP (Enrollment Status Page) when using Autopilot. No, not when applied, but needs a restart to take effect (unless you specify option 16 when creating the policy).

1 Registry value to configure Smart App Control is found in HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy. The DWORD value named VerifiedAndReputablePolicyState can be set to 0 = Off, 1 = On or 2 = Evaluation.

AppLocker CSP vs ApplicationControl CSP

The big difference is that the AppLocker CSP always requires a forced reboot, which means we cannot use it in practice when doing Autopilot and using the Enrollment Status Page. That leaves us with manual configuration of Application Control via ApplicationControl CSP, which is the most secure option where you are in total control. The only problem is that this involves many manual steps, and this surely needs a user interface (in Intune).

“WDAC policy deployment via the AppLocker CSP will continue to be supported, all new feature work will be done in the ApplicationControl CSP only”

https://learn.microsoft.com/en-us/windows/client-management/mdm/applicationcontrol-csp?source=recommendations

Example policies and check if policy is applied

You can check what policies are applied, if any on your computers, by looking at two places in the file system. If only one single policy is applied, which is the case if using Application Control with AppLocker CSP, it will be found in the below directory and names SIPolicy.p7b:

C:\Windows\System32\CodeIntegrity\CIPolicies

However, if multiple policies are applied, which is the case if you applied Smart App Control or using ApplicationControl CSP with base and supplemental policies, they will be found in:

C:\Windows\System32\CodeIntegrity\CIPolicies\Active

You can also start msinfo32.exe and see the current configuration.

Caption from msinfo32.exe

Analyzing potential impact of Smart App Control or Application Control

Regardless of if you enable Smart App Control in Evaluation mode or Application Control in audit mode, you can and must follow-up in Microsoft 365 Defender portal (https://security.microsoft.com). This is where you find everything you need to get an overview of the current situation.

Timeline

If you go to a specific device in the Defender portal (https://security.microsoft.com), you can explicitly see the actions by Application Control (and Smart App Control).

Device timeline showing block actions for this particular device.

KQL – Advanced hunting

To be able to get the big picture in a larger organization we need to use advanced hunting to get all the information we can about the audit events.

Smart App Control or Application Control in Evaluation / Audit mode

Use the following KQL query to list everything that would be blocked if switching the Smart App Control to On or Application Control policy to Block mode.

DeviceEvents
| where ActionType == "AppControlCodeIntegrityPolicyAudited"

Smart App Control or Application Control in On / Block mode

Use the following KQL query to list everything that is noticed by users that is blocked when running in On or Block mode.

DeviceEvents
| where ActionType == "AppControlCodeIntegrityPolicyBlocked"

To execute these KQL queries, head over to security.microsoft.com and go to Hunting > Advanced hunting and run the query and note the results, see below example:

Blocked actions, i.e. files that were prevented from being executed.

Getting from audit / evaluation mode to Block / On

Getting from Evaluation mode to On when using Smart App Control is technically easy – but the limitation is that you cannot create any exceptions if necessary. This basically means that you will be forced to live with some things being blocked, provide other means of delivering that app such as via Cloud PC, or simply disabling Smart App Control. In the best of worlds, having Smart App Control in On mode from day 1, let it be only for some or almost all devices is a huge security gain.

Getting from Audit mode to Block for Application Control requires some work as you will have to create the baseline policies and test, test and test before deploying full scale.

Something to note here as well is that when using Application Control, it is a strong recommendation to have the policies signed with a code signing certificate to provide the best security, i.e. protect the policy or policies from tampering by users or administrators. The code signing recommendation also adds some complexity to the process and routines around handling the signing itself.

Summary

I agree with Microsoft that Smart App Control is limited when it comes to exceptions and that Application Control is the superior technology to use. However, as it looks right now, there are no shortcuts to using Application Control and for most organizations, the threshold to pass to get to a block mode today is extensive and very time-consuming. At the same time, there are technical implementations that break most Autopilot scenarios which is not OK to step aside from.

What I really like about Smart App Control is that you get it for free when fresh installing or obtaining Windows 11 22H2 machines, having the ability to easily turn on the protection mechanism that will truly protect your devices. And you can start monitoring from day 1, and with minimum effort easily enable the protection mechanism.

The big drawback of Smart App Control is that you cannot make any exceptions if something is blocked and you want to allow it, that is very obvious. In this scenario you would have to disable Smart App Control or present the application to the users in another way, via for instance Azure Virtual Desktop where you could publish the application as a remote application.

So, what Microsoft should provide are the tools that will help IT departments to enable Application Control. There must be an easy way via Intune to 1) making sure we have an easy way of defining the Intune agent to become a managed installer and 2) making it easy to create a great baseline policy, and 3) making it easy to create supplemental policies whenever something needs to be allowed (as an option to deploying the binary via the Intune agent).

Replacing AppLocker with Microsoft Defender Application Control in Windows 10 1903 and later

Forget AppLocker and all its weaknesses and start using Microsoft Defender Application Control for superior application whitelisting in Windows 10 1903 and later.

This is a guide to get you started within an hour or two with what I call “AppLocker Deluxe” and that is Microsoft Defender Application Control, formerly known as Device Guard and up until recently Windows Defender Application Control (WDAC).

Most customers that did not use AppLocker before Wannacry and other types of ransomware attacks are now using AppLocker to prevent malicious software to run on their Windows devices. As many security specialists have shown, there are numerous ways to bypass AppLocker and still get code to execute. One of them being using regsvr32 to download and execute script directly from the internet for instance.

What is superior to AppLocker is Microsoft Defender Application Guard (MDAC). This takes application whitelisting to a new level and with Windows 10 version 1903 it becomes the first time since Windows 10 launched that it is actually usuable in many common day scenarios as the administration can now be on a level which is really to manage. The reason for this it being rather easy to manage now is primarily:

  • Multiple policies. You can have multiple policies complementing each other so that you do not have to sign everything nor have to create an entirely new baseline each time you want to allow new things to run.
  • Path rules. You can use path rules as of Windows 10 version 1903. As always, this is a balance between security and useability and administration so bear in mind and use this with caution. What is good is that MDAC comes with a use writable protection.

Pre-reqs for getting started

So to get started in something that looks like a real world scebario you need this:

  • 2 physical machines, different hardware models, that run Windows 10 version 1903 or preferably 1909 or later as that gives you some better insights.
  • A couple of hours of your time to get going!

High level steps

  1. Create a baseline on each hardware model.
  2. Merge the baselines into one general baseline.
  3. Create a supplemental policy.
  4. Deploy the two policies.
  5. Start the testing.
  6. Switch from Audit to Enforced mode!

1. Create a baseline on each hardware model

Let’s start with creating a baseline policy from two different machines, which will later be merged to one baseline policy. We will start with auditing, and eventually in the end of this guide switch to enforced mode.

$CIPolicyfileXML = "C:\temp\CIpolicy_model.xml"
New-CIPolicy -MultiplePolicy -filePath $CIPolicyfileXML -ScanPath C: -level FilePublisher -UserPEs -Fallback Hash

Now we set the necessary options for the code integrity policy, which is to use Microsofts Intelligent Security Graph for whitelisting (option 14), to allow supplemental policies to be used (option 17) and then we set Hardware Virtualized Code Integrity (HVCI) to Enabled.

#Automatically trust what Microsoft has deemed trustworthy using the Intelligent Security Graph
Set-RuleOption -FilePath $CIPolicyfileXML -Option 14
#Set the following option to make sure the policy can be applied without reboot
Set-RuleOption -FilePath $CIPolicyfileXML -Option 16
#Set this policy to allow supplemental policies, otherwise we can't supplement this basepolicy
Set-RuleOption -FilePath $CIPolicyfileXML -Option 17
#Now activating Hardware Virtualized Code Integrity (HVCI) and set it to enabled
Set-HVCIOptions -Enabled -FilePath $CIPolicyfileXML

Repeat the above process for at least two models, but preferably for each model you have in your environment (or at least the top five mot used models).

Note: Enabling the Intelligent Security Graph option will white list the installer for 7-Zip for instance. It will then also white list all executables that the 7-Zip installer puts on your system.

2. Merge the baselines into one general baseline

We will now merge the baselines from the two models (or more) and create one single baseline policy.

#When done collecting CIPolicies, merge them to create a common baseline
$CIPolicyfileXMLMerged = "C:\temp\Merged.xml"
$CIPolicyfileBin = "c:\temp\Merged.cip"
Merge-CIPolicy -OutputFilePath C:\temp\merged.xml -PolicyPaths "C:\temp\CIPolicy_modelX.xml","C:\temp\CIPolicy_modellY.xml"
#Then convert to binary format
ConvertFrom-CIPolicy -XmlfilePath $CIPolicyfileXMLMerged -BinaryFilePath $CIPolicyfileBin

Last but not least you must change the name of the Merged.cip file to match the Policy ID of the file which can be found at the bottom in the Merged.xml file, see the <PolicyID> section. The end result should look like {76300157-42A0-4A2D-A383-AF140D64AAE0}.cip.

3. Create a supplemental policy

Now we will create the first supplemental policy to supplement the baseline policy created in step 1 and 2. This is using path rules which is something that was added with Windows 10 version 1903.

#Now create a supplemental policy with file path rules
$CIPolicyfileXMLSupplemental = "C:\temp\Supplemental.xml"
$rules = New-CIPolicyRule -FilePathRule "C:\Program files\*"
$rules += New-CIPolicyRule -FilePathRule "C:\Program files (x86)\*"
$rules += New-CIPolicyRule -FilePathRule "\\server1\installation\*"
New-CIPolicy -FilePath $CIPolicyfileXMLSupplemental -Rules $rules -UserPEs
Set-CIPolicyIdInfo -FilePath $CIPolicyfileXMLSupplemental -BasePolicyToSupplementPath $CIPolicyfileXMLMerged
#now lookup the PolicyGUID from the bottom of the Supplemental.xml file.
ConvertFrom-CIPolicy -XmlFilePath $CIPolicyfileXMLSupplemental -Binary Supplemental.cip

You must change the name of the Supplemental.cip file to match the Policy ID of the supplemental file which can be found at the bottom in the Supplemental.xml file, see the <PolicyID> section. The end result should look like {56B75B7A-06D3-49EF-BCF8-8FC47C6ADA20}.cip.

4. Deploy the two policies

Now, lets deploy the two policies by copying them to C:\Windows\System32\CodeIntegrity\CIPolicies\Active.

For the sake of it, restart the machine. You could also use the below PowerShell command to refresh the policy without reboot:

Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath = 'C:\Windows\System32\CodeIntegrity\CiPolicies\Active\{GUID}.cip'}

5. Start the testing

Now you can start the testing and see what is blocked by fetching the log files which are located in Event Viewer under Applications and Services Logs > Microsoft > Windows > Code Integrity > Operational.

6. Switch from audit mode to enforced mode!

Out of everything that would have been blocked by fetching the logs as mentioned in step 5, create additional supplemental policies and deploy until everything you need to run is white listed. Then, switch from audit mode to enforced!

Set-RuleOption -FilePath $CIPolicyfileXML -Delete -Option 3

Deploying via Intune

Even though there are existing configuration settings for enabling Microsoft Defender Application Control in an Intune endpoint restrictions policy, enabling it via those settings will mean very limited control and you cannot use supplemental policies. So, therefore you need to deploy these control policies in another way.

1. Create a source folder in C:\ named MDAC, in which you create a folder named Source, where you copy the .CIP files.

2. Create a textfile named SchTask.ps1 and add the following content.

New-Item -Path "c:\" -Name "CI" -ItemType "directory"
Copy-Item -Path ".\{76300157-42A0-4A2D-A383-AF140D64AAE0}.cip" -Destination "C:\CI" -Force
Copy-Item -Path ".\{56B75B7A-06D3-49EF-BCF8-8FC47C6ADA20}.cip" -Destination "C:\CI" -Force
Copy-Item -Path ".\MDAC.ps1" -Destination "C:\CI" -Force
$Time = New-ScheduledTaskTrigger -Once -At 12:00
$User = "SYSTEM"
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ex bypass -file `"C:\CI\MDAC.ps1`""
Register-ScheduledTask -TaskName "CI" -Trigger $Time -User $User -Action $Action -Force
Start-ScheduledTask -TaskName "CI"
Return 0

3. Create a textfile named MDAC.ps1 and add the following content.

Copy-Item -Path "C:\CI\{56B75B7A-06D3-49EF-BCF8-8FC47C6ADA20}.cip" -Destination "C:\Windows\System32\CodeIntegrity\CiPolicies\Active" -Force
Copy-Item -Path "c:\CI\{76300157-42A0-4A2D-A383-AF140D64AAE0}.cip" -Destination "C:\Windows\System32\CodeIntegrity\CiPolicies\Active" -Force
Return 0

4. As we will deploy this using a Win32 app, download the Intune content prep tool and run the following command from the extracted IntuneWinAppUtil.exe.

IntuneWinAppUtil.exe -c C:\MDAC\Source -s SchTask.ps1 -o C:\MDAC

5. Create a new Win32 app in Intune and use the following parameters when adding it:

Program install and uninstall command:
powershell.exe -ExecutionPolicy Bypass .\SchTask.ps1
Running as System.

Detection rules:
Type: File
Path: C:\Windows\System32\CodeIntegrity\CiPolicies\Active
File or folder: {GUID}.cip
Detection method: file or folder exists

6. Assign the app and wait for the MDAC policy to apply. This can be verified by running msinfo32.exe and watching the status for Windows Defender Application Control.

Next steps: Looking at the CSP for Application Control for even smoother deploying via Intune.