WDAC File Rule Level: FileName#

Table of Contents#

Overview
How It Works
Where in the Evaluation Stack
XML Representation
PowerShell Usage
Pros and Cons
Attack Resistance Analysis
When to Use vs When to Avoid
Interaction with Other Levels
Real-World Scenario
OS Version and Compatibility Notes
Common Mistakes and Gotchas
Summary Table

Overview#

The FileName rule level in WDAC App Control for Business allows or denies execution based on metadata embedded in the file’s PE (Portable Executable) VERSIONINFO resource — not based on the file’s name on disk. This is a subtle but critical distinction that trips up many administrators.

When WDAC talks about “FileName”, it does not mean the filename you see in Windows Explorer (notepad.exe on the filesystem). It means the value of the OriginalFileName field stored inside the binary itself as part of its compiled-in version information. You can change the file’s name on disk to anything you like — OriginalFileName inside the PE does not change unless the source code is recompiled with a different value.

A FileName rule also requires a minimum file version (MinimumFileVersion), which acts as a version floor. Files that carry the matching original filename AND have a version number equal to or greater than the specified minimum will be allowed. Version 0.0.0.0 effectively means “any version with this name.”

The most important security caveat: FileName rules do not verify the signer or publisher. Any file — signed or unsigned, from Microsoft or from a random developer — that carries the matching OriginalFileName metadata will pass a FileName rule. This makes FileName rules significantly weaker than FilePublisher rules and fundamentally different in their trust model.

Despite this limitation, FileName rules are valuable in specific scenarios: allowing a product that is self-updated frequently (so Hash rules would break constantly), allowing a product line from a vendor who rotates signing certificates (so Publisher rules break), or allowing software by product name across versions without needing to track individual file hashes.

How It Works#

The VERSIONINFO Resource and OriginalFileName#

Every well-written Windows executable contains a VERSIONINFO resource embedded in its .rsrc section. This resource is compiled into the binary at build time and contains structured metadata:

1
VERSIONINFO
2
  FILEVERSION     23, 1, 0, 0
3
  PRODUCTVERSION  23, 1, 0, 0
4
  FILEFLAGSMASK   0x3fL
5
  FILEFLAGS       0x0L
6
  FILEOS          0x40004L
7
  FILETYPE        0x1L
8
  FILESUBTYPE     0x0L
9
  BEGIN
10
    BLOCK "StringFileInfo"
11
    BEGIN
12
      BLOCK "040904b0"
13
      BEGIN
14
        VALUE "OriginalFilename",   "7zFM.exe"
15
        VALUE "InternalName",       "7zFM"
16
        VALUE "FileDescription",    "7-Zip File Manager"
17
        VALUE "ProductName",        "7-Zip"
18
        VALUE "CompanyName",        "Igor Pavlov"
19
        VALUE "FileVersion",        "23.01"
20
        VALUE "ProductVersion",     "23.01"
21
        VALUE "LegalCopyright",     "Copyright (c) 1999-2023 Igor Pavlov"
22
      END
23
    END
24
    BLOCK "VarFileInfo"
25
    BEGIN
26
      VALUE "Translation", 0x0409, 0x04B0
27
    END
28
  END

The WDAC FileName level specifically targets these string fields. The default sub-level is OriginalFileName, but you can target any of the other fields using -SpecificFileNameLevel.

SpecificFileNameLevel Options#

When you use -Level FileName, the PowerShell cmdlet defaults to creating a rule based on OriginalFileName. You can override this:

`-SpecificFileNameLevel` Value	PE Field Used	Notes
`OriginalFileName`	`OriginalFilename` string value	Default; most stable, set at compile time
`InternalName`	`InternalName` string value	Often matches OriginalFileName without extension
`FileDescription`	`FileDescription` string value	Human-readable; may be localized
`ProductName`	`ProductName` string value	Allows all files from a product suite by product name
`PackageFamilyName`	UWP Package Family Name	For Universal Windows Platform apps
`FilePath`	Filesystem path at policy creation time	Special case — see Level-FilePath.md

