Option 13 — Enabled Installer#

What Is an Extended Attribute (EA)?#

Windows NTFS extended attributes are metadata fields attached to a file that live in the NTFS master file table (MFT) alongside the file’s standard attributes (name, size, timestamps). They are key-value pairs that applications and the kernel can read and write. Most user-space tools don’t expose them, but they are accessible via the NtQueryEaFile / NtSetEaFile NT native API calls and the fsutil command.

The KERNEL.SMARTLOCKER.ORIGINCLAIM EA#

When a managed installer process writes a file to disk, the AppLocker kernel driver (AppLockerFltr.sys) intercepts the write operation and attaches a special extended attribute to the written file:

1
EA Name:  KERNEL.SMARTLOCKER.ORIGINCLAIM
2
EA Value: Binary blob (variable length)
3
          ├── Header fields (version, flags)
4
          └── byte[4] = 0x00  ← This byte identifies the claim as "Managed Installer"

The critical discriminator is byte[4] of the EA value:

How ci.dll Uses the EA at Execution Time#

flowchart TD
    Exec([User/process calls CreateProcess or LoadLibrary])
    --> KernelCheck[Windows kernel\ncalls into ci.dll for code integrity check]
    KernelCheck --> PolicyCheck{Does file match\nany explicit policy rule?\nSigner / Hash / Path}
    PolicyCheck -- Yes --> Allow([File execution allowed])
    PolicyCheck -- No --> O13Check{Option 13\nEnabled in policy?}
    O13Check -- No --> Block([File execution blocked])
    O13Check -- Yes --> EARead[ci.dll calls NtQueryEaFile\non the file being executed]
    EARead --> EAExists{EA name\nKERNEL.SMARTLOCKER.ORIGINCLAIM\npresent?}
    EAExists -- No --> Block
    EAExists -- Yes --> EAByte{byte[4] of EA value\n== 0x00?}
    EAByte -- No --> O14Path([Route to ISG check\nsee Option 14])
    EAByte -- Yes --> ValidateClaim[ci.dll validates EA integrity\nChecks claim is not spoofed]
    ValidateClaim --> ClaimValid{EA claim\ncryptographically valid?}
    ClaimValid -- No --> Block
    ClaimValid -- Yes --> Allow

    style Exec fill:#162032,color:#58a6ff
    style KernelCheck fill:#162032,color:#58a6ff
    style PolicyCheck fill:#1a1a0d,color:#fde68a
    style Allow fill:#0d1f12,color:#86efac
    style O13Check fill:#1a1a0d,color:#fde68a
    style Block fill:#1f0d0d,color:#fca5a5
    style EARead fill:#162032,color:#58a6ff
    style EAExists fill:#1a1a0d,color:#fde68a
    style EAByte fill:#1a1a0d,color:#fde68a
    style O14Path fill:#1c1c2e,color:#a5b4fc
    style ValidateClaim fill:#162032,color:#58a6ff
    style ClaimValid fill:#1a1a0d,color:#fde68a

Inspecting the EA on a File#

1
# Check if a file has the Managed Installer EA
2
# Using fsutil (requires admin)
3
fsutil file queryEA "C:\Program Files\MyApp\myapp.exe"
4

5
# PowerShell alternative using P/Invoke to NtQueryEaFile
6
# (No built-in cmdlet; requires low-level API call)
7
# The presence of KERNEL.SMARTLOCKER.ORIGINCLAIM indicates MI-stamped file

1
REM From elevated command prompt:
2
fsutil file queryEA "C:\Program Files\MyApp\myapp.exe"
3
REM Output will show: KERNEL.SMARTLOCKER.ORIGINCLAIM if MI-stamped

EA Persistence and Inheritance#

• The EA is written to the file’s NTFS metadata at write time
• It persists as long as the file is on an NTFS volume
• It is NOT inherited by child files or copies made to non-NTFS volumes (FAT32, exFAT)
• If a file is copied to a FAT32 USB drive and back, the EA is lost — the copy will not be trusted
• File overwrites by non-MI processes do NOT re-stamp the EA; the original EA remains
• If a file is overwritten by a malicious process (not the MI), the overwritten content runs under the original EA — this is a known attack surface (see Security Considerations)

