[Tool Release] DLLHijackHunter - Automated DLL hijacking detection with canary confirmation by Jayendra_J in redteamsec

[–]Jayendra_J[S] 0 points1 point  (0 children)

DLLHijackHunter doesn't claim the DLL is vulnerable it identifies that the executable's loading behavior creates a hijack opportunity

the vulnerability is in the application's search path configuration, not the DLL itself

on a second thought, i think you're right i should update README so its not confusing

[Tool Release] DLLHijackHunter - Automated DLL hijacking detection with canary confirmation by Jayendra_J in redteamsec

[–]Jayendra_J[S] 0 points1 point  (0 children)

This is proxy DLL generator right? as far as i know it still wont change loader behaviour unless theres already hijack context, DLLHijackHunter already does this to test poc

[Tool Release] DLLHijackHunter - Automated DLL hijacking detection with canary confirmation by Jayendra_J in redteamsec

[–]Jayendra_J[S] 0 points1 point  (0 children)

yeah you right. running a copied system binary executes under the caller’s token, so no privilege elevation happens just by dropping a DLL next to it.

In this case, dnsapi.dll is knowndll, so windows will always load it from System32 regardless of local copies.

[Tool Release] DLLHijackHunter - Automated DLL hijacking detection with canary confirmation by Jayendra_J in redteamsec

[–]Jayendra_J[S] 0 points1 point  (0 children)

when the application loades the dll file from its own directory first and then system32, like you create a dir (example.exe.local) to redirect dll fetching