How WDAC Reads These Fields at Runtime#

At runtime, when a binary is about to be loaded via NtCreateSection(SEC_IMAGE), the kernel’s code integrity component (ci.dll) reads the PE’s resource directory to locate the VERSIONINFO resource. It then parses the StringFileInfo block to extract the relevant field value.

The comparison is case-insensitive and exact string match (no wildcards). The version comparison is a simple four-part numeric comparison (Major.Minor.Build.Revision), where the file must be ≥ MinimumFileVersion.

Inspecting OriginalFileName on a Live File#

1
# Method 1: VersionInfo property
2
(Get-Item "C:\Windows\System32\notepad.exe").VersionInfo |
3
    Select-Object OriginalFilename, InternalName, FileDescription, ProductName, FileVersion
4

5
# Method 2: Shell.Application COM object (shows exact embedded values)
6
$shell = New-Object -ComObject Shell.Application
7
$folder = $shell.Namespace("C:\Windows\System32")
8
$file = $folder.ParseName("notepad.exe")
9
# Property 34 = Product Version, 33 = File Version
10
Write-Host $file.ExtendedProperty("System.Software.ProductName")
11

12
# Method 3: Win32 API via P/Invoke (most accurate)
13
[System.Diagnostics.FileVersionInfo]::GetVersionInfo(
14
    "C:\Windows\System32\notepad.exe"
15
) | Select-Object OriginalFilename, InternalName, FileDescription, ProductName

Version Comparison Mechanics#

The version floor works as a four-component integer comparison:

1
File Version: 23.01.00.00   →  [23][1][0][0]
2
Min Version:  10.0.0.0      →  [10][0][0][0]
3

4
23 > 10 → File version is ABOVE the minimum → ALLOWED
5

6
File Version: 5.0.0.0       →  [5][0][0][0]
7
Min Version:  10.0.0.0      →  [10][0][0][0]
8

9
5 < 10 → File version is BELOW the minimum → NO MATCH (falls through)

Using MinimumFileVersion="0.0.0.0" accepts any version of the file with the matching name.

Where in the Evaluation Stack#

1
flowchart TD
2
    A([File load request\nNtCreateSection]) --> B{Explicit Deny rule\nmatches?}
3
    B -- Yes --> C([BLOCKED])
4
    B -- No --> D{Publisher / FilePublisher\n/ SignedVersion match?}
5
    D -- Yes --> E([ALLOWED\nCertificate-based rule])
6
    D -- No --> F{FileName rule match?\nOriginalFileName or\nother field ≥ MinVersion}
7
    F -- Yes --> G([ALLOWED\nFileName rule hit\nNO signature check])
8
    F -- No --> H{Hash rule\nmatch?}
9
    H -- Yes --> I([ALLOWED\nHash rule hit])
10
    H -- No --> J{Managed Installer\nEA present?}
11
    J -- Yes --> K([ALLOWED])
12
    J -- No --> L{ISG EA present?}
13
    L -- Yes --> M([ALLOWED])
14
    L -- No --> N([BLOCKED\nImplicit Deny])
15

16
    style A fill:#162032,stroke:#1e3a5f,color:#e2e8f0
17
    style B fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
18
    style C fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
19
    style D fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
20
    style E fill:#0d1f12,stroke:#1a5c2a,color:#86efac
21
    style F fill:#162032,stroke:#1e3a5f,color:#e2e8f0
22
    style G fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
23
    style H fill:#162032,stroke:#1e3a5f,color:#e2e8f0
24
    style I fill:#0d1f12,stroke:#1a5c2a,color:#86efac
25
    style J fill:#162032,stroke:#1e3a5f,color:#e2e8f0
26
    style K fill:#0d1f12,stroke:#1a5c2a,color:#86efac
27
    style L fill:#162032,stroke:#1e3a5f,color:#e2e8f0
28
    style M fill:#0d1f12,stroke:#1a5c2a,color:#86efac
29
    style N fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5