Architecture Overview#

The Managed Installer feature requires two separate but tightly integrated subsystems:

flowchart TD
    subgraph UserSpace["User Space"]
        SCCM([SCCM / Intune Agent\nor designated MI process])
        AppMgmt([Application Install\nFile writes to disk])
    end

    subgraph KernelSpace["Kernel Space"]
        AppLockerFltr([AppLockerFltr.sys\nKernel driver])
        FSFilter([File System Mini-filter\nIntercepts file writes])
        CIModule([ci.dll / Code Integrity\nEvaluates execution])
        NTFS([NTFS Volume\nEA storage in MFT])
    end

    subgraph Policy["Policy Layer"]
        AppLockerPolicy([AppLocker Policy\nManagedInstaller rule collection\nDesignates which processes are MIs])
        WDACPolicy([App Control Policy\nOption 13 enabled\nHonors MI claims])
    end

    SCCM --> AppMgmt
    AppMgmt -->|"CreateFile / WriteFile"| FSFilter
    FSFilter --> AppLockerFltr
    AppLockerFltr -->|"Is writing process designated\nas MI in AppLocker policy?"| AppLockerPolicy
    AppLockerPolicy -->|"Yes: write EA to file"| NTFS
    AppLockerPolicy -->|"No: do not stamp EA"| NTFS

    CIModule -->|"At execution time:\nread EA from MFT"| NTFS
    CIModule -->|"Option 13 check"| WDACPolicy

    style SCCM fill:#0d1f12,color:#86efac
    style AppMgmt fill:#162032,color:#58a6ff
    style AppLockerFltr fill:#1c1c2e,color:#a5b4fc
    style FSFilter fill:#1c1c2e,color:#a5b4fc
    style CIModule fill:#1c1c2e,color:#a5b4fc
    style NTFS fill:#162032,color:#58a6ff
    style AppLockerPolicy fill:#1a1a0d,color:#fde68a
    style WDACPolicy fill:#0d1f12,color:#86efac

What AppLockerFltr.sys Does#

AppLockerFltr.sys is a file system mini-filter driver loaded by the AppLocker service. Its responsibilities in the Managed Installer flow:

1. Intercepts all file write operations at the file system layer
2. Checks the writing process against the AppLocker ManagedInstaller rule collection
3. Stamps the EA (KERNEL.SMARTLOCKER.ORIGINCLAIM with byte[4]=0x00) on files written by designated MI processes
4. Propagates the stamp to extracted archives (if the installer extracts a ZIP/CAB, the extracted files are also stamped)

Verifying AppLockerFltr.sys is Loaded#

1
# Verify the AppLocker filter driver is loaded
2
Get-Service -Name AppIDSvc | Select-Object Status, StartType
3
# Should be: Running, Automatic
4

5
# Check the kernel module directly
6
fltMC | Where-Object { $_ -match "AppLocker" }
7
# or
8
Get-WmiObject Win32_SystemDriver | Where-Object Name -eq "AppLockerFltr"

1
REM From elevated command prompt:
2
fltMC
3
REM Look for "AppLockerFltr" in the output with an altitude number
4
REM Altitude ~130000 range for AppLocker

AppLocker ManagedInstaller Rule Collection#

The AppLocker ManagedInstaller rule collection is separate from the standard AppLocker Executable, Script, DLL, and Packaged Apps rule collections. It designates which processes have MI privileges.

1
<AppLockerPolicy Version="1">
2
  <RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
3

4
    <FilePublisherRule Id="6CC9B840-B4A0-49B1-A9B0-1358E4F4173F"
5
                       Name="CCM Client - Managed Installer"
6
                       Description="Microsoft SCCM client as managed installer"
7
                       UserOrGroupSid="S-1-1-0"
8
                       Action="Allow">
9
      <Conditions>
10
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
11
                                ProductName="*"
12
                                BinaryName="CCMEXEC.EXE"
13
                                FileVersionRange>
