Not really, WDAC doesn't usually just look at the filename. It can look at the certificate it was signed by, or fallback to using hashes.
Not really, WDAC doesn't usually just look at the filename. It can look at the certificate it was signed by, or fallback to using hashes.
Windows has both WDAC and Applocker for allowlisting, not just for exes, but stuff such as powershell scripts and what drivers run in the kernel as well.
https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/
In it's strongest form (a signed WDAC policy) even admin access can't easily override it, and a well written policy can even enforce stuff such as downgrade protection (example: only allow firefox.exe signed by Mozilla at or above a certain version) which prevents an attacker from loading older versions of an executable.
The problem is that it's not so easy to use in practice - an installer will often drop loads of unsigned files. Tor Browser ironically enough is a prime example, and any WDAC policies allowing it have to fallback on hash rules, which are fragile and must be regenerated every update, or filepath rules which are not so robust.
Microsoft is trying to make allowlisting more accessible with Smart App Control, which runs WDAC under the hood. It does save the hassle of managing one's own policies (and also blocks certain filetypes like lnks commonly used for malware), but it is not very customizable.