ImpulsiveDLLHijack: automates the process of discovering and exploiting DLL Hijacks

ImpulsiveDLLHijack

C# based tool which automates the process of discovering and exploiting DLL Hijacks in target binaries. The Hijacked paths discovered can later be weaponized during RedTeam Operations to evade EDR’s.

Methodological Approach :

The tool basically acts on automating the following stages performed for DLL Hijacking:

• Discovery – Finding Potentially Vulnerable DLL Hijack paths
• Exploitation – Confirming whether the Confirmatory DLL was been loaded from the Hijacked path leading to a confirmation of 100% exploitable DLL Hijack!

Discovery Methodology :

• Provide Target binary path to ImpulsiveDLLHijack.exe
• Automation of ProcMon along with the execution of Target binary to find Potentially Vulnerable DLL Hijackable paths.

Exploitation Methodology :

• Parse Potentially Vulnerable DLL Hijack paths from CSV generated automatically via ProcMon.
• Copy the Confirmatory DLL (as per the PE architecture) to the hijack paths one by one and execute the Target Binary for a predefined time period simultaneously.
• As the DLL hijacking process is in progress following are the outputs which can be gathered from the Hijack Scenario:
  • The Confirmatory DLL present on the potentially vulnerable Hijackable Path is loaded by the Target Binary we get the following output on the console stating that the DLL Hijack was successful – DLL Hijack Successful -> DLLName: | <Target_binary_name>
  • The Confirmatory DLL present on the potentially vulnerable Hijackable Path is not loaded by the Target Binary we get the following output on the console stating that the DLL Hijack was unsuccessful – DLL Hijack Unsuccessful -> <DLL_Path>

  Entry Point Not Found Scenarios:

  • The Confirmatory DLL present on the potentially vulnerable Hijackable Path is not loaded by the Target Binary as the Entry Point of the DLL is different from our default entry point “DllMain” throwing an error – “Entry Point Not Found”, we get the following output on the console stating that the DLL Hijack was hijackable if the entry point was correct -> DLL Hijack Successful -> [Entry Point Not Found – Manual Analysis Required!]: <Hijack_path>
  • The Confirmatory DLL present on the potentially vulnerable Hijackable Path is executed by the Target Binary even after the Entry Point of the DLL is different from our default entry point “DllMain” throwing an error “Entry Point Not Found”, we get the following output on the console stating that the DLL Hijack was a success even after the entry point was not correct -> DLL Hijack Successful -> [Entry Point Not Found]: <Hijack_path>

Note: The “Entry Point not found” Error is been handled by the code programmatically no need to close the MsgBox manually 🙂 # Rather this would crash the code further****

• Once the DLL Hijacking process is completed for every Potentially Vulnerable DLL Hijack path we get the final output on the console as well as in a text file (C:\DLLLogs\output_logs.txt) in the following format:
  • <DLLHijack_path> –> DLL Hijack Successful (if the Hijack was successful)
  • <DLLHijack_path> –> DLL Hijack Unsuccessful (if the Hijack was unsuccessful)
  • <DLLHijack_path> –> DLL Hijack Successful [Entry Point Not Found – Manual Analysis Required] (if the Entry point was not found but can be successful after manual analysis)
  • <DLLHijack_path> –> DLL Hijack Successful [Entry Point Not Found] (if the hijack was successful even after the entry point was not found)
  • <DLLHijack_path> –> Copy: Access to Path is Denied (Access denied)

**These Confirmed DLL Hijackable paths can later be weaponized during a Red Team Engagement to load a Malicious DLL Implant via a legitimate executable (such as OneDrive, Firefox, MSEdge, “Bring your own LOLBINs” etc.) and bypass State of the art EDR’s as most of them fail to detect DLL Hijacking as assessed by George Karantzas and Constantinos Patsakis as mentioned in there research paper: https://arxiv.org/abs/2108.10422

Install & Use