http://www.securityweek.com/free-tool-detects-exploits-dll-hijacking-vulnerabilities Ref.: https://hi.cybereason.com/hubfs/Siofra-Research-Tool-Cybereason.pdf
This tool looks a little too complicated to run for the ordinary user. - https://github.com/Cybereason/siofra/tree/289a7a24991a0ff079c8522808d3b2c0d790fa1d
It does look complicated. It seems to be concerned with .DLL files in the application folder. I've often thought that should be cause for concern because if you put a .DLL in an application's own folder, the application will use it, instead of the one in the windows system folder as long as it has the same name. Well, that always used to be the case. I haven't used Windows much lately.
Below is a listing of known DLL exploitation techniques. If I missed some, please feel free to add them: AppInit DLLs - https://attack.mitre.org/wiki/Technique/T1103 - All Win vers. DLL Injection - https://attack.mitre.org/wiki/Technique/T1055 - All Win vers. DLL Search Order Hijacking - https://attack.mitre.org/wiki/Technique/T1038 - All Win vers. DLL Side-Loading - https://attack.mitre.org/wiki/Technique/T1073 - All Win vers. Execution through Module Load - https://attack.mitre.org/wiki/Technique/T1129 - All Win vers. Netsh Helper DLL - https://attack.mitre.org/wiki/Technique/T1128 - All Win vers. Process Hollowing - https://attack.mitre.org/wiki/Technique/T1093 - All Win vers. Winlogon Helper DLL - https://attack.mitre.org/wiki/Technique/T1004 - XP, 2003 And even the latest ver. of .Net; Microsoft .NET Framework 4.7 DLL Hijacking - https://packetstormsecurity.com/files/143218/Microsoft-.NET-Framework-4.7-DLL-Hijacking.html
There is also "a wealth of bypass info" in the CyberReason .pdf: Bottom line - you can't 100% rely on UAC to alert you on Win binary execution.
Will read the report, and I have to admit that I never really paid much attention to this attack method. But perhaps people should indeed do so, because it does sound like an easy to pull of attack, and I'm not sure if it's easy to block via HIPS.
Came across a couple of GitHub postings for DLL hijacking in regards to UAC bypassing. The first up is: https://github.com/hjc4869/UacBypass Appears Win 10 ver. 1607+ shut this one down. Next up is: https://github.com/hfiref0x/UACME Given in the Readme is an extensive list, the majority of which are DDL hijack bypasses, by known malware and published POC's. Also given for each bypass are what Windows versions are vulnerable.
I am also going to add this Win 10 AMSI bypass which also "drives home" what CyberReason is describing. AMSI is being used to monitor script execution in Win 10 by Windows Defender. https://redmondmag.com/Articles/2016/10/01/Dissecting-Windows-10-Security.aspx?Page=1
Here is an interesting article about the Graftor malware using DLL hijacking: https://www.cylance.com/graftor-variant-leveraging-signed-microsoft-executable
What is interesting about this attack is the MS utility process used played no actual part in the malicious activity performed by the .dll other than allowing it to load:
Also the Cylance article references a Microsoft TechNet article on how .dlls are loaded: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx . It is important to note that the "SafeDllSearchMode" which is enabled by default does not apply to app directory resident .dll hijacking because the first directory searched is:
Crap. Another command line program. I won't waste my time with all the hundreds of modes you have to manually type into this thing. Not to say it isn't good but time consuming scans in this era are long out the door IMO
Actually, that is covered by DLL injection. However the reflective .dll injection introduced by the DoublePulsar loader, now allows for a non-reflective.dll to be used. Also this is direct .dll injection - no process hollowing performed.
Came across this SANS class that sums up nicely what CyberReason stated: https://samsclass.info/126/ppt/ch11.pdf -EDIT- The DLL vulnerability detector CyberReason developed is nothing new. In the above SANS .pdf, refer to this section: If you search the web, you will also find like detector tools.
Micro builds, fashions, then releases this software code and the end user spends a lifetime trying to identify and curb all the hacker openings they load it up with. What's wrong with this picture?
Also, the knowsdlls and knowndlls32 registry areas that store the system .dlls used by every process can be hijacked. For those who remember the old Comodo and Matousec Leak Tests, they had tests for this and they in most cases were the hardest to pass: http://resources.infosecinstitute.com/dll-hijacking-attacks-revisited/ BTW - this InfoSec article references a GitHub dll hijack detector utility here: https://github.com/adamkramer/dll_hijack_detect/releases
Not to steer too far off but from the same maker someone care to compile this? I can see where checking Handles is a good choice to measure for malware/ransomwarex Haven't checked lately but maybe process hacker has a plugin that could work the same or nearly. https://github.com/adamkramer/handle_monitor/releases
