Mastering Windows Defender Application Control (WDAC)

In the modern security landscape, the traditional approach of "detecting bad things" is no longer sufficient. For decades, security professionals relied on antivirus software to identify signatures of known malware. However, with the rise of polymorphic code, zero-day exploits, and sophisticated fileless attacks, trying to keep a list of everything "bad" is a losing game. Windows Defender Application Control (WDAC) flips this paradigm on its head. Instead of trying to identify what is malicious, WDAC defines exactly what is "good" and prevents everything else from running.

WDAC is a crucial component of a Zero Trust architecture. It moves the security boundary from the perimeter of the network down to the kernel of the operating system. By implementing WDAC, you are essentially telling the Windows operating system: "I only trust these specific publishers, these specific files, and these specific paths. If an executable, driver, or script is not on this list, do not execute it." This lesson will dive deep into the mechanics, deployment strategies, and management of WDAC to help you build a truly resilient Windows Server infrastructure.

Understanding the Fundamentals of WDAC

Windows Defender Application Control is a software-based security layer that restricts the applications users are allowed to run and the code that runs in the System Core (kernel). It was originally introduced as part of "Device Guard" in Windows 10, but it has since evolved into a standalone, highly configurable feature available on Windows 10, 11, and Windows Server 2016 and later.

Unlike its predecessor, AppLocker, WDAC is designed to be hardware-rooted and resistant to administrative tampering. While a local administrator can often find ways to circumvent or disable AppLocker, WDAC policies are enforced at the kernel level and can be protected by UEFI Secure Boot, making them much harder to bypass even with elevated privileges.

How WDAC Works

WDAC operates by checking every piece of code before it is loaded into memory. This includes:

• Executable files (.exe)
• Dynamic Link Libraries (.dll)
• Windows Installers (.msi)
• Drivers (.sys)
• Scripts (PowerShell, VBScript, etc.)

When a file attempts to run, the Windows kernel checks the active WDAC policy. If the file meets the criteria defined in the policy (such as having a valid digital signature from a trusted publisher), it is allowed to execute. If it doesn't, the OS blocks the execution and logs the event.

Callout: AppLocker vs. WDAC

While both tools provide application whitelisting, they serve different purposes. AppLocker is primarily a management tool designed to help organizations control which apps users can run to maintain a standard environment. It is relatively easy to set up but can be bypassed by an administrator.

WDAC, on the other hand, is a security feature. It is designed to protect the integrity of the OS against advanced threats. It supports multiple policies, can be digitally signed to prevent tampering, and integrates with hardware-based security features like TPM and Secure Boot. If your goal is high-level security and protection against malware, WDAC is the correct choice.

Policy Types: Base vs. Supplemental

One of the most powerful features of modern WDAC is the ability to use multiple policies simultaneously. This is achieved through Base and Supplemental policies.

1. Base Policies: These define the core "allow" rules for the entire system. A base policy typically includes rules for Windows itself, Microsoft-signed drivers, and perhaps a set of core enterprise applications. A system can have multiple base policies active at once.
2. Supplemental Policies: These are designed to expand a specific base policy. For example, you might have a strict base policy for all servers, but a supplemental policy for your Web Servers that allows the specific binaries required for IIS and your custom web applications. This modular approach makes management much easier.

Rule Levels and Policy Logic

When you create a WDAC policy, you must decide how the system should identify "trusted" software. This is known as the Rule Level. Choosing the right level is a balancing act between security and maintainability.

Common Rule Levels

