Skip to main content

Auto_DLL_Hijack_Suite_GUI

 This project provides a suite of two Python-based GUI tools designed to automate and streamline the process of discovering and testing potential DLL hijacking vulnerabilities in Windows applications.

Overview

This project provides a suite of two Python-based GUI tools designed to automate and streamline the process of discovering and testing potential DLL hijacking vulnerabilities in Windows applications. It leverages Sysinternals Process Monitor (Procmon) for data collection and provides a framework for testing identified hijack points with user-selected payloads.

Many applications attempt to load Dynamic Link Libraries (DLLs) without specifying a full path. If these DLLs are not found in standard locations, an attacker might be able to place a malicious DLL with the same name in a location that the application searches earlier (e.g., the application’s own directory if it has weak permissions), leading to the malicious DLL being loaded and executed. Manually identifying all such “NAME NOT FOUND” DLLs and testing each one for hijackability can be a tedious and time-consuming process. This suite aims to automate these steps.

The Suite Consists of Two Main Tools:

Procmon Capture GUI (ProcmonAutoCaptureGUI.exe):

  • Automates the configuration and execution of Process Monitor (Procmon) to capture file system events from a target application.
  • Filters Procmon output to identify DLLs that the target application attempts to load but result in a “NAME NOT FOUND” status.
  • Saves these potential hijack candidates (DLL names and paths) into a structured CSV file (e.g., output.csv).

Hijack Exploiter GUI (DLLHijackExploiterGUI.exe):

  • Parses the CSV file generated by the Procmon Capture GUI.
  • Allows the user to select one or more custom payload DLLs.
  • Systematically attempts to place the selected payload (renamed to the missing DLL’s name) into the identified directories.
  • Launches the target application to trigger the potential hijack.
  • Includes features for managing test execution, such as pausing, resuming, and stopping.




Problem Solved

  • This suite addresses the following challenges in DLL hijacking vulnerability research:
  • Time-Consuming Manual Analysis: Manually running Procmon, sifting through thousands of events, and identifying all “NAME NOT FOUND” DLLs for a target application is laborious.
  • Inefficient Testing: Manually copying, renaming, and testing multiple payloads against numerous potential hijack locations is error-prone and slow.
  • Missed Opportunities: Testers might focus only on a few obvious “NAME NOT FOUND” DLLs, potentially missing less common but still exploitable ones. This tool encourages testing a broader set of candidates.
  • Privilege Context: Helps differentiate between vulnerabilities exploitable by a normal user (if they have write access to a directory in the DLL search path) versus those requiring administrative privileges.

How to Use

Part 1: Data Collection (ProcmonAutoCaptureGUI.exe)

  • Run the ProcmonAutoCaptureGUI.exe.
  • Use the GUI to browse for the target executable you want to analyze.
  • Set the desired capture duration.
  • Specify the output CSV filename (default: output.csv).
  • Click “Start Procmon Capture & Generate CSV”.
  • The script will run Procmon, launch your target app, collect data, filter it, and save the results to the specified CSV file.

Part 2: Exploitation Testing (DLLHijackExploiterGUI.exe)

  • Ensure your custom payload DLLs (e.g., calcsigned.dll, notepad.dll) are in a Payloads subdirectory next to HijackExploiterGUI.py.
  • Run the DLLHijackExploiterGUI.exe.
  • Select verbosity and inter-DLL delay.
  • Browse for the output.csv (or custom named CSV) generated in Part 1.
  • Browse for the same target executable analyzed in Part 1.
  • Select one or more payloads from the list.
  • If running as Admin, confirm if you wish to proceed with admin-level tests.
  • Click “Start Exploitation”.
  • Monitor the GUI log and any payload actions (e.g., calc/notepad appearing).
  • Use “Pause”/”Resume” and “Stop” as needed.
  • Check dll_hijack_gui_log.txt for detailed logs.

Download:https://github.com/crazywifi/Auto_DLL_Hijack_Suite_GUI/tree/main

Disclaimer

This tool is intended for security research, penetration testing, and educational purposes only. Use it responsibly and only on systems you have explicit permission to test. The creator is not responsible for any misuse or damage caused by this tool. Always ensure your payload DLLs are safe and intended for testing environments.

Antivirus / Windows Defender Warnings (False Positives)

