AppLocker is a Microsoft security feature that helps control which applications and files can run on Windows systems, ensuring compliance and preventing malicious activity.
In addition to AppLocker, Microsoft published a block list, with applications that can bypass AppLocker configuration.
Executive summary
While reviewing Microsoft’s suggested configuration, Varonis Threat Labs noticed a subtle but important issue: the MaximumFileVersion field was set to 65355 instead of the expected 65535.
This small discrepancy could allow certain files to bypass restrictions.
For example, an attacker can modify a 'blocked' executable's version to exceed the 'maximum' version, allowing it to run and bypass the restrictions.
While not a critical vulnerability — since a "signed executables only" rule would still block such attempts — this highlights the importance of carefully reviewing and updating security policies for organizations so they can close potential gaps and align with best practices.
The beginning — what is AppLocker
AppLocker is Microsoft's enterprise-grade application control solution that helps administrators control which applications and files users can run on their Windows systems.
Think of it as a bouncer at a club, checking IDs and deciding who gets in and who doesn't. However, instead of people, it's blocking executables, scripts, and DLLs. Organizations use AppLocker to prevent malware, maintain compliance, and keep users from installing that sketchy "free" photo editor they found online.
AppLocker enforces rules such as allow this and block that. It can be incredibly effective when configured properly, but like any security tool, it's only as good as its implementation. And that's where this little adventure begins.
While exploring different attack surfaces on AppLocker, we found an article from Microsoft, “Applications that can bypass App control” this page.
The article is a live resource listing all known Microsoft-signed executables that attackers can use to execute code, effectively sidestepping AppLocker restrictions. It’s regularly updated with the latest discoveries. A big shout-out to Microsoft for maintaining such a valuable repository.
Most of the lines look like this:
At first glance, it seems pretty straightforward: a file name, a friendly name, plus the minimum and maximum version fields. But while digging around, something about this line made us pause and scratch our heads. It took a couple of hours to pinpoint exactly what was going on.
The discovery — how to bypass the policy
In the example above, the “MaximumFileVersion” field is set to 65355.65355.65355.65355, which might look like a max integer value, but note the difference: 65535 is the maximum value for an unsigned 16-bit integer, and it’s not the 65355 used by the policy.
What does this mean? In effect, you can bypass the policy by assigning any file version between 65355.65355.65355.65355 and 65535.65535.65535.65535 — slipping right through that gap.
Is this a real “Super Mega Zero Day?”
Unfortunately, no...
This policy is meant to be paired with one that only allows signed executables on the system, filling the gap for any potential malicious intent. When you change the file version, it will also 'break' the file signature, so that you’ll still be blocked by the broader “signed executables only” rule.
Still, it’s a good reminder that details matter.
Where did 65355 come from?
After some digging, it turns out that the likely source was a mistake in Microsoft’s Publish Page documentation. You can see the error in the cached version
As a result of our report to Microsoft about the discovery, it has since been corrected in the live version.
The takeaways
While not a critical discovery, the AppLocker finding brings important best practices to the surface:
- Avoid copy-pasting without double-checking
- If you use this policy, consider updating the MaximumFileVersion to a safer upper limit
- Details matter — especially in security
-1.png)