Note the yellow warning color on the FileName match — this represents the fact that FileName rules grant access without any signature verification. Any binary carrying the right embedded name passes, regardless of its publisher, origin, or signing status.

XML Representation#

FileRules Section — Allow by OriginalFileName#

1
<FileRules>
2
  <!--
3
    FileName rule allowing any file with OriginalFilename = "notepad.exe"
4
    at version 11.0.0.0 or higher.
5
    WARNING: This allows ANY binary with this embedded name, signed or not.
6
  -->
7
  <Allow
8
    ID="ID_ALLOW_A_NOTEPAD_FN_1"
9
    FriendlyName="Notepad by OriginalFileName v11+"
10
    FileName="notepad.exe"
11
    MinimumFileVersion="11.0.0.0" />
12
</FileRules>

Allow by ProductName (Covers Entire Product Suite)#

1
<FileRules>
2
  <!--
3
    ProductName-based FileName rule.
4
    All executables from the "7-Zip" product at any version are allowed.
5
    Requires -SpecificFileNameLevel ProductName when generating via PowerShell.
6
  -->
7
  <Allow
8
    ID="ID_ALLOW_A_7ZIP_SUITE_FN_1"
9
    FriendlyName="7-Zip product suite by ProductName"
10
    FileName="7-Zip"
11
    MinimumFileVersion="0.0.0.0" />
12
</FileRules>

Deny by FileName#

1
<FileRules>
2
  <!--
3
    Deny all versions of a file by OriginalFileName.
4
    Blocks any binary embedding this original filename from running.
5
  -->
6
  <Deny
7
    ID="ID_DENY_D_BLOCKED_TOOL_FN_1"
8
    FriendlyName="Block legacy-scanner.exe by name"
9
    FileName="legacy-scanner.exe"
10
    MinimumFileVersion="0.0.0.0" />
11
</FileRules>

Full Signing Scenario Wiring#

1
<SigningScenarios>
2
  <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="User Mode">
3
    <ProductSigners>
4
      <AllowedSigners />
5
    </ProductSigners>
6
    <FileRulesRef>
7
      <FileRuleRef RuleID="ID_ALLOW_A_NOTEPAD_FN_1" />
8
      <FileRuleRef RuleID="ID_ALLOW_A_7ZIP_SUITE_FN_1" />
9
    </FileRulesRef>
10
  </SigningScenario>
11
</SigningScenarios>

Comparison: FileName vs FilePublisher XML#

1
<Allow ID="ID_ALLOW_A_NOTEPAD_FN"
2
       FriendlyName="Notepad by name only"
3
       FileName="notepad.exe"
4
       MinimumFileVersion="10.0.0.0" />
5

6
<Allow ID="ID_ALLOW_A_NOTEPAD_FP"
7
       FriendlyName="Notepad by FilePublisher"
8
       FileName="notepad.exe"
9
       MinimumFileVersion="10.0.0.0" />
10
<!-- FilePublisher also requires a Signer entry with FileAttribRef:
11
<Signer ID="ID_SIGNER_MICROSOFT">
12
  <CertRoot Type="TBS" Value="...thumbprint..." />
13
  <CertPublisher Value="Microsoft Windows" />
14
  <FileAttribRef RuleID="ID_ALLOW_A_NOTEPAD_FP" />
15
</Signer>
16
-->

The key difference: FilePublisher requires the file to be signed by a specific publisher AND carry the matching filename. FileName only checks the embedded metadata — no certificate required.

PowerShell Usage#

Basic FileName Rule Generation (OriginalFileName Default)#

1
# Create a FileName-level policy for a specific file
2
# Defaults to OriginalFileName sub-level
3
New-CIPolicy `
4
    -Level FileName `
5
    -ScanPath "C:\Program Files\7-Zip" `
6
    -UserPEs `
7
    -OutputFilePath "C:\Policies\7zip-filename-policy.xml"

Using SpecificFileNameLevel#

1
# Use ProductName as the matching field instead of OriginalFileName
2
# This allows ALL 7-Zip files by product name, across any version
3
New-CIPolicy `
4
    -Level FileName `
