intermediate

Application control: AppLocker & Software Restriction Policies

Policy that decides which executables, scripts, and installers are even allowed to run — enforced before the image loader finishes its job.

Related labs

Hands-on exercises for this area — in the browser or on a Windows machine.

ACL & SDDL Lab

Paste SDDL or pick samples, then see owner, DACL, SACL, and ACE meaning in plain language.

Open lab

View all labs

Guided paths in this branch

Follow a short sequence step by step. Each path links to the first topic; use Read next on each page to continue.

Security deep dive

From identity (tokens) to object policy (DACL/SACL), through kernel access checks (SRM), ending with UAC and integrity boundaries.

1. Security 2. Access tokens 3. Security descriptors & ACLs 4. Access checks & Security Reference Monitor 5. UAC, integrity levels, and secure desktop

Follow this path

Why it matters

Every other security mechanism in this course assumes a program is already running and asks what it's allowed to touch. Application control asks the question one step earlier: should this program have been allowed to start running at all?

Mental model

Think of it as a gate bolted onto the image loader: before an EXE, DLL, script, or installer package actually gets to run, a rule engine evaluates it against an admin-defined policy (by publisher signature, path, or file hash) and can refuse the launch outright.

How it works

1**Software Restriction Policies (SRP)** is the older, simpler mechanism: path/hash/certificate-based rules evaluated by `AppLocker`'s predecessor, applied broadly and with fewer rule types.
2**AppLocker** is the modern replacement: richer rule collections (executables, scripts, installers, packaged apps, DLLs), per-user/group targeting, and an audit-only mode that logs what *would* have been blocked without actually blocking it — essential for safely rolling out a policy.
3**Application Identification (AppID, the `appid.sys`/`AppIDSvc` pair)** is the component that actually computes the publisher/hash/path identity used to evaluate rules — both SRP and AppLocker are policy layers built on top of what AppID determines about a given file.
4Enforcement happens at process-creation and DLL/script-load time, cooperating with the image loader and the script-hosting engines (PowerShell, `mshta`, the Windows Script Host) rather than being a single centralized checkpoint.

Key terms

Rule collection: An AppLocker category (executable, script, installer, packaged app, DLL) with its own independent rule set.
Publisher rule: A rule matching a code-signing certificate, optionally pinned to a specific product/version range.
Audit-only mode: Policy enforcement mode that logs would-be blocks without actually denying execution — the standard way to validate a new policy.

Blocking execution from a user's Downloads folder

A path-based AppLocker rule denying execution from `%USERPROFILE%\Downloads\*` stops a large share of common malware delivery (a user downloading and double-clicking an EXE) without needing signature or hash data at all — at the cost of also blocking legitimate portable tools placed there.

Common misconception

Assuming application control is a replacement for antivirus or for patching — it only answers 'should this image be allowed to start', not 'is this image malicious once it's already an allowed, signed binary', and a determined attacker who can plant files inside an allow-listed path or steal a trusted signing certificate routes around it entirely.

You should read next

Ranked from your current topic, related links, branch depth, and any active guided path.

expert