• Hash: This is the most secure but most difficult to maintain. It identifies a file by its unique cryptographic hash. If the file is updated by even a single byte, the hash changes, and the file will be blocked until the policy is updated.
• FileName: Identifies files by their name. This is generally discouraged as it is easy for an attacker to rename a malicious file to match a trusted name.
• Publisher: This is the "sweet spot" for most organizations. It trusts files based on the digital certificate used to sign them. For example, you can trust everything signed by "Microsoft Corporation" or "Adobe Systems Incorporated." When these companies update their software, the signature remains valid, and the software continues to work without policy updates.
• FilePublisher: A more granular version of the Publisher rule that includes the filename and version range.
• Path: Trusts everything in a specific folder. This is the least secure method because if an attacker gains write access to that folder, they can run whatever they want. However, it is sometimes necessary for legacy applications that aren't digitally signed.

Note: Whenever possible, prioritize Publisher rules. They offer a high level of security while significantly reducing the administrative overhead associated with software updates.

The Role of the Managed Installer

One of the biggest challenges with application control is handling software updates. If you use a tool like Microsoft Endpoint Configuration Manager (MECM/SCCM) to deploy software, you can designate it as a Managed Installer.

When a Managed Installer puts a file on the disk, WDAC marks that file as "trusted" automatically. This allows you to deploy and update software through your standard management tools without having to manually update your WDAC policies every time a new version of Chrome or Zoom is released.

Step-by-Step: Creating Your First WDAC Policy

