Skip to content

Application and Behavior Control

Authenticode (code signing)

On a stock, non-domain, unmanaged Windows 11 machine, Authenticode signature validity is essentially advisory for user-mode code (EXE/DLL).

Neither the Windows loader (CreateProcess) nor the DLL loader (LoadLibrary) performs any Authenticode signature validation. A piece of code that is either not signed or with an invalid signature is executed anyway.

The main exception is when an executable carries the Mark of the Web (MOTW) — i.e., it was downloaded from the Internet. In that case, Microsoft Defender SmartScreen evaluates the file's reputation by querying a cloud service (the same as the one queried by WDAC below). Reputation depends on many signals: signature validity, publisher trust, download prevalence, URL/domain reputation, and cloud telemetry. If reputation is insufficient a warning dialog is shown (not a hard block); the user can dismiss it and run the file anyway. This evaluation persists on each launch until sufficient reputation accumulates or the user manually unblocks the file.

Kernel-mode drivers must instead have a valid Authenticode signature, checked at load time (i.e., every time).

Attack Surface Reduction (ASR)

It is a form of policy-based behavioral detection that block specific techniques known to be used by malware and adversaries.

It consists of a set of approximately 20 rules enforced by Windows Defender. In non-domain joined machines all the ASR rules are disabled by default. They can be managed with PowerShell.

A subset of the available rules:

  • Block credential stealing from LSASS.
  • Block Adobe Reader from creating child processes.
  • Block all Office applications from creating child processes.
  • Block executable content from email client and webmail.
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion.
  • Block execution of potentially obfuscated scripts.
  • Block JavaScript or VBScript from launching downloaded executable content.
  • Block Office applications from creating executable content.
  • Block Office applications from injecting code into other processes.
  • Block untrusted and unsigned processes that run from USB.
  • Block process creations originating from PSExec and WMI commands.
  • Block Win32 API calls from Office macros.

According to Microsoft, some rules can be activated without any prior testing whereas most rules require testing (Audit mode) to make sure they do not block legitimate applications.

WDAC (Windows Defender Application Control)

It allows defining policies for determining whether a piece of code (executable, DLL, driver, script) is allowed to run at all, independent of runtime behavior.

It is enforced at the kernel level.

Policies can allow/deny based on publisher certificate, file hash, file path, Package Family Name, or other attributes. They can also be based on a reputation level determined dynamically and obtained from a cloud service (see next section).

One may define policies that lock down a system to only run known, signed, trusted software — common in kiosk machines, regulated/high-security environments. Or, policies that prevent execution of fileless/living-off-the-land attacks that ASR rules don't specifically name.

Deploying "strict policies" on common environments is hard: they can block many legitimate pieces of code; error messages can be misleading (attributing the observed failure to the real reason is hard). See Locking down Windows Part 2: AppControl Manager (AppControl Manager is an application with a GUI for managing WDAC).

Reputation

WDAC rules can be based on the reputation of a piece of code. Reputation is determined entirely by Microsoft's Intelligent Security Graph (ISG) — a cloud-based service, not any local heuristic or on-device analysis.

ISG is only consulted as a fallback, for binaries that are not explicitly allowed or denied by the WDAC policy. A file "not good" is not allowed to run.

Important details:

  • The decision from the cloud can change over time. There is a corresponding policy option that forces periodic re-validation of previously-ISG-authorized files.
  • Dynamically-generated or frequently-changing files require an explicit rule because they hardly collect a sufficient reputation.
  • Apps signed by the Microsoft Store are not covered by ISG, thus they should be authorized via explicit signer rules.
  • Boot-critical or business-critical binaries must never rely on ISG and must be allowed using explicit rules.
  • Offline/air-gapped environments are a poor fit because they cannot query the ISG.
  • When an installer runs that has good reputation according to the ISG, the files that the installer writes to disk will inherit the reputation from the installer — so reputation can propagate from an installer process to the files it drops, not just be evaluated file-by-file.

AppLocker

Older allowlist technology that applies only to domain-joined machines. It conists of a set of rules that can be targeted to specific users or groups.

Every AppLocker rule is a static, deterministic match against one of three attributes:

  • Publisher rule — code-signing certificate (publisher name, product name, file name, version range).
  • Path rule — file location.
  • Hash rule — cryptographic hash of the specific binary.

It is functionally similar to WDAC but with the fundamental limitation of being enforced at user level, not at the kernel level. Thus:

  • An adversary with sufficient privileges can tamper with the defined rules.
  • It is unable to block execution of kernel-mode drivers.

Another limitation is that it does not support reputation-based trust of executables.