TECHNICAL WHITEPAPER
Execution Trust on Microsoft Windows
Reputation, Mark-of-the-Web, and Application Control
How Windows decides whether code is allowed to run — and why the answer depends on which control is in force.
Subject: Endpoint security · Code integrity · Application control
Classification: Public / General distribution
Version 1.0
1. Executive Summary
Every time a Windows endpoint runs a binary, script, or driver, it makes a trust decision: should this code be permitted to execute? The mechanisms that inform that decision are layered and frequently misunderstood, and they fall into two fundamentally different security models. Reputation-based controls such as Microsoft Defender SmartScreen ask “is this known to be bad, or does it look risky?” and typically warn the user while still allowing an override. Application-control controls such as App Control for Business (WDAC), AppLocker, and Smart App Control invert the question to “is this explicitly approved to run?” and block anything that fails policy.
This distinction matters because the two models offer very different assurances. A code-signing certificate or a particular delivery format may influence a reputation prompt, but neither reliably prevents execution on a current, patched system. Only policy-enforced application control delivers the property of “unsigned or unapproved code does not run.” This paper explains each control, traces the documented history of Mark-of-the-Web (MOTW) bypass techniques that exploited container file formats, summarises the patches that closed them, and maps the whole picture to recognised security frameworks including MITRE ATT&CK, the CIS Critical Security Controls, and the ASD Essential Eight.
2. The Trust Problem
Traditional antivirus operates on a deny-known-bad model: code is allowed to run unless the scanner confidently identifies it as malicious. With large volumes of new and unique files appearing continuously, this model is structurally reactive — a never-before-seen file has no signature to match, and the most dangerous moment is precisely the moment of first encounter. The trusted user at the keyboard compounds the problem: a process launched by a user inherits that user’s access, so a single mistaken double-click can expose everything that user can reach.
Windows therefore layers several distinct controls between a downloaded file and its execution. Understanding them requires separating three concerns that are often conflated: provenance (where did this file come from?), reputation (is this file or publisher known and trusted?), and policy (is this code permitted to run here regardless of reputation?). Mark-of-the-Web addresses provenance; SmartScreen and Smart App Control address reputation; application control addresses policy.
3. Mark-of-the-Web (MOTW)
Mark-of-the-Web is the provenance tag that makes the other controls possible. When a file is downloaded from the internet, Windows attaches a hidden NTFS Alternate Data Stream (ADS) named Zone.Identifier, recording the security zone the file originated from (internet content is ZoneId=3), along with referrer and source URL information. Downstream security features inspect this stream to decide how to treat the file.
The presence of MOTW is the trigger for several protective behaviours: Microsoft Office opens MOTW-tagged documents in Protected View; SmartScreen subjects MOTW-tagged executables to a reputation check; and Smart App Control evaluates MOTW-tagged code against policy and reputation. The corollary is the crux of many evasion techniques: if the mark is absent, these checks do not fire. A file that never received MOTW — or had it stripped — is treated as a trusted local file.
4. Microsoft Defender SmartScreen
SmartScreen is a reputation service, not a signature scanner. When a user attempts to run a MOTW-tagged executable, SmartScreen performs a reputation lookup. Well-known, prevalent, trusted files run without friction; unknown or low-prevalence files produce the familiar “Windows protected your PC” warning, which the user can override. SmartScreen draws on the same cloud-backed reputation service — the Microsoft Intelligent Security Graph (ISG) — used by Defender Antivirus and by Smart App Control.
Two properties define SmartScreen’s security value and its limits. First, it is advisory: its default outcome for an unknown file is a dismissible warning, not a hard block. Second, it is reputation-driven: a file earns trust through prevalence and time, not merely by being signed. These properties explain why SmartScreen is best understood as a user-awareness and friction control rather than a code-execution barrier.
5. Code Signing and Reputation
Authenticode signing binds a publisher identity to a binary and lets Windows verify the file has not been tampered with since signing. It is commonly assumed that signing a binary causes SmartScreen to wave it through. This is inaccurate. Because SmartScreen is reputation-based, a freshly signed but low-prevalence binary still draws the “unknown publisher” warning until the publisher identity accrues reputation. Signing contributes to reputation; it does not substitute for it.
Extended Validation (EV) code-signing certificates historically conferred near-immediate SmartScreen reputation, which was a primary selling point of EV over standard Organization Validation (OV) certificates. That advantage has eroded over time and should not be treated as a guaranteed instant-trust mechanism, particularly alongside tightened issuance requirements such as mandatory hardware-token key storage. From a defensive standpoint, a signature is also a strong attribution and revocation lever: a signed file ties activity to an identifiable certificate that can be revoked, which limits the operational value of signing for adversaries while increasing it for defenders and software vendors.
6. Container Formats and the Mark-of-the-Web Bypass Lineage
Because so many protections hinge on MOTW being present, a recurring class of techniques has focused on delivering payloads in a way that prevents the mark from reaching the executed file. The classic approach used container file formats — disk images (.iso, .img, .vhd, .vhdx) and certain archives. A container downloaded from the internet receives MOTW, but the files inside historically did not inherit the mark when the container was mounted or extracted, because these formats do not carry NTFS alternate data streams. Once mounted, the inner payload was treated as a trusted local file and ran without a SmartScreen prompt. This technique is catalogued by MITRE ATT&CK as sub-technique T1553.005, Mark-of-the-Web Bypass, and saw heavy use by commodity and state-aligned actors during 2022.
Microsoft has progressively closed these gaps. The November 2022 update addressed under CVE-2022-41091 changed Windows so that MOTW propagates from a downloaded ISO to its contents, so launching an inner file now produces the expected security warning. Related MOTW handling issues in archive and SmartScreen logic were addressed in the same period (for example CVE-2022-44698), and subsequent variants — such as the LNK path-normalisation “LNK stomping” technique (CVE-2024-38217) and the WebDAV copy-paste “copy2pwn” issue (CVE-2024-38213) — have each been patched as they were disclosed.
The strategic lesson is twofold. First, on a current, patched endpoint the naive container bypass no longer works as it once did. Second, this area exhibits a persistent patch-and-iterate cycle: narrowly scoped fixes have repeatedly been followed by new variants of the same underlying weakness. Defenders should therefore treat MOTW-dependent protections as valuable but not self-sufficient, and should not assume any single delivery technique is reliably neutralised without verifying the target’s actual patch level.
7. Application Control: The Inverted Model
Application control changes the default posture of the operating system. Rather than allowing all code to run unless something flags it as bad, it permits code to run only when policy explicitly approves it. Microsoft’s own documentation frames the shift as moving from “is this known to be bad?” to “is this approved to run?” This is the only category of control discussed here that reliably prevents unsigned or unapproved code from executing.
7.1 App Control for Business (WDAC)
App Control for Business — formerly Windows Defender Application Control (WDAC) — is a code-integrity policy engine introduced with Windows 10. Policies apply at the device level and govern executables, DLLs, MSI installers, scripts, and drivers across both user mode and kernel mode. Rules can be expressed against several criteria, including the attributes of the code-signing certificate used to sign an application, signed file metadata such as original filename and version, the file hash, the app’s reputation via the Intelligent Security Graph, the identity of the managed installer that deployed it, and the launch path. Enforcement sits in the kernel and can be hardware-reinforced, making it substantially more tamper-resistant than reputation prompts; policies can themselves be signed to resist removal. An important operational property is that policies can run in audit mode — logging what would have been blocked without enforcing — which supports safe rollout.
7.2 AppLocker
AppLocker is the older application-control mechanism. It operates in user mode and supports allowlisting by publisher (signature), path, and hash, and — unlike App Control for Business — its rules can be targeted to users and groups rather than only devices. It is simpler to deploy through Group Policy but provides weaker assurance: it lacks kernel-mode driver control and has a larger body of known bypasses. It remains useful as a complementary, fine-grained layer and as an accessible starting point.
7.3 Smart App Control
Smart App Control, introduced in Windows 11, brings application control to consumers and smaller organisations. It is built on the same App Control for Business engine and ensures that only signed code, or code the cloud service predicts to be safe, is allowed to run; when code is unsigned and the service cannot confidently predict it is safe, it is blocked. It is enabled or disabled as a whole rather than finely policy-managed, and — by design — it begins in an evaluation mode and cannot be re-enabled without resetting Windows once turned off. Functionally it is a “block untrusted code” control rather than an advisory one.
7.4 Comparison of Windows execution-trust controls
8. Kernel-Mode Code Integrity and Driver Signing
Beneath the application layer, Windows enforces a separate and stricter requirement for kernel-mode code. On 64-bit Windows, kernel drivers must carry a valid signature anchored to a trusted authority or they will not load — a control known as Kernel-Mode Code Integrity / Driver Signature Enforcement. This is independent of the application-control policies above and addresses the highest-privilege code on the system. Hypervisor-protected Code Integrity (memory integrity) can further isolate the code-integrity checks themselves, raising the bar against tampering.
9. Cross-Platform Parallels
The execution-trust model is not unique to Windows; the same principle — establish a trust anchor, verify code against it, refuse to run what does not match — appears across platforms.
macOS — Gatekeeper: layered over mandatory code signing, Gatekeeper checks an application’s Developer ID signature and notarisation status and, by default, blocks software that is unsigned or not notarised.
Linux — IMA/EVM and dm-verity: the Integrity Measurement Architecture measures and can appraise files against signed reference values, while dm-verity provides block-level integrity for read-only, cryptographically verified images — together supplying signed/measured-execution and verified-boot equivalents.
The shared takeaway is that signing alone is a trust signal; it is the surrounding enforcement layer (Gatekeeper, IMA appraisal, application-control policy) that converts that signal into an execution decision.
10. Standards and Framework Alignment
Application control is not merely a vendor feature; it is codified as a frontline mitigation across major security frameworks, which is useful when justifying its adoption.
11. Conclusion and Recommendations
Windows offers a spectrum of execution-trust controls, but they are not interchangeable. Reputation controls (SmartScreen) raise user awareness and impose friction on unknown files, yet they warn rather than block and can be overridden. Provenance tagging (MOTW) underpins those checks but can be circumvented when delivery prevents the mark from reaching the payload — historically via container formats, though the well-known variants are now patched on current systems. The only controls that reliably stop unsigned or unapproved code from executing are policy-based application-control mechanisms.
Practical recommendations follow directly:
Treat SmartScreen and MOTW as awareness and provenance layers, not as execution barriers.
Maintain rigorous patch hygiene, since MOTW and SmartScreen bypasses have followed a persistent patch-and-iterate pattern.
Where the assurance goal is “unapproved code does not run,” deploy application control — App Control for Business (WDAC) for device-wide, kernel-enforced policy, AppLocker for user/group-scoped allowlisting, or Smart App Control for simpler estates.
Roll out application control in audit mode first, then move to enforcement once legitimate software is accounted for, and consider signed policies to resist tampering.
Layer application control with EDR and antivirus: allowlisting prevents unauthorised execution, while behavioural detection and signature scanning address what executes within the allowed set.
References
Microsoft Learn — Application Control for Windows. https://learn.microsoft.com/windows/security/application-security/application-control/
Microsoft Learn — App Control for Business (WDAC). https://learn.microsoft.com/windows/security/application-security/application-control/app-control-for-business/
Microsoft Learn — App Control for Business and AppLocker Overview.
Microsoft Learn — Smart App Control.
Microsoft Learn — Microsoft Defender SmartScreen overview.
Microsoft Learn — Zone.Identifier / Mark-of-the-Web (Attachment Manager).
MITRE ATT&CK — T1553.005, Subvert Trust Controls: Mark-of-the-Web Bypass. https://attack.mitre.org/techniques/T1553/005/
Microsoft Security Response Center — CVE-2022-41091 (Windows Mark-of-the-Web Security Feature Bypass).
Microsoft Security Response Center — CVE-2022-44698, CVE-2024-38217 (LNK stomping), CVE-2024-38213 (copy2pwn).
CIS Critical Security Controls v8 — Control 2: Inventory and Control of Software Assets.
Australian Signals Directorate — Essential Eight Maturity Model: Application Control.
CISA — #StopRansomware Guide.
This whitepaper is provided for general informational and educational purposes. It describes publicly documented Windows security mechanisms and their evolution. Product names and behaviours are subject to change; consult current vendor documentation for authoritative detail.