Creating a WDAC policy involves scanning a "Gold Image" (a system that has all the software you want to allow and none of the software you don't) and generating a policy based on what is found.

Step 1: Prepare the Reference Machine

Ensure you are working on a clean installation of Windows Server. Install all the necessary drivers, updates, and business applications that you want to include in your baseline.

Step 2: Scan the System and Generate the XML Policy

We use PowerShell to perform the scan. Open a PowerShell window as Administrator and run the following commands:

# Define the path for the new policy XML
$policyPath = "C:\WDAC\BasePolicy.xml"

# Scan the system and create the policy
# -Level Publisher: We want to trust software based on its certificate
# -Fallback Hash: If a file isn't signed, we fall back to its hash
New-CIPolicy -FilePath $policyPath -Level Publisher -Fallback Hash -UserPEs

Explanation of parameters:

• -FilePath: Where the resulting XML file will be saved.
• -Level Publisher: Tells WDAC to look for digital signatures first.
• -Fallback Hash: If a file has no signature, it records the hash so the file can still run.
• -UserPEs: Ensures that User Mode Executables (applications) are included in the scan, not just kernel drivers.

Step 3: Set the Policy to Audit Mode

Never deploy a new WDAC policy in "Enforcement" mode initially. You will almost certainly miss something, and the system will become unusable. Instead, we use Audit Mode.

# Set the policy to Audit Mode
Set-RuleOption -FilePath $policyPath -Option 3

In Audit Mode, WDAC will log everything that would have been blocked in the Event Viewer, but it won't actually stop anything from running. This allows you to verify your policy in a production-like environment without breaking things.

Step 4: Convert XML to Binary Format

Windows doesn't read the XML file directly; it requires a binary format (.cip or .p7b).

# Convert the XML to a binary file
$binaryPath = "C:\WDAC\BasePolicy.cip"
ConvertFrom-CIPolicy -XmlFilePath $policyPath -BinaryFilePath $binaryPath

Step 5: Deploy the Policy

For a single server, you can copy the binary file to C:\Windows\System32\CodeIntegrity\SiPolicy.p7b and restart the machine. For an enterprise environment, you would use Group Policy or Microsoft Intune to deploy the .cip file.

Refining and Merging Policies

After running in Audit Mode for a few days, you should check the Event Viewer. Navigate to: Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational

Look for Event ID 3076 (Audit failure). This event tells you exactly what would have been blocked. If you see a legitimate business application being flagged, you need to add it to your policy.

Merging New Rules

Instead of re-scanning the whole machine, you can create a small "capture" policy for the missing items and merge it into your base policy.

# Create a temporary policy for a specific new app
New-CIPolicy -FilePath "C:\WDAC\NewApp.xml" -Level Publisher -ScanPath "C:\Program Files\NewApp"

# Merge the new app rules into the existing base policy
Merge-CIPolicy -OutputFilePath "C:\WDAC\UpdatedBasePolicy.xml" -PolicyPaths "C:\WDAC\BasePolicy.xml", "C:\WDAC\NewApp.xml"

This modularity is what makes WDAC manageable in a dynamic environment. You can keep your base policy clean and add new rules as needed.

Advanced WDAC Features

As you become more comfortable with basic application control, you can explore advanced features that provide even deeper security.

PowerShell Constrained Language Mode

When a WDAC policy is active, PowerShell automatically switches to Constrained Language Mode (CLM) for any script that isn't explicitly trusted by the policy.

CLM prevents the execution of advanced commands often used by attackers, such as calling Win32 APIs directly or using COM objects to bypass security. This is one of the most effective ways to stop "fileless" malware and malicious PowerShell scripts.

The Intelligent Security Graph (ISG)

If your servers have internet access, you can enable the Intelligent Security Graph. This is a cloud-based service managed by Microsoft that tracks the reputation of billions of files.

If a file is not explicitly allowed by your policy but has a very high reputation on the ISG (meaning it is known to be safe and widely used), WDAC can be configured to allow it. This is a great way to handle small, common utilities that might not be in your main policy.

# Enable the Intelligent Security Graph option in your policy
Set-RuleOption -FilePath $policyPath -Option 14

Script Enforcement

By default, WDAC focuses on binaries. However, you can extend enforcement to include scripts. This means every .ps1, .vbs, or .js file must be signed by a trusted certificate or its hash must be in the policy.

Warning: Enabling script enforcement is a significant undertaking. Most environments have hundreds of small scripts running for maintenance, monitoring, and login. If you enable this without thorough auditing, you will break many background processes.

Deployment Strategies and Lifecycle Management

Implementing WDAC is not a "one-and-done" project. It is a lifecycle that requires planning, testing, and ongoing maintenance.

The "Gold Image" Approach

The most successful WDAC deployments start with a dedicated "Build Machine." This is a clean VM used specifically for policy generation.

1. Install the OS.
2. Install all approved software.
3. Run the WDAC scan.
4. Export the policy.
5. Revert the VM to a clean snapshot for the next update.

This ensures that your policy isn't "polluted" by temporary files or malware that might exist on a standard user's machine.

Phased Rollout

A typical WDAC rollout follows these phases:

1. Phase 1: Discovery. Run scripts to inventory all software across the server estate.
2. Phase 2: Audit Mode. Deploy the base policy in Audit Mode to a representative group of servers.
3. Phase 3: Analysis. Spend 2-4 weeks analyzing Audit logs and refining the policy.
4. Phase 4: Enforced Mode (Pilot). Move a small group of non-critical servers to Enforced Mode.
5. Phase 5: Full Enforcement. Broadly deploy the policy in Enforced Mode across the infrastructure.

Comparison: Deployment Methods

Common Pitfalls and How to Avoid Them

Even experienced administrators can run into trouble with WDAC. Here are the most common mistakes and how to avoid them.

1. Forgetting Drivers

WDAC doesn't just block apps; it blocks drivers. If you deploy a policy that doesn't include the signatures for your RAID controller or Network Interface Card (NIC), the server might fail to boot or lose network connectivity.

• Solution: Always perform your initial scan on hardware that is identical to your production servers, or ensure you include "Microsoft-signed drivers" as a default rule.

2. Not Accounting for Auto-Update Apps

Apps like Google Chrome or Slack update themselves frequently. If you use Hash-based rules, these apps will break every few weeks.

• Solution: Use Publisher rules for these applications. Trust the certificate of the developer rather than the specific file hash.

3. Policy Bloat

If you keep adding rules for every single file on every single server, your XML policy will become massive and difficult to read.

• Solution: Use Supplemental policies for department-specific or server-role-specific apps. Keep the Base policy focused on the OS and core tools.

4. Blocking the Managed Installer

If you use MECM to deploy software, but your WDAC policy blocks the MECM agent itself, you lose the ability to update the policy or deploy new software.

• Solution: Always ensure your management agents (MECM, Intune, Splunk, etc.) are explicitly allowed in your base policy with high-level Publisher rules.

Callout: The "Circle of Trust"

Think of WDAC as a "Circle of Trust." Your goal is to keep the circle as small as possible to maintain security, but large enough that your users and systems can function. Every time you add a rule, you are expanding that circle. Ask yourself: "Does this rule need to be here? Can I use a Publisher rule instead of 50 Hash rules?"

Troubleshooting WDAC

When something goes wrong, you need to know where to look. WDAC troubleshooting is almost entirely centered around the Event Viewer.

Key Event IDs

• 3076: Audit Failure. The file would have been blocked if the policy was in Enforcement mode.
• 3077: Enforcement Failure. The file was blocked.
• 3089: Signature information. This event provides the details of the certificate (Publisher, Issuer) for a blocked file, which is essential for creating new rules.
• 3090: Script block. Indicates a PowerShell script was forced into Constrained Language Mode.

Using the "Refresh" Command

If you update a policy file on a local machine, you don't always need to reboot. You can force the OS to reload the policy using the following command (available in newer versions of Windows):

citool.exe --refresh

This is a lifesaver during the testing phase, as it allows for rapid iteration without the downtime of a reboot.

Best Practices for Enterprise WDAC

To ensure long-term success with WDAC, follow these industry standards:

1. Sign Your Policies: You can digitally sign your WDAC policies. Once a policy is signed and the "Disabled: Scripting Enforcement" option is removed, even a local administrator cannot delete or modify the policy file. This is the ultimate protection against "living-off-the-land" attacks.
2. Use Versioning: Always increment the version number in your XML policy (<VersionEx>1.0.0.1</VersionEx>). This helps you track deployments and ensures that the OS knows it is receiving a newer version of the policy.
3. Maintain a "Lab" Environment: Never test a new policy change on a production server. Have a small lab that mirrors your production software stack.
4. Automate Policy Generation: If you are a large organization, look into the "WDAC Ecosystem" tools provided by Microsoft on GitHub. These allow you to automate the creation of policies based on your internal certificate authority or your software inventory.
5. Enable Hypervisor-Protected Code Integrity (HVCI): WDAC works best when combined with HVCI (also known as Memory Integrity). HVCI uses hardware virtualization to protect the Code Integrity process, preventing attackers from injecting malicious code into the kernel even if they find a vulnerability.

Summary and Key Takeaways

Windows Defender Application Control is perhaps the most powerful security feature available in the Windows ecosystem. While it requires more planning and effort than traditional antivirus, the security benefits are incomparable. By moving to a "Default Deny" posture, you effectively neutralize entire classes of malware and exploit techniques.

Key Takeaways:

• Shift to Zero Trust: WDAC implements application whitelisting at the kernel level, ensuring only trusted code can execute.
• Audit Before Enforce: Always start in Audit Mode. Use Event IDs 3076 and 3089 to identify necessary rules before switching to Enforcement Mode.
• Prefer Publisher Rules: Use digital signatures (Publisher level) for rules whenever possible to allow for software updates without manual policy changes.
• Leverage Managed Installers: Use tools like MECM to automatically trust the software you deploy, reducing administrative overhead.
• Protect PowerShell: WDAC automatically triggers Constrained Language Mode, which is a critical defense against modern fileless attacks.
• Modular Management: Use a combination of Base and Supplemental policies to keep your security configuration clean and manageable.
• Hardware Root of Trust: For maximum security, combine WDAC with UEFI Secure Boot and signed policies to prevent even administrators from tampering with security settings.

By mastering WDAC, you are not just adding another layer of security; you are fundamentally changing the way your Windows Servers protect themselves. It is a journey from reactive security to proactive, structural integrity.