5
    -SpecificFileNameLevel ProductName `
6
    -ScanPath "C:\Program Files\7-Zip" `
7
    -UserPEs `
8
    -OutputFilePath "C:\Policies\7zip-productname-policy.xml"

1
# Use InternalName as the matching field
2
New-CIPolicy `
3
    -Level FileName `
4
    -SpecificFileNameLevel InternalName `
5
    -ScanPath "C:\Tools\MyApp" `
6
    -UserPEs `
7
    -OutputFilePath "C:\Policies\myapp-internalname-policy.xml"

1
# Use FileDescription as the matching field
2
New-CIPolicy `
3
    -Level FileName `
4
    -SpecificFileNameLevel FileDescription `
5
    -ScanPath "C:\Tools\MyApp" `
6
    -UserPEs `
7
    -OutputFilePath "C:\Policies\myapp-description-policy.xml"

FileName with Hash Fallback#

1
# Use FileName as primary; fall back to Hash for files without VERSIONINFO
2
New-CIPolicy `
3
    -Level FileName `
4
    -Fallback Hash `
5
    -ScanPath "C:\Program Files\MyProduct" `
6
    -UserPEs `
7
    -OutputFilePath "C:\Policies\myproduct-fn-hash.xml"

This is important because not all executables have a VERSIONINFO resource. Older tools, stripped binaries, and some Go/Rust/C++ executables may lack this metadata entirely. Without a fallback, these files would have no rule generated and would be denied.

Generate Individual Rules#

1
# Create a rule object for a single file
2
$rules = New-CIPolicyRule `
3
    -Level FileName `
4
    -DriverFilePath "C:\Tools\legacy-tool.exe"
5

6
# Inspect the generated rule to see what OriginalFileName was found
7
$rules | Where-Object { $_.TypeId -eq "FileAttrib" } |
8
    Select-Object FriendlyName, FileName, MinimumFileVersion
9

10
# Add to existing policy
11
Merge-CIPolicy `
12
    -PolicyPaths "C:\Policies\base-policy.xml" `
