Part 10 of the WDAC detection-engineering series — detecting novel exploitation paths that bypass application control via browser memory corruption or signed Electron/Node shells, with a Sigma rule and exploit-process detection guidance.

Part 9 of the WDAC detection-engineering series — detecting abuse of Windows signature catalogs and previous-version signed script hosts to launder unsigned code past application control, with a Sigma rule and catalog-integrity monitoring guidance.

Part 8 of the WDAC detection-engineering series — detecting signed Microsoft installers, helpers, and deserialising utilities repurposed to execute attacker code, with a Sigma rule and tuning guidance.

Part 7 of the WDAC detection-engineering series — detecting Windows Subsystem for Linux binaries used to cross an application-control boundary, with a Sigma rule and WSL telemetry guidance.

Part 6 of the WDAC detection-engineering series — detecting User-Mode Code Integrity (UMCI) bypasses and escapes from PowerShell Constrained Language Mode, with a Sigma rule and PowerShell event-log coverage.

Part 5 of the WDAC detection-engineering series — detecting WMIC XSL stylesheets, mshta, winrm.vbs, and COM XSL transformations used to execute attacker code from trusted interpreters, with a Sigma rule and script-engine lineage guidance.

Part 4 of the WDAC detection-engineering series — detecting attackers who weaponise WDAC policies to switch off EDR at boot, including malicious .cip writes, GPO policy deployment, and the heartbeat-absence "dark endpoint" detection.

Part 3 of the WDAC detection-engineering series — detecting trusted developer compilers and REPL hosts repurposed to execute attacker code, with a Sigma rule and parentage tuning guidance.

Part 2 of the WDAC detection-engineering series — how to detect a Microsoft-signed debugger used to inject shellcode into a remote process, including a Sigma rule for script-driven injection and behavioural detection of thread-context manipulation.

Part 1 of the WDAC detection-engineering series — a baseline strategy for catching application-control bypass LOLBINs with Sysmon image-load and process-create telemetry, with a ready-to-use Sigma rule.

A category-by-category system hardening checklist for Windows and Linux — accounts, network, firewall, patching, services, logging, physical — mapped to CIS, NIST and STIG, plus the process and tooling to keep it maintained.

The FileName rule level in WDAC App Control for Business allows or denies execution based on metadata embedded in the file's PE VERSIONINFO resource — not base

The FilePath rule level in WDAC App Control for Business allows execution of any code located at a specified filesystem path — without checking what that code a

FilePublisher is the gold standard rule level for most enterprise WDAC deployments. It offers the optimal balance between specificity and maintainability — tigh

The Hash rule level in Windows Defender Application Control is the most granular and cryptographically precise rule level available. A Hash rule allows or deni

The LeafCertificate rule level trusts files based on the end-entity certificate that was used to directly sign those files. This is the actual code-signing cer

The PcaCertificate rule level in Windows Defender Application Control trusts files based on the intermediate Certificate Authority certificate that sits betwee

The Publisher rule level is one of the most practical and widely used certificate-based trust levels in Windows Defender Application Control , also known as App

The SignedVersion rule level in WDAC App Control for Business grants execution rights based on two combined criteria: the file must be signed by a specific publ

> CRITICAL: The RootCertificate level is NOT SUPPORTED in App Control for Business . This document explains why, what happens if you try to use it, and what you

> Windows Hardware Quality Lab signing — a Microsoft-operated certification program that tests and cryptographically endorses hardware drivers. The WHQL level i

> Combines the WHQL EKU trust check with the Common Name of the leaf certificate — allowing only WHQL-certified drivers from a specific named hardware vendor,

> The most specific WHQL-family rule level: combines the WHQL EKU trust check, vendor leaf certificate CN, specific driver filename, and a minimum version floor

> Formerly known as: Windows Defender Application Control