Why filename policy fails on renamed binaries

A great deal of endpoint policy is written against filenames. Block psexec.exe. Alert on a known tool by name. Allow chrome.exe from a specific directory. The rules are readable, auditable, and easy to explain to someone reviewing the control, which is most of why they persist.

They also rest on an assumption that does not hold: that the filename is a property of the program.

What a rename actually changes

Renaming a file changes a directory entry. The file’s contents are untouched, same hash, same imports, same resources, same signature. Every property that determines what the program does survives the operation, and the one property the rule matches on does not.

This is not a technique that requires tooling or privilege. It is a right-click.

The partial fixes, and where each stops

Path plus name. Constraining to a directory helps, but only where the directory is one users cannot write to. A rule scoped under a user profile constrains very little, because the user controls that entire subtree.

Publisher rules. Matching on the signing certificate rather than the name is a real improvement, and application control frameworks support it well. It works exactly as far as the inventory is signed. Internal tooling, contractor deliverables, build artifacts and most single-binary open-source utilities are not signed, and a publisher rule has nothing to bind to.

Hashes. Precise, and precisely brittle: a hash rule is invalidated by the next patch. Maintaining hash allowlists across a fleet is the workflow that consumes the staffing, and the coverage achieved is exactly the coverage someone had time to curate.

The shape of the answer

Each of these substitutes an attribute that is easy to observe for the one that is hard: what the file actually is. The name is easy and wrong. The path is easy and contingent. The hash is exact and unstable. The certificate is strong and frequently absent.

Content-derived identity is harder to compute and has none of those failure modes, because it reads the properties a rename does not touch, imports, section layout, embedded resources, original filename, code characteristics. A file called TSClient.exe that is structurally a remote access tool is identifiable as one regardless of what the directory entry says.

The practical takeaway is narrower than “stop using filename rules.” Filename rules are fine as a first filter. The mistake is treating a name as identity and then building an inventory on top of it, because everything downstream inherits the assumption.