13
    -OutputFilePath "C:\Policies\updated-policy.xml" `
14
    -Rules $rules

Audit Version Info Before Creating Rules#

1
# Audit all EXEs in a folder for their VERSIONINFO fields
2
# Helps understand what FileName rules will be created
3
Get-ChildItem "C:\Tools" -Recurse -Filter "*.exe" | ForEach-Object {
4
    $vi = $_.VersionInfo
5
    [PSCustomObject]@{
6
        FilePath        = $_.FullName
7
        FileName        = $_.Name
8
        OriginalFilename = $vi.OriginalFilename
9
        InternalName    = $vi.InternalName
10
        FileDescription = $vi.FileDescription
11
        ProductName     = $vi.ProductName
12
        FileVersion     = $vi.FileVersion
13
        HasVersionInfo  = ($vi.OriginalFilename -ne $null -and $vi.OriginalFilename -ne "")
14
    }
15
} | Export-Csv "C:\Reports\version-info-audit.csv" -NoTypeInformation

Pros and Cons#

Attribute	Details
Precision	Medium — targets a name, not a specific binary
Security Strength	Lower than Publisher/FilePublisher — no signature check
Update Resilience	High — name-based rules survive patches and version bumps
Unsigned File Support	Yes — unsigned files with matching name metadata pass
Kernel Driver Support	Yes (when used under KMCI scenario)
Maintenance Burden	Low — set-and-forget unless OriginalFileName changes
Spoofability	Yes — any binary can embed the target name in its VERSIONINFO
Sub-level Flexibility	High — ProductName, InternalName, FileDescription all available
Recommended Primary Use	Frequently updated software without stable signing
Recommended Fallback Use	Not recommended as fallback (weaker than Hash for security)
Risk of Over-Permission	Medium-High — grants access to any file claiming the right name

Attack Resistance Analysis#

1
flowchart TD
2
    ATK([Attacker Goal:\nBypass WDAC FileName Rule])
3

4
    ATK --> P1[Rename malicious.exe\nto notepad.exe on disk]
5
    ATK --> P2[Modify VERSIONINFO in\nmalicious binary to set\nOriginalFilename = target name]
6
    ATK --> P3[Copy allowed filename\nbinary and patch code]
7
    ATK --> P4[Use a LOLBin that\nalready has an allowed name]
8
    ATK --> P5[Inject into running\nallowed process]
9

10
    P1 --> R1{Does on-disk name\nmatch FileName rule?}
11
    R1 -- No --> B1([BLOCKED\nWDAC checks embedded\nOriginalFilename, NOT disk name])
12
    R1 -- Irrelevant --> B1
13

14
    P2 --> R2{Can attacker modify\nVERSIONINFO and still\npass code integrity?}
15
    R2 -- Yes, if unsigned --> A2([ALLOWED\nCritical weakness:\nunsigned binary with spoofed\nOriginalFilename passes])
16
    R2 -- No, if signed\nand hash validated --> B2([BLOCKED\nbut Hash rule not\nbeing used here])
17

18
    P3 --> R3{Patched binary\nhas same OriginalFilename?}
19
    R3 -- Yes, if unsigned --> A3([ALLOWED\nSame weakness:\nno signature check])
20

21
    P4 --> R4{LOLBin OriginalFilename\nin allow rules?}
22
    R4 -- Yes --> A4([ALLOWED\nLOLBin already approved])
23

24
    P5 --> B5([NOT STOPPED\nProcess injection bypasses\nfile load checks])
25

26
    style ATK fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
27
    style P1 fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
28
    style P2 fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
29
    style P3 fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
30
    style P4 fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
31
    style P5 fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
32
    style B1 fill:#0d1f12,stroke:#1a5c2a,color:#86efac
33
    style A2 fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
34
    style B2 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
35
    style A3 fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
36
    style A4 fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
37
    style B5 fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
38
    style R1 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
39
    style R2 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
40
    style R3 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
41
    style R4 fill:#162032,stroke:#1e3a5f,color:#e2e8f0

Critical Security Note#

The single most important security implication of FileName rules: an attacker with the ability to drop an unsigned binary can craft any VERSIONINFO they want and pass a FileName rule. This requires the attacker to already have write access to a location from which the binary can be executed — but if your threat model includes insider attackers or compromised user accounts, FileName rules alone are insufficient.

For this reason, Microsoft’s guidance is to use FilePublisher (which includes a signature check) rather than FileName whenever possible. FileName should be reserved for cases where the software is unsigned by design or where the certificate situation is unstable.

When to Use vs When to Avoid#

1
flowchart TD
2
    Q1{Is the target software\nsigned by a consistent\ntrusted certificate?}
3
    Q1 -- Yes --> A1([Avoid FileName\nUse FilePublisher instead\nStronger security model])
4
    Q1 -- No --> Q2{Does the software\nhave a stable\nORIGINALFILENAME field?}
5
    Q2 -- No --> A2([Avoid FileName\nUse Hash fallback\nfor files without VERSIONINFO])
6
    Q2 -- Yes --> Q3{Is the software\nupdated very frequently\nbreaking Hash rules?}
7
    Q3 -- No --> Q4{Do you need to allow\nentire product suite\nby product name?}
8
    Q4 -- Yes --> U1([Use FileName with\n-SpecificFileNameLevel ProductName])
9
    Q4 -- No --> U2([FileName acceptable\nbut consider FilePublisher\nif you can get signing])
10
    Q3 -- Yes --> U3([FileName is appropriate\nSurvives version bumps\nwith low maintenance])
11

12
    style Q1 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
13
    style Q2 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
14
    style Q3 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
15
    style Q4 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
16
    style A1 fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
17
    style A2 fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
18
    style U1 fill:#0d1f12,stroke:#1a5c2a,color:#86efac
19
    style U2 fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
20
    style U3 fill:#0d1f12,stroke:#1a5c2a,color:#86efac

Interaction with Other Levels#

1
flowchart LR
2
    subgraph Stronger Certificate Levels
3
        FPB[FilePublisher\nSame Name Check\nBUT also verifies cert]
4
        PUB[Publisher\nCert check only\nno name check]
5
    end
6

7
    subgraph FileName Level
8
        FN[FileName\nName metadata only\nNO cert check]
9
    end
10

11
    subgraph Weaker / Broader Levels
12
        HASH[Hash\nExact binary match\nmost granular]
13
    end
14

15
    FPB --> |Name check PLUS\ncert validation| STRONGER[More Secure]
16
    FN --> |Name check ONLY\nno cert| WEAKER[Less Secure\nthan FilePublisher]
17
    HASH --> |Exact match\ncannot be spoofed| STRONGEST[Most Precise]
18

19
    FPB -.->|Falls back to if\ncert changes| FN
20
    FN -.->|Falls back to if\nno VERSIONINFO| HASH
21

22
    style FPB fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
23
    style PUB fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
24
    style FN fill:#162032,stroke:#1e3a5f,color:#e2e8f0
25
    style HASH fill:#162032,stroke:#1e3a5f,color:#e2e8f0
26
    style STRONGER fill:#0d1f12,stroke:#1a5c2a,color:#86efac
27
    style WEAKER fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
28
    style STRONGEST fill:#0d1f12,stroke:#1a5c2a,color:#86efac

FileName vs FilePublisher: Side-by-Side#

Feature	FileName	FilePublisher
Checks OriginalFilename	Yes	Yes
Checks MinimumFileVersion	Yes	Yes
Checks signer certificate	No	Yes
Unsigned files pass	Yes	No
Survives certificate rotation	Yes	No
Spoof risk	High	Low
Maintenance burden	Low	Low-Medium

Real-World Scenario#

An enterprise allows a legacy internal reporting tool (acme-report.exe) that is signed with an expiring certificate. Rather than deal with re-signing logistics, the admin uses FileName rules to bridge the gap.

1
sequenceDiagram
2
    participant Admin as IT Admin
3
    participant PS as PowerShell
4
    participant XML as Policy XML
5
    participant MDM as Intune
6
    participant EP as Endpoint
7
    participant CI as ci.dll
8

9
    Admin->>Admin: acme-report.exe v2.x is signed\nbut cert expires in 30 days
10
    Admin->>Admin: v3.x will be unsigned during transition
11
    Admin->>PS: Inspect VERSIONINFO of acme-report.exe
12
    PS-->>Admin: OriginalFilename = "acme-report.exe"\nProductName = "ACME Reporting Suite"\nFileVersion = "2.5.0.0"
13

14
    Admin->>PS: New-CIPolicy -Level FileName\n-SpecificFileNameLevel OriginalFileName\n-ScanPath C:\Tools\acme-report
15
    PS->>XML: <Allow FileName="acme-report.exe"\nMinimumFileVersion="2.0.0.0" />
16
    Admin->>MDM: Deploy updated policy
17

18
    Note over EP,CI: v2.5 (signed) runs — FileName rule matches first
19

20
    EP->>CI: Load acme-report.exe v2.5
21
    CI->>CI: Extract OriginalFilename from VERSIONINFO
22
    CI->>CI: Compare: "acme-report.exe" == "acme-report.exe" ✓
23
    CI->>CI: Compare version: 2.5.0.0 >= 2.0.0.0 ✓
24
    CI-->>EP: ALLOWED (no cert check needed)
25

26
    Note over EP,CI: v3.0 released as UNSIGNED\ncert has expired
27

28
    EP->>CI: Load acme-report.exe v3.0 (unsigned)
29
    CI->>CI: Extract OriginalFilename = "acme-report.exe" ✓
30
    CI->>CI: Compare version: 3.0.0.0 >= 2.0.0.0 ✓
31
    CI-->>EP: ALLOWED (FileName rule still valid — no sig needed)
32

33
    Note over Admin,CI: Risk: attacker could craft binary\nwith same OriginalFilename
34

35
    Admin->>Admin: Plan to get code signing for v3.x\nand migrate to FilePublisher rules

This scenario demonstrates the legitimate use case: bridging periods of certificate instability or transition. The admin accepts the security trade-off (no cert check) as temporary.

OS Version and Compatibility Notes#

Windows Version	FileName Rules	SpecificFileNameLevel	Notes
Windows 10 1507	Yes (basic)	Limited	Early WDAC, ProductName support varied
Windows 10 1607	Yes	Yes	SpecificFileNameLevel properly supported
Windows 10 1703	Yes	Yes	Multiple policy format available
Windows 10 1903+	Yes	Yes	Full feature parity
Windows 11 21H2+	Yes	Yes	Full support
Windows Server 2016	Yes	Yes	Full support
Windows Server 2019	Yes	Yes	Full support
Windows Server 2022	Yes	Yes	Full support

Note: PackageFamilyName as a SpecificFileNameLevel target requires Windows 10 1709 or later for full UWP app support.

Common Mistakes and Gotchas#

Confusing on-disk filename with OriginalFilename: The most common mistake. If a file is renamed on disk to evil.exe, a FileName rule for notepad.exe will NOT fire — because the rule checks the embedded OriginalFilename field inside the PE, not the filesystem name. But also the inverse: renaming notepad.exe to something-else.exe on disk does NOT prevent the FileName rule from matching (if OriginalFilename inside is still notepad.exe).
Assuming unsigned files are blocked: FileName rules explicitly do NOT require a signature. A malicious binary with OriginalFilename=notepad.exe set in its VERSIONINFO will pass the FileName rule. Always pair FileName rules with an understanding that unsigned files from any source can pass.
Files without VERSIONINFO are silently skipped: If a binary has no VERSIONINFO resource at all (some stripped C/C++ binaries, many Go binaries), the FileName rule simply does not match. The file will fall through to Hash or be denied. Ensure you use -Fallback Hash when scanning directories with such files.
Localization issues with FileDescription and ProductName: Both FileDescription and ProductName fields can be localized. A multilingual application may have different values in different language builds. A rule created from the English build may not match the Japanese build. OriginalFilename and InternalName are typically not localized.
Using MinimumFileVersion 0.0.0.0 excessively: While convenient, setting all version floors to 0.0.0.0 means even extremely old versions of software pass the rule. Consider setting a reasonable baseline version that represents the oldest acceptable version in your environment.
ProductName rules granting overly broad access: If a vendor ships many different products and they all use the same ProductName, a ProductName-based rule allows all of them. Verify the ProductName field is specific enough before creating such rules.
Forgetting that FileName is weaker than FilePublisher: Teams sometimes choose FileName to avoid dealing with certificate management, not realizing they have meaningfully reduced their security posture. Document this decision and plan migration to FilePublisher once signing is established.
FileName rules in KMCI context: FileName rules can technically appear in kernel mode scenarios, but kernel drivers are generally expected to be signed (WHQL or otherwise). Using FileName rules for kernel drivers in production is unusual and potentially risky — the lack of signature verification is especially concerning for kernel code.

Summary Table#

Attribute	Value
Rule Level Name	FileName
XML Element	`<Allow FileName="..." MinimumFileVersion="..."/>`
What is Checked	Embedded VERSIONINFO field (OriginalFilename by default)
Signature Required	No — unsigned files can pass
Minimum Version Check	Yes — `MinimumFileVersion` attribute
Sub-levels Available	OriginalFileName, InternalName, FileDescription, ProductName, PackageFamilyName
Covers Unsigned Files	Yes
Works for Kernel Drivers	Yes (but not recommended without signing)
Spoofable	Yes — any binary can set any VERSIONINFO
Update Resilience	High — name rarely changes across versions
Maintenance Burden	Low
Security Strength	Medium-Low (no cert check)
vs FilePublisher	Weaker — FilePublisher includes cert validation
PowerShell Level Name	`FileName`
SpecificFileNameLevel Flag	`-SpecificFileNameLevel <value>`
Min Windows Version	Windows 10 1507 / Server 2016 (basic); 1607 for full SpecificFileNameLevel