14
          <BinaryVersionRange LowSection="*" HighSection="*" />
15
        </FilePublisherCondition>
16
      </Conditions>
17
    </FilePublisherRule>
18

19
    <FilePublisherRule Id="...">
20
      <Conditions>
21
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, ..."
22
                                BinaryName="INTUNEMANAGEMENTEXTENSION.EXE"
23
                                .../>
24
      </Conditions>
25
    </FilePublisherRule>
26

27
  </RuleCollection>
28
</AppLockerPolicy>

Configuring AppLocker Managed Installer via PowerShell#

1
# Get current AppLocker policy
2
$Policy = Get-AppLockerPolicy -Local
3

4
# Create a new ManagedInstaller rule for SCCM
5
$Rule = New-AppLockerPolicy -FileInformation (
6
    Get-AppLockerFileInformation -Path "C:\Windows\CCM\CcmExec.exe"
7
) -RuleType Publisher -User Everyone -RuleNamePrefix "MI_SCCM"
8

9
# Note: AppLocker ManagedInstaller rules require manual XML editing
10
# as PowerShell cmdlets don't directly expose the ManagedInstaller collection type.
11
# Use Set-AppLockerPolicy with a manually crafted XML:
12
Set-AppLockerPolicy -XmlPolicy "C:\Policies\AppLockerMI.xml" -Merge
13

14
# Verify the AppID service is running (required for MI stamping)
15
Start-Service AppIDSvc
16
Set-Service AppIDSvc -StartupType Automatic

Step 1: Configure AppLocker Managed Installer Rule#

Before enabling Option 13 in your WDAC policy, you must configure the AppLocker ManagedInstaller rule collection and ensure AppLockerFltr.sys is active.

1
# Step 1: Enable the AppID Service (required for AppLockerFltr.sys)
2
Set-Service -Name AppIDSvc -StartupType Automatic
3
Start-Service -Name AppIDSvc
4

5
# Step 2: Verify AppLockerFltr is loaded as a file system filter
6
fltMC  # Look for AppLockerFltr in the output
7

8
# Step 3: Create and apply AppLocker ManagedInstaller policy
9
# (must be done via XML — no direct PS cmdlet for ManagedInstaller collection)
10
$AppLockerXml = @"
11
<AppLockerPolicy Version="1">
12
  <RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
13
    <FilePublisherRule Id="6CC9B840-B4A0-49B1-A9B0-1358E4F4173F"
14
                       Name="SCCM Client"
15
                       Description="ConfigMgr managed installer"
16
                       UserOrGroupSid="S-1-1-0"
17
                       Action="Allow">
18
      <Conditions>
19
        <FilePublisherCondition
20
            PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
21
            ProductName="*"
22
            BinaryName="CCMEXEC.EXE">
23
          <BinaryVersionRange LowSection="*" HighSection="*" />
24
        </FilePublisherCondition>
25
      </Conditions>
26
    </FilePublisherRule>
27
  </RuleCollection>
28
</AppLockerPolicy>
29
"@
30
$AppLockerXml | Out-File "C:\Policies\AppLockerMI.xml" -Encoding UTF8
31
Set-AppLockerPolicy -XmlPolicy "C:\Policies\AppLockerMI.xml" -Merge

Step 2: Enable Option 13 in WDAC Policy#

1
# Enable Managed Installer in the WDAC policy
2
Set-RuleOption -FilePath "C:\Policies\MyPolicy.xml" -Option 13
3

4
# Verify
5
[xml]$xml = Get-Content "C:\Policies\MyPolicy.xml"
6
$xml.SiPolicy.Rules.Rule | Where-Object { $_.Option -eq "Enabled:Managed Installer" }
7

