Application whitelisting is one of those actions on an organization's security roadmaps, which either never happens or is adapted to fit the current environment rather than having it implemented to its full extent. Although far from perfect, with a large number of bypasses for its whitelisting capabilities (described in the Github repository here), AppLocker is still a great, free* tool that introduces resilience in the environment. Many of the bypasses rely on abusing Microsoft signed executables, as they are whitelisted by default and have the capability to launch other executables. In the previously linked Github repository, the author has made an effort to provide AppLocker rules to prevent the bypasses, however, many of these are likely to break things in a fully-functional real-world environment with "legacy" systems.
One of the most common (unfortunately) implementations is a blacklisting approach. In this implementation, everything is allowed to execute by default (the opposite of white-listing) unless it has specifically been forbidden not to. This approach is often employed to prevent and/or eliminate initial infections. Often observed is also a mixed version of white/blacklisting - for example, allow everything in "Program Files" and "Windows" folders to execute while blocking the rest (including the C:\Users\ and its sub-folders).
Testing environment
Let's assume we want to block PsExec from executing by utilizing the hash blocking technique. PsExec's hash is the following:
To block the executable from running, we set up AppLocker (Default rules are a cheap and cheat way for this test, which are also somewhat *required* to be in place to ensure that the operating system continues to operate as expected) to block PsExec by its hash value:
In order to have AppLocker running on the system, we have to ensure that the Application identity service (AppIDSvc) is running on the system (it is not by default!). In a domain environment, a GPO could be applied that forces AppIDSvc to run automatically on boot:
If everything is working, attempt to execute PsExec will result in an error:
It works as expected and the binary file is prevented from executing.
1. Changing the hash of an executable with a hex editor
Using an interactive hex editor (HxD in my case), we can load the executable and inspect its content:
Let's modify the content - for example, if we change "O" to "N" the the string "DOS".
The resulting VALID executable will have completely different hash value and is therefore allowed to execute:
2. Changing the hash through shell access only
It is also possible to just append "random" data at the end of the file and persist it as a valid executable while the hash value will be changed and allow execution:
3. Magic
It is also possible to avoid changing the files hash completely by using programming languages to load the file as a stream of bytes in the memory and execute it from there. The easiest (probably) is to utilize PowerShell to read the file into a bytes array and reflectively inject it using Invoke-ReflectivePEInject (Note - the file is a bit outdated and to get the injection working on (some) Windows 10 systems requires changes):
Takeaways - blacklisting is not "perfect.
*Applocker is available in Enterprise editions of Microsoft Windows