Please be aware: Due to the nature of this tool and the actions it performs, it is highly likely that Windows Defender or other antivirus/EDR solutions will flag the compiled executables (or even the Python scripts) as potentially malicious (e.g., Trojan, PUA — Potentially Unwanted Application, Generic Malware).

Why does this happen?

  • Antivirus software uses various detection methods, including:
  • Heuristics: The tool performs actions that, while legitimate for security testing and research in this context, are also common in actual malware:
  • Launching Processes: It programmatically starts Procmon64.exe and the target application being tested using subprocess.
  • Process Inspection: It uses libraries like psutil to list loaded DLLs in other processes and check parent-child relationships.
  • File Manipulation: It copies payload DLLs into application directories and later removes them (shutil, os.remove).
  • Potentially Suspicious Payloads: If using payloads that perform network callbacks (curl, reverse shells) or modify the system significantly, these actions themselves are inherently suspicious.
  • Packed Executables (if using — onefile with PyInstaller): Single-file executables created by PyInstaller work by unpacking themselves into a temporary location before running. This technique is also used by malware packers to hide malicious code, making AV engines suspicious of any such packer behavior. (Note: Even — onedir mode might trigger flags due to the bundled Python components or script behavior).
  • Lack of Code Signing: The executables are not digitally signed by a trusted Certificate Authority. Unsigned executables originating from the internet or unofficial sources are treated with higher suspicion by security software.
  • Low Reputation: As a specialized tool, it likely doesn’t have the widespread use and established reputation that allows AVs to trust it automatically.

What to do if it’s flagged:

  • Verify the Source: Ensure you downloaded the code/executable directly from this official GitHub repository or built it yourself from the source code provided here. Do not run executables from untrusted sources.
  • Submit as False Positive: If you believe the detection is incorrect, please submit the flagged file to your antivirus vendor for analysis (e.g., Microsoft Defender File Submission portal). This helps improve their detection accuracy.

Comments

Popular posts from this blog

Free Cybersecurity Certifications

Introduction to Cybersecurity Cybersecurity Essentials Networking Essentials Android Bug Bounty Hunting: Hunt Like a Rat Ethical Hacking Essentials (EHE) Digital Forensics Essentials (DFE) Network Defense Essentials (NDE) Introduction to Dark Web, Anonymity, and Cryptocurrency AWS Skill Builder Introduction to Cybersecurity Building a Cybersecurity Toolkit Cyber Aces Free Cyber Security Training Course Introduction to Information Security Penetration Testing - Discovering Vulnerabilities

Is your webcam exposed on the internet and everyone enjoying your personal moments? | How to check webcam or security camera is exposed on the internet or not?

Nowadays we start using many technology devices in our homes. Many people are installing CCTV or security cameras in their houses, private rooms, offices, private places, etc for security purposes and monitoring, but many of them don't know how to configure that device securely. So let's talk about CCTV and security cameras only.  What do most CCTV/Security camera users believe? Most users believe that using a strong username and password on a camera administrative page protects them. (Partially true in the case of online cameras) Example: Why it is partially true? It's partially true because you are protecting only the camera administrative page which is also an important part. Still, you are not protecting the protocol used to control streaming media servers (Real-Time Streaming Protocol ( RTSP )). I have seen many online webcams whose administrative page is secured by strong credentials, but they forget to secure the RTSP protocol which gives me access to the streaming ...

Web Application Security Testing (WAPT) Interview Questions

Let's Contribute All Together For Creating a Questions Dump What are the vulnerabilities you have to test in the Login form, Payment gateway? What is clickjacking? What is the mitigation of clickjacking? What is CSRF? How to mitigate CSRF? Let's take an example, If a developer implements a CSRF token in a cookie, will it mitigate the CSRF issue? Is it possible to mitigate the CSRF by header? If yes why, if No why? If the data is in JSON format, how you will check the CSRF issue and what are the ways of exploitation? Where to implement the CSRF token and why? If the client doesn't want to change the UI or doesn't want to implement the CSRF tokens, and headers then what mitigation you recommended to the client for CSRF? What is the problem with the per-request token? Is login CSRF possible? Explain login CSRF? Have you ever exploited it? What is the mitigation for login CSRF? Suppose, in an application csrf token is implemented in each request and every request, except th...