8
# Convert to binary and deploy
9
ConvertFrom-CIPolicy -XmlFilePath "C:\Policies\MyPolicy.xml" `
10
                     -BinaryFilePath "C:\Policies\MyPolicy.p7b"

Step 3: Verify MI Stamping is Working#

1
# After deploying software via the designated MI tool,
2
# verify the EA stamp was written
3

4
# Method 1: fsutil (requires admin)
5
fsutil file queryEA "C:\Program Files\DeployedApp\app.exe"
6

7
# Method 2: Check Code Integrity event log for MI authorization events
8
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" |
9
    Where-Object { $_.Id -in @(3090, 3091, 3092) } |
10
    Select-Object TimeCreated, Id, Message |
11
    Format-Table -Wrap

Disable Option 13#

1
# Remove Managed Installer from WDAC policy
2
Remove-RuleOption -FilePath "C:\Policies\MyPolicy.xml" -Option 13

Scenario A: Option 13 enabled but AppIDSvc not running#

• AppLockerFltr.sys is NOT loaded as a file system filter
• Files written by the designated MI process are NOT stamped with the EA
• When users try to execute deployed applications, ci.dll finds no EA and no policy rule
• Result: All applications deployed via MDM/SCCM are blocked at execution time
• Symptoms: Event ID 3077 floods the CodeIntegrity log for every application
• Recovery: Start AppIDSvc, ensure it is set to Automatic, redeploy applications via MI to re-stamp files

Scenario B: AppLocker MI rules not configured (only Option 13 in WDAC policy)#

• AppLockerFltr.sys is loaded, but no process is designated as a managed installer
• No EA stamps are ever written (there is no MI process to trigger them)
• Same result as Scenario A: all MDM-deployed apps are blocked
• Recovery: Create AppLocker ManagedInstaller rule collection, designate the deployment agent

Scenario C: File copied from NTFS to FAT32 and back#

• The EA (KERNEL.SMARTLOCKER.ORIGINCLAIM) is lost during the FAT32 step
• The copy does not have MI trust
• Result: The file is blocked even though it was originally MI-installed
• Recommendation: Always deploy from the MI tool directly; do not copy from external media

Scenario D: Attacker exploits an MI-designated process#

• If an attacker compromises the SCCM client (CcmExec.exe) or the SCCM server
• They can deploy malicious files that receive the MI EA stamp
• Those files will be trusted by App Control even without policy rules
• Mitigation: Use signed WDAC policies, protect the SCCM infrastructure with strong access controls, monitor for unexpected SCCM deployments via audit logs
• Severity: Critical — MI trust is only as secure as the designated installer process

Scenario E: Pre-existing files (installed before MI was configured)#

• Files installed before MI was enabled do NOT have the EA stamp
• They are not retroactively trusted
• Resolution: Redeploy applications via the MI tool after MI is configured, OR add explicit policy rules for pre-existing applications

Event IDs to Monitor#

Trust Chain Security#

The security of Managed Installer is entirely dependent on the security of the designated installer process. If that process is compromised, it becomes an unrestricted application deployment channel. Security recommendations:

1. Sign the WDAC policy (use a hardware-backed certificate). An unsigned policy can be replaced by an admin-level attacker who could designate any process as MI.
2. Protect the MI process (SCCM/Intune). Use privileged access workstations for SCCM administration. Enable MFA and PIM for Intune admin roles.
3. Monitor MI deployment events in SCCM/Intune. Unexpected deployments to production machines should trigger alerts.
4. Limit who can designate MI processes. AppLocker MI policy changes require GPO admin privileges.

Known Limitations#

• No file provenance after copy: EA is lost when copying to non-NTFS volumes
• No retrospective stamping: Files installed before MI was configured are not trusted retroactively
• Network shares: Files on SMB shares do not receive local NTFS EA stamps (the EA would be on the share server, not evaluated by the local ci.dll)
• Container workloads: Docker/Windows containers have their own file system layers; MI EA behavior in container contexts requires validation
• In-place upgrades: Windows OS upgrades may reset or alter AppLocker configuration; verify MI designation post-upgrade

EA Spoofing Defense#

ci.dll does not simply trust the presence of the EA byte value. The EA includes a cryptographic claim structure that ci.dll validates against the current AppLocker MI policy configuration. An attacker cannot manually write a fake KERNEL.SMARTLOCKER.ORIGINCLAIM EA to an arbitrary file and have it trusted — the claim must be consistent with the active MI policy as validated by the kernel. This prevents trivial EA injection attacks.