I got an error message saying my post was flagged as spam so I am posting it here according to the instructions in the error...
I am testing AppLocker's functionality to assess suitability for protecting a windows application from tampering. As a test I have a simple executable compiled from C# that displays a window and button. When the button is clicked it uses a single
DLL dependency to pull the system time and IP and return it as a string. The window then updates with a message stating the returned string. An AppLocker executable rule was added to allow the executable based on its hash. Additionally, I have generic DLL
rules that allow execution of all DLLs in the Windows folder and the Program Files folder. My test executable and its dependency are both in a folder on the desktop (not a valid DLL execution folder).
After ensuring the AppIdSvc is running and doing a gpupdate on the client PC, I was able to run the executable (as expected) but the executable was also able to run its DLL dependency even though the dependency was outside of the Windows/Program
Files directories. This was also the case after I replaced that DLL with a tampered one to ensure it wasn't somehow related to the rule created for the executable and to prove that my executable is actually running that dependency (it is). Even after I added
an explicit rule to deny both the legitimate and tampered DLLs based on their hash, it's still able to run in both cases. Reviewing the AppLocker logs I don't see any message saying the DLL was or was not allowed to run (it's as if AppLocker never saw it)
even though I am able to see that the DLL was accessed by the executable in Process Monitor. Other AppLocker logs show that the executable was allowed to run (letting me know my rules are working - I also ran many other AppLocker tests to ensure it is actually
running and it was).
Is AppLocker not able to protect the integrity of dependency DLLs based on their hash? Can an allowed executable run any DLL? I've read some articles that rundll32 circumvents the DLL rules by being allowed to run from its safe location while loading
and executing DLLs from unsafe locations and there may be something similar here.
