Expected LocationsThe file
hid.dllis normally found in the following paths:
Vulnerable ExecutablesThe following executables attempt to load
DetectionBelow a sample Sigma rule that will find processes that loaded
hid.dlllocated in a folder that is not one of the expected locations (see above).
Why should I care about this?
DLL Hijacking enables the execution of malicious code through a signed and/or trusted executable. Defensive measures such as AV and EDR solutions may not pick up on this activity out of the box, and allow-list applications such as AppLocker may not block the execution of the untrusted code. There are numerous examples of threat actors that have been observed to leaverage DLL Hijacking to achieve their objectives. As such, this project wants to encourage you to monitor for unusual activity involving
How do I abuse this vulnerability?
As a red teamer, you'll have to compile your own version of
hid.dll. More background on this can be found here.
How could the vendor have prevented this vulnerability?
Most DLL Hijacking vulnerabilities are introduced by the 'lazy' loading of DLL files, which relies on Windows' default DLL search order. Explicitly specifying where a required DLL is located is easy and often already helps a lot. This doesn't have to hurt portability if Windows API calls are used to obtain paths, e.g. GetSystemDirectory to get the path of the System32 folder. Even better is to check the signature of required DLLs prior to loading them; most platforms, frameworks and/or runtimes offer means to verify DLL signatures with minimal performance impact.
This DLL Hijack doesn't seem to work (anymore), why is it still included?
Luckily, vendors regularly patch vulnerable applications in order to prevent DLL Hijacking from taking place. Nevertheless, older versions will remain vulnerable; for that reason, the entry won't be deleted from this project. To help others, you may want to open a pull request updating the 'precondition' tag on this entry to make the community aware of the reduced scope.